Практиките на DevOps функционираат. Во тоа се уверивме и самите кога го намаливме времето за инсталирање на ослободување за 10 пати. Во системот FIS Profile, кој го користиме во VTB, инсталацијата сега трае 90 минути наместо 10. Времето на изработка на објавувањето се намали од две недели на два дена. Бројот на постојани дефекти во имплементацијата падна на речиси минимум. За да се извлечеме од „рачната работа“ и да ја елиминираме зависноста од продавачот, моравме да работиме со патерици и да најдеме неочекувани решенија. Под сечењето е детална приказна за тоа како изградивме целосен внатрешен развој.
Пролог: DevOps е филозофија
Во текот на изминатата година, направивме многу работа за да го организираме внатрешниот развој и имплементација на практиките на DevOps во VTB:
- Изградивме внатрешни развојни процеси за 12 системи;
- Пуштивме 15 цевководи, од кои четири беа донесени во производство;
- Автоматизирани 1445 тест сценарија;
- Успешно имплементиравме голем број изданија подготвени од домашни тимови.
Еден од најтешките за организирање внатрешен развој и имплементација на практиките DevSecOps се покажа дека е системот FIS Profile - процесор на малопродажен производ на не-релациона DBMS. Како и да е, можевме да го изградиме развојот, да го лансираме гасоводот, да инсталираме поединечни пакети што не се издаваат на производот и научивме како да составуваме изданија. Задачата не беше лесна, но интересна и без очигледни ограничувања во имплементацијата: тука е системот - треба да изградите внатрешен развој. Единствениот услов е да се користи ЦД-то пред продуктивна средина.
На почетокот, алгоритмот за имплементација изгледаше едноставен и јасен:
- Развиваме првична развојна експертиза и постигнуваме прифатливо ниво на квалитет од тимот на кодови без груби дефекти;
- Ние се интегрираме во постоечките процеси колку што е можно повеќе;
- За да го пренесеме кодот помеѓу очигледните фази, сечеме цевковод и туркаме еден од неговите краеви во продолжение.
За тоа време, тимот за развој со потребната големина мора да развие вештини и да го зголеми уделот на својот придонес во изданијата на прифатливо ниво. И тоа е тоа, можеме да ја сметаме задачата завршена.
Се чини дека ова е целосно енергетски ефикасен пат до потребниот резултат: еве го DevOps, еве ги метриките за перформанси на тимот, еве ја акумулираната експертиза... Но, во пракса, добивме уште една потврда дека DevOps сè уште се занимава со филозофија , а не „прикачен на процесот gitlab, ansible, nexus и понатаму на листата“.
Откако уште еднаш го анализиравме акцискиот план, сфативме дека во себе градиме еден вид аутсорсинг продавач. Затоа, реинженерството на процесите беше додадено на алгоритмот опишан погоре, како и развојот на експертиза по целата развојна рута за да се постигне водечка улога во овој процес. Не е најлесната опција, но ова е патот на идеолошки правилен развој.
Каде започнува внатрешниот развој?
Тоа не беше најпријателскиот систем за работа. Архитектонски, тоа беше еден голем не-релациски DBMS, кој се состоеше од многу посебни извршни објекти (скрипти, процедури, серии, итн.), кои беа повикани по потреба и работеа на принципот на црна кутија: прима барање и издава одговор. Други тешкотии што вреди да се забележат вклучуваат:
- Егзотични јазик (MUMPS);
- Интерфејс на конзолата;
- Недостаток на интеграција со популарните алатки и рамки за автоматизација;
- Обем на податоци во десетици терабајти;
- Оптоварување од над 2 милиони операции на час;
- Значење - Деловно-критично.
Во исто време, немаше складиште за изворен код на наша страна. Воопшто. Имаше документација, но сите клучни знаења и компетенции беа на страна на надворешна организација.
Почнавме да го совладуваме развојот на системот речиси од нула, земајќи ги предвид неговите карактеристики и малата дистрибуција. Започна во октомври 2018 година:
- Ја проучувал документацијата и основите на генерирање кодови;
- Го проучувавме краткиот курс за развој добиен од продавачот;
- Совладани почетни развојни вештини;
- Составивме прирачник за обука за нови членови на тимот;
- Се договоривме да го вклучиме тимот во „борбен“ режим;
- Го реши проблемот со контролата на квалитетот на кодот;
- Организиравме штанд за развој.
Поминавме три месеци развивајќи експертиза и потопувајќи се во системот, а од почетокот на 2019 година, инхаус развојот го започна своето движење кон светла иднина, понекогаш со тешкотии, но самоуверено и намерно.
Миграција на складиштето и автоматски тестови
Првата задача на DevOps е складиштето. Брзо се договоривме да обезбедиме пристап, но беше неопходно да се мигрираме од сегашниот SVN со една багажничка гранка до нашата целна Git со преминување кон модел од неколку гранки и развој на Git Flow. Имаме и 2 тима со сопствена инфраструктура, плус дел од тимот на продавачот во странство. Морав да живеам со два Gits и да обезбедам синхронизација. Во таква ситуација, тоа беше помалото од двете зла.
Миграцијата на складиштето беше постојано одложувана, таа беше завршена дури во април, со помош на колегите од првата линија. Со Git Flow, решивме да ги задржиме работите едноставни за почеток и се решивме на класичната шема со жешка поправка, развој и ослободување. Тие решија да го напуштат господарот (ака прод-како). Подолу ќе објасниме зошто оваа опција се покажа како оптимална за нас. Како работник се користеше надворешно складиште кое му припаѓа на продавачот, вообичаено за два тима. Се синхронизираше со внатрешното складиште според распоред. Сега со Git и Gitlab беше можно да се автоматизираат процесите.
Прашањето за автотестови беше решено изненадувачки лесно - ни беше обезбедена готова рамка. Земајќи ги во предвид особеностите на системот, повикувањето на посебна операција беше разбирлив дел од деловниот процес и во исто време служеше како единица тест. Остануваше само да се подготват податоците од тестот и да се постави саканиот редослед на повикување на скриптите и евалуација на резултатите. Како што се пополнува списокот на сценарија, формиран врз основа на оперативните статистики, критичноста на процесите и постоечката регресивна методологија, почнаа да се појавуваат автоматски тестови. Сега би можеле да започнеме со изградба на гасоводот.
Како беше: моделот пред автоматизацијата
Постојниот модел на процесот на имплементација е посебна приказна. Секоја модификација беше рачно пренесена како посебен пакет за инкрементална инсталација. Следуваше рачна регистрација во Jira и рачна инсталација на околини. За поединечни пакувања, сè изгледаше јасно, но со подготовката на изданието, работите беа покомплицирани.
Монтажата се вршеше на ниво на поединечни испораки, кои беа независни објекти. Секоја промена е нова испорака. Меѓу другото, 60-70 технички верзии беа додадени на 10-15 пакети на главната композиција за издавање - верзии добиени кога се додава или исклучува нешто од изданието и се одразуваат на промените во продажбата надвор од изданија.
Објектите во рамките на испораките се преклопуваат едни со други, особено во извршниот код, кој беше помалку од половина единствен. Имаше многу зависности и од веќе инсталираниот код и од оној чија инсталација штотуку беше планирана.
За да се добие потребната верзија на кодот, неопходно беше строго да се следи редоследот на инсталацијата, при што предметите беа физички препишувани многу пати, околу 10-12 пати.
Откако инсталирав серија пакети, морав рачно да ги следам упатствата за да ги иницијализирам поставките. Ослободувањето беше составено и инсталирано од продавачот. Составот на изданието беше разјаснет речиси пред моментот на имплементација, што подразбираше создавање на пакети „раздвојување“. Како резултат на тоа, значителен дел од залихите се префрли од пуштање во пуштање со сопствена опашка на „раздвојувања“.
Сега е јасно дека со овој пристап - склопување на сложувалката за ослободување на ниво на пакетот - единствената мастер гранка нема практично значење. Инсталирањето на производство траеше од еден и пол до два часа физичка работа. Добро е што барем на ниво на инсталатер беше наведен редоследот на обработка на објекти: полињата и структурите беа внесени пред податоците за нив и процедурите. Сепак, ова функционираше само во посебен пакет.
Логичен резултат на овој пристап беа задолжителните дефекти на инсталацијата во форма на искривени верзии на предмети, непотребна шифра, исчезнати инструкции и непотребни меѓусебни влијанија на предметите, кои беа трескавично елиминирани по ослободувањето.
Први ажурирања: извршете склопување и испорака
Автоматизацијата започна со пренос на код преку цевка по оваа рута:
- Подигнете ја готовата испорака од складиштето;
- Инсталирајте го на посветена околина;
- Извршете автотестови;
- Оценете го резултатот од инсталацијата;
- Повикајте го следниов цевковод од страната на командата за тестирање.
Следниот цевковод треба да ја регистрира задачата во Jira и да чека командите да бидат дистрибуирани до избраните циклуси за тестирање, кои зависат од времето на имплементација на задачата. Активирање - писмо за подготвеност за испорака на дадена адреса. Ова, се разбира, беше очигледна патерица, но морав да почнам од некаде. Во мај 2019 година, преносот на кодот започна со проверки на нашите средини. Процесот започна, останува само да се доведе во пристојна форма:
- Секоја модификација се изведува во посебна гранка, која одговара на инсталациониот пакет и се спојува во целната главна гранка;
- Активирањето на лансирањето на нафтоводот е појавата на нов commit во главната гранка преку барање за спојување, кое го затвораат одржувачите од внатрешниот тим;
- Складиштата се синхронизираат еднаш на секои пет минути;
- Монтажата на инсталациониот пакет е започната - со користење на асемблерот добиен од продавачот.
По ова, веќе постоеја чекори за проверка и пренос на кодот, за лансирање на цевката и склопување на наша страна.
Оваа опција беше лансирана во јули. Тешкотиите на транзицијата резултираа со одредено незадоволство кај продавачот и во првата линија, но во текот на следниот месец успеавме да ги отстраниме сите груби рабови и да воспоставиме процес меѓу тимовите. Сега имаме склопување со обврзување и испорака.
Во август, успеавме да ја завршиме првата инсталација на посебен пакет за производство со помош на нашиот гасовод, а од септември, без исклучок, сите инсталации на поединечни пакети кои не се издаваат се изведуваа преку нашата CD алатка. Дополнително, успеавме да постигнеме дел од внатрешните задачи во 40% од составот за издавање со помал тим од продавачот - ова е дефинитивен успех. Остана најсериозната задача - да се собере и инсталира ослободувањето.
Конечно решение: кумулативни инсталациски пакети
Совршено разбравме дека скриптирањето на инструкциите на продавачот беше толку автоматизација; моравме да го преиспитаме самиот процес. Решението беше очигледно - да се собере кумулативно снабдување од гранката за ослободување со сите објекти од бараните верзии.
Започнавме со доказ за концепт: рачно го составивме пакетот за ослободување според содржината од претходната имплементација и го инсталиравме на нашите средини. Сè успеа, концептот се покажа како остварлив. Следно, го решивме проблемот со скриптирање на поставките за иницијализација и нивно вклучување во commit. Подготвивме нов пакет и го тестиравме во околини за тестирање како дел од ажурирањето на контурата. Инсталацијата беше успешна, иако со широк спектар на коментари од тимот за имплементација. Но, главната работа е што ни беше дадено зелено светло да влеземе во производство во ноемвриското издание со нашето склопување.
Со само нешто повеќе од еден месец, рачно избраните залихи јасно навестија дека времето истекува. Тие решија да ја направат градбата од гранката за ослободување, но зошто да се одвои? Немаме прод-како, а постоечките гранки не се добри - има многу непотребен код. Итно треба да ги намалиме прод-лајковите, а ова е над три илјади обврски. Склопувањето со рака воопшто не е опција. Ние скициравме скрипта што се провлекува низ дневникот за инсталација на производот и ги собира обврските до гранката. Третиот пат работеше правилно, а откако „завршив со датотека“ гранката беше подготвена.
Напишавме сопствен билдер за инсталациониот пакет и го завршивме за една недела. Потоа моравме да го измениме инсталерот од основната функционалност на системот, бидејќи е со отворен код. По низа проверки и модификации, резултатот се сметаше за успешен. Во меѓувреме, се оформи составот на изданието, за чија правилна инсталација беше неопходно да се усогласи тест коло со производствената, а за ова беше напишано посебно сценарио.
Секако, имаше многу коментари за првата инсталација, но генерално кодот функционираше. И по третата инсталација, сè почна да изгледа добро. Контролата на составот и контролата на верзијата на објектите беа следени одделно во рачен режим, што во оваа фаза беше сосема оправдано.
Дополнителен предизвик беше големиот број на неизданија кои требаше да се земат предвид. Но, со гранката слична на Prod и Rebase, задачата стана транспарентна.
Прв пат, брзо и без грешки
На објавувањето му пристапивме со оптимистички став и повеќе од десетина успешни инсталации на различни кола. Но, буквално еден ден пред истекот на рокот, се покажа дека продавачот не ја завршил работата за да го подготви пуштањето за инсталација на прифатен начин. Ако поради некоја причина нашата изградба не работи, издавањето ќе биде нарушено. Згора на тоа, преку нашите напори, што е особено непријатно. Немавме начин да се повлечеме. Затоа, размисливме за алтернативни опции, подготвивме акциони планови и започнавме со инсталацијата.
Изненадувачки, целото ослободување, составено од повеќе од 800 предмети, започна правилно, првиот пат и за само 10 минути. Поминавме еден час проверувајќи ги дневниците барајќи грешки, но не најдовме никакви.
Целиот следен ден владееше тишина во разговорот за објавување: нема проблеми со имплементацијата, искривени верзии или „несоодветен“ код. Дури и беше некако незгодно. Подоцна, се појавија некои коментари, но во споредба со другите системи и претходното искуство, нивниот број и приоритет беа значително помали.
Дополнителен ефект од кумулативниот ефект беше зголемувањето на квалитетот на склопување и тестирање. Поради повеќекратните инсталации на целосното ослободување, навремено беа идентификувани дефекти во изградбата и грешки при распоредувањето. Тестирањето во конфигурации за целосно ослободување овозможи дополнително да се идентификуваат дефектите во меѓусебното влијание на предметите што не се појавија при инкременталните инсталации. Дефинитивно беше успех, особено со оглед на нашиот придонес од 57% во изданието.
Резиме и заклучоци
За помалку од една година успеавме:
- Изградете целосен внатрешен развој користејќи егзотичен систем;
- Елиминирајте ја критичната зависност од продавачот;
- Стартувајте CI/CD за многу непријателско наследство;
- Подигнување на процесите на имплементација на ново техничко ниво;
- Значително намалување на времето на распоредување;
- Значително намалување на бројот на грешки во имплементацијата;
- Самоуверено декларирајте се како водечки експерт за развој.
Се разбира, голем дел од опишаното изгледа како целосно глупости, но ова се карактеристиките на системот и ограничувањата на процесот што постојат во него. Во моментов, промените влијаеја на производите и услугите на IS Profile (главни сметки, пластични картички, штедни сметки, зачувани, готовински заеми), но потенцијално пристапот може да се примени на која било ИС за која е поставена задачата за имплементирање на практиките на DevOps. Кумулативниот модел може безбедно да се реплицира за последователни имплементации (вклучувајќи ги и оние кои не се објавуваат) од повеќе испораки.
Извор: www.habr.com