Методологија имплементације пројекта која се користи у Слацк-у

Довођење новог издања пројекта у производњу захтева пажљив баланс између брзине примене и поузданости решења. Слацк вреднује брзе итерације, кратке циклусе повратних информација и брз одговор на захтеве корисника. Поред тога, компанија има стотине програмера који настоје да буду што продуктивнији.

Аутори материјала, чији превод данас објављујемо, кажу да компанија која настоји да се придржава таквих вредности и истовремено расте мора стално да унапређује свој систем имплементације пројеката. Компанија треба да улаже у транспарентност и поузданост радних процеса, чинећи то како би се осигурало да ови процеси одговарају обиму пројекта. Овде ћемо говорити о токовима посла који су се развили у Слацк-у и о неким одлукама које су довеле компанију да користи систем за имплементацију пројеката који данас постоји.

Како данас функционишу процеси имплементације пројекта

Сваки ПР (пулл захтев) у Слацк-у мора бити предмет прегледа кода и мора успешно проћи све тестове. Тек након што су ови услови испуњени, програмер може спојити свој код у главну грану пројекта. Међутим, овај код се примењује само током радног времена, по северноамеричком времену. Као резултат тога, због чињенице да су наши запослени на својим радним местима, у потпуности смо спремни да решимо све неочекиване проблеме.

Сваког дана извршимо око 12 планираних распоређивања. Током сваке имплементације, програмер одређен као водећи за имплементацију је одговоран за стављање нове верзије у производњу. Ово је процес у више корака који осигурава да се склоп неометано доведе у производњу. Захваљујући овом приступу, можемо да откријемо грешке пре него што утичу на све наше кориснике. Ако има превише грешака, имплементација склопа се може вратити. Ако се након објављивања открије одређени проблем, лако се може објавити исправка за њега.

Интерфејс система Цхецкпоинт, који се користи у Слацк-у за имплементацију пројеката

Процес постављања новог издања у производњу може се сматрати да се састоји од четири корака.

▍1. Креирање гране издања

Свако издање почиње новом граном издања, тачком у нашој Гит историји. Ово вам омогућава да доделите ознаке издању и обезбеђује место где можете да правите исправке уживо за грешке пронађене у процесу припреме издања за пуштање у производњу.

▍2. Примена у сценском окружењу

Следећи корак је постављање склопа на сервере за постављање и покретање аутоматског теста за укупне перформансе пројекта (тест дима). Стагинг окружење је производно окружење које не прима спољни саобраћај. У овом окружењу вршимо додатно ручно тестирање. Ово нам даје додатно поверење да модификовани пројекат функционише исправно. Аутоматизовани тестови сами по себи нису довољни да обезбеде овај ниво самопоуздања.

▍3. Примена у окружењима са храном за псе и канаринцима

Примена у продукцији почиње са интерним окружењем, представљеним скупом хостова који служе нашим интерним Слацк радним просторима. Пошто смо веома активни Слацк корисници, овај приступ нам је помогао да ухватимо много грешака у раној фази примене. Након што смо се уверили да основна функционалност система није покварена, склоп се поставља у канаринско окружење. Представља системе који чине око 2% производног саобраћаја.

▍4. Постепено пуштање у производњу

Ако се индикатори праћења за ново издање покажу стабилним, и ако након постављања пројекта у канаринско окружење нисмо добили ниједну притужбу, настављамо са постепеним пребацивањем продукцијских сервера на ново издање. Процес имплементације је подељен у следеће фазе: 10%, 25%, 50%, 75% и 100%. Као резултат тога, можемо полако да пребацимо производни саобраћај на ново издање система. Истовремено, имамо времена да истражимо ситуацију ако се открију било какве аномалије.

▍Шта ако нешто крене наопако током постављања?

Прављење модификација кода је увек ризик. Али са овим се носимо захваљујући присуству добро обучених „вођа имплементације“ који управљају процесом довођења новог издања у производњу, прате индикаторе праћења и координирају рад програмера који објављују код.

У случају да нешто заиста крене наопако, трудимо се да откријемо проблем што је пре могуће. Истражујемо проблем, проналазимо ПР који узрокује грешке, враћамо га назад, анализирамо га темељно и креирамо нову верзију. Истина, понекад проблем остаје непримећен док пројекат не крене у производњу. У таквој ситуацији најважније је вратити услугу. Стога, пре него што почнемо да истражујемо проблем, одмах се враћамо на претходну радну верзију.

