Практыкі DevOps працуюць. Мы пераканаліся ў гэтым самі, калі скарацілі час усталёўкі рэлізаў у 10 раз. У сістэме FIS Profile, якую мы выкарыстоўваем у ВТБ, усталёўка зараз займае не 90 хвілін, а 10. Час зборкі рэлізу знізілася з двух тыдняў да двух дзён. Колькасць пастаянных дэфектаў укаранення пры гэтым упала амаль да мінімуму. Каб сысці ад «ручной працы» і ўхіліць залежнасць ад вендара, нам прыйшлося мінуць праз працу з мыліцамі і знайсці нечаканыя рашэнні. Пад катом - падрабязная гісторыя пра тое, як мы пабудавалі паўнавартасную ўнутраную распрацоўку.
Пралог: DevOps - гэта філасофія
За мінулы год з невялікім мы правялі немалую працу па арганізацыі ўнутранай распрацоўкі і ўкараненні практык DevOps у ЗГБ:
- Выбудавалі працэсы ўнутранай распрацоўкі па 12 сістэмах;
- Запусцілі 15 pipeline, чатыры з якіх давялі да прадуктыва;
- Аўтаматызавалі 1445 сцэнарыяў тэсціравання;
- Паспяхова ўкаранілі шэраг рэлізаў, падрыхтаваных інхаўс-камандамі.
Адной з самых складаных для арганізацыі inhouse-распрацоўкі і ўкаранення практык DevSecOps аказалася сістэма FIS Profile – рознічны прадуктовы працэсар на нерэляцыйнай СКБД. Тым не менш мы змаглі пабудаваць распрацоўку, запусціць pipeline, выканаць усталёўку на прадуктыў асобных пазарэлізных пакетаў і навучыліся збіраць рэлізы. Задача была няпростая, але затое цікавая і без відавочных абмежаванняў у рэалізацыі: вось сістэма - трэба пабудаваць inhouse-распрацоўку. Адзіная ўмова - выкарыстоўваць CD да прадуктыўнага асяроддзя.
Спачатку алгарытм рэалізацыі здаваўся простым і зразумелым:
- Напрацоўваем пачатковую экспертызу распрацоўкі і дамагаемся ад каманды кода прымальнага ўзроўню якасці без грубых дэфектаў;
- Максімальна ўбудоўваемся ў існуючыя працэсы;
- Для перадачы кода паміж відавочнымі этапамі пілуем pipeline і ўпіраем яго адным з канцоў у прад.
За гэты час каманда распрацоўшчыкаў неабходнай колькасці павінна напрацаваць скілы і павысіць долю свайго ўкладу ў рэлізы да прымальнага ўзроўню. І ўсё, можна лічыць задачу выкананай.
Здавалася б, цалкам сабе энергаэфектыўны шлях да патрабаванага выніку: вось DevOps, вось метрыкі прадукцыйнасці каманды, вось набраная экспертыза… Але на практыцы мы атрымалі чарговае пацверджанне таго, што DevOps гэта ўсёткі пра філасофію, а не «прыкруціць да працэсу gitlab, ansible, nexus і далей па спісе».
У чарговы раз прааналізаваўшы план дзеянняў, мы зразумелі, што будуем у сабе нейкі аўтсорс вендара. Таму ў апісаны вышэй алгарытм дадалі рэінжынірынг працэсаў, а таксама напрацоўку экспертызы па ўсім маршруце распрацоўкі для дасягнення вядучай ролі ў гэтым працэсе. Не самы просты варыянт, але такі шлях ідэалагічна правільнай распрацоўкі.
З чаго пачынаецца inhouse-распрацоўка
Працаваць трэба было з далёка не самай прыязнай сістэмай. Архітэктурна яна ўяўляла сабой адну вялікую нерэляцыйную СКБД, складалася з мноства асобных выкананых аб'ектаў (скрыптоў, працэдур, батчоў і т. д.), якія выклікаліся па неабходнасці, і працавала па прынцыпе чорнай скрыні: атрымлівае запыт - выдае адказ. Сярод іншых складанасцяў варта адзначыць:
- Экзатычная мова (MUMPS);
- Кансольны інтэрфейс;
- Адсутнасць інтэграцыі з папулярнымі сродкамі аўтаматызацыі і фрэймворкамі;
- Аб'ём дадзеных у дзясяткі тэрабайт;
- Нагрузку звыш 2 млн аперацый у гадзіну;
- Значнасць – Business-Critical.
Пры гэтым рэпазітар зыходнага кода на нашым баку адсутнічаў. Зусім. Дакументацыя мелася, але ўсе ключавыя веды і кампетэнцыі былі на баку знешняй арганізацыі.
Да засваення распрацоўкі па сістэме мы прыступілі практычна з нуля, улічваючы яе асаблівасці і слабое распаўсюджванне. Пачалі ў кастрычніку 2018 года:
- Вывучылі дакументацыю і асновы кодагенерацыі;
- Праштудзіравалі атрыманы ад вендара кароткі курс па распрацоўцы;
- Асвоілі пачатковыя скілы распрацоўкі;
- Склалі метадычку для новых удзельнікаў каманды;
- Дамовіліся аб уключэнні каманды ў працу ў «баявым» рэжыме;
- Вырашылі пытанне з кантролем якасці кода;
- Арганізавалі стэнд для распрацоўкі.
На напрацоўку экспертызы і апусканне ў сістэму мы патрацілі тры месяцы, а ўжо з пачатку 2019 года inhouse-распрацоўка пачала свой рух насустрач светлай будучыні, часам са скрыпам, але ўпэўнена і мэтанакіравана.
Міграцыя рэпазітара і аўтатэсты
Першая задача DevOps - рэпазітар. Аб прадастаўленні доступу дамовіліся хутка, але трэба было выканаць міграцыю з бягучага SVN з адной trunk-галінай у мэтавай для нас Git з пераходам на мадэль з некалькіх галін і прапрацоўкай Git Flow. А яшчэ ў нас 2 каманды са сваёй інфраструктурай плюс частка каманды вендара за мяжой. Прыйшлося жыць з двума Git'амі і забяспечыць сінхранізацыю. У такой сітуацыі гэта было меншае з попелаў.
Міграцыя рэпазітара неаднаразова адкладалася, выканалі яе толькі да красавіка не без дапамогі калегаў з фронт-лініі. З Git Flow вырашылі для пачатку не мудрагеліць, спыніліся на класічнай схеме з hotfix, develop і release. Ад master (ён жа prod-like) вырашылі адмовіцца. Ніжэй мы растлумачым, чаму такі варыянт аказаўся для нас аптымальным. У якасці працоўнага выкарыстоўвалі вонкавы рэпазітар, які належыць вендару, адзіны для двух каманд. Ён сінхранізаваўся з унутраным рэпазітаром па раскладзе. Цяпер з Git і Gitlab можна было займацца аўтаматызацыяй працэсаў.
Пытанне аўтатэстаў вырашыўся на здзіўленне лёгка - нам падалі гатовы фрэймворк. З улікам асаблівасцяў сістэмы выклік асобнай аперацыі ўяўляў сабою зразумелую частку бізнэс-працэсу і раўналежна з'яўляўся unit-тэстам. Заставалася падрыхтаваць тэставыя дадзеныя і задаць патрэбны парадак выкліку сцэнарыяў з ацэнкай вынікаў. Па меры напаўнення пераліку сцэнарыяў, сфарміраванага на аснове статыстыкі выканання аперацый, крытычнасці працэсаў і існуючай методыкі рэгрэсу, пачалі з'яўляцца аўтатэсты. Цяпер можна было пачынаць займацца пабудовай pipeline.
Як было: мадэль да аўтаматызацыі
Якая склалася мадэль працэсу ўкаранення - асобная гісторыя. Кожная дапрацоўка ўручную перадавалася ў выглядзе самастойнага інкрыментальнага ўсталявальнага пакета. Далей ішла ручная рэгістрацыя ў Jira і ручная ўстаноўка на асяроддзі. Для асобных пакетаў усё выглядала зразумела, але з падрыхтоўкай рэлізу справы ішлі складаней.
Зборка выконвалася на ўзроўні асобных паставак, якія з'яўляліся самастойнымі аб'ектамі. Любая змена - новая пастаўка. Акрамя іншага, да 60-70 пакетаў асноўнага складу рэлізу дадавалася 10-15 тэхнічных - версій, атрыманых пры даданні або выключэнні чаго-небудзь з рэлізу і адлюстраванні зменаў прода пазарэліз.
Аб'екты ўнутры паставак перасякаліся паміж сабой, асабліва ў частцы выкананага кода, які быў унікальны менш чым напалову. Было мноства залежнасцяў як ад ужо пастаўленага кода, так і ад таго, усталёўка якога толькі планавалася.
Для атрымання патрэбнай версіі кода патрабавалася строга выконваць парадак усталёўкі, падчас якой аб'екты шматкроць перазапісваліся фізічна, некаторыя па 10-12 разоў.
Пасля ўсталявання партыі пакетаў прыходзілася ўручную выконваць інструкцыі па ініцыялізацыі наладкавых параметраў. Рэліз збіраў і ўсталёўваў вендар. Склад рэлізу ўдакладняўся практычна да моманту ўкаранення, што вабіла за сабой стварэнне развязачных пакетаў. У выніку прыкметная частка паставак пераязджала з рэлізу ў рэліз са сваім хвастом "развязак".
Зараз зразумела, што пры такім падыходзе - зборцы рэлізнага пазла на ўзроўні пакетаў - адзіная master-галіна не мела практычнага сэнсу. Устаноўка на прод займала ад паўтары да дзвюх гадзін ручной працы. Добра, што хаця б на ўзроўні ўсталёўшчыка задаваўся парадак апрацоўкі аб'ектаў: палі і структуры заязджалі раней, чым дадзеныя для іх і працэдуры. Зрэшты, гэта працавала толькі ў рамках асобнага пакета.
Лагічным вынікам такога падыходу былі абавязковыя дэфекты ўсталёўкі ў выглядзе крывых версій аб'ектаў, лішняга кода, прапушчаных інструкцый і няўлічаных узаемаўплываў аб'ектаў, якія ліхаманкава ўхіляліся пасля рэлізу.
Першыя абнаўленні: зборка па коміце і дастаўка
Аўтаматызацыю пачалі з перадачы кода праз трубу па такім маршруце:
- Забраць гатовую пастаўку са сховішча;
- Усталяваць яе на вылучанае асяроддзе;
- Прагнаць аўтатэсты;
- Ацаніць вынік усталёўкі;
- Выклікаць наступны pipeline на баку каманды тэсціравання.
Наступны pipeline павінен зарэгістраваць задачу ў Jira і чакаць каманды для разлівання на выбраныя контуры тэсціравання, якія залежаць ад тэрмінаў укаранення задачы. Трыгер - ліст аб гатоўнасці пастаўкі на зададзены адрас. Гэта, вядома, быў відавочны мыліца, але з чагосьці трэба было пачаць. З траўня 2019 пачалася перадача кода з праверкамі на нашых асяроддзях. Працэс пайшоў, засталося прывесці яго ў прыстойны выгляд:
- Кожная дапрацоўка выконваецца ў асобнай галіны, якая адпавядае ўсталявальнаму пакету і ўліваецца ў мэтавую майстар-галіна;
- Трыгер запуску pipeline — з'яўленне новага комміта ў майстар-галіне праз merge request, які закрываюць мэйнтэйнеры з каманды інхаўс;
- Сінхранізацыя рэпазітараў адбываецца раз у пяць хвілін;
- Запускаецца зборка ўсталявальнага пакета - пры дапамозе зборшчыка, атрыманага ад вендара.
Пасля гэтага ішлі ўжо існуючыя крокі па праверцы і перадачы кода, па запуску трубы і зборцы на нашым баку.
Гэты варыянт запусцілі ў ліпені. Цяжкасці пераходу пацягнулі за сабой некаторую незадаволенасць вендара і фронт-лініі, але за наступны месяц нам удалося прыбраць усе шурпатасці і наладзіць працэс у камандах. У нас з'явілася зборка па коміце і дастаўка.
У жніўні атрымалася выканаць першую ўсталёўку асобнага пакета на прад сродкамі нашага pipeline, а з верасня ўсё без выключэння ўсталёўкі асобных пазарэлізных пакетаў выконваліся праз наш сродак CD. Акрамя таго, нам удалося дасягнуць долі inhouse задач у 40% складу рэлізу пры меншай па колькасці, чым у вендара, камандзе - гэта пэўны поспех. Заставалася самая сур'ёзная задача - сабраць і ўсталяваць рэліз.
Фінальнае рашэнне: кумулятыўныя ўсталявальныя пакеты
Мы выдатна разумелі, што скрыптаваць інструкцыю вендара - так сабе аўтаматызацыя, трэба было пераасэнсаваць сам працэс. Рашэнне ляжала на паверхні - збіраць кумулятыўную пастаўку з рэлізнай галіны з усімі аб'ектамі патрэбных версій.
Пачалі з proof of concept: сабралі рукамі рэлізную пастаўку па складзе мінулага ўкаранення і выканалі яе ўстаноўку на нашых асяроддзях. Усё атрымалася, канцэпцыя аказалася жыццяздольнай. Далей вырашылі пытанне са скрыптаваннем якія ініцыялізуюць налад і ўключэннем іх у коміт. Падрыхтавалі новы пакет і праверылі яго ўжо на асяроддзях тэсціравання ў рамках абнаўлення контуру. Устаноўка была паспяховай, хоць і з шырокім шэрагам заўваг ад каманды ўкаранення. Але галоўнае, што нам далі дабро на выхад у прадуктыў у лістападаўскім рэлізе з нашай зборкай.
Заставалася крыху больш за месяц, сабраныя ўручную пастаўкі празрыста намякалі, што часу ў абрэз. Зборку вырашылі рабіць з рэлізнай галіны, але ад чаго яе отбранчевать? Prod-like у нас няма, а існуючыя галіны не падыходзяць - шмат лішняга кода. Трэба тэрмінова пілаваць prod-like, а гэта больш за тры тысячы комітаў. Збіраць рукамі - наогул не варыянт. Накідалі скрыпт, які бяжыць па логу ўстаноўкі прадуктыва і набірае коміты ў галіну. Разу з трэцяга ён спрацаваў карэктна, і пасля "дапрацоўкі напільнікам" галіна была гатова.
Зборшчык установачнага пакета напісалі свой, справіліся за тыдзень. Затым прыйшлося дапрацоўваць усталёўшчык з core-функцыянальнасці сістэмы, балазе яна open-source. Пасля шэрагу праверак і дапрацовак вынік прызналі паспяховым. Тым часам аформіўся склад рэлізу, для карэктнай усталёўкі якога прыйшлося выраўноўваць тэставы контур з прадуктывам, напісалі для гэтага асобны скрыпт.
Натуральна, да першай устаноўкі было шмат заўваг, але ў цэлым код "заехаў". А ўжо прыкладна з трэцяй усталёўкі ўсё стала нядрэнна глядзецца. Кантроль складу і версійнасць аб'ектаў адсочвалі асобна ў ручным рэжыме, што на дадзеным этапе было суцэль апраўдана.
Дадатковая складанасць складалася ў вялікай колькасці внерэлізаў, якія даводзілася ўлічваць. Але з Prod-like галіной і Rebase задача стала празрыстай.
З першага разу, хутка і без памылак
Да моманту рэлізу мы падышлі з аптымістычным настроем і больш за дзясяткам паспяховых усталёвак на розныя контуры. Але літаральна за суткі да тэрміну аказалася, што вендар не выканаў працы па падрыхтоўцы рэлізу да ўстаноўкі прынятым спосабам. Калі з нейкіх прычынаў наша зборка не зойдзе, то рэліз будзе сарваны. Прычым нашымі намаганнямі, што асабліва непрыемна. Шляхоў для адступлення ў нас не было. Таму мы прадумалі альтэрнатыўныя варыянты, падрыхтавалі планы дзеянняў і пачалі ўстаноўку.
Дзіўна, але ўвесь рэліз, які складаецца з 800 з лішнім аб'ектаў, заехаў карэктна, з першага разу і ўсяго за 10 хвілін. Цэлую гадзіну мы вывяралі логі ў пошуках памылак, але не знайшлі ніводнай.
Увесь наступны дзень у рэлізным чаце панавала цішыня: ніякіх праблем укаранення, крывых версій ці "левага" кода. Нават неяк няёмка было. Пазней вылезлі асобныя заўвагі, але на фоне іншых сістэм і папярэдняга досведу іх колькасць і прыярытэтнасць былі прыкметна ніжэй.
Дадатковым эфектам ад кумулятыву аказалася павышэнне якасці зборкі і тэсціравання. За кошт шматразовых усталёвак поўнага рэлізу своечасова выяўляліся дэфекты зборкі і памылкі разгортвання. Тэставанне ў поўных рэлізных канфігурацыях дазволіла дадаткова выяўляць дэфекты ўзаемаўплыву аб'ектаў, якія не выяўляліся пры інкрыментальных усталёўках. Гэта вызначана быў поспех, асабліва на фоне нашага фундуша ў рэліз на ўзроўні 57%.
Вынікі і высновы
Менш чым за год нам удалося:
- Пабудаваць паўнавартасную ўнутраную распрацоўку па экзатычнай сістэме;
- Ухіліць крытычную залежнасць ад вендара;
- Запусціць CI/CD для вельмі непрыязнага legacy;
- Падняць на новы тэхнічны ўзровень працэсы ўкаранення;
- Прыкметна скараціць працягласць разгортвання;
- Значна зменшыць колькасць памылак укаранення;
- Упэўнена заявіць аб сабе як аб вядучай экспертызе распрацоўкі.
Зразумела, шмат што з апісанага выглядае як адкрытая кастылізацыя, але такія асаблівасці сістэмы і існыя ў ёй працэсныя абмежаванні. На дадзены момант змены закранулі прадуктаў і сэрвісаў ІС Profile (майстар-рахункі, пластыкавыя карты, назапашвальныя рахункі, эскроу, крэдыт наяўнымі), але патэнцыйна падыход можна прымяніць да любой ІС, для якой пастаўлена задача ўкаранення практык DevOps. Кумулятыўную мадэль можна смела тыражаваць на наступныя ўкараненні (у тым ліку пазарэлізныя) з мноства паставак.
Крыніца: habr.com