Apakah perlu untuk melarang penyebaran ke produksi pada waktu-waktu tertentu? Atau gerakan #NoDeployFriday menjadi peninggalan saat tidak ada tes integrasi yang komprehensif dan penyebaran berkelanjutan?

Di tim Anda, Anda mungkin menghadapi dilema yang sama. Siapa yang benar dan siapa yang harus disalahkan? Apakah meninggalkan penyebaran pada hari Jumat merupakan strategi yang masuk akal untuk mengurangi risiko, atau apakah itu budaya buruk yang mencegah kita menciptakan sistem yang lebih baik dan lebih stabil?

Ding ding

Saya yakin bahwa para insinyur yang beruntung karena “berhubungan” kehilangan hari-hari libur mereka karena semua perubahan pada hari Jumat. Saya juga dalam situasi ini. Panggilan telepon saat Anda keluar bersama keluarga atau di tengah malam, memberi tahu Anda tentang macetnya aplikasi. Setelah Anda masuk ke komputer dan memeriksa log yang tumbuh cepat, menjadi jelas bahwa semuanya hancur oleh pengecualian yang jarang ditangani. Menjijikkan.

Analisis ini mengungkapkan bahwa untuk skenario yang menyebabkan kegagalan, tidak ada tes yang ditulis, tampaknya karena itu tidak dianggap kemungkinan. Setelah serangkaian panggilan telepon yang panjang dengan insinyur lain untuk mencari cara yang lebih baik untuk mengembalikan perubahan dan memperbaiki semuanya, sistem mulai bekerja kembali. Fuh.

Pertemuan lima alasan diadakan pada hari Senin.

" Mari kita berhenti penggelaran pada hari Jumat. Kemudian pada akhir pekan semuanya akan bekerja secara stabil, dan minggu depan kita akan waspada setelah semua jenis rilis ."

Semua orang mengangguk. Jika sesuatu tidak beroperasi sebelum tengah hari pada hari Kamis, maka menunggu sampai Senin pagi. Apakah pendekatan ini membahayakan atau membantu?


Seperti yang Anda ketahui, pernyataan Twitter seringkali sangat subjektif. Meskipun larangan rilis Jumat tampaknya masuk akal, seseorang akan dengan cepat menunjukkan bahwa ini hanya penopang karena kerapuhan platform, yang disebabkan oleh proses pengujian dan penyebaran yang buruk.

Beberapa bahkan menyarankan agar Anda lebih menyukai penyebaran sepi daripada akhir pekan itu sendiri:


Pengguna lain percaya bahwa penerapan flag fungsi mungkin merupakan solusi yang memungkinkan.


Pengguna ini percaya bahwa masalah penyebaran yang berisiko seharusnya tidak muncul karena proses dan alat yang tersedia untuk kami hari ini.

Siapa yang membuat keputusan?

Semua pertukaran pendapat ini menunjukkan bahwa kita, sebagai komunitas insinyur, dapat sangat tidak setuju dan tidak perlu saling setuju. Siapa sangka. Situasi ini mungkin juga menunjukkan bahwa gambaran keseluruhan dengan #NoDeployFriday berisi nuansa seperti itu yang tidak terlalu tercermin dengan baik di Twitter. Benarkah kita semua harus menerapkan penyebaran yang terus-menerus, kalau tidak kita "salah"?

Dalam membuat keputusan seperti itu ada aspek psikologis. Permusuhan terhadap rilis Jumat berasal dari rasa takut membuat kesalahan selama seminggu (karena kelelahan atau terburu-buru), yang dapat membahayakan sementara sebagian besar karyawan beristirahat selama dua hari. Akibatnya, komitmen Jumat yang berisi masalah potensial dapat merusak akhir pekan bagi banyak orang: insinyur tugas, insinyur lain yang akan membantu memecahkan masalah dari jarak jauh, dan mungkin spesialis infrastruktur yang harus memulihkan data yang rusak. Jika kegagalan tersebut ternyata serius, maka karyawan lain perusahaan mungkin juga terlibat dalam situasi tersebut, yang perlu menghubungi pelanggan dan meminimalkan kerusakan.

