От скриптове до собствена платформа: как автоматизирахме разработката в ЦИАН

На RIT 2019 наш колега Александър Коротков направи доклад представяне за автоматизацията на разработката в ЦИАН: за да улесним живота и работата, ние използваме собствена платформа Integro. Тя проследява жизнения цикъл на задачите, освобождава разработчиците от рутинни операции и значително намалява броя на бъговете в продукция. В този пост ще допълним доклада на Александър и ще разкажем как преминахме от прости скриптове към обединяване на open source продукти чрез собствената платформа и с какво се занимава отделен екип за автоматизация.
 

Нулево ниво

„Нулево ниво не съществува, не знам такова“
Майстор Шифу от м/ф „Кунг-Фу Панда“

Автоматизацията в ЦИАН започна 14 години след основаването на компанията. Тогава в екипа за разработка имаше 35 човека. Трудно е да се повярва, нали? Разбира се, по някакъв начин автоматизация е съществувала, но отделно направление за непрекъсната интеграция и доставка на код започна да се формира именно през 2015 година. 

По това време имахме огромен монолит от Python, C# и PHP, разположен на Linux/Windows сървъри. За деплой на този монстър имахме набор от скриптове, които стартирахме ръчно. Имаше и компилация на монолита, която носеше болка и страдания поради конфликти при сливане на клонове, поправки на дефекти и повторно сглобяване „с друг набор задачи в билд“. Опитно процесът изглеждаше така:

Това не ни удовлетворяваше и искахме да изградим повторяем, автоматизиран и управляем процес на сглобяване и деплой. За това ни беше нужна CI/CD система и избирахме между безплатната версия на Teamcity и безплатния Jenkins, тъй като работехме с тях и двата ни удовлетворяваха по набор от функции. Избрахме Teamcity като по-свеж продукт. Тогава все още не използвахме микросервисна архитектура и не разчитахме на голямо количество задачи и проекти.

Пристигаме до идеята за собствена система

Внедряването на Teamcity премахна само част от ръчната работа: оставаше създаването на Pull Request-ове, проследяването на задачите по статуси в Jira и изборът на задачи за релиз. С това системата Teamcity вече не се справяше. Трябваше да изберем пътя за по-нататъшна автоматизация. Разглеждахме варианти за работа с скриптове в Teamcity или преминаване към външни системи за автоматизация. В крайна сметка решихме, че е необходима максимална гъвкавост, която може да предостави само собствено решение. Така се появи първата версия на вътрешната система за автоматизация, наречена Integro.

Teamcity се занимава с автоматизация на ниво стартиране на процесите на компилиране и деплой, докато Integro се фокусира на висшата автоматизация на процесите на разработка. Нужно беше да обединим работата с задачите в Jira с обработката на свързания изходен код в Bitbucket. На този етап вътре в Integro започнаха да се появяват собствени работни потоци за работа с различни типове задачи. 

Поради увеличаването на автоматизацията в бизнес процесите, се увеличи броят на проектите и run-овете в Teamcity. Така се появи нов проблем: един безплатен инстанс на Teamcity започна да не е достатъчен (3 агента и 100 проекта), добавихме още един инстанс (още 3 агента и 100 проекта), след това още. В крайна сметка получихме система от няколко клъстера, която беше трудна за управление:

Когато се постави въпросът за 4-ти инстанс, осъзнахме, че така не може да продължава, тъй като общите разходи за поддръжка на 4 инстанса вече не се вписваха в никакви рамки. Възникна въпросът за покупка на платен Teamcity или избор в полза на безплатната Jenkins. Извършихме изчисления по инстансите и плановете за автоматизация и решихме, че ще живеем с Jenkins. След няколко седмици преминахме на Jenkins и се освободи от част от главоболието, свързано с поддръжката на няколко инстанса на Teamcity. Така успяхме да се фокусираме върху разработката на Integro и доработването на Jenkins за нас.

