Ing GitLab, kita ngolah piranti lunak kanthi rong cara: kanthi manual lan otomatis. Waca terus kanggo sinau babagan tugas manajer rilis nggawe lan ngirim nganyari penting liwat panyebaran otomatis menyang gitlab.com, uga patch kanggo pangguna sing bisa digunakake ing instalasi dhewe.
Aku nyaranake nyetel pangeling ing smartwatch sampeyan: saben sasi ing tanggal 22, pangguna sing nggarap GitLab ing fasilitas bisa ndeleng nganyari versi produk kita saiki. Rilis saben wulan ngemot fitur-fitur anyar, pangembangan sing wis ana, lan asring nuduhake asil pungkasan panjaluk komunitas kanggo perkakas utawa gabungan.
Nanging, minangka praktik nuduhake, pangembangan piranti lunak arang banget tanpa cacat. Nalika bug utawa kerentanan keamanan ditemokake, manajer rilis ing tim pangiriman nggawe tembelan kanggo pangguna kita kanthi instalasi. Gitlab.com dianyari sajrone proses CD. Kita nelpon proses CD iki penyebaran otomatis supaya ora kebingungan karo fitur CD ing GitLab. Proses iki bisa nggabungake saran saka panjalukan narik sing diajukake dening pangguna, pelanggan, lan tim pangembangan internal, supaya ngrampungake masalah sing mboseni kanggo ngeculake patch ditanggulangi kanthi rong cara sing beda banget.
Β«Kita mesthekake yen kabeh sing digawe pangembang disebarake menyang kabeh lingkungan saben dina sadurunge diluncurake menyang GitLab.com", nerangake , Manajer Teknis Senior, Departemen Infrastruktur. "Coba rilis kanggo panginstalan sampeyan minangka jepretan kanggo panyebaran gitlab.com, sing wis ditambahake langkah-langkah sing kapisah kanggo nggawe paket supaya pangguna bisa digunakake kanggo nginstal ing instalasi.".
Preduli saka bug utawa kerentanan, pelanggan gitlab.com bakal nampa perbaikan sakcepete sawise diterbitake, sing mupangati proses CD otomatis. Patch kanggo pangguna kanthi instalasi dhewe mbutuhake persiapan sing kapisah dening manajer rilis.
Tim pangiriman kerja keras kanggo ngotomatisasi sebagian besar proses sing melu nggawe rilis kanggo nyuda (tegese wektu kanggo produksi, yaiku wektu sing digunakake kanggo produksi), periode wektu saka proses panjalukan gabungan dening pangembang kanggo penyebaran ing gitlab.com.
Β«Tujuane tim pengiriman yaiku kanggo mesthekake yen kita bisa luwih cepet minangka perusahaan, utawa paling ora nggawe wong sing ngirim luwih cepet, bener.?, ujare Marin.
Pelanggan gitlab.com lan pangguna instalasi entuk manfaat saka upaya tim pangiriman kanggo nyuda wektu siklus lan nyepetake penyebaran. Ing artikel iki kita bakal nerangake podho lan beda antarane rong cara iki. , lan kita uga bakal njlèntrèhaké cara tim pangiriman kita nyiapake patch kanggo pangguna sing nggarap fasilitas, uga carane kita mesthekake yen gitlab.com dianyari nggunakake penyebaran otomatis.
Apa sing ditindakake manajer rilis?
Anggota tim saben wulan rilis kita kanggo pangguna ing fasilitas, kalebu patch lan rilis keamanan sing bisa kedadeyan ing antarane rilis. Dheweke uga tanggung jawab kanggo mimpin transisi perusahaan menyang penyebaran otomatis lan terus-terusan.
Rilis instalasi mandiri lan rilis gitlab.com nggunakake alur kerja sing padha nanging mlaku ing wektu sing beda, Marin nerangake.
Kaping pisanan, manajer rilis, preduli saka jinis rilis, mesthekake yen GitLab kasedhiya lan aman wiwit aplikasi kasebut diluncurake ing gitlab.com, kalebu mesthekake yen masalah sing padha ora ana ing infrastruktur pelanggan karo dheweke. kapasitas dhewe.
Sawise bug utawa kerentanan ditandhani tetep ing GitLab, manajer rilis kudu ngevaluasi manawa bakal dilebokake ing patch utawa nganyari keamanan kanggo pangguna kanthi instalasi. Yen dheweke mutusake manawa bug utawa kerentanan kudu nganyari, kerja persiapan diwiwiti.
Manajer rilis kudu mutusake apa arep nyiapake fix, utawa kapan bakal nyebarake - lan iki gumantung banget karo konteks kahanan kasebut, "ing sawetoro wektu, mesin ora apik kanggo ngatur konteks minangka wong"ujare Marin.
Iku kabeh babagan mbenakake
Apa patch lan kenapa kita butuh?
Manajer rilis mutusake apa bakal ngeculake fix adhedhasar keruwetan bug kasebut.
Kasalahan beda-beda gumantung saka keruwetan. Dadi kesalahan S4 utawa S3 bisa dadi gaya, kayata pamindahan piksel utawa lambang. Iki ora kurang penting, nanging ora ana impact pinunjul ing workflow sapa, kang tegese kamungkinan sing fix bakal digawe kanggo kesalahan S3 utawa S4 kuwi cilik, nerangake Marin.
Nanging, kerentanan S1 utawa S2 tegese pangguna ora kudu nganyari menyang versi paling anyar, utawa ana bug sing signifikan sing mengaruhi alur kerja pangguna. Yen kalebu ing tracker, akeh pangguna sing nemoni, mula manajer rilis langsung miwiti nyiapake.
Sawise tembelan kanggo kerentanan S1 utawa S2 wis siyap, manajer rilis wiwit ngeculake tembelan kasebut.
Contone, patch GitLab 12.10.1 digawe sawise sawetara masalah pamblokiran diidentifikasi lan pangembang ndandani masalah dhasar sing nyebabake. Manajer Rilis netepake kabeneran tingkat keruwetan sing ditugasake, lan sawise konfirmasi, proses ngeculake fix diluncurake, sing wis siyap sajrone XNUMX jam sawise masalah pamblokiran ditemokake.
Nalika akeh S4, S3 lan S2 nglumpukake, manager release katon ing konteks kanggo nemtokake urgency release fix, lan nalika nomer tartamtu saka wong-wong mau wis tekan, kabeh digabungake lan dirilis. Perbaikan sawise rilis utawa nganyari keamanan dirangkum ing kiriman blog.
Kepiye manajer rilis nggawe patch
Kita nggunakake GitLab CI lan fitur liyane kaya ChatOps kita kanggo ngasilake patch. Manajer rilis miwiti rilis fix kanthi ngaktifake tim ChatOps ing saluran internal kita #releases ing Slack.
/chatops run release prepare 12.10.1ChatOps dianggo ing Slack kanggo micu macem-macem acara, sing banjur diproses lan dieksekusi dening GitLab. Contone, tim pangiriman nyiyapake ChatOps kanggo ngotomatisasi macem-macem perkara kanggo ngeculake patch.
Sawise manajer rilis miwiti tim ChatOps ing Slack, karya liyane bakal ditindakake kanthi otomatis ing GitLab nggunakake CICD. Ana komunikasi rong arah ing antarane ChatOps ing Slack lan GitLab sajrone proses rilis amarga manajer rilis ngaktifake sawetara langkah utama ing proses kasebut.
Video ing ngisor iki nuduhake proses teknis nyiapake tembelan kanggo GitLab.
Kepiye cara penyebaran otomatis ing gitlab.com
Proses lan alat sing digunakake kanggo nganyari gitlab.com padha karo sing digunakake kanggo nggawe tambalan. Nganyari gitlab.com mbutuhake karya manual sing kurang saka sudut pandang manajer rilis.
Tinimbang mlaku penyebaran nggunakake ChatOps, kita nggunakake fitur CI contone. , sing manajer rilis bisa gawe jadwal tumindak tartamtu sing bakal ditindakake ing wektu sing dibutuhake. Tinimbang proses manual, ana pipa sing mlaku kanthi periodik sapisan saben jam sing ndownload owah-owahan anyar sing digawe kanggo proyek GitLab, paket lan jadwal penyebaran, lan kanthi otomatis mbukak testing, QA lan langkah-langkah liyane sing perlu.
"Dadi kita duwe akeh panyebaran sing mlaku ing lingkungan sing beda-beda sadurunge gitlab.com, lan sawise lingkungan kasebut apik lan tes nuduhake asil sing apik, manajer rilis miwiti tumindak penyebaran gitlab.com," ujare Marin.
Teknologi CICD kanggo ndhukung nganyari gitlab.com ngotomatisasi kabeh proses nganti manajer rilis kudu miwiti penyebaran lingkungan produksi kanthi manual menyang gitlab.com.
Marin dadi rinci babagan proses nganyari gitlab.com ing video ing ngisor iki.
Apa maneh sing ditindakake tim pangiriman?
Bentenane utama antarane proses nganyari gitlab.com lan ngeculake patch menyang pelanggan ing omah yaiku proses sing terakhir mbutuhake wektu luwih akeh lan luwih akeh karya manual saka manajer rilis.
"Kadhangkala kita tundha ngeculake patch menyang pelanggan kanthi instalasi amarga ana masalah sing dilaporake, masalah perkakas, lan amarga ana akeh nuansa sing kudu digatekake nalika ngeculake patch siji," ujare Marin.
Salah sawijining tujuan jangka pendek tim pangiriman yaiku nyuda jumlah karya manual ing bagean manajer rilis kanggo nyepetake rilis. Tim kasebut ngupayakake nyederhanakake, nyelarasake, lan ngotomatisasi proses rilis, sing bakal mbantu ngatasi masalah keruwetan sing sithik (S3 lan S4, kira-kira. penerjemah). Fokus ing kacepetan minangka indikator kinerja utama: perlu kanggo nyuda MTTP - wektu saka nampa panjalukan gabungan kanggo nyebarake asil menyang gitlab.com - saka 50 jam saiki nganti 8 jam.
Tim pangiriman uga nggarap migrasi gitlab.com menyang infrastruktur basis Kubernetes.
Editor n.b.: Yen sampeyan wis krungu babagan teknologi Kubernetes (lan aku ora mangu-mangu yen sampeyan duwe), nanging durung ndemek tangan, aku nyaranake melu kursus intensif online , kang bakal dianakakΓ© 28-30 September, lan , sing bakal ditindakake tanggal 14-16 Oktober. Iki bakal ngidini sampeyan navigasi kanthi yakin lan nggarap teknologi kasebut.
Iki minangka rong pendekatan sing nggayuh tujuan sing padha: pangiriman nganyari kanthi cepet, kanggo gitlab.com lan kanggo klien ing fasilitase.
Apa ana gagasan utawa rekomendasi kanggo kita?
Saben uwong olèh kontribusi kanggo GitLab, lan kita nampa umpan balik saka pembaca. Yen sampeyan duwe ide kanggo tim pengiriman, aja ragu-ragu kanthi kabar team: Delivery.
Source: www.habr.com