Cara kami mengeluarkan patch perisian dalam GitLab

Cara kami mengeluarkan patch perisian dalam GitLab

Di GitLab, kami memproses pembetulan perisian dalam dua cara: secara manual dan automatik. Teruskan membaca untuk mengetahui tentang tugas pengurus keluaran untuk mencipta dan menyampaikan kemas kini penting melalui penggunaan automatik ke gitlab.com, serta tampalan untuk pengguna bekerja dengan pemasangan mereka sendiri.

Saya mengesyorkan menetapkan peringatan pada jam pintar anda: setiap bulan pada 22hb, pengguna yang bekerja dengan GitLab di kemudahan mereka boleh melihat kemas kini kepada versi semasa produk kami. Keluaran bulanan mengandungi ciri baharu, perkembangan yang sedia ada dan selalunya menunjukkan hasil akhir permintaan komuniti untuk perkakasan atau gabungan.

Tetapi, seperti yang ditunjukkan oleh amalan, pembangunan perisian jarang sekali tanpa cacat. Apabila pepijat atau kelemahan keselamatan ditemui, pengurus keluaran dalam pasukan penghantaran membuat tampung untuk pengguna kami dengan pemasangan mereka. Gitlab.com dikemas kini semasa proses CD. Kami memanggil proses CD ini penempatan automatik untuk mengelakkan kekeliruan dengan ciri CD dalam GitLab. Proses ini boleh menggabungkan cadangan daripada permintaan tarik yang dikemukakan oleh pengguna, pelanggan dan pasukan pembangunan dalaman kami, supaya menyelesaikan masalah membosankan untuk melepaskan patch diselesaikan dalam dua cara yang sangat berbeza.

Β«Kami memastikan semua yang dibuat oleh pembangun digunakan untuk semua persekitaran setiap hari sebelum melancarkannya ke GitLab.com", menerangkan Marin Jankovki, Pengurus Teknikal Kanan, Jabatan Infrastruktur. "Fikirkan keluaran untuk pemasangan anda sebagai syot kilat untuk penempatan gitlab.com, yang mana kami telah menambah langkah berasingan untuk membuat pakej supaya pengguna kami boleh menggunakannya untuk memasang pada pemasangan mereka'.

Tanpa mengira pepijat atau kelemahan, pelanggan gitlab.com akan menerima pembetulan sejurus selepas mereka diterbitkan, yang merupakan faedah daripada proses CD automatik. Tampalan untuk pengguna dengan pemasangan mereka sendiri memerlukan penyediaan berasingan oleh pengurus keluaran.

Pasukan penghantaran sedang bekerja keras untuk mengautomasikan kebanyakan proses yang terlibat dalam membuat keluaran untuk mengurangkan MTTP (masa min kepada pengeluaran, iaitu masa yang dibelanjakan untuk pengeluaran), tempoh masa daripada memproses permintaan penggabungan oleh pembangun kepada penggunaan di gitlab.com.

Β«Matlamat pasukan penghantaran adalah untuk memastikan bahawa kita boleh bergerak lebih pantas sebagai sebuah syarikat, atau sekurang-kurangnya membuat orang penghantaran bekerja lebih cepat, betul?, kata Marin.

Kedua-dua pelanggan gitlab.com dan pengguna pemasangan mereka mendapat manfaat daripada usaha pasukan penghantaran untuk mengurangkan masa kitaran dan mempercepatkan penggunaan. Dalam artikel ini kami akan menerangkan persamaan dan perbezaan antara kedua-dua kaedah ini. isu, dan kami juga akan menerangkan cara pasukan penghantaran kami menyediakan tampung untuk pengguna yang bekerja pada kemudahan mereka, serta cara kami memastikan bahawa gitlab.com dikemas kini menggunakan penempatan automatik.

Apakah yang dilakukan oleh pengurus pelepasan?

Ahli pasukan setiap bulan memindahkan peranan pengurus pelepasan keluaran kami kepada pengguna di kemudahan mereka, termasuk tampung dan keluaran keselamatan yang mungkin berlaku antara keluaran. Mereka juga bertanggungjawab untuk memimpin peralihan syarikat kepada penggunaan automatik dan berterusan.