С увеличением базовой автоматизации (в виде автоматического создания Pull Request-ов, сбора и публикации данных о покрытии кода и других проверок) возникло стойкое желание максимально отойти от ручных релизов и передать эту работу роботам. Кроме того, внутри компании начался переход на микросервисы, которые требовали частых релизов, причем каждый из них работал отдельно. Так мы постепенно пришли к автоматическим релизам наших микросервисов (монолит пока что выпускаем вручную из-за сложности процесса). Тем не менее, как это часто бывает, возникла новая сложность. 

Автоматизируем тестирование

Из-за автоматизации релизов ускорились процессы разработки, что частично произошло за счет пропуска некоторых этапов тестирования. Это привело к временной потере качества. Звучит банально, но вместе с ускорением релизов также потребовалось изменить и методологию разработки продукта. Мы начали задумываться об автоматизации тестирования, привитии разработчикам индивидуальной ответственности (речь идет о «принятии идеи в голове», а не о денежных штрафах) за выпускаемый код и приводимые в нем баги, а также о решениях по выпуску или не выпуску задач через автоматический деплой. 

Для устранения проблем с качеством мы пришли к двум важным решениям: начали проводить канареечное тестирование и внедрили автоматический мониторинг фона ошибок с автоматическим реагированием на его превышение. Первое решение позволило выявлять очевидные ошибки до полноценного попадания кода в production, второе уменьшило время реагирования на проблемы в production. Ошибки, конечно, бывают, но мы тратим больше времени и сил не на их исправление, а на минимизацию. 

Команда автоматизации

Сейчас у нас в штате 130 разработчиков, и мы продолжаем расти. Команда по непрерывной интеграции и доставке кода (далее — команда Deploy and Integration или DI) состоит из 7 человек и работает в двух направлениях: разработка платформы автоматизации Integro и DevOps. 

DevOps отговаря за Dev/Beta средите на сайта CIAN, средите Integro, помага на разработчиците при решаване на проблеми и разработва нови подходи за мащабиране на средите. Направлението за разработка Integro се занимава както със самото Integro, така и със свързани услуги, например, плъгини за Jenkins, Jira, Confluence, както и разработва помощни инструменти и приложения за екипите разработчици. 

Екипът DI работи съвместно с екипа на Платформата, която се занимава с разработването на архитектура, библиотеки и подходи към разработката вътре в компанията. В същото време, всеки разработчик в ЦИАН може да допринесе за автоматизацията, например, да направи микроавтоматизация според нуждите на екипа или да сподели страхотна идея как да направим автоматизацията още по-добра.

Слоен кейк на автоматизацията в ЦИАН

Всички системи, участвали в автоматизацията, могат да бъдат разделени на няколко слоя:

1. Външни системи (Jira, Bitbucket и др.). С тях работят екипите разработчици.
2. Платформа Integro. Най-често разработчиците не работят с нея директно, но именно тя поддържа работата на цялата автоматизация.
3. Услуги за доставка, оркестриране и откритие (например, Jenkins, Consul, Nomad). С тяхна помощ ние разгръщаме кода на сървърите и осигуряваме работата на услугите помежду си.
4. Физически слой (сървъри, ОС, свързано ПО). На този слой работи нашият код. Това може да бъде както физически сървър, така и виртуален (LXC, KVM, Docker).

Въз основа на това понятие разделяме зоните на отговорност вътре в екипа DI. Двата първи слоя падат в зоната на отговорност на направлението за разработка Integro, а два последни слоя вече в зоната на отговорност на DevOps. Такова разделение позволява да се фокусираме върху задачите и не пречи на взаимодействието, тъй като се намираме близо един до друг и постоянно обменяме знания и опит.

Integro

Нека се фокусираме върху Integro и да започнем с технологичния стек:

• CentOs 7
• Docker + Nomad + Consul + Vault
• Java 11 (старият монолит Integro ще остане на Java 8)
• Spring Boot 2.X + Spring Cloud Config
• PostgreSql 11
• RabbitMQ 
• Apache Ignite
• Camunda (вградена)
• Grafana + Graphite + Prometheus + Jaeger + ELK
• Web UI: React (CSR) + MobX
• SSO: Keycloak

