Hentikan saluran atau pompa pipa Anda, yo

Jika rilis Anda cepat, otomatis, dan andal, Anda mungkin tidak membaca artikel ini.

Sebelumnya, proses rilis kami adalah manual, lambat, dan buggy.
Kami gagal sprint setelah sprint, karena kami tidak punya waktu untuk membuat dan mengeluarkan fitur untuk Tinjauan Sprint berikutnya. Kami membenci rilis kami. Seringkali mereka bertahan selama tiga hingga empat hari.

Dalam artikel ini, kami akan menjelaskan praktik Stop the Line, yang membantu kami fokus memperbaiki masalah pipa tata letak. Hanya dalam tiga bulan, kami berhasil meningkatkan tingkat penyebaran sebesar 10 kali. Hari ini, penyebaran kami sepenuhnya otomatis, dan pelepasan monolith hanya memakan waktu 4-5 jam.

Hentikan Garis. Latihan ditemukan oleh tim

Saya ingat bagaimana kami menghasilkan Stop the Line. Dalam retrospektif umum, kami membahas rilis panjang yang mencegah kami mencapai tujuan sprint. Salah satu pengembang kami menyarankan:

- [Sergey] Mari kita batasi volume rilis. Ini akan membantu kami menguji, memperbaiki bug, dan menyebarkan lebih cepat.
- [Dima] Bisakah kita memperkenalkan batasan pada pekerjaan yang sedang berjalan (batas WIP)? Misalnya, segera setelah kami menyelesaikan 10 tugas, kami menghentikan pengembangan.
- [Pengembang] Tapi tugasnya mungkin berbeda ukurannya. Ini tidak akan menyelesaikan masalah rilis besar.
- [I] Mari kita perkenalkan pembatasan berdasarkan durasi rilis, dan bukan pada jumlah tugas. Kami akan menghentikan pengembangan jika rilisnya memakan waktu terlalu lama.

Kami memutuskan bahwa jika rilis berlangsung lebih dari 48 jam, maka kami menyalakan lampu yang berkedip dan menghentikan pekerjaan semua tim pada fitur bisnis monolith. Semua tim yang bekerja pada monolith harus menghentikan pengembangan dan fokus pada mendorong rilis saat ini dalam penjualan atau menghilangkan alasan yang menyebabkan keterlambatan rilis. Ketika rilis macet, tidak masuk akal untuk membuat fitur baru, karena mereka masih akan segera hadir. Pada saat ini, dilarang untuk menulis kode baru, bahkan di cabang terpisah.

Kami juga memperkenalkan "Stop the Line Board" pada flip chart sederhana. Di atasnya, kami menulis tugas yang membantu mendorong rilis saat ini, atau membantu menghindari alasan penundaannya.

Tentu saja, Stop The Line bukanlah keputusan yang mudah, tetapi praktik ini merupakan langkah penting menuju pengiriman berkelanjutan dan DevOps asli.

Mari kita lepaskan dengan cepat: dari masalah ke praktik Stop the line yang disesuaikan

Rasa sakit rilis lambat. Mengapa mereka begitu lama? Analisis

Extreme Programming (XP) memiliki aturan emas: jika ada yang sakit, lakukan sesering mungkin. Rilis kami selalu menyebalkan. Kami menghabiskan beberapa hari untuk menyebarkan lingkungan pengujian, mengembalikan database, menjalankan tes (biasanya beberapa kali), mencari tahu mengapa mereka jatuh, memperbaiki bug dan, akhirnya, lepaskan.

Sprint berlangsung 2 minggu, dan rilis bergulir selama tiga hari. Untuk dapat merilisnya sebelum Tinjauan Sprint pada hari Jumat, Anda harus memulai rilis pada hari Senin dengan cara yang baik. Ini berarti bahwa kami bekerja dengan tujuan hanya berlari 50% dari waktu. Dan jika kita bisa melepaskan setiap hari, maka masa kerja produktif akan tumbuh menjadi 80-90%.

