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