Грађевински блокови система за имплементацију

Хајде да погледамо технологије које су у основи нашег система имплементације пројекта.

▍Брза имплементација

Горе описани ток посла може изгледати, ретроспективно, помало очигледан. Али наш систем распоређивања није одмах постао овакав.

Када је компанија била много мања, цела наша апликација је могла да ради на 10 Амазон ЕЦ2 инстанци. Примена пројекта у овој ситуацији значила је коришћење рсинц за брзу синхронизацију свих сервера. Раније је нови код био само један корак од производње, представљен у окружењу за постављање. Склопови су креирани и тестирани у таквом окружењу, а затим су ишли директно у производњу. Било је веома лако разумети такав систем; дозвољавао је сваком програмеру да примени код који је написао у било ком тренутку.

Али како је растао број наших клијената, тако је растао и обим инфраструктуре потребне за подршку пројекту. Убрзо, с обзиром на константан раст система, наш модел примене, заснован на гурању новог кода на сервере, више није радио свој посао. Наиме, додавање сваког новог сервера значило је повећање времена потребног за завршетак имплементације. Чак и стратегије засноване на паралелној употреби рсинц-а имају одређена ограничења.

На крају смо решили овај проблем преласком на потпуно паралелни систем имплементације, који је дизајниран другачије од старог система. Наиме, сада нисмо слали код на сервере помоћу скрипте за синхронизацију. Сада је сваки сервер самостално преузео нови склоп, знајући да то треба да уради праћењем промене кључа Цонсул. Сервери су учитавали код паралелно. То нам је омогућило да одржимо велику брзину имплементације чак иу окружењу константног раста система.

1. Продукцијски сервери надгледају Цонсул кључ. 2. Кључ се мења, то говори серверима да треба да почну да преузимају нови код. 3. Сервери преузимају тарбалл датотеке са кодом апликације

▍Атомске примене

Још једно решење које нам је помогло да дођемо до вишеслојног система распоређивања било је атомско распоређивање.

Пре употребе атомских имплементација, свака примена може довести до великог броја порука о грешци. Чињеница је да процес копирања нових датотека на производне сервере није био атомски. Ово је резултирало кратким временским периодом у коме је код који је позивао нове функције био доступан пре него што су саме функције биле доступне. Када је такав код позван, то је резултирало враћањем интерних грешака. Ово се манифестовало у неуспелим захтевима за АПИ и поквареним веб страницама.

Тим који је радио на овом проблему га је решио увођењем концепта „врућих“ и „хладних“ директоријума. Код у врућем директоријуму је одговоран за обраду производног саобраћаја. А у „хладним” директоријумима, код се, док систем ради, само припрема за употребу. Током примене, нови код се копира у некоришћени хладни директоријум. Затим, када на серверу нема активних процеса, врши се тренутна промена директоријума.

1. Распакивање кода апликације у „хладни“ директоријум. 2. Пребацивање система на „хладни“ директоријум, који постаје „врућ“ (атомски рад)

Резултати: померање нагласка на поузданост

У 2018. пројекат је порастао до таквог обима да је веома брзо увођење почело да штети стабилности производа. Имали смо веома напредан систем распоређивања у који смо уложили много времена и труда. Све што је требало да урадимо је да обновимо и побољшамо наше процесе распоређивања. Израсли смо у прилично велику компанију, чији развој се користи широм света за организовање несметаних комуникација и решавање важних проблема. Стога је поузданост постала фокус наше пажње.

Морали смо да учинимо процес постављања нових Слацк издања безбеднијим. Ова потреба нас је навела да побољшамо наш систем распоређивања. У ствари, горе смо разговарали о овом побољшаном систему. У дубинама система, настављамо да користимо технологије брзе и атомске имплементације. Начин на који се врши распоређивање се променио. Наш нови систем је дизајниран да постепено примењује нови код на различитим нивоима, у различитим окружењима. Сада користимо напредније алате за подршку и алате за праћење система него раније. Ово нам даје могућност да ухватимо и поправимо грешке много пре него што имају прилику да дођу до крајњег корисника.

Али нећемо ту стати. Овај систем стално унапређујемо, користећи напредније помоћне алате и алате за аутоматизацију рада.

Драги читаоци! Како функционише процес постављања нових издања пројекта тамо где радите?

Извор: ввв.хабр.цом