Keluaran pemasangan sendiri dan keluaran gitlab.com menggunakan aliran kerja yang serupa tetapi dijalankan pada masa yang berbeza, jelas Marin.

Pertama sekali, pengurus keluaran, tanpa mengira jenis keluaran, memastikan bahawa GitLab tersedia dan selamat dari saat aplikasi dilancarkan di gitlab.com, termasuk memastikan bahawa isu yang sama tidak berakhir dalam infrastruktur pelanggan dengan mereka. kapasiti sendiri.

Sebaik sahaja pepijat atau kelemahan ditanda telah diperbaiki dalam GitLab, pengurus keluaran mesti menilai bahawa ia akan disertakan dalam tampung atau kemas kini keselamatan untuk pengguna dengan pemasangan mereka. Jika dia memutuskan bahawa pepijat atau kelemahan patut dikemas kini, kerja persediaan bermula.

Pengurus keluaran mesti memutuskan sama ada untuk menyediakan pembetulan, atau bila untuk menggunakannya - dan ini sangat bergantung pada konteks situasi, "Sementara itu, mesin tidak pandai mengurus konteks seperti manusia"kata Marin.

Ini semua tentang pembaikan

Apakah patch dan mengapa kita memerlukannya?

Pengurus keluaran memutuskan sama ada untuk mengeluarkan pembetulan berdasarkan keterukan pepijat.

Ralat berbeza-beza bergantung pada keterukan mereka. Jadi ralat S4 atau S3 boleh menjadi gaya, seperti anjakan piksel atau ikon. Ini tidak kurang pentingnya, tetapi tidak ada kesan yang ketara pada aliran kerja sesiapa sahaja, yang bermaksud bahawa kemungkinan pembetulan akan dibuat untuk ralat S3 atau S4 sedemikian adalah kecil, jelas Marin.

Walau bagaimanapun, kelemahan S1 atau S2 bermakna pengguna tidak seharusnya mengemas kini kepada versi terkini, atau terdapat pepijat ketara yang menjejaskan aliran kerja pengguna. Jika mereka disertakan dalam penjejak, ramai pengguna telah menemuinya, jadi pengurus keluaran segera mula menyediakan pembetulan.

Sebaik sahaja tampalan untuk kelemahan S1 atau S2 sedia, pengurus keluaran mula mengeluarkan tampung.

Sebagai contoh, tampung GitLab 12.10.1 telah dibuat selepas beberapa isu penyekatan dikenal pasti dan pembangun membetulkan isu asas yang menyebabkannya. Pengurus Keluaran menilai ketepatan tahap keterukan yang ditetapkan, dan selepas pengesahan, proses mengeluarkan pembetulan telah dilancarkan, yang telah siap dalam masa XNUMX jam selepas masalah penyekatan ditemui.

Apabila banyak S4, S3 dan S2 terkumpul, pengurus keluaran melihat konteks untuk menentukan keperluan mendesak untuk mengeluarkan pembetulan, dan apabila bilangan tertentu daripadanya dicapai, kesemuanya digabungkan dan dikeluarkan. Pembetulan selepas keluaran atau kemas kini keselamatan diringkaskan dalam catatan blog.

Cara pengurus keluaran mencipta tampung

Kami menggunakan GitLab CI dan ciri lain seperti ChatOps kami untuk menjana tampung. Pengurus keluaran memulakan keluaran pembetulan dengan mengaktifkan pasukan ChatOps pada saluran dalaman kami #releases dalam Slack.

/chatops run release prepare 12.10.1

ChatOps berfungsi dalam Slack untuk mencetuskan acara yang berbeza, yang kemudiannya diproses dan dilaksanakan oleh GitLab. Sebagai contoh, pasukan penghantaran menyediakan ChatOps untuk mengautomasikan pelbagai perkara untuk mengeluarkan patch.

Sebaik sahaja pengurus keluaran memulakan pasukan ChatOps dalam Slack, kerja selebihnya berlaku secara automatik dalam GitLab menggunakan CICD. Terdapat komunikasi dua hala antara ChatOps dalam Slack dan GitLab semasa proses keluaran kerana pengurus keluaran mengaktifkan beberapa langkah utama dalam proses tersebut.

