Dalam hal pengiriman scrum, orang biasanya mengharapkan eksekusi rilis setelah sprint berakhir. Ini berarti langsung setelah presentasi demo yang sukses ke klien.
Tapi saya selalu bertanya-tanya bagaimana ini bisa menjadi ekspektasi otomatis. Apalagi jika Anda mempertimbangkan kemungkinan kegiatan di bawah ini yang harus terjadi sebelum atau di sampingnya.
- Kembangkan dan selesaikan semua cerita dalam sprint. Beberapa cerita mungkin selesai lebih cepat, tetapi sering kali, ceritanya selesai tepat sebelum akhir sprint. Bahkan mungkin setelah presentasi demo, terbuka di sini.
- Lakukan semua pengujian terjadwal atas konten sprint untuk memastikan kode yang akan dirilis sudah siap produksi.
- Mengejar bug yang ditemukan dan memperbaikinya tepat waktu sebelum rilis terjadi.
- Pastikan pipeline penerapan diperbarui dengan konten terbaru dan pipeline itu sendiri dapat diandalkan untuk dijalankan.
- Jalankan pipeline di semua lingkungan yang relevan untuk membawanya ke status terbaru dari kode serta perspektif data.
- Persiapkan catatan rilis dan komunikasikan dengan klien tentang dampak rilis dan apa yang sebenarnya akan berubah setelahnya.
- Jika relevan, sinkronkan dengan tim scrum paralel lainnya untuk memastikan konten yang bergantung akan dirilis secara bersamaan. Tidak boleh ada yang terlewatkan untuk memastikan konten rilis Anda berfungsi seperti yang diharapkan.
- Di atas semua ini, ikuti semua upacara scrum. Tidak hanya terkait dengan sprint saat ini tetapi juga yang ditargetkan untuk sprint berikutnya (misalnya, sesi penyempurnaan cerita).
Sekarang bayangkan sprint memiliki dua minggu.
Kegiatan rilis sendiri membutuhkan waktu dan orang untuk menyelesaikannya. Tapi tidak bisa terlalu banyak. Tepat setelah hari terakhir sprint datang langsung hari pertama sprint berikutnya, dan lingkaran akan dimulai lagi.
Apakah ekspektasi pelepasan setelah setiap sprint masih terlihat begitu otomatis?
Rilis Pemrosesan Konten
Jika semua proses dalam sprint diotomatisasi, ada kemungkinan untuk hanya “menarik pelatuk” dan menginstal versi kode terbaru ke dalam produksi di akhir setiap sprint. Masalahnya adalah saya tidak pernah mengalami kondisi tim scrum yang begitu sempurna.
Jika ini benar-benar terjadi di beberapa bisnis swasta skala kecil, saya sangat iri dengan mereka. Namun kenyataan di dunia korporat adalah bahwa tim scrum tidak akan mencapai tingkat kedewasaan tersebut. Sebaliknya, proses rilis biasanya terkait dengan aktivitas yang memakan waktu yang mencapai sebagian besar sprint berikutnya, yang memengaruhi sprint tersebut dari perspektif konten dan semua metrik. Pelepasan hanyalah tindakan yang membuat stres yang tidak ingin dilakukan oleh siapa pun di tim.
Jadi saya setelah menemukan skenario terbaik berikutnya untuk menangani rilis.
Kesimpulannya adalah membuat setiap detik sprint menjadi Release Sprint. Inilah artinya.
Versi Kode Terpisah Untuk Rilis Berikutnya
Ini tentang menangani cabang terpisah di repositori GIT. Ada banyak cara untuk mendekati masalah yang sama, dan semuanya bisa berhasil. Namun untuk tujuan artikel ini, saya akan membuat hal-hal sederhana untuk menunjukkan pendekatan dan dampaknya.
Untuk meminimalkan dampak aktivitas pengembangan yang sedang berlangsung, penting untuk memisahkan konten untuk rilis berikutnya ke dalam cabang terpisah. Sebut saja Cabang Rilis. Dengan ini, berikut ini akan diselesaikan:
- Tim pengembangan dapat melanjutkan aktivitas dan bergabung ke dalam cerita baru cabang utama tanpa gangguan.
- Tidak ada risiko konten rilis akan terpengaruh oleh modifikasi kode yang tidak terduga dari tim scrum.
- Kegiatan pengujian dapat dilakukan di ruang yang terisolasi. Di sini, hanya perubahan yang diperlukan untuk menyelesaikan pengujian yang akan diperkenalkan.
- Karena saluran rilis hanya akan menyebarkan konten dari Cabang Rilis ke dalam produksi, kami memiliki proses yang jelas dan kontrol penuh atas konten yang akan dirilis. Tidak mungkin terjadi beberapa komit tak terduga ke dalam cabang Git akan merusak kode yang sudah diuji.
Jadi kesampingkan saja konten rilis berikutnya dan biarkan ia menyimpulkan ke keadaan stabil, siap untuk dirilis.
Atur Waktu Rilis Agar Bekerja Berulang Kali
Saya menyerah pada ambisi untuk melakukan pelepasan setelah setiap sprint selesai. Sangat jelas ini tidak akan memiliki peluang untuk bekerja. Setidaknya tidak dengan efek samping seperti:
- berdampak pada konten pengembangan sprint berikutnya,
- tidak dapat menstabilkan konten rilis,
- mengejar semua kegiatan pengujian yang diperlukan, dll.
Jadi tujuannya adalah untuk mengeksekusi rilis pada akhir setiap sprint kedua. Itu akan menyiratkan hal berikut:
- Rilis akan selalu berisi cerita dari dua sprint terakhir yang sudah selesai. Karena rilis dilakukan dalam sprint saat ini (sprint aktif), konten sprint ini belum termasuk dalam rilis.
- Ada waktu satu sprint penuh untuk menyelesaikan aktivitas pengujian dan perbaikan bug yang diperlukan.
- Pemilik rilis memiliki cukup waktu untuk mengumpulkan informasi yang relevan dengan rilis (test case, catatan rilis, dll.) dengan sprint non-rilis. Dengan cara ini, mereka pada dasarnya dapat beroperasi secara mandiri dan membuat tim pengembangan lainnya mengerjakan cerita baru.
- Jika ditemukan bug, pemilik Rilis dapat dengan cepat terhubung dengan pengembang konkret untuk memperbaiki masalah dan kembali ke konten sprint saat ini. Jadi harus selalu ada persentase waktu yang dialokasikan dari kapasitas tim untuk mendukung perbaikan bug ini. Berapa banyak tepatnya yang dapat ditemukan dari waktu ke waktu.
Jelas pengguna tidak akan mendapatkan konten sprint terbaru di dalam rilis terbaru. Namun seiring waktu, ini akan menjadi tidak relevan. Mereka akan mendapatkan dua sprint konten dengan setiap rilis berikutnya, setelah setiap sprint kedua.
Ini terlihat seperti kompromi yang baik antara kepuasan pengiriman yang cepat dan mengikuti aktivitas scrum tanpa gangguan yang signifikan.
Jalankan Penerapan Rilis
Saat pengujian, perbaikan bug, dan aktivitas kesiapan jalur pipa berhasil diselesaikan, ini merupakan proses yang cukup mudah untuk mengeksekusi jalur pipa produksi dan menyelesaikan rilis ke produksi.
Karena diterapkan dari cabang yang berdiri sendiri, ini pada dasarnya dapat menjadi aktivitas yang tidak diperhatikan dan tidak terlihat. Tidak ada yang perlu tahu. Jika demikian, ini adalah implementasi terbaik dari penyebaran rilis.
Prasyarat untuk itu adalah membuat pipa DevOps otomatis yang solid. Tidak hanya digunakan untuk menyebarkan ke lingkungan produksi tetapi juga ke semua lingkungan tingkat rendah lainnya. Ini mungkin termasuk dev, kotak pasir, pengujian, jaminan kualitas, lingkungan kinerja, dll. Ini akan menjadi satu klik untuk menerapkan semua solusi untuk setiap lingkungan.
Pelepasan seharusnya tidak menjadi titik sakit atau stres. Atau mimpi buruk yang ditakuti semua orang dan terus mempersiapkan diri untuk hari itu selama satu minggu. Tidak – sebagai gantinya, jika tidak ada yang memperhatikan ini sama sekali, ini adalah tanda terbaik dari rilis yang sukses.
Menggabungkan Kembali Cabang Rilis Menjadi Cabang Pengembangan
Cabang Rilis sekarang berisi beberapa konten khusus yang tidak ada di cabang pengembangan reguler yang sedang berlangsung. Ini terkait dengan semua perbaikan yang diterapkan selama periode pengujian. Konten ini perlu digabungkan kembali ke cabang pengembangan untuk memastikan perbaikan akan tetap ada bahkan setelah rilis berikutnya.
Pada saat itu, Cabang Rilis terbaru berfungsi sebagai kode produksi darurat yang siap diterapkan kembali. Jika masalah prioritas tinggi yang mendesak perlu diselesaikan segera setelah penerapan produksi, cabang ini dapat digunakan. Sangat mudah untuk mengambil kode ini dan menerapkan perbaikan di dalamnya. Ini masih merupakan salinan persis dari kode produksi saat ini tanpa konten baru yang belum dirilis.
Terakhir, setelah periode pengujian baru dimulai, cabang rilis sebelumnya dapat dihapus dan diganti dengan yang baru. Yang baru dibuat lagi sebagai salinan dari cabang pengembangan saat ini.
Tetapkan Rilis Reguler
Dan sekarang kami memilikinya 😀—proses yang solid untuk mendekati rilis. Satu-satunya hal yang hilang adalah membuat komitmen untuk menjaganya tetap teratur. Dalam hal ini, setelah setiap sprint kedua.
Dengan menjaganya tetap teratur, kami benar-benar menetapkan landasan untuk membuatnya lebih mudah dicapai, terutama karena:
- Jika rilis setelah waktu yang tidak terlalu lama, tidak banyak konten baru untuk dipasang ke produksi. Kenaikannya kecil dan dianggap stabil.
- Sekarang begitu banyak konten baru berarti tidak terlalu banyak aktivitas pengujian dan pembuatan kasus uji. Lebih sedikit komunikasi, panggilan kesepakatan, dan kolaborasi dengan pemangku kepentingan tentang apa saja yang perlu divalidasi ulang. Mereka juga akan setuju bahwa tidak lama lagi sejak rilis terakhir. Jadi kurang penting dimasukkan ke dalam tindakan ini.
- Tim akan terbiasa dengan siklus ini; seiring waktu, itu akan menjadi bagian alami dari tim.
- Sebagai efek samping, lingkungan pengembangan dan pengujian sering mendapatkan penyegaran data. Itu tetap diperlukan untuk setiap siklus pengujian baru. Jadi itu bukan sekadar kegiatan terjadwal yang harus dilakukan. Sebaliknya, tindakan yang sudah menjadi bagian dari proses yang ditetapkan. Perubahan cara pandang ini sangat berpengaruh pada atmosfir tim. Orang tidak akan percaya itu.
Kesimpulan
Bab ini menyimpulkan posting saya sebelumnya tentang topik siklus hidup scrum. Juga, ini tentang apa yang terbukti berhasil dalam kehidupan nyata.
Seringkali, tim memulai dengan cara yang gesit dan melakukan banyak hal dengan salah. Kemudian mereka berevolusi, pada akhirnya, dan mulai melakukan berbagai hal secara berbeda. Seri ini dapat membantu beberapa dari mereka untuk melakukan perubahan ini lebih cepat.
Pendekatan rilis ini juga bukan satu-satunya yang bisa diterapkan, juga bukan tanpa masalah. Itu akan tetap ada, dan tim harus menghadapinya. Kemudian tingkatkan apa yang mungkin dan lupakan apa yang tidak masuk akal.
Tapi dari yang saya tahu, pendekatan ini, meski sederhana, membuktikan bahwa perubahan itu mungkin. Dari sprint yang kacau dan tidak dapat diprediksi hingga pengiriman yang lebih stabil dengan rilis reguler yang dapat diandalkan dan direncanakan. Dan itu tidak memerlukan metodologi khusus yang sangat rumit – hanya aturan sederhana dan kemauan untuk mengikuti rencana.
