Alporti novan projekt-eldonon en produktadon postulas zorgan ekvilibron inter deploja rapideco kaj solvfidindeco. Slack taksas rapidajn ripetojn, mallongajn respondciklojn kaj rapidan respondon al uzantpetoj. Krome, la kompanio havas centojn da programistoj, kiuj strebas esti kiel eble plej produktivaj.
La aŭtoroj de la materialo, kies tradukon ni publikigas hodiaŭ, diras, ke kompanio, kiu strebas aliĝi al tiaj valoroj kaj samtempe kreskas, devas senĉese plibonigi sian projektan disfaldan sistemon. La kompanio devas investi en travidebleco kaj fidindeco de laborprocezoj, farante tion por certigi, ke ĉi tiuj procezoj respondas al la skalo de la projekto. Ĉi tie ni parolos pri la laborfluoj, kiuj disvolviĝis en Slack, kaj pri iuj el la decidoj, kiuj igis la kompanion uzi la projektan deplojsistemon, kiu ekzistas hodiaŭ.
Kiel projektaj deplojprocezoj funkcias hodiaŭ
Ĉiu PR (tira peto) en Slack devas esti submetita al koda revizio kaj devas sukcese trapasi ĉiujn testojn. Nur post kiam ĉi tiuj kondiĉoj estas plenumitaj, la programisto povas kunfandi sian kodon en la majstran branĉon de la projekto. Tamen, ĉi tiu kodo estas deplojita nur dum komercaj horoj, nordamerika tempo. Kiel rezulto, pro la fakto ke niaj dungitoj estas ĉe siaj laborlokoj, ni estas plene pretaj solvi ajnajn neatenditajn problemojn.
Ĉiutage ni efektivigas ĉirkaŭ 12 planitajn deplojojn. Dum ĉiu deplojo, la programisto indikita kiel la deplojgvidanto respondecas pri akirado de la nova konstruo en produktadon. Ĉi tio estas plurpaŝa procezo, kiu certigas, ke la asembleo estas produktata glate. Danke al ĉi tiu aliro, ni povas detekti erarojn antaŭ ol ili influas ĉiujn niajn uzantojn. Se estas tro da eraroj, la disfaldiĝo de la asembleo povas esti reprenita. Se specifa problemo estas malkovrita post liberigo, solvo povas facile esti liberigita por ĝi.
Interfaco de la Checkpoint-sistemo, kiu estas uzata en Slack por disfaldi projektojn
La procezo de deplojado de nova eldono al produktado povas esti opiniita kiel konsistanta el kvar paŝoj.
▍1. Kreante eldonbranĉon
Ĉiu eldono komenciĝas per nova eldonbranĉo, punkto en nia Git-historio. Ĉi tio permesas vin asigni etikedojn al la eldono kaj disponigas lokon kie vi povas fari vivajn korektojn por cimoj trovitaj en la procezo de preparado de la eldono por eldono al produktado.
▍2. Deplojo en sursceniga medio
La sekva paŝo estas deploji la asembleon sur enscenigantaj serviloj kaj ruli aŭtomatan teston por la ĝenerala agado de la projekto (fuma provo). La sursceniga medio estas produktadmedio kiu ne ricevas eksteran trafikon. En ĉi tiu medio, ni faras pliajn manajn provojn. Ĉi tio donas al ni plian fidon, ke la modifita projekto funkcias ĝuste. Aŭtomatigitaj testoj sole ne sufiĉas por provizi ĉi tiun nivelon de konfido.
▍3. Deplojo en hundomanĝo kaj kanariaj medioj
Deplojo al produktado komenciĝas per hunda medio, reprezentita de aro da gastigantoj, kiuj servas niajn internajn laborspacojn de Slack. Ĉar ni estas tre aktivaj uzantoj de Slack, preni ĉi tiun aliron helpis nin kapti multajn cimojn frue en la deplojo. Post kiam ni certigis, ke la baza funkcieco de la sistemo ne estas rompita, la aro estas deplojita en la kanaria medio. Ĝi reprezentas sistemojn kiuj respondecas pri proksimume 2% de produktadtrafiko.
▍4. Laŭgrada liberigo al produktado
Se la monitoraj indikiloj por la nova eldono montriĝas stabilaj, kaj se post deplojado de la projekto en la kanaria medio ni ne ricevis plendojn, ni daŭre transdonas iom post iom la produktadservilojn al la nova eldono. La deplojprocezo estas dividita en la sekvajn stadiojn: 10%, 25%, 50%, 75% kaj 100%. Kiel rezulto, ni povas malrapide transdoni produktan trafikon al la nova eldono de la sistemo. Samtempe, ni havas tempon por esplori la situacion se iuj anomalioj estas detektitaj.
▍Kion se io misfunkcias dum deplojo?
Fari modifojn al kodo ĉiam estas risko. Sed ni traktas ĉi tion danke al la ĉeesto de bone trejnitaj "deplojestroj", kiuj administras la procezon alporti novan eldonon en produktadon, kontrolas monitorajn indikilojn kaj kunordigas la laboron de programistoj liberigantaj kodon.
En la okazo, ke io vere misfunkcias, ni provas detekti la problemon kiel eble plej frue. Ni esploras la problemon, trovas la PR, kiu kaŭzas la erarojn, retroiras ĝin, analizas ĝin ĝisfunde kaj kreas novan konstruon. Vere, foje la problemo pasas nerimarkita ĝis la projekto eniras en produktadon. En tia situacio, la plej grava afero estas restarigi la servon. Tial, antaŭ ol ni komencas esplori la problemon, ni tuj reiras al la antaŭa funkcianta konstruo.
Konstrubrikoj de Deploja Sistemo
Ni rigardu la teknologiojn, kiuj subtenas nian projektan deplojsistemon.
▍Rapidaj deplojoj
La laborfluo priskribita supre povas ŝajni, retrospektive, iom evidenta. Sed nia deplojsistemo ne iĝis tiel tuj.
Kiam la kompanio estis multe pli malgranda, nia tuta aplikaĵo povus funkcii per 10 Amazon EC2-instancoj. Deploji la projekton en ĉi tiu situacio signifis uzi rsync por rapide sinkronigi ĉiujn servilojn. Antaŭe, nova kodo estis nur unu paŝo for de produktado, reprezentita per sursceniga medio. Asembleoj estis kreitaj kaj testitaj en tia medio, kaj poste iris rekte al produktado. Estis tre facile kompreni tian sistemon; ĝi permesis al iu ajn programisto deploji la kodon kiun li skribis iam ajn.
Sed dum la nombro de niaj klientoj kreskis, ankaŭ la skalo de la infrastrukturo necesa por subteni la projekton. Baldaŭ, konsiderante la konstantan kreskon de la sistemo, nia deplojmodelo, bazita sur puŝado de nova kodo al la serviloj, ne plu faris sian laboron. Nome, aldoni ĉiun novan servilon signifis pliigi la tempon necesan por kompletigi la deplojon. Eĉ strategioj bazitaj sur paralela uzo de rsync havas certajn limigojn.
Ni finis solvi ĉi tiun problemon moviĝante al tute paralela deplojsistemo, kiu estis desegnita malsame ol la malnova sistemo. Nome, nun ni ne sendis kodon al la serviloj per sinkroniga skripto. Nun ĉiu servilo sendepende elŝutis la novan asembleon, sciante, ke ĝi bezonas fari tion monitorante la ŝlosilan ŝanĝon de Konsulo. La serviloj ŝarĝis la kodon paralele. Ĉi tio permesis al ni konservi altan rapidecon de deplojo eĉ en medio de konstanta sistema kresko.
1. Produktaj serviloj monitoras la Konsulŝlosilon. 2. La ŝlosilo ŝanĝiĝas, ĉi tio diras al la serviloj, ke ili devas komenci elŝuti novan kodon. 3. Serviloj elŝutas tarball dosierojn kun aplika kodo
▍Atomaj deplojoj
Alia solvo, kiu helpis nin atingi plurnivelan deplojsistemon, estis atoma deplojo.
Antaŭ uzi atomdeplojojn, ĉiu deplojo povus rezultigi grandan nombron da erarmesaĝoj. La fakto estas, ke la procezo kopii novajn dosierojn al produktaj serviloj ne estis atoma. Tio rezultigis mallongan fenestron de tempo kie la kodo kiu vokis novajn funkciojn estis havebla antaŭ ol la funkcioj mem estis haveblaj. Kiam tia kodo estis vokita, ĝi rezultigis internajn erarojn estantajn resendita. Ĉi tio manifestiĝis en malsukcesaj API-petoj kaj rompitaj retpaĝoj.
La teamo kiu laboris pri ĉi tiu problemo solvis ĝin enkondukante la koncepton de "varmaj" kaj "malvarmaj" adresaroj. La kodo en la varma dosierujo respondecas pri prilaborado de produktada trafiko. Kaj en "malvarmaj" dosierujoj, la kodo, dum la sistemo funkcias, estas nur preta por uzo. Dum deplojo, nova kodo estas kopiita al neuzata malvarma dosierujo. Tiam, kiam ne estas aktivaj procezoj sur la servilo, tuja dosierŝanĝo estas farita.
1. Malpaki la aplikan kodon en "malvarman" dosierujon. 2. Ŝanĝi la sistemon al "malvarma" dosierujo, kiu fariĝas "varma" (atoma operacio)
Rezultoj: ŝanĝo en emfazo al fidindeco
En 2018, la projekto kreskis al tia skalo, ke tre rapida deplojo komencis damaĝi la stabilecon de la produkto. Ni havis tre altnivelan deplojan sistemon en kiun ni investis multe da tempo kaj peno. Ni nur bezonis rekonstrui kaj plibonigi niajn deplojajn procezojn. Ni kreskis al sufiĉe granda kompanio, kies evoluoj estis uzataj tra la tuta mondo por organizi seninterrompajn komunikadojn kaj solvi gravajn problemojn. Tial fidindeco fariĝis la fokuso de nia atento.
Ni devis fari la procezon de deplojado de novaj Slack-eldonoj pli sekura. Ĉi tiu bezono kondukis nin plibonigi nian deplojan sistemon. Fakte, ni diskutis ĉi tiun plibonigitan sistemon supre. En la profundoj de la sistemo, ni daŭre uzas rapidajn kaj atomajn deplojajn teknologiojn. La maniero de deplojo estas farita ŝanĝiĝis. Nia nova sistemo estas dizajnita por iom post iom deploji novan kodon sur malsamaj niveloj, en malsamaj medioj. Ni nun uzas pli altnivelajn subtenajn ilojn kaj sistemajn monitorajn ilojn ol antaŭe. Ĉi tio donas al ni la kapablon kapti kaj ripari erarojn longe antaŭ ol ili havas ŝancon atingi la finuzanton.
Sed ni ne haltos tie. Ni konstante plibonigas ĉi tiun sistemon, uzante pli altnivelajn helpajn ilojn kaj laboraŭtomatigajn ilojn.
Karaj legantoj! Kiel funkcias la procezo de deplojado de novaj projekt-eldonoj kie vi laboras?
fonto: www.habr.com