Mengambil posisi seorang idealis, kita dapat mengasumsikan bahwa di dunia yang ideal dengan kode sempurna, cakupan pengujian sempurna dan QA sempurna, tidak ada perubahan yang dapat menyebabkan masalah. Tetapi kita adalah manusia, dan manusia cenderung membuat kesalahan. Akan selalu ada beberapa kasus perbatasan aneh yang tidak ditutup selama pengembangan. Inilah hidup. Jadi gerakan #NoDeployFriday masuk akal, setidaknya secara teoritis. Namun, ini hanya alat buta. Saya percaya bahwa perlu untuk mengevaluasi perubahan yang dibuat tergantung pada situasi, dan apriori perlu untuk melanjutkan dari fakta bahwa kami menyebarkan pada setiap hari, bahkan pada hari Jumat, tetapi pada saat yang sama harus dapat mengisolasi perubahan yang harus menunggu hingga Senin.

Ada beberapa masalah yang bisa kita diskusikan. Saya membaginya menjadi beberapa kategori:

1. Memahami "radius kehancuran" dari perubahan.
   
2. Tingkat kesehatan dari proses penyebaran.
   
3. Kemampuan untuk mendeteksi kesalahan secara otomatis.
   
4. Berapa lama untuk menyelesaikan masalah.
   

Sekarang mari kita bahas.

Memahami "radius kehancuran"

Ketika tombak daring tentang rilis Jumat mulai pecah, mereka selalu melupakan yang penting - tentang sifat perubahan itu. Tidak ada perubahan yang identik dalam basis kode. Beberapa komitmen mengatur antarmuka sedikit dan tidak lebih; yang lain menolak ratusan kelas tanpa memengaruhi fungsionalitas program; yang lain mengubah skema basis data dan membuat perubahan besar pada proses konsumsi data waktu nyata; yang keempat dapat memulai kembali satu contoh, sedangkan yang kelima dapat memulai kaskade ulang semua jenis layanan.

Melihat kode tersebut, insinyur harus memiliki gagasan yang bagus tentang "radius kehancuran" dari perubahan yang dilakukan. Bagian mana dari kode dan aplikasi yang akan terpengaruh? Apa yang bisa jatuh jika kode baru crash? Apakah itu hanya klik pada tombol yang akan menimbulkan kesalahan, atau apakah semua entri baru akan hilang? Apakah perubahan dibuat untuk satu layanan yang terisolasi, atau akankah banyak layanan dan dependensi berubah secara bersamaan?

Saya tidak bisa membayangkan siapa yang akan menolak untuk melakukan perubahan dengan "radius kehancuran" kecil dan penyebaran sederhana pada hari apa saja dalam seminggu. Tetapi pada saat yang sama, perubahan besar - terutama yang terkait dengan infrastruktur penyimpanan - harus dilakukan lebih hati-hati, mungkin pada saat ada lebih sedikit pengguna online. Akan lebih baik jika perubahan skala besar seperti itu dilakukan secara paralel untuk menguji dan mengevaluasi pekerjaan mereka di bawah beban nyata, dan tidak ada yang akan mengetahuinya.

Di sini Anda perlu mengambil keputusan tergantung situasinya. Apakah setiap insinyur menyadari "radius kehancuran" dari perubahan di lingkungan produksi, dan tidak hanya di lingkungan pengembangan? Jika tidak, mengapa? Apakah mungkin untuk meningkatkan dokumentasi, pelatihan, dan tampilan efek perubahan kode dalam produksi?

Apakah "radius kehancuran" kecil? Luncurkan pada hari Jumat.

Apakah "radius kehancuran" besar? Tunggu hingga Senin.

Tingkat kesehatan dari proses penyebaran

Salah satu cara untuk mengurangi risiko adalah dengan terus meningkatkan proses penyebaran. Jika untuk meluncurkan versi baru aplikasi, masih perlu bagi spesialis untuk mengetahui skrip mana yang harus dijalankan, file mana dan di mana untuk menyalin, maka sudah waktunya untuk melakukan otomatisasi. Dalam beberapa tahun terakhir, alat di bidang ini telah melangkah jauh ke depan. Kami sering menggunakan Jenkins Pipeline dan Concourse , mereka memungkinkan Anda untuk langsung mengatur jalur perakitan, pengujian, dan penyebaran dengan kode.

