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

На 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-ове, събиране и публикуване на Code coverage и други проверки) възникна постоянна нужда да се откажем от ръчните релизи и да оставим работата на роботите. Освен това в компанията започна преместване към микросервизи, които изискваха чести релизи, отделно един от друг. Така постепенно стигнахме до автоматизирани релизи на нашите микросервизи (монолитът все още се издава ръчно заради сложността на процеса). Но, както обикновено се случва, възникна нова сложност. 

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

Заради автоматизацията на релизите процесите на разработка се ускориха, частично за сметка на пропускане на някои етапи от тестването. А това доведе до временно влошаване на качеството. Звучи банално, но заедно с ускорените релизи трябваше да променим и методологията на разработка на продукта. Нужно беше да помислим за автоматизация на тестването, прилагане на лична отговорност (тук става въпрос за "приемане на идеята в главата", а не финансови санкции) на разработчика за издавания код и бъговете в него, както и за решение относно пускането/не пускането на задачата чрез автоматичен деплой. 

За да се справим с проблемите с качеството, стигнахме до две важни решения: започнахме да провеждаме канарейско тестване и внедрихме автоматично мониторинг на фоновите грешки с автоматично реагиране при превишаване на нормата. Първото решение позволи да се откриват очевидни грешки преди пълноправното попадане на кода в production, а второто намали времето за реакция на проблеми в production. Грешки, разбира се, се случват, но ние влагаме по-голямата част от времето и усилията си не в корекцията, а в минимизацията. 

Екип по автоматизация

В момента имаме екип от 130 разработчици и продължаваме да растем. Екипът по непрекъсната интеграция и доставка на код (нататък — екип Deploy and Integration или DI) се състои от 7 души и работи в 2 направления: разработка на платформата за автоматизация 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. За целта той чрез Consul открива IP:PORT на микросервиса за интеграция с Jenkins (по-нататък наричан Jenkins-микросервис) и изпраща асинхронна заявка за стартиране на компилацията в 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. Уеб утилити (UI за управление на тестови среди, събиране на статистики и т.н.).
7. Интеграция с тракери на задачи и подобни системи.
8. Управление на работния поток за различни задачи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6. Тестировчиците провеждат тест на задачата. Ако нямат проблеми, преминават задачата в статус "Готов за изграждане".

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

8. Задачата преминава в статус "Канара" (Jira микросервиз).

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

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

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

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

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

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

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

Какво следва

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

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

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