Sebagai tim pengiriman kami, hanya menggunakan sumber daya kami sendiri, redid sistem kami di bawah CI / CD.
Tim insinyur terus-menerus berada di bawah tekanan: Anda perlu memberikan fungsi-fungsi baru dalam bentuk produk yang layak dan pada saat yang sama terus-menerus meminimalkan waktu siklus . Seringkali, para ahli tanpa menggenggam alat modern. Integrasi dan Pengiriman Berkelanjutan (CI / CD) dibangun ke dalam GitLab, satu-satunya aplikasi siklus hidup DevOps kami, dan sekarang kami bermigrasi ke Kubernetes untuk mengurangi waktu siklus lebih jauh. Namun, untuk CI / CD - dan akhirnya Kubernetes - kami mengambil jalan yang agak tidak biasa. Tim Pengiriman , yang memindahkan kami ke pengiriman terus-menerus dari GitLab.com, menegangkan sistem yang lama, dan baru kemudian kami sepenuhnya beralih ke Kubernetes.
Bagaimana kami merilis rilis sebelum CI / CD
Antara 7 Agustus dan 27 September 2019, komunitas besar GitLab dan anggota tim kami mencapai rata-rata 55 komit per hari - ini adalah pengulangan berkelanjutan dari produk kami untuk membuat fitur baru. Tetapi sebelum kami menguasai pengiriman terus-menerus, kami menggunakan periode pembekuan fungsi baru dimulai pada tanggal 7 setiap bulan: pada saat ini teknisi kami mengalihkan perhatian mereka dari mengembangkan fungsi baru ke debugging untuk menyiapkan rilis mendatang yang keluar secara stabil pada tanggal 22 setiap bulan.
Dengan memperkenalkan tenggat waktu yang ketat, kami menanamkan pada pengembang perilaku yang membantu mereka pada akhirnya fokus pada tanggal tertentu, bukan fokus pada kesiapan.
"... para pengembang mulai menari dari tanggal 7, karena mereka melihat kalender dan berpikir: yah, masih ada waktu, hari ke 7 dalam seminggu, dan kemudian, pada tengah malam tanggal 6, mereka dengan panik bergabung," kata Marine Jankowski , CTO dari tim Pengiriman. "Mereka tahu bahwa jika mereka melanggar tenggat waktu, mereka harus menunggu satu bulan lagi, dan jika mereka berhasil melakukannya tepat waktu, mereka akan memiliki dua minggu lagi untuk debug."
Sejak awal GitLab.com, periode pembekuan fitur baru telah digunakan sebagai waktu untuk menstabilkan, ”jelas Marine.
Namun, jumlah pengguna terus bertambah dan kebutuhan akan fitur-fitur baru memaksa kami untuk mempercepat laju pengembangan. Periode stabilisasi memperlambat siklus dan sangat menunda transisi ke debugging, regresi dan pengiriman fungsi - baik kepada pengguna di Gitlab.com dan pelanggan individu.
"Dalam beberapa kasus, [fitur baru yang membeku] bahkan memicu ketidakstabilan platform - karena fakta bahwa perbaikan prioritas utama tidak mencapai klien tepat waktu," kata Marine. - "Dengan beralih ke CI / CD, kami memberikan produk baru dan men-debug mereka lebih cepat."
Sebelum kami membentuk tim Pengiriman untuk memindahkan GitLab.com ke pengiriman berkelanjutan - dan akhirnya ke Kubernetes - kami bergantung pada manajer rilis . Ini adalah posisi transisi di antara pengembang yang dipegang oleh orang yang sedang mempersiapkan rilis baru. Kami telah mengulangi proses ini selama lebih dari 5 tahun , tetapi manajer rilis telah menciptakan basis pengetahuan dan lebih atau kurang mengotomatiskannya.
Namun, metode ini ternyata tidak efektif, karena jadwal penyebaran dan persiapan untuk peluncuran melayang: dari setengah hari hingga beberapa hari karena fakta bahwa tugas-tugas untuk pelaksanaan manual terakumulasi dalam proses .
"Manajer rilis menerima daftar tugas yang tetap, tenggat waktu, dan mengulangi langkah-langkah di atas berulang kali hingga rilis yang sepenuhnya siap dan stabil di GitLab.com diperoleh," kata Marine. Dalam arti paling umum, berikut ini diperlukan dari manajer rilis:
- Menyinkronkan secara manual banyak repositori yang membentuk GitLab.
- Pastikan bahwa versi yang benar termasuk dalam cabang Git yang dibuat secara manual.
- Ketika rilis menerima tag, gunakan secara manual lingkungan pengujian dan produksi ke GitLab.com.
- Pastikan semuanya berfungsi, dan publikasikan paket secara manual untuk setiap pengguna.
Pada presentasi di Brooklyn selama GitLab Commit mengenai topik ini, Marine membagikan hasil pengamatan untuk 2018: dalam periode dua minggu sebelum rilis, tim Pengiriman menghabiskan 60% dari waktu membujuk dengan penyebaran, 26% lainnya dihabiskan untuk tugas-tugas manual dan semi-manual seperti menulis ulasan rilis bulanan.
Hasil pengamatan untuk 2018, sebelum pindah ke pengiriman berkelanjutan: ini adalah bagaimana tim Pengiriman menghabiskan waktu 2 minggu sebelum rilis.
"Berbicara secara umum, lalu 14 hari, dua minggu sebelum rilis, tim hanya melakukan apa yang sedang menatap monitor, menonton bagaimana cat mengering, atau sesuatu," kata Marine.
Tetapi dengan mengambil 86% dari pie ini (60% untuk penyebaran + 26% untuk tugas-tugas manual), tim Pengiriman akan memecahkan sejumlah masalah:
- Rilis baru tanpa penundaan.
- Penerapan yang berulang dan lebih cepat tanpa downtime.
- Lebih banyak waktu untuk bermigrasi GitLab.com ke Kubernetes.
- Lebih banyak kebebasan untuk mempersiapkan organisasi Anda untuk pengiriman berkelanjutan.
Meskipun CD hanya tersedia di GitLab.com, pelanggan individu kami juga mendapat manfaat dari transisi kami ke sana. Sekarang semua yang tidak terpengaruh oleh pengujian CI diuji secara otomatis dan manual di lingkungan - sebelum sampai ke GitLab.com. Segala sesuatu yang sampai ke GitLab.com dan perlu debugging akan di-debug dalam beberapa jam. Jadi rilis final untuk pelanggan individu akan bersih.
Transisi dari pembekuan ke CD adalah masalah waktu, ketika tumpukan fungsi kami tumbuh, dan tim insinyur yang dipimpin oleh Marina tampaknya mengamati transisi: “Tim Pengiriman dibentuk dengan tujuan tunggal untuk mentransfer perusahaan ke model CD, dan pada saat yang sama mentransfer perusahaan ke platform Kubernetes untuk memfasilitasi penskalaan dan mempercepat siklus. "
Sebagian besar perusahaan menggantikan GitLab akan memulai transisi ke CI / CD dan Kubernetes, pertama mengintegrasikan teknologi baru ke dalam alur kerja mereka dan memperbaiki proses pengembangan dalam proses. Kami telah memilih pendekatan yang berbeda.
Migrasi ke Kubernetes membutuhkan perubahan tidak hanya dalam sistem produksi, tetapi juga dalam pendekatan pengembangan, ”kata Marine. Kubernetes menawarkan fitur-fitur tertentu yang tersedia dengan mudah dan tanpa investasi tambahan. Tetapi untuk benar-benar mendapatkan manfaat dari fitur gratis yang ditawarkan oleh Kubernetes, Anda memerlukan semacam CI / CD.
Tim Pengiriman menerima ini: untuk memfasilitasi transisi ke Kubernetes untuk pengiriman berkelanjutan, teknisi kami harus sudah bekerja dengan fokus pada CI / CD, yang menyiratkan peningkatan kontrol kualitas (QA) dan perencanaan fungsi yang lebih ketat. Dan kemudian tim Pengiriman kami membuat keputusan yang suram : membangun sistem CD dengan alat-alat yang ada dan mengatur kembali infrastruktur aplikasi GitLab.com - alih-alih segera menguasai alat dan teknologi CD baru.
"Idenya sederhana," kata Marin, "kami menggunakan alat yang tersedia , mengotomatiskan sebagian besar tugas manual dan menguji seluruh sistem statis di bawah beban. Jika sistem statis bertahan, kami melanjutkan ke uji dinamis."
Pendekatan ini memberikan dua manfaat utama:
Pertama , kami telah mengidentifikasi semua kelemahan dalam pendekatan kami dan menstabilkannya dengan mengotomatisasi dengan CI, sehingga aplikasi kami telah tumbuh lebih kuat, dan keberhasilan transisi ke Kubernetes menjadi lebih nyata.
Kedua , membentuk tim insinyur dalam bentuk CD, kami menerapkannya dalam benak para insinyur GitLab, yang terbiasa dengan penyebaran setiap minggu dan menunggu, kadang-kadang sepanjang hari, karena mereka memengaruhi penggabungan, merupakan perubahan budaya yang nyata.
"Sejak kami menguasai CI / CD, pengembang kami mulai memahami dengan cara baru apa artinya dilakukan," kata Marine.
Sebelum pengenalan CI / CD, perubahan dianggap siap segera setelah peninjauan selesai. Ini menghilangkan penyebaran ke berbagai lingkungan, yang memakan waktu. Hari ini, penyebaran dikirim dalam beberapa jam, jadi tidak ada alasan untuk tidak mengkonfirmasi bahwa perubahan itu operasional di lingkungan pengujian dan produksi.
Menyebarkan aplikasi ulasan Kubernet memungkinkan pengembang untuk menjalankan pemeriksaan kualitas secara nyata dalam waktu nyata, dan menggunakan tanda fitur untuk pengiriman progresif juga mempercepat pengembangan.
"Dari langkah pertama dalam CD, pengembang diharuskan merespons setiap kontrol kualitas otomatis, dan juga untuk melakukan konfirmasi manual pada tingkat baru di lingkungan produksi dan pengujian. Plus, pengembang dapat membuat perubahan pada lingkungan produksi dalam satu hari. padahal sebelumnya butuh beberapa hari (atau bahkan berminggu-minggu). "
Dengan CD, Anda dapat melakukan pemeriksaan kualitas kode lebih sering. Dan karena dengan perubahan sistem CI / CD kami dalam kode yang disampaikan sepanjang waktu, pengembang memutar sesuai permintaan untuk masalah non-standar yang muncul secara real time, karena "periode inkubasi" sangat berkurang.
Metode baru kami
Setelah menerapkan sistem CI / CD , kami mengotomatiskan 90% dari proses. Sisanya 10% memerlukan intervensi manusia - koordinasi diperlukan antara banyak orang dengan hak akses.
"Kami secara bertahap mengurangi 10% ini - sehingga kami hanya perlu persetujuan untuk publikasi rilis," kata Marine. Dalam iterasi saat ini, proses CI / CD bekerja sebagai berikut :
- CI secara otomatis mencari tag tertentu dalam permintaan gabungan yang disetujui oleh pengulas dan pengembang.
- CI secara otomatis menyinkronkan repositori yang diperlukan dan pada saat yang sama membuat cabang, tag, dan juga menyertakan versi rilis yang benar yang ingin kami sampaikan.
- Ketika build selesai, paket secara otomatis digunakan untuk menguji lingkungan.
- Pemeriksaan kualitas otomatis dilakukan dan, jika semuanya berjalan dengan baik, penyebaran dikirim ke segmen kecil pengguna di lingkungan produksi.
- Sejalan dengan ini, pengembang melakukan kontrol kualitas dari tingkat yang berbeda secara manual - untuk memastikan bahwa fungsi-fungsi baru berfungsi sebagaimana mestinya.
- Jika masalah prioritas tinggi ditemukan selama konfirmasi manual, penyebaran berhenti.
- Ketika langkah sebelumnya selesai, anggota tim Pengiriman akan memulai pengiriman penempatan untuk semua pengguna GitLab.com.
- Kemudian, berdasarkan penyebaran produksi terbaru yang diluncurkan di GitLab.com, rilis pelanggan individu dibuat.
Seperti halnya tim teknik lainnya, penskalaan adalah tantangan nyata bagi kami. Namun, salah satu tantangan terbesar bagi para teknisi adalah memastikan bahwa kontrol kualitas mencakup segalanya, tetapi untuk proyek besar seperti GitLab.com ini adalah pekerjaan yang intens. Dan Anda juga perlu memastikan bahwa ada cukup pemantauan dan pemberitahuan, sehingga proyek tidak hanya berfungsi pada aturan yang telah ditentukan.
Tantangan besar kedua bagi kami adalah kompleksitas sistem GitLab.com dan transfer perubahan yang tepat dalam proses ke semua tim teknik. "Menghentikan proses dan kebiasaan yang telah dibangun selama bertahun-tahun jauh dari mudah," kata Marine.
Hasil
GitLab sudah mendapatkan banyak manfaat dari beralih ke CI / CD.
Pengamatan dan evaluasi pada tahun 2019 menunjukkan bahwa dalam 14 hari sebelum rilis, tim Pengiriman menghabiskan 82% dari waktu yang lebih produktif: ia dibebaskan untuk mengerjakan tugas-tugas penting lainnya.
Pengamatan untuk 2019 menunjukkan bahwa dalam 2 minggu yang sama banyak waktu berharga seperti itu dibebaskan dari pengembang berkat transisi ke CD.
Dengan mengotomatiskan pekerjaan manual, tim Pengiriman akhirnya beralih ke mengubah infrastruktur GitLab.com untuk meningkatkan dukungan untuk kecepatan pengembangan dan lalu lintas pengguna, dan pada saat yang sama, migrasi ke Kubernetes.
"Dan, seperti yang sudah saya katakan, semua ini tanpa Kubernetes. Semuanya dilakukan pada sistem pendahulu yang lama," kata Marine kepada para tamu dari Komit GitLab Brooklyn. - "Tapi kami memenangkan waktu, jadi sekarang tim saya terlibat erat dalam migrasi. Namun, salah satu perubahan terbesar terjadi justru pada kebiasaan mengatur pengembangan."
Hasil setelah transisi signifikan. Jika pada sistem lama pada Mei 2019 tim mengirim 7 penempatan, kemudian pada Agustus 2019 angka ini meningkat menjadi 35. Dan ini bukan batasnya: angkanya akan meningkat secara signifikan - sekarang tim mengirim banyak penempatan setiap hari.
"Kami baru saja memigrasi Layanan Registrasi kami ke Kubernetes, dan jika Anda menggunakan registry container di GitLab.com , semua permintaan Anda dieksekusi di platform Kubernetes," kata Marine. - "GitLab adalah sistem multi-komponen, dan kami terus mengisolasi dan mentransfer layanan lain."
Setiap rilis baru termasuk fitur CI / CD baru. Misalnya, dalam rilis 12.3, kami memperluas GitLab Container Registry - memungkinkan pengguna untuk menggunakan CI / CD dan mengumpulkan dan menanamkan gambar / tag ke dalam proyek mereka sendiri . Ada inovasi baru yang menarik lainnya.
Juga mentransfer sistem ke pengiriman berkelanjutan?
Marin menyarankan perusahaan yang baru saja akan beralih ke CD untuk memulai dengan apa yang mereka miliki.
"Sedangkan bagi saya, duduk dan menunggu migrasi ke platform baru adalah merugikan diri sendiri," kata Marine. "Sebagian besar sistem dapat diubah dalam beberapa cara dan mempercepat siklus pemrosesan tanpa bermigrasi ke sistem yang sama sekali baru. Mempercepat siklus pengembangan / pelepasan sangat meningkatkan efisiensi setiap insinyur dalam sistem dan membebaskan lebih banyak waktu untuk bermigrasi ke platform baru, seperti Kubernetes."
Jika Anda ingin tahu tentang apa yang akan terjadi selanjutnya, lihat ringkasan terperinci dari fitur CI / CD baru yang menarik ini yang sedang menunggu - dengan rilis 12,4 dan seterusnya.
Melewatkan Komit GitLab Brooklyn?
Jika Anda tidak dapat menghadiri presentasi Marina dengan latar belakang transisi kami ke Kubernetes, tonton video lengkapnya di bawah, dan bergabunglah dengan kami di European GitLab Commit di London, 9 Oktober .