Membawa rilis proyek baru ke dalam produksi memerlukan keseimbangan yang cermat antara kecepatan penerapan dan keandalan solusi. Slack menghargai iterasi yang cepat, siklus umpan balik yang singkat, dan respons yang cepat terhadap permintaan pengguna. Selain itu, perusahaan ini memiliki ratusan programmer yang berusaha untuk menjadi seproduktif mungkin.
Penulis materi, terjemahan yang kami terbitkan hari ini, mengatakan bahwa perusahaan yang berupaya untuk mematuhi nilai-nilai tersebut dan pada saat yang sama berkembang harus terus meningkatkan sistem penerapan proyeknya. Perusahaan perlu berinvestasi pada transparansi dan keandalan proses kerja, hal ini dilakukan untuk memastikan bahwa proses tersebut sesuai dengan skala proyek. Di sini kita akan berbicara tentang alur kerja yang berkembang di Slack, dan tentang beberapa keputusan yang mengarahkan perusahaan untuk menggunakan sistem penerapan proyek yang ada saat ini.
Cara kerja proses penerapan proyek saat ini
Setiap PR (pull request) di Slack harus menjalani peninjauan kode dan harus berhasil melewati semua tes. Hanya setelah kondisi ini terpenuhi, pemrogram dapat menggabungkan kodenya ke dalam cabang utama proyek. Namun, kode ini hanya diterapkan selama jam kerja, waktu Amerika Utara. Oleh karena itu, karena karyawan kami berada di tempat kerja mereka, kami sepenuhnya siap untuk menyelesaikan masalah yang tidak terduga.
Setiap hari kami melakukan sekitar 12 penerapan yang direncanakan. Selama setiap penerapan, pemrogram yang ditunjuk sebagai pemimpin penerapan bertanggung jawab untuk memasukkan versi baru ke dalam produksi. Ini adalah proses multi-langkah yang memastikan perakitan dibawa ke produksi dengan lancar. Berkat pendekatan ini, kami dapat mendeteksi kesalahan sebelum kesalahan tersebut memengaruhi semua pengguna kami. Jika terdapat terlalu banyak kesalahan, penerapan rakitan dapat dibatalkan. Jika masalah tertentu ditemukan setelah rilis, perbaikan dapat dengan mudah dirilis untuk masalah tersebut.
Antarmuka sistem Checkpoint, yang digunakan di Slack untuk menyebarkan proyek
Proses penerapan rilis baru ke produksi dapat dianggap terdiri dari empat langkah.
▍1. Membuat cabang rilis
Setiap rilis dimulai dengan cabang rilis baru, sebuah titik dalam sejarah Git kami. Hal ini memungkinkan Anda untuk menetapkan tag pada rilis dan menyediakan tempat di mana Anda dapat melakukan perbaikan langsung untuk bug yang ditemukan dalam proses persiapan rilis untuk rilis ke produksi.
▍2. Penerapan dalam lingkungan pementasan
Langkah selanjutnya adalah menyebarkan perakitan pada server pementasan dan menjalankan pengujian otomatis untuk kinerja proyek secara keseluruhan (uji asap). Lingkungan pementasan adalah lingkungan produksi yang tidak menerima lalu lintas eksternal. Di lingkungan ini, kami melakukan pengujian manual tambahan. Hal ini memberi kami keyakinan tambahan bahwa proyek yang dimodifikasi berfungsi dengan benar. Tes otomatis saja tidak cukup untuk memberikan tingkat kepercayaan ini.
▍3. Penerapan di lingkungan dogfood dan canary
Penerapan ke produksi dimulai dengan lingkungan dogfood, yang diwakili oleh sekumpulan host yang melayani ruang kerja internal Slack kami. Karena kami adalah pengguna Slack yang sangat aktif, pendekatan ini membantu kami menemukan banyak bug di awal penerapan. Setelah kami memastikan bahwa fungsionalitas dasar sistem tidak rusak, perakitan diterapkan di lingkungan canary. Ini mewakili sistem yang menyumbang sekitar 2% dari lalu lintas produksi.
▍4. Rilis bertahap ke produksi
Jika indikator pemantauan untuk rilis baru ternyata stabil, dan jika setelah penerapan proyek di lingkungan canary kami belum menerima keluhan apa pun, kami terus mentransfer server produksi ke rilis baru secara bertahap. Proses deployment dibagi menjadi tahapan sebagai berikut: 10%, 25%, 50%, 75% dan 100%. Hasilnya, kami dapat secara perlahan mentransfer lalu lintas produksi ke rilis sistem yang baru. Pada saat yang sama, kami punya waktu untuk menyelidiki situasi jika ada anomali yang terdeteksi.
▍Bagaimana jika terjadi kesalahan selama penerapan?
Melakukan modifikasi pada kode selalu mengandung risiko. Namun kami mengatasinya berkat kehadiran “pemimpin penerapan” terlatih yang mengelola proses membawa rilis baru ke dalam produksi, memantau indikator pemantauan, dan mengoordinasikan pekerjaan pemrogram yang merilis kode.
Jika terjadi sesuatu yang tidak beres, kami berusaha mendeteksi masalahnya sedini mungkin. Kami menyelidiki masalahnya, menemukan PR yang menyebabkan kesalahan, mengembalikannya, menganalisisnya secara menyeluruh, dan membuat versi baru. Benar, terkadang masalahnya tidak diketahui sampai proyek mulai berproduksi. Dalam situasi seperti ini, hal terpenting adalah memulihkan layanan. Oleh karena itu, sebelum kami mulai menyelidiki masalahnya, kami segera kembali ke build kerja sebelumnya.
Blok Bangunan Sistem Penerapan
Mari kita lihat teknologi yang mendasari sistem penerapan proyek kami.
▍ Penerapan cepat
Alur kerja yang dijelaskan di atas mungkin tampak, jika dipikir-pikir, agak jelas. Namun sistem penerapan kami tidak langsung menjadi seperti ini.
Ketika perusahaan masih jauh lebih kecil, seluruh aplikasi kami dapat berjalan pada 10 instans Amazon EC2. Menyebarkan proyek dalam situasi ini berarti menggunakan rsync untuk menyinkronkan semua server dengan cepat. Sebelumnya, kode baru hanya berjarak satu langkah dari produksi, yang diwakili oleh lingkungan pementasan. Rakitan dibuat dan diuji dalam lingkungan seperti itu, dan kemudian langsung menuju produksi. Sangat mudah untuk memahami sistem seperti itu; sistem ini memungkinkan pemrogram mana pun untuk menyebarkan kode yang telah ditulisnya kapan saja.
Namun seiring bertambahnya jumlah klien kami, skala infrastruktur yang dibutuhkan untuk mendukung proyek juga meningkat. Segera, mengingat pertumbuhan sistem yang konstan, model penerapan kami, yang didasarkan pada memasukkan kode baru ke server, tidak lagi berfungsi. Yaitu, menambahkan setiap server baru berarti menambah waktu yang dibutuhkan untuk menyelesaikan penerapan. Bahkan strategi yang didasarkan pada penggunaan rsync secara paralel memiliki keterbatasan tertentu.
Kami akhirnya memecahkan masalah ini dengan beralih ke sistem penerapan paralel, yang dirancang berbeda dari sistem lama. Yaitu, sekarang kami tidak mengirimkan kode ke server menggunakan skrip sinkronisasi. Sekarang masing-masing server secara mandiri mengunduh rakitan baru, mengetahui bahwa hal itu perlu dilakukan dengan memantau perubahan kunci Konsul. Server memuat kode secara paralel. Hal ini memungkinkan kami mempertahankan kecepatan penerapan yang tinggi bahkan dalam lingkungan dengan pertumbuhan sistem yang konstan.
1. Server produksi memantau kunci Konsul. 2. Perubahan kunci, ini memberitahu server bahwa mereka harus mulai mengunduh kode baru. 3. Server mendownload file tarball dengan kode aplikasi
▍Penyebaran atom
Solusi lain yang membantu kami mencapai sistem penerapan multi-tingkat adalah penerapan atom.
Sebelum menggunakan penerapan atom, setiap penerapan dapat menghasilkan banyak pesan kesalahan. Faktanya adalah proses penyalinan file baru ke server produksi tidak bersifat atomik. Hal ini mengakibatkan jangka waktu yang singkat ketika kode yang memanggil fungsi baru tersedia sebelum fungsi itu sendiri tersedia. Ketika kode tersebut dipanggil, hal ini mengakibatkan kesalahan internal dikembalikan. Hal ini terwujud dalam permintaan API yang gagal dan halaman web yang rusak.
Tim yang menangani masalah ini memecahkannya dengan memperkenalkan konsep direktori “panas” dan “dingin”. Kode di direktori hot bertanggung jawab untuk memproses lalu lintas produksi. Dan di direktori “dingin”, kode, saat sistem sedang berjalan, hanya disiapkan untuk digunakan. Selama penerapan, kode baru disalin ke direktori dingin yang tidak digunakan. Kemudian, ketika tidak ada proses aktif di server, peralihan direktori instan dilakukan.
1. Membongkar kode aplikasi ke dalam direktori “dingin”. 2. Mengalihkan sistem ke direktori “dingin”, yang menjadi “panas” (operasi atom)
Hasil: pergeseran penekanan ke keandalan
Pada tahun 2018, proyek ini berkembang sedemikian rupa sehingga penerapan yang sangat cepat mulai mengganggu stabilitas produk. Kami memiliki sistem penerapan yang sangat canggih dan kami menginvestasikan banyak waktu dan tenaga. Yang perlu kami lakukan hanyalah membangun kembali dan meningkatkan proses penerapan kami. Kami telah berkembang menjadi perusahaan yang cukup besar, yang perkembangannya telah digunakan di seluruh dunia untuk mengatur komunikasi yang tidak terputus dan untuk memecahkan masalah-masalah penting. Oleh karena itu, keandalan menjadi fokus perhatian kami.
Kami perlu membuat proses penerapan rilis Slack baru menjadi lebih aman. Kebutuhan ini mendorong kami untuk meningkatkan sistem penerapan kami. Faktanya, kami telah membahas sistem yang ditingkatkan ini di atas. Di bagian dalam sistem, kami terus menggunakan teknologi penerapan yang cepat dan atomik. Cara penerapannya telah berubah. Sistem baru kami dirancang untuk menerapkan kode baru secara bertahap pada tingkat yang berbeda, di lingkungan yang berbeda. Kami sekarang menggunakan alat pendukung dan alat pemantauan sistem yang lebih canggih dibandingkan sebelumnya. Hal ini memberi kami kemampuan untuk menangkap dan memperbaiki kesalahan jauh sebelum kesalahan tersebut sampai ke pengguna akhir.
Tapi kita tidak akan berhenti di situ. Kami terus meningkatkan sistem ini, menggunakan alat bantu yang lebih canggih dan alat otomatisasi kerja.
Pembaca yang terhormat Bagaimana proses penerapan rilis proyek baru di tempat Anda bekerja?
Sumber: www.habr.com