Ние следваме принципите на микросервисното разработване, въпреки че имаме и наследство под формата на монолита от ранната версия на Integro. Всеки микросервис работи в свой собствен Docker контейнер, а услугите комуникират помежду си чрез HTTP заявки и съобщения RabbitMQ. Микросервисите се намират един друг чрез Consul и отправят запитване, преминавайки през удостоверяване чрез SSO (Keycloak, OAuth 2/OpenID Connect).

Като реален пример ще разгледаме взаимодействието с Jenkins, което се състои от следните стъпки:

1. Микросервисът за управление на работния поток (наречен Flow микросервис) иска да стартира сборка в Jenkins. За целта той намира IP:PORT на микросервиса за интеграция с Jenkins (наречен Jenkins микросервис) чрез Consul и изпраща асинхронно запитване за стартиране на сборка в Jenkins.
2. Jenkins микросервисът след получаването на запитването формулира и предоставя в отговор Job ID, по който после може да се идентифицира резултатът от работата. В същото време той стартира сборка в Jenkins чрез извикване на REST API.
3. Jenkins извършва сборката и след приключването ѝ изпраща webhook с резултатите от изпълнението в Jenkins микросервиза.
4. Jenkins микросервисът, получавайки webhook, формулира съобщение за приключване на обработването на запитването и прикрепя към него резултатите от изпълнението. Формулираното съобщение се изпраща в опашката RabbitMQ.
5. Чрез RabbitMQ публикуваното съобщение попада в Flow микросервиза, който научава за резултата от обработката на задачата си, сопоставяйки Job ID от запитването и полученото съобщение.

В момента имаме около 30 микросервиза, които могат да бъдат разделени на няколко групи:

1. Управление на конфигурации.
2. Информиране и взаимодействие с потребителите (месинджъри, имейл).
3. Работа с изходния код.
4. Интеграция с инструменти за разгръщане (Jenkins, Nomad, Consul и т.н.).
5. Мониторинг (на разширения, грешки и т.н.).
6. Web инструменти (UI за управление на тестови среди, събиране на статистика и т.н.).
7. Интеграция с таск трекери и подобни системи.
8. Управление на работния поток за различни задачи.

Работен поток на задачата

Integro автоматизира действията, свързани с жизнения цикъл на задачата. В опростен вид под жизнен цикъл на задачата разбираме работния поток на задачата в Jira. В нашите процеси на разработка има няколко вариации на работния поток в зависимост от проекта, типа задача и опцията, избрана в конкретната задача. 

Нека разгледаме работния поток, който използваме най-често:

На схемата зъбното колело посочва, че преминаването се извършва автоматично от Integro, докато фигурката на човека означава, че преминаването се извършва ръчно от човек. Нека разгледаме няколко пъти, по които задачата може да премине в този работен процес.

Напълно ръчно тестване на DEV+BETA без канарейни тестове (обикновено така пускаме монолита):

Могат да има и други комбинации от преминавания. Понякога пътят, по който задачата ще поеме, може да бъде избран чрез опциите в Jira.

Движение на задачата

Нека разгледаме основните стъпки, които се изпълняват при движение на задачата през работния процес „Тестване на DEV + канарейни тестове“:

1. Разработчик или PM създава задача.

2. Разработчикът поема задачата. След завършване я премества в статус IN REVIEW.

3. Jira изпраща Webhook към Jira микросервиса (отговаря за интеграцията с Jira).

4. Jira микросервисът изпраща заявка към Flow-сервиса (отговаря за вътрешните работни процеси, в които се извършва работа) за стартиране на работния процес.

5. Вътре в Flow-сервиса:

• Назначават се ревюъри за задачата (Users микросервиса, който знае всичко за потребителите + Jira микросервиса).
• Чрез Source микросервиса (знае за хранилищата и клоновете, но не работи с кода) се извършва търсене на хранилищата, в които има клон на нашата задача (за улеснение на търсенето името на клона съвпада с номера на задачата в Jira). Най-често задачата има само един клон в едно хранилище, което улеснява управлението на опашката за деплой и намалява свързаността между хранилищата.
• За всяко намерено клонче се извършва следната последователност от действия:

  i) Подливаме master клона (Git микросервиса за работа с кода).
  ii) Клонът се блокира от промени от разработчика (Bitbucket микросервиса).
  iii) Създава се Pull Request за този клон (Bitbucket микросервиса).
  iv) Изпраща се съобщение за ново Pull Request в чатове на разработчиците (Notify микросервиса за работа с известия).
  v) Започват се сборка, тестване и деплой на задачата на DEV (Jenkins микросервиса за работа с Jenkins).
  vi) Ако всички предходни точки завършат успешно, Integro поставя своето одобрение в Pull Request (Bitbucket микросервиса).

• Integro очаква одобрение в Pull Request от назначените ревюъри.
• След като бъдат получени всички необходими одобрения (включително успешно преминали автоматизирани тестове), Integro премества задачата в статус Test on Dev (Jira микросервиса).

6. Тестировачите провеждат тест на задачата. Ако няма проблеми, те прехвърлят задачата в статус Ready For Build.

7. Integro „вижда“, че задачата е готова за релиз и стартира нейното внедряване в канарения режим (Jenkins микросервис). Готовността за релиз се определя от набор от правила. Например, задачата е в необходимия статус, няма блокировки на други задачи, в момента няма активни внедрявания на този микросервис и т.н.

8. Задачата се прехвърля в статус Canary (Jira микросервис).

9. Jenkins стартира чрез Nomad внедряването на задачата в канарения режим (обикновено 1-3 инстанса) и уведомява за внедряването сервиза за мониторинг на релизите (DeployWatch микросервис).

10. DeployWatch микросервисът събира фон на грешки и реагира на него, ако е необходимо. При превишаване на фона на грешки (нормата се изчислява автоматично) се извършва уведомление на разработчиците чрез Notify микросервис. Ако в рамките на 5 минути разработчикът не реагира (натисне Revert или Stay), автоматично се стартира откат на канарените инстанси. Ако фонът не е превишен, разработчикът трябва ръчно да стартира внедряването на задачата в Production (натискайки бутона в UI). Ако в рамките на 60 минути разработчикът не стартира внедряването в Production, канарените инстанси също ще бъдат откатени за безопасност.

11. След стартиране на внедряването в Production:

• Задачата се прехвърля в статус Production (Jira микросервис).
• Jenkins микросервисът стартира процеса на внедряване и уведомява за внедряването DeployWatch микросервис.
• DeployWatch микросервисът проверява, че на Production всички контейнери са обновени (имало е случаи, когато не всички са се обновили).
• Чрез Notify микросервис се изпраща уведомление за резултатите от внедряването в Production.

12. Разработчиците ще имат 30 минути за стартиране на откат на задачата от Production в случай на открито неправилно поведение на микросервиса. След изтичане на това време задачата автоматично ще бъде влита в master (Git микросервис).

13. След успешен merge в master статусът на задачата ще бъде променен на Closed (Jira микросервис).

Схемата не претендира за пълна детайлност (в действителност стъпките са още повече), но позволява оценка на степента на интеграция в процесите. Ние не смятаме тази схема за идеална и подобряваме процесите за автоматично подпомагане на релизите и внедряването.

Какво следва

Имаме големи планове за развитие на автоматизацията, например, отказ от ръчни операции при релизите на монолита, подобряване на мониторинга при автоматичния деплой, подобряване на взаимодействието с разработчиците.

Но тук ще спрем за момента. Много теми в прегледа на автоматизацията обхванахме повърхностно, някои дори не засегнахме, затова с радост ще отговорим на въпросите ви. Очакваме предложения какво да осветим по-подробно, пишете в коментарите.

Източник: habr.com