Nggawa rilis proyek anyar menyang produksi mbutuhake keseimbangan sing ati-ati antarane kacepetan panyebaran lan linuwih solusi. Nilai Slack iterasi cepet, siklus umpan balik sing cendhak, lan respon cepet kanggo panjaluk pangguna. Kajaba iku, perusahaan duwe atusan programer sing ngupayakake supaya bisa produktif.
Penulis materi, terjemahan sing diterbitake saiki, ujar manawa perusahaan sing ngupayakake netepi nilai kasebut lan ing wektu sing padha tuwuh kudu terus nambah sistem penyebaran proyek. Perusahaan kudu nandur modal ing transparansi lan linuwih proses kerja, nindakake iki kanggo mesthekake yen proses kasebut cocog karo skala proyek kasebut. Ing kene kita bakal ngomong babagan alur kerja sing wis dikembangake ing Slack, lan babagan sawetara keputusan sing nyebabake perusahaan nggunakake sistem penyebaran proyek sing ana saiki.
Kepiye proses panyebaran proyek bisa digunakake saiki
Saben PR (panyuwunan tarik) ing Slack kudu ditinjau kode lan kudu sukses kabeh tes. Mung sawise kondisi kasebut bisa ditemokake programmer bisa nggabungake kode kasebut menyang cabang master proyek kasebut. Nanging, kode iki disebarake mung sajrone jam kerja, wektu Amerika Utara. Akibaté, amarga karyawan kita ana ing papan kerjane, kita wis siyap kanggo ngrampungake masalah sing ora dikarepake.
Saben dina kita nindakake udakara 12 penyebaran sing direncanakake. Sajrone saben panyebaran, programer sing ditunjuk minangka pimpinan penyebaran tanggung jawab kanggo nggawe produksi anyar. Iki minangka proses multi-langkah sing njamin perakitan digawa menyang produksi kanthi lancar. Thanks kanggo pendekatan iki, kita bisa ndeteksi kesalahan sadurunge mengaruhi kabeh pangguna. Yen ana akeh banget kasalahan, penyebaran Déwan bisa mbalek maneh. Yen masalah tartamtu ditemokaké sawise release, fix bisa gampang dirilis kanggo iku.
Antarmuka sistem Checkpoint, sing digunakake ing Slack kanggo nyebarake proyek
Proses deploying release anyar kanggo produksi bisa dianggep minangka dumadi saka papat langkah.
▍1. Nggawe cabang release
Saben rilis diwiwiti kanthi cabang rilis anyar, titik ing sejarah Git kita. Iki ngidini sampeyan nemtokake tag kanggo rilis lan nyedhiyakake papan ing ngendi sampeyan bisa ndandani kewan omo sing ditemokake ing proses nyiapake rilis kanggo rilis menyang produksi.
▍2. Penyebaran ing lingkungan pementasan
Langkah sabanjure kanggo masang Déwan ing server pementasan lan mbukak test otomatis kanggo kinerja sakabèhé saka project (test kumelun). Lingkungan pementasan minangka lingkungan produksi sing ora nampa lalu lintas eksternal. Ing lingkungan iki, kita nindakake testing manual tambahan. Iki menehi kapercayan tambahan yen proyek sing diowahi bisa digunakake kanthi bener. Tes otomatis mung ora cukup kanggo nyedhiyakake tingkat kapercayan iki.
▍3. Penyebaran ing dogfood lan lingkungan kenari
Penyebaran menyang produksi diwiwiti kanthi lingkungan dogfood, diwakili dening sakumpulan host sing nglayani ruang kerja Slack internal. Amarga kita minangka pangguna Slack sing aktif, pendekatan iki mbantu kita nyekel akeh kewan omo ing awal penyebaran. Sawise kita wis nggawe manawa fungsi dhasar saka sistem ora bejat, Déwan disebaraké ing lingkungan kenari. Iku nggambarake sistem sing kira-kira 2% saka lalu lintas produksi.
▍4. Rilis bertahap kanggo produksi
Yen indikator ngawasi kanggo rilis anyar dadi stabil, lan yen sawise nyebarake proyek kasebut ing lingkungan kenari kita durung nampa keluhan, kita terus mindhah server produksi menyang rilis anyar. Proses penyebaran dipérang dadi tahapan ing ngisor iki: 10%, 25%, 50%, 75% lan 100%. Akibaté, kita bisa alon-alon nransfer lalu lintas produksi menyang release anyar saka sistem. Ing wektu sing padha, kita duwe wektu kanggo neliti kahanan kasebut yen ana anomali sing dideteksi.
▍ Apa yen ana sing salah nalika nyebarake?
Nggawe modifikasi kode tansah dadi resiko. Nanging kita ngrampungake iki amarga anané "pemimpin penyebaran" sing dilatih kanthi apik sing ngatur proses nggawa rilis anyar menyang produksi, ngawasi indikator pemantauan lan koordinasi karya programer sing ngeculake kode.
Yen ana sing salah, kita nyoba ndeteksi masalah kasebut kanthi cepet. Kita neliti masalah kasebut, golek PR sing nyebabake kesalahan, gulung maneh, analisa kanthi tliti, lan nggawe bangunan anyar. Bener, kadhangkala masalah kasebut ora diweruhi nganti proyek kasebut dadi produksi. Ing kahanan kaya mengkono, sing paling penting yaiku mulihake layanan kasebut. Mula, sadurunge miwiti neliti masalah kasebut, kita langsung bali menyang bangunan kerja sadurunge.
Blok Bangunan Sistem Penyebaran
Ayo goleki teknologi sing ndasari sistem penyebaran proyek kita.
▍Panyebaran cepet
Alur kerja sing diterangake ing ndhuwur bisa uga katon, ing retrospect, rada ketok. Nanging sistem penyebaran kita ora langsung dadi kaya iki.
Nalika perusahaan luwih cilik, kabeh aplikasi bisa mlaku ing 10 instans Amazon EC2. Nyebarake proyek ing kahanan iki tegese nggunakake rsync kanggo nyinkronake kabeh server kanthi cepet. Sadurunge, kode anyar mung siji langkah adoh saka produksi, diwakili dening lingkungan pementasan. Majelis digawe lan diuji ing lingkungan kasebut, banjur langsung menyang produksi. Iku gampang banget kanggo mangerteni sistem kasebut; ngidini programer kanggo masang kode sing wis ditulis ing sembarang wektu.
Nanging amarga jumlah klien saya tambah akeh, uga skala infrastruktur sing dibutuhake kanggo ndhukung proyek kasebut. Ora suwe, amarga sistem terus berkembang, model penyebaran kita, adhedhasar push kode anyar menyang server, ora nindakake tugas maneh. Yaiku, nambah saben server anyar tegese nambah wektu sing dibutuhake kanggo ngrampungake penyebaran. Malah strategi adhedhasar panggunaan paralel rsync duwe watesan tartamtu.
Kita rampung ngrampungake masalah iki kanthi pindhah menyang sistem penyebaran paralel, sing dirancang kanthi beda saka sistem lawas. Yaiku, saiki kita ora ngirim kode menyang server nggunakake skrip sinkronisasi. Saiki saben server bebas ndownload perakitan anyar, ngerti yen kudu ditindakake kanthi ngawasi owah-owahan tombol Konsul. Server ngemot kode kasebut kanthi paralel. Iki ngidini kita njaga kacepetan panyebaran kanthi cepet sanajan ing lingkungan sing terus berkembang sistem.
1. Server produksi ngawasi tombol Konsul. 2. Owah-owahan tombol, iki ngandhani server sing kudu miwiti ndownload kode anyar. 3. Server ngundhuh file tarball kanthi kode aplikasi
▍Panyebaran atom
Solusi liyane sing mbantu kita nggayuh sistem penyebaran multi-tier yaiku penyebaran atom.
Sadurunge nggunakake panyebaran atom, saben panyebaran bisa nyebabake akeh pesen kesalahan. Kasunyatane yaiku proses nyalin file anyar menyang server produksi ora atom. Iki nyebabake wektu cendhak nalika kode sing diarani fungsi anyar kasedhiya sadurunge fungsi kasebut kasedhiya. Nalika kode kasebut diarani, iki nyebabake kesalahan internal bali. Iki diwujudake ing panjaluk API sing gagal lan kaca web sing rusak.
Tim sing nggarap masalah iki ngrampungake kanthi ngenalake konsep direktori "panas" lan "kadhemen". Kode ing direktori panas tanggung jawab kanggo ngolah lalu lintas produksi. Lan ing direktori "kadhemen", kode kasebut, nalika sistem mlaku, mung disiapake kanggo digunakake. Sajrone panyebaran, kode anyar disalin menyang direktori kadhemen sing ora digunakake. Banjur, nalika ora ana proses aktif ing server, saklar direktori cepet ditindakake.
1. Unpacking kode aplikasi menyang direktori "kadhemen". 2. Ngalih sistem menyang direktori "kadhemen", sing dadi "panas" (operasi atom)
Asil: owah-owahan ing emphasis kanggo linuwih
Ing taun 2018, proyek kasebut tuwuh dadi skala sing cepet banget, mula nyebarake kanthi cepet ngrusak stabilitas produk. Kita duwe sistem panyebaran sing luwih maju, sing nandur modal akeh wektu lan gaweyan. Kabeh sing perlu kita lakoni yaiku mbangun maneh lan nambah proses penyebaran. Kita wis berkembang dadi perusahaan sing cukup gedhe, sing perkembangane wis digunakake ing saindenging jagad kanggo ngatur komunikasi tanpa gangguan lan ngrampungake masalah penting. Mulane, linuwih dadi fokus perhatian kita.
Kita kudu nggawe proses nyebarake rilis Slack anyar luwih aman. Kebutuhan iki nyebabake kita nambah sistem penyebaran kita. Ing kasunyatan, kita ngrembug sistem sing luwih apik ing ndhuwur. Ing jero sistem, kita terus nggunakake teknologi panyebaran cepet lan atom. Cara panyebaran wis diganti. Sistem anyar kita dirancang kanggo nyebarake kode anyar kanthi bertahap ing tingkat sing beda, ing lingkungan sing beda. Saiki kita nggunakake alat dhukungan lan alat ngawasi sistem sing luwih maju tinimbang sadurunge. Iki menehi kita kemampuan kanggo nyekel lan ndandani kasalahan dawa sadurunge padha duwe kesempatan kanggo nggayuh pangguna pungkasan.
Nanging kita ora bakal mandheg ing kana. Kita terus-terusan ngapikake sistem iki, nggunakake alat bantu sing luwih maju lan alat otomatisasi kerja.
Para pamaca ingkang kinurmatan! Kepiye proses nyebarake rilis proyek anyar ing ngendi sampeyan kerja?
Source: www.habr.com