ДевОпс праксе раде. У то смо се и сами уверили када смо време инсталације издања смањили за 10 пута. У систему ФИС Профиле, који користимо у ВТБ-у, инсталација сада траје 90 минута уместо 10. Време израде издања је смањено са две недеље на два дана. Број упорних недостатака у имплементацији пао је скоро на минимум. Да бисмо се удаљили од „ручног рада“ и елиминисали зависност од продавца, морали смо да радимо са штакама и пронађемо неочекивана решења. Испод реза је детаљна прича о томе како смо изградили пуноправни унутрашњи развој.
Пролог: ДевОпс је филозофија
Током протекле године урадили смо доста посла на организовању интерног развоја и имплементације ДевОпс пракси у ВТБ:
- Изградили смо интерне развојне процесе за 12 система;
- Покренули смо 15 цевовода, од којих су четири доведена у производњу;
- Аутоматизовано 1445 тестних сценарија;
- Успешно смо имплементирали велики број издања које су припремили интерни тимови.
Један од најтежих за организовање унутрашњег развоја и имплементације ДевСецОпс пракси се показао ФИС Профиле системом - малопродајним процесором производа на нерелационом ДБМС-у. Ипак, били смо у могућности да направимо развој, покренемо цевовод, инсталирамо појединачне пакете без издања на производ и научимо како да састављамо издања. Задатак није био лак, али занимљив и без очигледних ограничења у имплементацији: ево система - потребно је да изградите сопствени развој. Једини услов је да користите ЦД пре продуктивног окружења.
У почетку је алгоритам имплементације изгледао једноставан и јасан:
- Развијамо почетну развојну експертизу и постижемо прихватљив ниво квалитета од кодног тима без грубих недостатака;
- Интегришемо се у постојеће процесе што је више могуће;
- Да бисмо пребацили код између очигледних фаза, пресечемо цевовод и гурнемо један од његових крајева у наставак.
Током овог времена, развојни тим потребне величине мора развити вештине и повећати удео свог доприноса издањима на прихватљив ниво. И то је то, можемо сматрати да је задатак завршен.
Чини се да је ово потпуно енергетски ефикасан пут до траженог резултата: ево ДевОпс-а, ево метрике учинка тима, ево акумулиране стручности... Али у пракси смо добили још једну потврду да је ДевОпс и даље филозофија , а не „прикачен за гитлаб процес, ансибле, некус и даље на листи.“
Након што смо још једном анализирали акциони план, схватили смо да у себи градимо неку врсту оутсоурце добављача. Због тога је горе описаном алгоритму додат реинжењеринг процеса, као и развој стручности дуж читавог пута развоја како би се постигла водећа улога у овом процесу. Није најлакша опција, али ово је пут идеолошки исправног развоја.
Где почиње унутрашњи развој?
То није био најпријатељскији систем за рад. Архитектонски, то је био један велики нерелациони ДБМС, састојао се од много засебних извршних објеката (скрипте, процедуре, групе итд.), који су се позивали по потреби, а радио је по принципу црне кутије: прима захтев и издаје одговор. Остале потешкоће које вреди напоменути укључују:
- Егзотични језик (МУМПС);
- Интерфејс конзоле;
- Недостатак интеграције са популарним алатима и оквирима за аутоматизацију;
- Обим података у десетинама терабајта;
- Оптерећење од преко 2 милиона операција на сат;
- Значај - пословно-критичан.
Истовремено, на нашој страни није постојало складиште изворног кода. Уопште. Документација је постојала, али сва кључна знања и компетенције су биле на страни спољне организације.
Почели смо да савладавамо развој система готово од нуле, узимајући у обзир његове карактеристике и ниску дистрибуцију. Почело у октобру 2018:
- Проучавао документацију и основе генерисања кода;
- Проучили смо кратак курс о развоју који смо добили од продавца;
- Овладао почетним развојним вештинама;
- Саставили смо приручник за обуку за нове чланове тима;
- Договорили смо се да укључимо тим у „борбени“ режим;
- Решен проблем са контролом квалитета кода;
- Организовали смо штанд за развој.
Провели смо три месеца развијајући експертизу и урањајући се у систем, а од почетка 2019. године, инхоусе развој је кренуо ка светлој будућности, понекад тешко, али самоуверено и циљано.
Миграција спремишта и аутотестови
Први ДевОпс задатак је спремиште. Брзо смо се договорили око обезбеђивања приступа, али је било неопходно прећи са тренутног СВН-а са једном транк граном на наш циљни Гит са преласком на модел неколико грана и развојем Гит Флов-а. Такође имамо 2 тима са сопственом инфраструктуром, плус део тима добављача у иностранству. Морао сам да живим са два Гита и да обезбедим синхронизацију. У таквој ситуацији, то је било мање од два зла.
Селидба складишта је више пута одлагана, завршена је тек у априлу, уз помоћ колега са прве линије фронта. Са Гит Флов-ом, одлучили смо да ствари за почетак буду једноставне и одлучили смо се на класичној шеми са хитном исправком, развојем и издавањем. Одлучили су да напусте мастер (ака прод-лике). У наставку ћемо објаснити зашто се ова опција показала оптималном за нас. Екстерно складиште које припада добављачу, заједничко за два тима, коришћено је као радник. Синхронизовано је са интерним репозиторијумом према распореду. Сада је са Гитом и Гитлаб-ом било могуће аутоматизовати процесе.
Питање аутотестова се решило изненађујуће лако - добили смо готов оквир. Узимајући у обзир специфичности система, позивање посебне операције је био разумљив део пословног процеса и истовремено је служио као јединични тест. Остало је само да се припреме подаци о тесту и да се подеси жељени редослед позивања скрипти и евалуације резултата. Како се листа сценарија, формирана на основу статистике рада, критичности процеса и постојеће методологије регресије, попуњавала, почели су да се појављују аутоматски тестови. Сада бисмо могли да почнемо да градимо гасовод.
Како је било: модел пре аутоматизације
Постојећи модел процеса имплементације је посебна прича. Свака модификација је ручно пренета као посебан инкрементални инсталациони пакет. Затим је уследила ручна регистрација у Јира и ручна инсталација у окружењима. За појединачне пакете све је изгледало јасно, али са припремом издања ствари су биле компликованије.
Монтажа је вршена на нивоу појединачних испорука, које су биле самостални објекти. Свака промена је нова испорука. Између осталог, 60–70 техничких верзија је додато у 10-15 пакета састава главног издања – верзије добијене додавањем или искључивањем нечега из издања и одражавањем промена у продаји ван издања.
Објекти унутар испорука су се преклапали једни са другима, посебно у извршном коду, који је био мање од половине јединствен. Било је много зависности како од већ инсталираног кода тако и од оног чија је инсталација управо планирана.
Да би се добила потребна верзија кода, било је неопходно стриктно пратити редослед инсталације, током којег су објекти физички преписани много пута, неких 10–12 пута.
Након инсталирања серије пакета, морао сам ручно да пратим упутства да иницијализујем подешавања. Издање је саставио и инсталирао продавац. Састав издања је разјашњен скоро пре тренутка имплементације, што је подразумевало креирање пакета за „децоуплинг“. Као резултат тога, значајан део залиха се кретао од издања до издања са сопственим репом „одвајања“.
Сада је јасно да са овим приступом – састављањем слагалице за издавање на нивоу пакета – једна главна грана није имала практично значење. Инсталација у производњи трајала је од једног и по до два сата ручног рада. Добро је да је бар на нивоу инсталатера прецизиран редослед обраде објеката: поља и структуре су унете пре података за њих и процедура. Међутим, ово је функционисало само у посебном пакету.
Логичан резултат оваквог приступа били су обавезни инсталацијски недостаци у виду искривљених верзија објеката, непотребног кода, недостајућих инструкција и неурачунатих међусобних утицаја објеката, који су грозничаво отклоњени након пуштања у рад.
Прва ажурирања: обавезна монтажа и испорука
Аутоматизација је почела преношењем кода кроз цев дуж ове руте:
- Покупите готову испоруку из складишта;
- Инсталирајте га у наменском окружењу;
- Покрени аутотестове;
- Процените резултат инсталације;
- Позовите следећи цевовод са стране команде за тестирање.
Следећи цевовод треба да региструје задатак у Јира и сачека да се команде дистрибуирају одабраним петљама за тестирање, које зависе од времена имплементације задатка. Триггер - писмо о спремности за испоруку на дату адресу. Ово је, наравно, била очигледна штака, али морао сам негде да почнем. У мају 2019, пренос кода је почео проверама наших окружења. Процес је почео, остаје само да се доведе у пристојан облик:
- Свака модификација се врши у посебној грани, која одговара инсталационом пакету и спаја се у циљну мастер грану;
- Окидач покретања цевовода је појава новог урезивања у главној грани кроз захтев за стапање, који затварају одржаваоци из унутрашњег тима;
- Спремишта се синхронизују једном сваких пет минута;
- Покреће се склапање инсталационог пакета - помоћу асемблера добијеног од продавца.
Након овога, већ су постојали кораци за проверу и пренос кода, за покретање цеви и склапање на нашој страни.
Ова опција је покренута у јулу. Тешкоће транзиције довеле су до извесног незадовољства међу продавцем и линијом фронта, али смо у наредних месец дана успели да отклонимо све грубе ивице и успоставимо процес међу тимовима. Сада имамо монтажу по обавези и испоруку.
У августу смо успели да завршимо прву инсталацију засебног пакета у продукцији помоћу нашег цевовода, а од септембра, без изузетка, све инсталације појединачних неиздајућих пакета вршене су преко нашег ЦД алата. Поред тога, успели смо да постигнемо удео унутрашњих задатака у 40% састава издања са мањим тимом од продавца - ово је дефинитиван успех. Остао је најозбиљнији задатак - саставити и инсталирати издање.
Коначно решење: кумулативни инсталациони пакети
Савршено смо разумели да је скриптовање инструкција продавца тако-тако аутоматизација; морали смо да поново размислимо о самом процесу. Решење је било очигледно - прикупити кумулативну понуду са гране за издавање са свим објектима потребних верзија.
Почели смо са доказом концепта: ручно смо саставили пакет издања у складу са садржајем претходне имплементације и инсталирали га у наша окружења. Све је испало, концепт се показао одрживим. Затим смо решили проблем скриптовања подешавања иницијализације и њиховог укључивања у урезивање. Припремили смо нови пакет и тестирали га у окружењима за тестирање као део ажурирања контуре. Инсталација је била успешна, али уз широк спектар коментара тима за имплементацију. Али главна ствар је да смо добили зелено светло да кренемо у производњу у новембру са нашом монтажом.
Пошто је преостало нешто више од месец дана, ручно биране залихе јасно су наговестиле да време истиче. Одлучили су да направе буилд од гране за издавање, али зашто би је требало одвојити? Немамо Прод-лике, а постојеће гране нису добре - има много непотребног кода. Хитно морамо да смањимо прод-лајкове, а ово је преко три хиљаде урезивања. Ручно склапање уопште није опција. Скицирали смо скрипту која пролази кроз дневник инсталације производа и прикупља урезивање у грану. Трећи пут је прорадио како треба, и након „завршетка са датотеком“ грана је била спремна.
Написали смо сопствени буилдер за инсталациони пакет и завршили га за недељу дана. Затим смо морали да изменимо инсталатер из основне функционалности система, пошто је отвореног кода. После низа провера и модификација, резултат се сматра успешним. У међувремену се обликовала композиција издања, за чију је исправну инсталацију било потребно ускладити тестно коло са производним, а за то је написан посебан сценарио.
Наравно, било је доста коментара о првој инсталацији, али у целини код је функционисао. И након отприлике треће инсталације све је почело да изгледа добро. Контрола композиције и контрола верзије објеката праћени су одвојено у ручном режиму, што је у овој фази било сасвим оправдано.
Додатни изазов представљао је велики број неиздавања који су морали бити узети у обзир. Али са граном налик на Прод и Ребасеом, задатак је постао транспарентан.
Први пут, брзо и без грешака
Издању смо приступили са оптимистичним ставом и више десетина успешних инсталација на различитим круговима. Али буквално дан пре истека рока, испоставило се да продавац није завршио посао припреме издања за инсталацију на прихваћен начин. Ако из неког разлога наша изградња не ради, издање ће бити поремећено. Штавише, нашим напорима, што је посебно непријатно. Нисмо имали начина да се повучемо. Стога смо размислили о алтернативним опцијама, припремили акционе планове и почели монтажу.
Изненађујуће, читаво издање, које се састоји од више од 800 објеката, почело је исправно, први пут и за само 10 минута. Провели смо сат времена проверавајући евиденције тражећи грешке, али их нисмо пронашли.
Цео следећи дан владала је тишина у ћаскању о издању: није било проблема са имплементацијом, погрешних верзија или „неприкладног“ кода. Чак је било некако и незгодно. Касније су се појавили неки коментари, али у поређењу са другим системима и претходним искуством, њихов број и приоритет су били приметно мањи.
Додатни ефекат кумулативног ефекта био је повећање квалитета монтаже и тестирања. Због вишеструких инсталација пуног издања, благовремено су идентификовани недостаци у изградњи и грешке у примени. Тестирање у конфигурацијама пуне верзије омогућило је да се додатно идентификују недостаци у међусобном утицају објеката који се нису појавили током инкременталних инсталација. То је дефинитивно био успех, посебно с обзиром на наш допринос издању од 57%.
Резултати и закључци
За мање од годину дана успели смо да:
- Изградите пуноправни унутрашњи развој користећи егзотични систем;
- Елиминишите критичну зависност од добављача;
- Покрените ЦИ/ЦД за веома непријатељско наслеђе;
- Подићи процесе имплементације на нови технички ниво;
- Значајно смањити време примене;
- Значајно смањити број грешака у имплементацији;
- Са сигурношћу се изјасните као водећи стручњак за развој.
Наравно, много тога што је описано изгледа као потпуно срање, али ово су карактеристике система и ограничења процеса која постоје у њему. Тренутно су промене утицале на производе и услуге ИС Профиле (мастер рачуне, пластичне картице, штедне рачуне, есцров, готовинске кредите), али потенцијално приступ може да се примени на било који ИС за који је постављен задатак имплементације ДевОпс пракси. Кумулативни модел се може безбедно реплицирати за наредне имплементације (укључујући оне без издавања) из многих испорука.
Извор: ввв.хабр.цом