Rata-rata rilis kami biasanya memakan waktu dua hingga tiga hari. Pada awalnya, enam tim mengerjakan kode di cabang dev umum (dan dengan pertumbuhan perusahaan, jumlah tim meningkat menjadi sembilan). Tepat sebelum rilis, kami mengunyah cabang rilis. Sementara cabang ini sedang diuji dan mundur, tim terus berkembang di cabang pengembang umum. Sebelum cabang rilis mencapai penjualan, tim akan menulis kode yang cukup banyak.

Semakin banyak perubahan dalam kenaikan, semakin besar kemungkinan bahwa perubahan yang dilakukan oleh tim yang berbeda akan saling mempengaruhi, yang berarti semakin hati-hati peningkatan harus diuji, dan semakin banyak waktu yang dibutuhkan untuk melepaskannya. Ini adalah siklus yang memperkuat diri sendiri (lihat Gambar 2). Semakin banyak perubahan dalam rilis (rilis "kuda"), semakin lama waktu regresi. Semakin lama waktu regresi, semakin banyak waktu antara rilis dan lebih banyak perubahan yang dilakukan tim sebelum rilis berikutnya. Kami menyebutnya "kuda melahirkan kuda". Diagram CLD berikut (Diagram Lingkaran Penyebab) menggambarkan hubungan ini:


Fig. 2. Diagram CLD: rilis lama menyebabkan rilis lebih lama

Otomasi regresi dengan perintah QA

Awalnya kami memutuskan untuk menyingkirkan pengujian regresi manual, tetapi jalan menuju ini adalah yang panjang dan sulit. Dua tahun lalu, regresi manual Dodo IS berlangsung seminggu penuh. Kemudian kami memiliki seluruh tim penguji manual yang menguji fitur yang sama di 10 negara minggu demi minggu. Anda tidak akan iri dengan pekerjaan itu.

Pada Juni 2017, kami membentuk tim QA. Tujuan utama tim adalah untuk mengotomatiskan regresi operasi bisnis yang paling penting: menerima pesanan dan produk manufaktur. Segera setelah kami memiliki cukup tes untuk mulai mempercayai kami, kami benar-benar meninggalkan pengujian manual. Tetapi ini hanya terjadi 1,5 tahun setelah kami memulai otomatisasi regresi. Setelah itu, kami membubarkan tim QA, dan tim QA bergabung dengan tim pengembangan.

Namun, tes UI memiliki kelemahan yang signifikan. Karena mereka bergantung pada data aktual dalam database, data ini harus dikonfigurasi. Satu pengujian dapat merusak data untuk pengujian lainnya. Tes mungkin gagal tidak hanya karena beberapa logika rusak, tetapi juga karena jaringan yang lambat atau data yang usang dalam cache. Kami harus menghabiskan banyak upaya untuk menyingkirkan tes yang berkedip dan membuatnya dapat diandalkan dan dapat diproduksi kembali.

Satu langkah untuk Menghentikan garis. Inisiatif #IReleaseEveryDay

Kami membuat komunitas #IReleaseEveryDay yang berpikiran sama dan bertukar pikiran tentang cara mempercepat pipa penyebaran. Tindakan pertama adalah sebagai berikut:

• kami secara signifikan mengurangi serangkaian tes UI dengan membuang tes yang berulang dan tidak perlu. Ini mengurangi waktu pengujian beberapa puluh menit;
• Kami secara signifikan mengurangi waktu untuk mengatur lingkungan karena pemulihan awal dari database dan enkripsi data. Sebagai contoh, sekarang kami membuat salinan cadangan dari database di malam hari, dan segera setelah rilis dimulai, kami mengubah lingkungan pengujian ke database cadangan dalam beberapa detik.

Berkat solusi di atas, kami mengurangi waktu rilis rata-rata, tapi itu masih lama sekali. Saatnya untuk perubahan sistem.

