Ang pagdadala ng bagong paglabas ng proyekto sa produksyon ay nangangailangan ng maingat na balanse sa pagitan ng bilis ng pag-deploy at pagiging maaasahan ng solusyon. Binibigyang halaga ng Slack ang mga mabilis na pag-ulit, maikling cycle ng feedback, at agarang pagtugon sa mga kahilingan ng user. Bilang karagdagan, ang kumpanya ay may daan-daang mga programmer na nagsusumikap na maging produktibo hangga't maaari.
Ang mga may-akda ng materyal, ang pagsasalin na inilalathala namin ngayon, ay nagsasabi na ang isang kumpanya na nagsusumikap na sumunod sa mga naturang halaga at sa parehong oras ay lumalaki ay dapat na patuloy na mapabuti ang sistema ng pag-deploy ng proyekto nito. Ang kumpanya ay kailangang mamuhunan sa transparency at pagiging maaasahan ng mga proseso ng trabaho, ginagawa ito upang matiyak na ang mga prosesong ito ay tumutugma sa laki ng proyekto. Dito ay pag-uusapan natin ang tungkol sa mga daloy ng trabaho na nabuo sa Slack, at tungkol sa ilan sa mga desisyon na nagbunsod sa kumpanya na gamitin ang sistema ng pag-deploy ng proyekto na umiiral ngayon.
Paano gumagana ang mga proseso ng pag-deploy ng proyekto ngayon
Ang bawat PR (pull request) sa Slack ay dapat sumailalim sa pagsusuri ng code at dapat na matagumpay na makapasa sa lahat ng mga pagsubok. Pagkatapos lamang matugunan ang mga kundisyong ito, maaaring pagsamahin ng programmer ang kanyang code sa master branch ng proyekto. Gayunpaman, ang code na ito ay naka-deploy lamang sa mga oras ng negosyo, oras ng North American. Bilang resulta, dahil sa katotohanan na ang aming mga empleyado ay nasa kanilang mga lugar ng trabaho, kami ay ganap na handa upang malutas ang anumang hindi inaasahang mga problema.
Araw-araw ay nagsasagawa kami ng humigit-kumulang 12 nakaplanong pag-deploy. Sa bawat pag-deploy, ang programmer na itinalaga bilang lead sa deployment ay may pananagutan sa pagkuha ng bagong build sa produksyon. Ito ay isang multi-step na proseso na nagsisiguro na ang pagpupulong ay dinadala sa produksyon nang maayos. Salamat sa diskarteng ito, maaari naming makita ang mga error bago ito makaapekto sa lahat ng aming mga gumagamit. Kung mayroong masyadong maraming mga error, ang pag-deploy ng pagpupulong ay maaaring ibalik. Kung ang isang partikular na isyu ay natuklasan pagkatapos ilabas, ang isang pag-aayos ay madaling mailabas para dito.
Interface ng Checkpoint system, na ginagamit sa Slack para mag-deploy ng mga proyekto
Ang proseso ng pag-deploy ng bagong release sa produksyon ay maaaring isipin na binubuo ng apat na hakbang.
β1. Paglikha ng isang release branch
Ang bawat release ay nagsisimula sa isang bagong release branch, isang punto sa aming kasaysayan ng Git. Nagbibigay-daan ito sa iyong magtalaga ng mga tag sa release at nagbibigay ng lugar kung saan maaari kang gumawa ng mga live na pag-aayos para sa mga bug na makikita sa proseso ng paghahanda ng release para sa release sa produksyon.
β2. Deployment sa isang staging environment
Ang susunod na hakbang ay ang pag-deploy ng assembly sa mga staging server at magpatakbo ng awtomatikong pagsubok para sa pangkalahatang pagganap ng proyekto (smoke test). Ang kapaligiran ng pagtatanghal ay isang kapaligiran ng produksyon na hindi tumatanggap ng panlabas na trapiko. Sa ganitong kapaligiran, nagsasagawa kami ng karagdagang manu-manong pagsubok. Nagbibigay ito sa amin ng karagdagang kumpiyansa na gumagana nang tama ang binagong proyekto. Ang mga awtomatikong pagsubok lamang ay hindi sapat upang maibigay ang antas ng kumpiyansa na ito.
β3. Deployment sa dogfood at canary environment
Ang pag-deploy sa produksyon ay nagsisimula sa isang dogfood na kapaligiran, na kinakatawan ng isang hanay ng mga host na nagsisilbi sa aming mga panloob na workspace ng Slack. Dahil kami ay napaka-aktibong user ng Slack, ang paggamit ng diskarteng ito ay nakatulong sa amin na mahuli ang maraming mga bug nang maaga sa pag-deploy. Matapos naming matiyak na ang pangunahing pag-andar ng system ay hindi nasira, ang pagpupulong ay ipinakalat sa kapaligiran ng canary. Kinakatawan nito ang mga system na nagkakaloob ng humigit-kumulang 2% ng trapiko sa produksyon.
β4. Unti-unting paglabas sa produksyon
Kung ang mga indicator ng pagsubaybay para sa bagong release ay naging stable, at kung pagkatapos ng pag-deploy ng proyekto sa canary environment ay wala kaming natanggap na anumang reklamo, patuloy naming unti-unting inililipat ang mga production server sa bagong release. Ang proseso ng pag-deploy ay nahahati sa mga sumusunod na yugto: 10%, 25%, 50%, 75% at 100%. Bilang resulta, maaari naming dahan-dahang ilipat ang trapiko ng produksyon sa bagong release ng system. Kasabay nito, mayroon tayong panahon upang siyasatin ang sitwasyon kung may nakitang anomalya.
βPaano kung may mali sa panahon ng pag-deploy?
Ang paggawa ng mga pagbabago sa code ay palaging isang panganib. Ngunit nakayanan namin ito salamat sa pagkakaroon ng mahusay na sinanay na "mga pinuno ng deployment" na namamahala sa proseso ng pagdadala ng isang bagong release sa produksyon, sinusubaybayan ang mga indicator ng pagsubaybay at coordinate ang gawain ng mga programmer na naglalabas ng code.
Kung sakaling may mali talaga, sinusubukan naming tuklasin ang problema sa lalong madaling panahon. Sinisiyasat namin ang problema, hanapin ang PR na nagdudulot ng mga error, ibalik ito, masusing pag-aralan ito, at lumikha ng bagong build. Totoo, kung minsan ang problema ay hindi napapansin hanggang sa ang proyekto ay napupunta sa produksyon. Sa ganoong sitwasyon, ang pinakamahalagang bagay ay ibalik ang serbisyo. Samakatuwid, bago namin simulan ang pagsisiyasat sa problema, agad kaming bumalik sa dating gumaganang build.
Mga Building Block ng isang Deployment System
Tingnan natin ang mga teknolohiyang sumasailalim sa aming sistema ng pag-deploy ng proyekto.
βMabilis na pag-deploy
Ang daloy ng trabaho na inilarawan sa itaas ay maaaring mukhang, sa pagbabalik-tanaw, medyo halata. Ngunit ang aming deployment system ay hindi naging ganito kaagad.
Noong mas maliit ang kumpanya, maaaring tumakbo ang aming buong application sa 10 instance ng Amazon EC2. Ang pag-deploy ng proyekto sa sitwasyong ito ay nangangahulugan ng paggamit ng rsync upang mabilis na i-synchronize ang lahat ng mga server. Dati, ang bagong code ay isang hakbang lamang mula sa produksyon, na kinakatawan ng isang kapaligiran sa pagtatanghal. Ang mga pagtitipon ay nilikha at sinubukan sa gayong kapaligiran, at pagkatapos ay dumiretso sa produksyon. Napakadaling maunawaan ang ganoong sistema; pinapayagan nito ang sinumang programmer na i-deploy ang code na isinulat niya anumang oras.
Ngunit habang lumalaki ang bilang ng aming mga kliyente, lumaki rin ang laki ng imprastraktura na kinakailangan upang suportahan ang proyekto. Sa lalong madaling panahon, dahil sa patuloy na paglaki ng system, ang aming modelo ng deployment, batay sa pagtulak ng bagong code sa mga server, ay hindi na ginagawa ang trabaho nito. Ibig sabihin, ang pagdaragdag ng bawat bagong server ay nangangahulugan ng pagtaas ng oras na kinakailangan upang makumpleto ang pag-deploy. Kahit na ang mga diskarte batay sa parallel na paggamit ng rsync ay may ilang mga limitasyon.
Natapos namin ang paglutas ng problemang ito sa pamamagitan ng paglipat sa isang ganap na parallel na sistema ng pag-deploy, na idinisenyo nang iba mula sa lumang sistema. Lalo na, ngayon ay hindi kami nagpadala ng code sa mga server gamit ang isang synchronization script. Ngayon ang bawat server ay nakapag-iisa na nag-download ng bagong pagpupulong, alam na kailangan nitong gawin ito sa pamamagitan ng pagsubaybay sa pagbabago ng Consul key. Ang mga server ay nag-load ng code nang magkatulad. Nagpahintulot ito sa amin na mapanatili ang isang mataas na bilis ng pag-deploy kahit na sa isang kapaligiran ng patuloy na paglago ng system.
1. Sinusubaybayan ng mga production server ang Consul key. 2. Ang mga pangunahing pagbabago, ito ay nagsasabi sa mga server na kailangan nilang simulan ang pag-download ng bagong code. 3. Nagda-download ang mga server ng mga tarball file na may application code
βMga pag-deploy ng atom
Ang isa pang solusyon na nakatulong sa amin na maabot ang isang multi-tier na deployment system ay ang atomic deployment.
Bago gumamit ng mga atomic deployment, ang bawat deployment ay maaaring magresulta sa isang malaking bilang ng mga mensahe ng error. Ang katotohanan ay ang proseso ng pagkopya ng mga bagong file sa mga server ng produksyon ay hindi atomic. Nagresulta ito sa isang maikling palugit ng panahon kung saan ang code na tinatawag na mga bagong function ay magagamit bago ang mga pag-andar mismo ay magagamit. Kapag tinawag ang naturang code, nagresulta ito sa mga panloob na error na ibinalik. Nagpakita ito sa mga nabigong kahilingan sa API at mga sirang web page.
Ang pangkat na nagtrabaho sa problemang ito ay nalutas ito sa pamamagitan ng pagpapakilala ng konsepto ng "mainit" at "malamig" na mga direktoryo. Ang code sa mainit na direktoryo ay responsable para sa pagproseso ng trapiko ng produksyon. At sa "malamig" na mga direktoryo, ang code, habang tumatakbo ang system, ay inihahanda lamang para magamit. Sa panahon ng pag-deploy, ang bagong code ay kinokopya sa isang hindi nagamit na malamig na direktoryo. Pagkatapos, kapag walang mga aktibong proseso sa server, isang instant na paglipat ng direktoryo ay isinasagawa.
1. Pag-unpack ng application code sa isang "malamig" na direktoryo. 2. Paglipat ng system sa isang "malamig" na direktoryo, na nagiging "mainit" (atomic na operasyon)
Mga resulta: pagbabago sa diin sa pagiging maaasahan
Noong 2018, ang proyekto ay lumago sa isang sukat na ang napakabilis na pag-deploy ay nagsimulang makapinsala sa katatagan ng produkto. Nagkaroon kami ng napaka-advance na sistema ng pag-deploy kung saan nag-invest kami ng maraming oras at pagsisikap. Ang kailangan lang naming gawin ay muling buuin at pahusayin ang aming mga proseso sa pag-deploy. Kami ay lumago sa isang medyo malaking kumpanya, na ang mga pag-unlad ay ginamit sa buong mundo upang ayusin ang walang patid na mga komunikasyon at upang malutas ang mahahalagang problema. Samakatuwid, ang pagiging maaasahan ay naging pokus ng aming pansin.
Kailangan naming gawing mas secure ang proseso ng pag-deploy ng mga bagong release ng Slack. Ang pangangailangang ito ay humantong sa amin upang mapabuti ang aming deployment system. Sa katunayan, tinalakay namin ang pinahusay na sistemang ito sa itaas. Sa kaibuturan ng system, patuloy kaming gumagamit ng mabilis at atomic na mga teknolohiya sa pag-deploy. Nagbago ang paraan ng pag-deploy. Ang aming bagong system ay idinisenyo upang unti-unting mag-deploy ng bagong code sa iba't ibang antas, sa iba't ibang kapaligiran. Gumagamit na kami ngayon ng mas advanced na mga tool sa suporta at mga tool sa pagsubaybay ng system kaysa dati. Nagbibigay ito sa amin ng kakayahang mahuli at ayusin ang mga error bago pa sila magkaroon ng pagkakataong maabot ang end user.
Ngunit hindi tayo titigil doon. Patuloy naming pinapahusay ang system na ito, gamit ang mas advanced na mga pantulong na tool at mga tool sa automation ng trabaho.
Minamahal na mambabasa! Paano gumagana ang proseso ng pag-deploy ng mga bagong release ng proyekto kung saan ka nagtatrabaho?
Pinagmulan: www.habr.com