Proses penyebaran penuh adalah hal yang menarik. Ini memungkinkan Anda untuk mundur dan mencoba mengabstraksi apa yang harus terjadi sejak permintaan tarik diinisialisasi hingga aplikasi dioperasikan. Deskripsi semua langkah dalam kode, misalnya, dalam alat yang disebutkan di atas, akan membantu Anda menggeneralisasi definisi langkah dan menggunakannya kembali di semua aplikasi. Selain itu, akan menarik bagi Anda untuk mencatat beberapa keputusan aneh atau malas yang pernah Anda buat dan rujuk.

Untuk setiap insinyur yang telah membaca dua paragraf sebelumnya dan bereaksi dengan gaya “Tentu saja! Kami telah melakukan ini selama bertahun-tahun! ” Saya dapat menjamin bahwa 9 orang lainnya mempresentasikan infrastruktur aplikasi mereka dan meringis, menyadari jumlah pekerjaan yang perlu dilakukan untuk mentransfer sistem ke pipa penyebaran modern. Ini berarti mengambil keuntungan dari alat-alat modern yang tidak hanya melakukan integrasi terus menerus, tetapi juga memungkinkan Anda untuk terus memasok bug ke prod, dan insinyur hanya perlu menekan tombol untuk commissioning (atau bahkan melakukannya secara otomatis jika Anda cukup berani).

Meningkatkan konveyor penempatan membutuhkan keterlibatan dan staf yang tepat - ini jelas bukan proyek sampingan. Solusi yang baik adalah dengan menyoroti tim untuk meningkatkan alat internal. Jika mereka masih tidak tahu tentang masalah yang ada - dan mereka mungkin tahu - maka Anda dapat mengumpulkan informasi tentang situasi paling menyakitkan terkait dengan proses rilis, kemudian memprioritaskan dan memperbaikinya bersama-sama dengan orang lain. Perlahan, tapi pasti, situasinya akan membaik: kode akan beroperasi lebih cepat dan dengan lebih sedikit masalah. Semakin banyak orang akan dapat mempelajari pendekatan yang lebih baik dan melakukan perbaikan sendiri. Ketika situasi membaik, pendekatan akan didistribusikan dalam tim, dan proyek baru ini akan selesai dengan benar, tanpa meniru kebiasaan buruk lama.

Dari saat penggabungan, permintaan tarikan ke komit harus otomatis sehingga Anda bahkan tidak perlu memikirkannya. Ini tidak hanya membantu mengisolasi masalah nyata dalam QA, karena satu-satunya variabel adalah kode yang diubah, tetapi membuat penulisan kode jauh lebih menyenangkan. Komisioning didesentralisasi, yang meningkatkan otonomi dan tanggung jawab pribadi. Dan ini, pada gilirannya, mengarah pada keputusan yang lebih disengaja tentang kapan dan bagaimana mengeluarkan kode baru.

Konveyor penyebaran yang andal? Mulai hari Jumat.

Menyalin skrip secara manual? Tunggu hingga Senin.

Kemampuan untuk mendeteksi kesalahan

Komisioning tidak berhenti setelah kode mulai bekerja. Jika terjadi kesalahan, kita perlu mengetahuinya, dan disarankan agar kita diberi tahu tentang hal ini, dan tidak perlu mencari informasi sendiri. Untuk melakukan ini, Anda perlu secara otomatis memindai log aplikasi untuk kesalahan, secara eksplisit melacak metrik kunci (misalnya, jumlah pesan yang diproses per detik, atau proporsi kesalahan), serta sistem peringatan yang menginformasikan insinyur tentang masalah kritis dan menunjukkan tren negatif untuk metrik tertentu.

