Di GitLab, kami memproses perbaikan perangkat lunak dengan dua cara: secara manual dan otomatis. Baca terus untuk mengetahui tentang tugas manajer rilis dalam membuat dan mengirimkan pembaruan penting melalui penerapan otomatis ke gitlab.com, serta patch untuk digunakan pengguna pada instalasi mereka sendiri.
Saya sarankan untuk menyetel pengingat di jam tangan pintar Anda: setiap bulan pada tanggal 22, pengguna yang bekerja dengan GitLab di fasilitas mereka dapat melihat pembaruan ke versi produk kami saat ini. Rilis bulanan berisi fitur-fitur baru, pengembangan dari fitur-fitur yang sudah ada, dan sering kali menunjukkan hasil akhir dari permintaan komunitas untuk perkakas atau penggabungan.
Namun, seperti yang ditunjukkan oleh praktik, pengembangan perangkat lunak jarang sekali tanpa cacat. Ketika bug atau kerentanan keamanan ditemukan, manajer rilis di tim pengiriman membuat patch untuk pengguna kami dengan instalasi mereka. Gitlab.com diperbarui selama proses CD. Kami menyebut proses CD ini sebagai penerapan otomatis untuk menghindari kebingungan dengan fitur CD di GitLab. Proses ini dapat menggabungkan saran dari permintaan tarik yang dikirimkan oleh pengguna, pelanggan, dan tim pengembangan internal kami, sehingga pemecahan masalah membosankan dalam merilis patch diselesaikan dengan dua cara yang sangat berbeda.
Β«Kami memastikan bahwa semua yang dibuat oleh pengembang diterapkan ke semua lingkungan setiap hari sebelum diluncurkan ke GitLab.com", menjelaskan , Manajer Teknis Senior, Departemen Infrastruktur. "Pikirkan rilis untuk instalasi Anda sebagai snapshot untuk penerapan gitlab.com, yang mana kami telah menambahkan langkah-langkah terpisah untuk membuat paket sehingga pengguna kami dapat menggunakannya untuk menginstal pada instalasi mereka'.
Terlepas dari bug atau kerentanannya, pelanggan gitlab.com akan menerima perbaikan segera setelah dipublikasikan, yang merupakan manfaat dari proses CD otomatis. Patch untuk pengguna dengan instalasinya sendiri memerlukan persiapan terpisah oleh manajer rilis.
Tim pengiriman bekerja keras untuk mengotomatiskan sebagian besar proses yang terlibat dalam pembuatan rilis untuk menguranginya (waktu rata-rata hingga produksi, yaitu waktu yang dihabiskan untuk produksi), periode waktu mulai dari pemrosesan permintaan penggabungan oleh pengembang hingga penerapan di gitlab.com.
Β«Tujuan dari tim pengiriman adalah untuk memastikan bahwa kita dapat bergerak lebih cepat sebagai sebuah perusahaan, atau setidaknya membuat orang-orang pengiriman bekerja lebih cepat, bukan??, kata Marin.
Pelanggan gitlab.com dan pengguna instalasi mereka mendapat manfaat dari upaya tim pengiriman untuk mengurangi waktu siklus dan mempercepat penerapan. Pada artikel kali ini kami akan menjelaskan persamaan dan perbedaan kedua metode tersebut. , dan kami juga akan menjelaskan cara tim pengiriman kami menyiapkan patch untuk pengguna yang bekerja di fasilitas mereka, serta cara kami memastikan bahwa gitlab.com mutakhir menggunakan penerapan otomatis.
Apa yang dilakukan manajer rilis?
Anggota tim setiap bulan rilis kami kepada pengguna di fasilitas mereka, termasuk rilis patch dan keamanan yang mungkin terjadi di antara rilis. Mereka juga bertanggung jawab memimpin transisi perusahaan menuju penerapan otomatis dan berkelanjutan.
Rilis instalasi mandiri dan rilis gitlab.com menggunakan alur kerja yang serupa tetapi dijalankan pada waktu yang berbeda, Marin menjelaskan.
Yang pertama dan terpenting, manajer rilis, apa pun jenis rilisnya, memastikan bahwa GitLab tersedia dan aman sejak aplikasi diluncurkan di gitlab.com, termasuk memastikan bahwa masalah yang sama tidak berakhir pada infrastruktur pelanggan mereka. kapasitas sendiri.
Setelah bug atau kerentanan ditandai telah diperbaiki di GitLab, manajer rilis harus mengevaluasi apakah bug atau kerentanan tersebut akan disertakan dalam patch atau pembaruan keamanan untuk pengguna dengan instalasi mereka. Jika dia memutuskan bahwa suatu bug atau kerentanan perlu diperbarui, pekerjaan persiapan dimulai.
Manajer rilis harus memutuskan apakah akan menyiapkan perbaikan, atau kapan menerapkannya - dan ini sangat bergantung pada konteks situasinya, "Sementara itu, mesin tidak sebaik manusia dalam mengelola konteks"ucap Marin.
Ini semua tentang perbaikannya
Apa itu patch dan mengapa kita membutuhkannya?
Manajer rilis memutuskan apakah akan merilis perbaikan berdasarkan tingkat keparahan bug.
Kesalahan bervariasi tergantung pada tingkat keparahannya. Jadi kesalahan S4 atau S3 bisa bersifat gaya, seperti perpindahan piksel atau ikon. Hal ini tidak kalah pentingnya, namun tidak ada dampak yang signifikan terhadap alur kerja siapa pun, yang berarti kecil kemungkinan terjadinya perbaikan untuk kesalahan S3 atau S4 tersebut, jelas Marin.
Namun, kerentanan S1 atau S2 berarti pengguna tidak boleh memperbarui ke versi terbaru, atau terdapat bug signifikan yang memengaruhi alur kerja pengguna. Jika mereka disertakan dalam pelacak, banyak pengguna yang menemukannya, sehingga manajer rilis segera mulai menyiapkan perbaikan.
Setelah patch untuk kerentanan S1 atau S2 siap, manajer rilis mulai merilis patch tersebut.
Misalnya, patch GitLab 12.10.1 dibuat setelah beberapa masalah pemblokiran teridentifikasi dan pengembang memperbaiki masalah mendasar yang menyebabkan masalah tersebut. Manajer Rilis menilai kebenaran tingkat keparahan yang ditetapkan, dan setelah konfirmasi, proses pelepasan perbaikan diluncurkan, yang siap dalam waktu XNUMX jam setelah masalah pemblokiran ditemukan.
Ketika banyak S4, S3 dan S2 terakumulasi, manajer rilis melihat konteksnya untuk menentukan urgensi rilis perbaikan, dan ketika jumlah tertentu tercapai, semuanya digabungkan dan dirilis. Perbaikan pasca-rilis atau pembaruan keamanan dirangkum dalam postingan blog.
Bagaimana manajer rilis membuat patch
Kami menggunakan GitLab CI dan fitur lain seperti ChatOps kami untuk membuat patch. Manajer rilis memulai rilis perbaikan dengan mengaktifkan tim ChatOps di saluran internal kami #releases di kendur.
/chatops run release prepare 12.10.1ChatOps bekerja di dalam Slack untuk memicu berbagai peristiwa, yang kemudian diproses dan dijalankan oleh GitLab. Misalnya, tim pengiriman menyiapkan ChatOps untuk mengotomatiskan berbagai hal untuk merilis patch.
Setelah manajer rilis memulai tim ChatOps di Slack, pekerjaan selanjutnya dilakukan secara otomatis di GitLab menggunakan CICD. Ada komunikasi dua arah antara ChatOps di Slack dan GitLab selama proses rilis saat manajer rilis mengaktifkan beberapa langkah utama dalam proses tersebut.
Video di bawah ini menunjukkan proses teknis mempersiapkan patch untuk GitLab.
Cara kerja penerapan otomatis di gitlab.com
Proses dan alat yang digunakan untuk memperbarui gitlab.com serupa dengan yang digunakan untuk membuat tambalan. Memperbarui gitlab.com memerlukan lebih sedikit pekerjaan manual dari sudut pandang manajer rilis.
Daripada menjalankan penerapan menggunakan ChatOps, kami menggunakan fitur CI, misalnya. , yang dengannya manajer rilis dapat menjadwalkan tindakan tertentu untuk dilakukan pada waktu yang diperlukan. Alih-alih proses manual, ada saluran yang berjalan secara berkala satu jam sekali yang mengunduh perubahan baru yang dibuat pada proyek GitLab, mengemasnya dan menjadwalkan penerapan, dan secara otomatis menjalankan pengujian, QA, dan langkah-langkah lain yang diperlukan.
βJadi kami memiliki banyak penerapan yang berjalan di lingkungan berbeda sebelum gitlab.com, dan setelah lingkungan tersebut berada dalam kondisi yang baik dan pengujian menunjukkan hasil yang baik, manajer rilis memulai tindakan penerapan gitlab.com,β kata Marin.
Teknologi CICD untuk mendukung pembaruan gitlab.com mengotomatiskan seluruh proses hingga manajer rilis harus secara manual meluncurkan penerapan lingkungan produksi ke gitlab.com.
Marin menjelaskan secara detail tentang proses pembaruan gitlab.com dalam video di bawah ini.
Apa lagi yang dilakukan tim pengiriman?
Perbedaan utama antara proses pembaruan gitlab.com dan rilis patch ke pelanggan internal adalah bahwa proses terakhir memerlukan lebih banyak waktu dan lebih banyak pekerjaan manual dari manajer rilis.
βKami terkadang menunda peluncuran patch ke pelanggan dengan instalasi mereka karena masalah yang dilaporkan, masalah peralatan, dan karena ada banyak perbedaan yang perlu dipertimbangkan saat merilis satu patch,β kata Marin.
Salah satu tujuan jangka pendek tim pengiriman adalah mengurangi jumlah pekerjaan manual di pihak manajer rilis untuk mempercepat rilis. Tim ini berupaya menyederhanakan, menyederhanakan, dan mengotomatiskan proses rilis, yang akan membantu memperbaiki masalah dengan tingkat keparahan rendah (S3 dan S4, kira-kira Penerjemah). Berfokus pada kecepatan adalah indikator kinerja utama: MTTP perlu dikurangi - waktu mulai dari menerima permintaan penggabungan hingga menyebarkan hasilnya ke gitlab.com - dari saat ini 50 jam menjadi 8 jam.
Tim pengiriman juga berupaya memigrasikan gitlab.com ke infrastruktur berbasis Kubernetes.
Catatan Redaksi: Jika Anda pernah mendengar tentang teknologi Kubernetes (dan saya yakin Anda pernah mendengarnya), tetapi belum menyentuhnya dengan tangan Anda, saya sarankan untuk mengikuti kursus intensif online , yang akan berlangsung 28-30 September, dan , yang akan berlangsung 14-16 Oktober. Ini akan memungkinkan Anda menavigasi dan bekerja dengan teknologi dengan percaya diri.
Ini adalah dua pendekatan yang memiliki tujuan yang sama: pengiriman pembaruan yang cepat, baik untuk gitlab.com maupun untuk klien di fasilitas mereka.
Ada ide atau rekomendasi untuk kami?
Setiap orang dipersilakan untuk berkontribusi pada GitLab, dan kami menyambut masukan dari pembaca kami. Jika Anda memiliki ide untuk tim pengiriman kami, jangan ragu dengan pemberitahuan team: Delivery.
Sumber: www.habr.com