Video di bawah menunjukkan proses teknikal menyediakan tampalan untuk GitLab.

Cara penggunaan automatik berfungsi pada gitlab.com

Proses dan alatan yang digunakan untuk mengemas kini gitlab.com adalah serupa dengan yang digunakan untuk membuat tampung. Mengemas kini gitlab.com memerlukan kurang kerja manual dari sudut pandangan pengurus keluaran.

Daripada menjalankan penggunaan menggunakan ChatOps, kami menggunakan ciri CI cth. saluran paip berjadual, yang mana pengurus keluaran boleh menjadualkan tindakan tertentu untuk dilakukan pada masa yang diperlukan. Daripada proses manual, terdapat saluran paip yang berjalan secara berkala sekali sejam yang memuat turun perubahan baharu yang dibuat pada projek GitLab, membungkusnya dan menjadualkan penggunaan serta menjalankan ujian, QA dan langkah lain yang diperlukan secara automatik.

"Jadi, kami mempunyai banyak penempatan yang dijalankan dalam persekitaran yang berbeza sebelum gitlab.com, dan selepas persekitaran tersebut berada dalam keadaan baik dan ujian menunjukkan hasil yang baik, pengurus keluaran memulakan tindakan penggunaan gitlab.com," kata Marin.

Teknologi CICD untuk menyokong kemas kini gitlab.com mengautomasikan keseluruhan proses sehingga pengurus keluaran mesti melancarkan penggunaan persekitaran pengeluaran secara manual ke gitlab.com.

Marin menerangkan secara terperinci tentang proses kemas kini gitlab.com dalam video di bawah.

Apa lagi yang dilakukan oleh pasukan penghantaran?

Perbezaan utama antara proses kemas kini gitlab.com dan mengeluarkan patch kepada pelanggan secara dalaman ialah proses kedua memerlukan lebih banyak masa dan lebih banyak kerja manual daripada pengurus keluaran.

"Kami kadangkala menangguhkan pengeluaran tampalan kepada pelanggan dengan pemasangan mereka disebabkan isu yang dilaporkan, isu perkakasan dan kerana terdapat banyak nuansa yang perlu diambil kira semasa mengeluarkan tampung tunggal," kata Marin.

Salah satu matlamat jangka pendek pasukan penghantaran adalah untuk mengurangkan jumlah kerja manual di pihak pengurus pelepasan untuk mempercepatkan pelepasan. Pasukan ini sedang berusaha untuk memudahkan, memperkemas dan mengautomasikan proses keluaran, yang akan membantu mendapatkan pembetulan kepada isu keterukan rendah (S3 dan S4, lebih kurang penterjemah). Memfokuskan pada kelajuan ialah penunjuk prestasi utama: adalah perlu untuk mengurangkan MTTP - masa daripada menerima permintaan penggabungan kepada melaksanakan keputusan ke gitlab.com - daripada 50 jam semasa kepada 8 jam.

Pasukan penghantaran juga sedang berusaha untuk memindahkan gitlab.com ke infrastruktur berasaskan Kubernetes.

N.b editor.: Jika anda telah mendengar tentang teknologi Kubernetes (dan saya tidak ragu-ragu bahawa anda telah melakukannya), tetapi masih belum menyentuhnya dengan tangan anda, saya cadangkan untuk mengambil bahagian dalam kursus intensif dalam talian Pangkalan Kubernetes, yang akan diadakan pada 28-30 September, dan Kubernetes Mega, yang akan berlangsung pada 14–16 Oktober. Ini akan membolehkan anda menavigasi dan bekerja dengan teknologi dengan yakin.

Ini adalah dua pendekatan yang mengejar matlamat yang sama: penghantaran kemas kini yang pantas, untuk gitlab.com dan untuk pelanggan di kemudahan mereka.

Sebarang idea atau cadangan untuk kami?

Semua orang dialu-alukan untuk menyumbang kepada GitLab, dan kami mengalu-alukan maklum balas daripada pembaca kami. Jika anda mempunyai sebarang idea untuk pasukan penghantaran kami, jangan teragak-agak buat aplikasi dengan notis team: Delivery.

Sumber: www.habr.com

Tambah komen