Ringkasan

  • 3 menit

Dalam modul ini, Anda menentukan pola penyebaran sebagai cara otomatis untuk meluncurkan fitur aplikasi baru dengan lancar kepada pengguna Anda. Pola penyebaran yang baik dapat membantu Anda meminimalkan waktu henti. Ini juga dapat memungkinkan Anda untuk meluncurkan fitur baru secara progresif kepada pengguna Anda.

Anda dapat memilih dari beberapa pola penyebaran. Pola penyebaran yang Anda pilih tergantung pada alasan penyebaran dan sumber daya Anda. Apakah Anda memiliki penguji kenari di tempat? Apakah Anda menggunakan peluncuran gelap dan memilih penguji yang tidak tahu bahwa mereka penguji? Jika Anda memiliki sekumpulan penguji tepercaya yang meningkat secara progresif dari set kecil ke set yang lebih besar, maka Anda dapat memilih penyebaran eksposur progresif. Atau, jika Anda ingin tahu apakah satu versi berkinerja lebih baik daripada versi lain, Anda dapat memilih pengujian A/B.

Tim Tailspin memilih untuk menerapkan pola penyebaran biru-hijau, menggunakan slot penyebaran di Azure App Service. Slot penerapan adalah aplikasi yang aktif yang memiliki nama host tersendiri. Tim dapat menukar dua slot penyebaran. Dengan bertukar, mereka dapat mendorong perubahan pada produksi secara instan. Meskipun tim belum siap untuk merilis situs web mereka ke publik, mereka telah membuktikan bahwa mereka bisa mendapatkan fitur baru kepada pengguna mereka tanpa menimbulkan waktu henti.

Sebagai bonus, dalam modul ini Anda juga belajar cara mengembalikan ke kondisi semula perubahan yang tidak diinginkan dengan membalikkan commit Git dan kemudian meneruskan perubahan yang dikembalikan melalui pipeline.

Bagaimana penilaian terhadap kinerja tim?

Dalam Menilai proses pengembangan perangkat lunak yang ada modul, Mara melakukan latihan pemetaan aliran nilai . Latihan ini membantu tim menganalisis proses siklus rilis mereka saat ini.

Ingat bahwa rasio aktivitas , atau efisiensi, adalah waktu proses dibagi dengan waktu tenggang total:

$${Rasio\ aktivitas\ =\ }{\dfrac{Waktu\ proses}{Total\ waktu\ tunggu}}$$

Tim web Tailspin awalnya menggunakan metrik ini untuk menentukan bahwa metrik tersebut efisien 23 persen.

Tim pertama-tama mengurangi beberapa inefisiensi ketika mereka menerapkan integrasi berkelanjutan (CI). Dengan menerapkan pengiriman berkelanjutan (CD), mereka sekarang telah mengurangi inefisiensi lebih jauh.

Di jalur pembelajaran sebelumnya, tim mengurangi:

  • Waktu yang diperlukan untuk menyiapkan kontrol sumber untuk fitur baru. Waktu yang diperlukan dari tiga hari menjadi nol hari.

    Tim mencapai peningkatan ini dengan berpindah dari kontrol sumber terpusat ke Git, bentuk kontrol sumber terdistribusi. Dengan menggunakan kontrol sumber terdistribusi, mereka tidak perlu menunggu file dibuka kuncinya.

  • Waktu yang diperlukan untuk mengirimkan kode ke Amita, penguji. Waktu yang diperlukan dari dua hari menjadi nol hari.

    Tim mencapai peningkatan ini dengan memindahkan proses build mereka ke Azure Pipelines. Azure Pipelines secara otomatis memberi tahu Amita saat build tersedia. Pengembang tidak perlu memperbarui spreadsheet Amita lagi untuk memberi tahu Amita.

  • Waktu yang dibutuhkan Amita untuk menguji fitur baru. Waktu yang diperlukan dari tiga hari menjadi satu hari.

    Tim mencapai peningkatan ini dengan menguji kode mereka secara unit. Mereka menjalankan pengujian unit setiap kali perubahan bergerak melalui alur build, sehingga lebih sedikit bug dan regresi mencapai Amita. Pengurangan beban kerja berarti Amita dapat menyelesaikan setiap pengujian manual lebih cepat.

Alur rilis yang Anda dan tim bangun di jalur pembelajaran ini berkurang:

  • Waktu yang diperlukan untuk memasukkan build ke tahap Test. Waktu yang diperlukan dari tiga hari menjadi satu hari.

    Tim mencapai ini dengan menggunakan pemicu terjadwal untuk menerapkan ke Test setiap hari pada pukul 03.00.

  • Waktu yang diperlukan untuk memasukkan build yang diuji ke Staging. Waktu yang diperlukan dari dua hari menjadi nol hari.

    Tim mencapai peningkatan ini dengan menambahkan tes Selenium UI, bentuk pengujian fungsi, ke tahap Test. Pengujian otomatis ini jauh lebih cepat daripada versi manual.

  • Waktu yang diperlukan untuk mendapatkan build yang disetujui dari Penahapan ke live. Waktu yang diperlukan berubah dari satu hari menjadi kurang dari satu hari.

    Tim mencapai peningkatan ini dengan menambahkan pemeriksaan persetujuan manual ke dalam alur kerja. Saat manajemen berhenti, Tim dapat merilis perubahan dari Penahapan untuk ditayangkan.

Perubahan ini mengurangi total waktu tunggu dari 22 hari menjadi 10 hari. Ketika kita mengganti angka-angka ini ke dalam persamaan:

$${Activity\ ratio\ =\ }{\dfrac{5\ days}{10\ days}}{ = 0,50}$$

Kalikan hasilnya dengan 100 persen, dan kita mendapatkan pengurangan 50 persen.

Meskipun selalu ada ruang untuk perbaikan, perubahan ini adalah kemenangan bagi tim. Pelanggan tidak hanya mendapatkan nilai lebih cepat, tim Tailspin sekarang menghabiskan lebih sedikit waktu menunggu dan lebih banyak waktu untuk melakukan apa yang paling mereka nikmati: memberikan fitur yang mereka tahu yang akan disukai pelanggan mereka.

Pelajari lebih lanjut

Gunakan sumber tambahan ini untuk mempelajari lebih lanjut tentang App Service, slot penyebaran, dan membatalkan perubahan.