🧑🏽‍🤝‍🧑🏼 ♑️ 👩🏼‍🎤 Metodologi penyebaran proyek yang digunakan oleh Slack 💃🏿 🔵 🕝

Kesimpulan dari rilis proyek baru ke dalam produksi membutuhkan keseimbangan yang hati-hati antara kecepatan penyebaran dan keandalan solusi. Slack menghargai iterasi cepat, loop umpan balik pendek, dan responsif terhadap permintaan pengguna. Selain itu, perusahaan ini memiliki ratusan programmer yang berjuang untuk produktivitas setinggi mungkin.

Para penulis materi, terjemahan yang kami terbitkan hari ini, mengatakan bahwa perusahaan yang berusaha untuk mematuhi nilai-nilai tersebut dan pada saat yang sama tumbuh harus terus meningkatkan sistem penyebaran proyeknya. Perusahaan perlu berinvestasi dalam transparansi dan keandalan proses kerja, untuk memastikan bahwa proses ini sesuai dengan ruang lingkup proyek. Di sini kita akan berbicara tentang proses kerja yang telah dikembangkan di Slack, dan tentang beberapa solusi yang membuat perusahaan menggunakan sistem penyebaran proyek yang ada saat ini.

Bagaimana proses penyebaran proyek bekerja hari ini

Setiap PR (permintaan tarik) di Slack harus dikenai peninjauan kode dan harus lulus semua tes dengan sukses. Hanya setelah kondisi ini terpenuhi, seorang programmer dapat menggabungkan kodenya dengan cabang utama dari proyek. Namun, penyebaran kode semacam itu hanya dilakukan selama jam kerja menurut waktu Amerika Utara. Sebagai hasilnya, kami, karena fakta bahwa karyawan kami sedang bekerja, sepenuhnya siap untuk menyelesaikan masalah yang tidak terduga.

Setiap hari kami menyelesaikan sekitar 12 penyebaran yang direncanakan. Selama setiap penyebaran, programmer, yang ditugaskan sebagai penyebaran utama, bertanggung jawab untuk membawa perakitan baru ke produksi. Ini adalah proses multi-langkah, yang memberikan kesimpulan yang mulus dari perakitan dalam mode kerja. Berkat pendekatan ini, kami dapat mendeteksi kesalahan sebelum memengaruhi semua pengguna kami. Jika ada terlalu banyak kesalahan, penyebaran majelis dapat dibatalkan. Jika masalah tertentu terdeteksi setelah rilis, perbaikan dapat dengan mudah dirilis untuk itu.

Antarmuka sistem Checkpoint yang digunakan oleh Slack untuk menyebarkan proyek.

Proses penempatan rilis baru dalam produksi dapat diwakili dalam empat langkah.

▍1. Membuat cabang rilis

Setiap rilis dimulai dengan cabang rilis baru, dari saat dalam sejarah Git kami. Ini memungkinkan Anda untuk menetapkan tag ke rilis dan menyediakan tempat di mana Anda dapat melakukan koreksi operasional untuk kesalahan yang ditemukan dalam proses mempersiapkan rilis untuk rilis dalam produksi.

▍2. Penempatan menengah

Langkah selanjutnya adalah memasang perakitan ke server panggung dan menjalankan tes otomatis untuk keseluruhan kinerja proyek (uji asap). Lingkungan perantara adalah lingkungan produksi di mana lalu lintas eksternal tidak turun. Dalam lingkungan ini, kami melakukan pengujian manual tambahan. Ini memberi kami keyakinan tambahan bahwa proyek yang dimodifikasi bekerja dengan benar. Tes otomatis saja tidak cukup untuk mendapatkan kepercayaan diri seperti itu.

▍3. Penempatan di lingkungan dogfood dan kenari

Penempatan dalam produksi dimulai dengan lingkungan dogfood yang diwakili oleh serangkaian host yang melayani ruang kerja Slack internal kami. Karena kami adalah pengguna Slack yang sangat aktif, menggunakan pendekatan ini telah membantu mendeteksi banyak kesalahan pada tahap awal penerapan. Setelah kami memastikan bahwa fungsionalitas dasar sistem tidak rusak, majelis ditempatkan di lingkungan kenari. Ini adalah sistem yang menerima sekitar 2% dari lalu lintas produksi.

▍4. Kesimpulan Bertahap dalam Produksi

Jika indikator pemantauan rilis baru berubah menjadi stabil, dan jika setelah menyebarkan proyek di lingkungan kenari kami belum menerima keluhan, kami melanjutkan transfer server produksi secara bertahap ke rilis baru. Proses penyebaran dibagi menjadi beberapa tahapan berikut: 10%, 25%, 50%, 75% dan 100%. Akibatnya, kami dapat secara perlahan mentransfer lalu lintas produksi ke rilis sistem baru. Pada saat yang sama, kami punya waktu untuk menyelidiki situasi jika mengungkapkan beberapa anomali.

▍Bagaimana jika terjadi kesalahan selama pemasangan?

Membuat modifikasi pada kode selalu berisiko. Tetapi kita dapat mengatasi hal ini berkat “manajer penempatan” kami yang terlatih dengan baik yang mengelola proses memperkenalkan rilis baru ke dalam produksi, memantau kinerja pemantauan, dan mengoordinasikan pekerjaan programmer yang merilis kode.

Jika ada masalah, kami mencoba mendeteksi masalah sedini mungkin. Kami menyelidiki masalah, menemukan PR yang menyebabkan kesalahan, memutar kembali, menganalisisnya dengan hati-hati, dan membuat perakitan baru. Benar, kadang-kadang masalah tidak diperhatikan sebelum proyek dimasukkan ke dalam produksi. Dalam situasi seperti itu, yang paling penting adalah mengembalikan layanan. Karena itu, sebelum memulai investigasi masalah, kami segera kembali ke majelis kerja sebelumnya.