Bagaimana jika ...

Kami memperkenalkan aturan bahwa jika rilis berlangsung lebih dari 48 jam, maka kami menyalakan lampu berkedip dan menghentikan pekerjaan semua tim pada fitur bisnis monolith. Semua tim yang mengerjakan monolith harus menghentikan pengembangan dan fokus pada peluncuran rilis saat ini untuk penjualan atau menghilangkan alasan yang menunda rilis.

Ketika rilis macet, tidak masuk akal untuk membuat fitur baru, karena mereka masih akan segera hadir. Pada saat ini, dilarang untuk menulis kode baru, bahkan di cabang terpisah. Prinsip ini dijelaskan dalam artikel Pengiriman Berkelanjutan Martin Fowler: "Jika terjadi masalah dengan tata letak, tim Anda harus memprioritaskan solusi dari masalah ini di atas dengan mengerjakan fitur baru."

Rombongan flasher

Selama Stop the line, flasher oranye menyala di kantor. Siapa pun yang datang ke lantai tiga, tempat pengembang Dodo IS bekerja, melihat sinyal visual ini. Kami memutuskan untuk tidak membuat pengembang kami gila dengan suara sirene dan hanya menyisakan lampu berkedip yang menjengkelkan. Jadi dikandung. Bagaimana kita bisa merasa nyaman ketika rilis sedang bermasalah?

Fig. 3. Blinker Hentikan Garis

Perlawanan tim dan sabotase kecil

Pada awalnya Stop the Line menyukai semua tim, karena itu menyenangkan. Semua orang senang sebagai anak-anak dan meletakkan foto-foto lampu darurat kami. Tetapi ketika terbakar 3-4 hari berturut-turut, itu menjadi tidak lucu. Suatu hari, salah satu tim melanggar peraturan dan mengunggah kode ke cabang dev selama Stop the Line untuk menyelamatkan tujuan lari cepatnya. Paling mudah untuk melanggar aturan jika itu menghentikan Anda dari bekerja. Ini adalah cara cepat dan kotor untuk melakukan fitur bisnis, mengabaikan masalah sistem.

Sebagai Scrum Master, saya tidak tahan dengan pelanggaran aturan, jadi saya mengangkat masalah ini secara retrospektif umum. Kami memiliki percakapan yang sulit. Sebagian besar tim sepakat bahwa aturan itu berlaku untuk semua orang. Kami sepakat bahwa setiap tim harus mematuhi aturan, bahkan jika itu tidak setuju dengan mereka. Dan pada saat yang sama tentang bagaimana Anda dapat mengubah aturan tanpa menunggu retrospektif berikutnya.

Apa yang tidak berhasil sebagaimana dimaksud?

Awalnya, pengembang tidak fokus pada pemecahan masalah sistem dengan penyebaran pipelint. Ketika rilis macet, alih-alih membantu menghilangkan penyebab keterlambatan, mereka lebih memilih untuk mengembangkan layanan mikro yang tidak tunduk pada aturan Stop the Line. Layanan mikronik bagus, tetapi masalah monolit tidak akan menyelesaikan sendiri. Untuk mengatasi masalah ini, kami memperkenalkan simpanan Stop The Line.

Beberapa solusi adalah perbaikan cepat yang menyembunyikan masalah daripada menyelesaikannya. Sebagai contoh, banyak tes diperbaiki dengan menambah waktu tunggu atau menambah pelatihan ulang. Salah satu tes ini berjalan selama 21 menit. Tes mencari karyawan yang paling baru dibuat dalam tabel tanpa indeks. Alih-alih mengoreksi logika permintaan, programmer menambahkan 3 coba lagi. Akibatnya, tes lambat menjadi lebih lambat. Ketika Stop The Line muncul dengan tim pemilik yang berfokus pada masalah pengujian, selama tiga sprint berikutnya mereka berhasil mempercepat pengujian kami 2-3 kali.