Operasi selalu berbeda dari pengembangan, dan insinyur perlu memantau operasi bagian-bagian tertentu dari sistem. Anda perlu menjawab pertanyaan tentang setiap perubahan berikutnya: apakah itu mempercepat atau memperlambat sistem? Ada lebih atau kurang waktu tunggu? Apakah kita dibatasi oleh prosesor atau I / O?

Data tentang metrik dan kesalahan harus dikirim ke sistem peringatan. Tim harus dapat menentukan sinyal mana yang mengindikasikan situasi negatif, dan mengirim pesan otomatis tentangnya. Untuk tim kami dan insiden paling serius, kami menggunakan PagerDuty.

Mengukur metrik sistem produksi berarti insinyur dapat melihat apakah ada sesuatu yang berubah setelah setiap penyebaran, baik atau buruk. Dan dalam kasus terburuk, sistem akan secara otomatis memberi tahu seseorang tentang masalahnya.

Pemantauan, pemberitahuan, dan spesialis panggilan yang baik? Sebarkan pada hari Jumat.

Secara manual melihat log melalui ssh? Tunggu hingga Senin.

Berapa lama untuk menyelesaikan masalah?

Akhirnya, kriteria utama adalah berapa lama waktu yang dibutuhkan untuk memperbaiki masalah. Ini sebagian tergantung pada "radius kerusakan" dari perubahan yang dilakukan. Bahkan jika Anda memiliki jaringan penyebaran yang menjilat, beberapa perubahan sulit untuk diperbaiki dengan cepat. Kembalikan perubahan dalam sistem ekstraksi data dan dalam skema indeks pencarian mungkin memerlukan pengindeksan ulang melelahkan, selain memperbaiki beberapa baris kode. Penempatan rata-rata, validasi, koreksi, dan penempatan ulang perubahan CSS mungkin membutuhkan waktu beberapa menit, sementara perubahan besar pada repositori mungkin memerlukan berhari-hari kerja.

Untuk semua pekerjaan dalam pipa penempatan, yang pada tingkat makro dapat meningkatkan keandalan perubahan, tidak ada perubahan yang sama, jadi Anda perlu mengevaluasi secara terpisah. Jika ada yang salah, bisakah kita memperbaikinya dengan cepat?

Apakah sepenuhnya diperbaiki dengan komit pemulihan tunggal? Sebarkan pada hari Jumat.

Apakah ada kesulitan besar jika terjadi kesalahan? Tunggu hingga Senin.

Pikirkan sendiri, putuskan sendiri

Apa posisi saya di #NoDeployFriday? Saya pikir itu semua tergantung pada rilis. Perubahan dengan "radius hit" kecil yang mudah untuk diputar kembali dapat digunakan kapan saja, kapan saja. Dengan perubahan besar, yang dampaknya harus dipantau secara ketat dalam sistem produksi, saya sangat merekomendasikan menunggu hingga Senin.

Bahkan, terserah Anda untuk menggunakan pada hari Jumat. Jika Anda bekerja dengan sistem yang berderit dan rapuh, yang terbaik adalah menghindari hari Jumat sampai Anda telah melakukan semua yang diperlukan untuk meningkatkan proses penyebaran. Pastikan untuk melakukannya, jangan menepisnya. Menolak rilis Jumat adalah cara biasa untuk menutupi kekurangan infrastruktur sementara. Ini adalah pengurangan kerusakan yang wajar untuk kebaikan bisnis. Tapi itu buruk jika aturan ini mencakup kelemahan konstan.

Jika Anda tidak yakin apa dampak perubahan yang akan terjadi, maka tunda hingga Senin. Tetapi pikirkan apa yang dapat Anda lakukan lain kali untuk lebih memahami efek ini, dan meningkatkan infrastruktur terkait untuk ini. Seperti biasa dalam hidup, setiap keputusan memiliki nuansa tersendiri. Solusi tidak dibagi menjadi "hitam" dan "putih", menjadi "benar" dan "salah": sementara kami melakukan segala yang kami bisa untuk bisnis, aplikasi dan satu sama lain, meningkatkan sistem kami, maka kami melakukan semuanya dengan baik.

Pemasangan yang sukses.