Blok Bangunan Penempatan

Pertimbangkan teknologi yang mendasari sistem penyebaran proyek kami.

▍ Pengiriman cepat

Alur kerja yang dijelaskan di atas mungkin tampak, dalam retrospeksi, menjadi sesuatu yang sangat jelas. Tetapi sistem penyebaran kami tidak menjadi begitu jauh.

Ketika perusahaan secara signifikan lebih kecil, seluruh aplikasi kami dapat berjalan di 10 instance Amazon EC2. Menyebarkan proyek dalam situasi ini berarti menggunakan rsync untuk menyinkronkan semua server dengan cepat. Sebelumnya, kode baru dipisahkan dari produksi hanya dengan satu langkah, diwakili oleh lingkungan perantara. Kebaktian diciptakan dan diuji dalam lingkungan seperti itu, dan kemudian langsung diproduksi. Memahami sistem seperti itu sangat sederhana, memungkinkan setiap programmer untuk menyebarkan kode yang ditulisnya kapan saja.

Tetapi dengan bertambahnya jumlah pelanggan kami, begitu pula skala infrastruktur yang diperlukan untuk memastikan operasi proyek. Segera, mengingat pertumbuhan sistem yang konstan, model penyebaran kami, berdasarkan pengiriman kode baru ke server, berhenti menangani tugasnya. Yaitu, penambahan setiap server baru berarti peningkatan waktu yang dibutuhkan untuk menyelesaikan penyebaran. Bahkan strategi berdasarkan penggunaan paralel rsync memiliki keterbatasan tertentu.

Akibatnya, kami memecahkan masalah ini dengan beralih ke sistem penempatan paralel sepenuhnya, yang tidak diatur seperti sistem lama. Yaitu, sekarang kami tidak mengirim kode ke server menggunakan skrip sinkronisasi. Sekarang masing-masing server secara independen mengunduh perakitan baru, mengetahui bahwa itu perlu dilakukan, berkat mengamati perubahan kunci Konsul. Server mengunduh kode secara paralel. Ini memungkinkan kami untuk mempertahankan kecepatan penyebaran tinggi bahkan dalam lingkungan pertumbuhan sistem yang konstan.

1. Server produksi memantau kunci Konsul. 2. Kuncinya berubah, ini memberi tahu server bahwa mereka harus mulai mengunduh kode baru. 3. Server mengunggah file tarball dengan kode aplikasi

DeployPenyebaran anatomi

Solusi lain yang membantu kami mencapai sistem penempatan multi-level adalah penyebaran atom.

Sebelum menggunakan penyebaran atom, setiap penyebaran dapat menghasilkan sejumlah besar pesan kesalahan. Faktanya adalah bahwa proses menyalin file baru ke server produksi tidak bersifat atomik. Hal ini menyebabkan adanya rentang waktu singkat ketika kode di mana fungsi-fungsi baru dipanggil tersedia sebelum fungsi-fungsi itu sendiri tersedia. Ketika kode tersebut dipanggil, ia mengembalikan kesalahan internal. Ini dimanifestasikan dalam permintaan API yang gagal dan di halaman web yang rusak.

Tim yang menangani masalah ini menyelesaikannya dengan memperkenalkan konsep direktori "panas" (panas) dan "dingin" (dingin). Kode dalam direktori "hot" bertanggung jawab untuk memproses lalu lintas produksi. Dan di direktori "dingin", kode, ketika sistem sedang berjalan, hanya bersiap-siap untuk digunakan. Selama penyebaran, kode baru disalin ke direktori "dingin" yang tidak digunakan. Kemudian, ketika tidak ada proses aktif di server, direktori akan beralih secara instan.

1. Buka kemasan kode aplikasi ke direktori "dingin". 2. Mengalihkan sistem ke direktori "dingin", yang menjadi "panas" (operasi atom)

Intinya: pergeseran penekanan pada keandalan

Pada tahun 2018, proyek tersebut tumbuh sedemikian rupa sehingga penyebaran yang sangat cepat mulai merusak stabilitas produk. Kami memiliki sistem penyebaran yang sangat maju di mana kami menginvestasikan banyak waktu dan upaya. Kami hanya perlu merestrukturisasi dan meningkatkan proses organisasi penyebaran. Kami telah menjadi perusahaan yang cukup besar, yang perkembangannya digunakan di seluruh dunia untuk mengatur komunikasi yang tidak terputus dan untuk memecahkan masalah-masalah penting. Karena itu, fokus perhatian kami adalah keandalan.

Kami perlu membuat proses penempatan rilis Slack baru lebih aman. Kebutuhan ini mendorong kami untuk meningkatkan sistem penempatan kami. Faktanya, di atas kami membahas sistem yang ditingkatkan ini. Dalam perut sistem, kami terus menggunakan teknologi penyebaran cepat dan atom. Mengubah bagaimana tepatnya penyebaran dilakukan. Sistem baru kami dirancang untuk secara bertahap menggunakan kode baru di tingkat yang berbeda, di lingkungan yang berbeda. Sekarang kami menggunakan lebih maju dari sebelumnya, alat bantu dan alat bantu untuk memantau sistem. Ini memberi kami kesempatan untuk menangkap dan menghilangkan kesalahan jauh sebelum mereka mendapatkan kesempatan untuk mencapai pengguna akhir.

Tapi kita tidak akan berhenti di situ. Kami terus meningkatkan sistem ini menggunakan alat bantu yang lebih canggih dan alat otomatisasi.

Pembaca yang budiman! Bagaimana proses penggelaran rilis proyek baru di tempat Anda bekerja?

Metodologi penyebaran proyek yang digunakan oleh Slack