Bagaimana perilaku tim setelah berlatih Stop the Line?

Sebelumnya, hanya satu tim yang memiliki masalah dengan rilis - yang mendukung rilis. Tim berusaha untuk menyingkirkan tugas yang tidak menyenangkan ini sesegera mungkin, alih-alih berinvestasi dalam perbaikan jangka panjang. Misalnya, jika tes pada lingkungan uji telah jatuh, mereka dapat dimulai kembali secara lokal dan jika tes lulus, lanjutkan rilis. Dengan diperkenalkannya Stop The Line, tim sekarang memiliki waktu untuk menstabilkan tes. Kami menulis ulang kode persiapan pengujian, mengganti beberapa tes UI dengan tes API, dan menghapus batas waktu yang tidak perlu. Sekarang hampir semua tes lulus dengan cepat dan di lingkungan apa pun.

Sebelumnya, tim tidak secara sistematis terlibat dalam utang teknis. Kami sekarang memiliki tumpukan peningkatan teknis yang kami analisis selama Stop the Line. Misalnya, kami menulis ulang tes pada .Net Core, yang memungkinkan kami untuk menjalankannya di Docker. Menjalankan tes di Docker memungkinkan kami menggunakan Selenium Grid untuk memaralelkan tes dan selanjutnya mengurangi waktu pelaksanaannya.

Sebelumnya, tim mengandalkan tim QA untuk pengujian dan tim infrastruktur untuk penempatan. Sekarang tidak ada yang bisa diandalkan kecuali diri mereka sendiri. Tim sendiri menguji dan merilis kode dalam Produksi. Ini asli, bukan DevOps palsu.

Evolusi metode Stop the line

Dalam retrospektif sprint umum, kami meninjau eksperimen. Selama beberapa retrospektif berikutnya, kami telah membuat banyak perubahan pada aturan Stop the Line, misalnya:

• Lepaskan saluran. Semua informasi tentang rilis saat ini adalah dalam saluran Slack yang terpisah. Saluran ini memiliki semua tim yang perubahannya termasuk dalam rilis. Di saluran ini, petugas rilis meminta bantuan.
• Majalah Rilis. Orang yang bertanggung jawab atas rilis mencatat tindakannya. Ini membantu untuk menemukan alasan keterlambatan rilis dan untuk menemukan pola.
• Aturan lima menit. Dalam lima menit setelah pengumuman Stop the Line, perwakilan tim berkumpul di sekitar lampu darurat.
• Backlog Hentikan Garis. Ada flipchart di dinding dengan backlog Stop The Line - daftar tugas yang dapat dilakukan oleh tim sementara jalur berhenti.
• Jangan memperhitungkan hari Jumat terakhir sprint. Tidak adil membandingkan dua rilis, misalnya, satu yang dimulai pada hari Senin dan yang lain dimulai pada hari Jumat. Tim pertama dapat menghabiskan dua hari penuh untuk mendukung rilis, dan selama rilis kedua akan ada banyak acara pada hari Jumat (Sprint Review, Team Retrospective, General Retrospective) dan Senin berikutnya (Perencanaan Umum dan Tim Sprint), sehingga tim Jumat memiliki waktu lebih sedikit untuk lepaskan dukungan. Rilis Jumat akan dihentikan lebih besar dari Senin. Oleh karena itu, kami memutuskan untuk mengecualikan Jumat terakhir sprint dari persamaan.
• Penghapusan hutang teknis. Setelah beberapa bulan, tim memutuskan bahwa selama pemberhentian mereka dapat mengerjakan utang teknis, dan tidak hanya mempercepat pipa penyebaran.
• Pemilik Stop the Line. Salah satu pengembang mengajukan diri untuk menjadi pemilik Stop The Line. Dia sangat tenggelam dalam alasan keterlambatan rilis dan mengelola backlog Stop the Line. Ketika garis berhenti, pemilik dapat menarik tim mana pun untuk mengerjakan elemen-elemen dari simpanan Stop the Line.
• Post mortem. Pemilik Stop the Line memegang post mortem setelah setiap pemberhentian.

Biaya kerugian

Karena Stop the Line, kami belum memenuhi beberapa tujuan sprint. Perwakilan bisnis tidak terlalu senang dengan kemajuan kami dan mengajukan banyak pertanyaan di Tinjauan Sprint. Mengikuti prinsip transparansi, kami berbicara tentang apa itu Stop the Line, dan mengapa Anda harus menunggu beberapa sprint lagi. Di setiap Sprint Review, kami menunjukkan kepada tim dan pemangku kepentingan berapa banyak uang kami yang hilang karena Stop the Line. Biaya dihitung sebagai total gaji tim pengembangan selama downtime.

• November - 2 106.000 p.
• Desember - 503 504 hal.
• Januari - 1 219 767 hal.
• Februari - 2 002 278 hal.
• Maret - 0 hlm.
• April - 0 hlm.
• Mei - 361 138 hal.

Transparansi semacam itu menciptakan tekanan yang sehat dan memotivasi tim untuk segera menyelesaikan masalah pemasangan pipa. Menyaksikan angka-angka ini, tim kami memahami bahwa tidak ada yang datang secara gratis, dan setiap Stop the Line memberi kami satu sen yang cukup.

Hasil

Bahkan, praktik Stop the Line mengubah siklus penguatan diri (Gbr. 2) menjadi dua siklus penyeimbangan (Gbr. 4). Stop the Line membantu kami fokus pada peningkatan pipa penyebaran saat terlalu lambat. Hanya dalam 4 sprint, kami:

• Turunkan 12 rilis stabil
• Mengurangi waktu pembuatan hingga 30%
• Tes UI dan API yang distabilkan. Sekarang mereka melewati semua lingkungan dan bahkan secara lokal.
• Singkirkan tes berkedip
• Mulai mempercayai tes kami.

Fig. 4. CLD chart: Menghentikan waktu rilis Saldo Line

Kesimpulan dari Scrum Masters

Stop The Line adalah contoh utama dari solusi kuat yang ditemukan oleh tim pengembangan itu sendiri. Scrum Master tidak bisa hanya mengambil dan membawa tim latihan baru yang cemerlang. Latihan hanya akan berhasil jika tim sendiri yang membuatnya. Ini membutuhkan kondisi yang menguntungkan: suasana kepercayaan dan budaya eksperimen.

Tentu saja, kepercayaan dan dukungan dari bisnis diperlukan, yang hanya mungkin dilakukan dengan transparansi penuh. Umpan balik, seperti retrospektif umum dan teratur dengan semua perwakilan tim, membantu menciptakan, menerapkan, dan memodifikasi praktik-praktik baru.

Seiring waktu, praktik Stop the Line harus membunuh dirinya sendiri. Semakin sering kita menghentikan garis, semakin banyak kita berinvestasi dalam pipa penyebaran, semakin stabil dan cepat rilis menjadi, semakin sedikit alasan untuk berhenti. Pada akhirnya, garis tidak akan pernah berhenti, kecuali kami memutuskan untuk menurunkan ambang batas, misalnya, dari 48 menjadi 24 jam. Namun, berkat praktik ini, kami telah sangat meningkatkan prosedur rilis. Tim memperoleh pengalaman tidak hanya dalam pengembangan, tetapi juga dalam pengiriman cepat nilai ke produk. Ini adalah DevOps asli.

Apa selanjutnya Saya tidak tahu. Mungkin kita akan segera meninggalkan latihan ini. Tim akan memutuskan. Tetapi jelas bahwa kami akan terus bergerak menuju Pengiriman Berkelanjutan dan DevOps. Suatu hari, impian saya untuk melepaskan monolit beberapa kali sehari akan menjadi kenyataan.