От скриптове до нашата собствена платформа: как автоматизирахме разработката в CIAN

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

Нулево ниво

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

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

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

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

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

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

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

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

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

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

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

Благодарение на автоматизацията на версиите, процесите на разработка се ускориха, отчасти поради пропускането на някои етапи на тестване. И това доведе до временна загуба на качество. Звучи тривиално, но заедно с ускоряването на изданията беше необходимо да се промени методологията за разработване на продукта. Трябваше да се мисли за автоматизиране на тестването, насаждане на лична отговорност (тук говорим за „приемане на идеята в главата“, а не за парични глоби) на разработчика за пуснатия код и грешки в него, както и решението да освобождаване/не освобождаване на задача чрез автоматично внедряване. 

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

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

В момента имаме персонал от 130 разработчици и продължаваме растат. Екипът за непрекъсната интеграция и доставка на код (наричан по-долу Deploy and Integration или DI team) се състои от 7 души и работи в 2 направления: развитие на платформата за автоматизация Integro и DevOps. 

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

Екипът на DI работи съвместно с екипа на платформата, който разработва вътрешно архитектурата, библиотеките и подходите за разработка. В същото време всеки разработчик в рамките на CIAN може да допринесе за автоматизацията, например да направи микроавтоматизация, която да отговаря на нуждите на екипа, или да сподели страхотна идея как автоматизацията да стане още по-добра.

Слоеста торта на автоматизацията в CIAN

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

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

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

Интегро

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

• CentOS 7
• Докер + Номад + Консул + Трезор
• Java 11 (старият монолит Integro ще остане на Java 8)
• Spring Boot 2.X + Spring Cloud Config
• PostgreSql 11
• RabbitMQ 
• Apache Ignite
• Camunda (вграден)
• Grafana + Graphite + Prometheus + Jaeger + ELK
• Уеб интерфейс: React (CSR) + MobX
• SSO: Keycloak

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

Като пример от реалния живот, помислете за взаимодействие с Дженкинс, което се състои от следните стъпки:

1. Микроуслугата за управление на работни потоци (наричана по-долу микроуслуга Flow) иска да изпълни компилация в Jenkins. За да направи това, той използва Consul, за да намери IP:PORT на микроуслугата за интеграция с Jenkins (наричана по-нататък микроуслуга Jenkins) и изпраща асинхронна заявка до нея, за да започне изграждането в Jenkins.
2. След получаване на заявка, микроуслугата Jenkins генерира и отговаря с Job ID, който след това може да се използва за идентифициране на резултата от работата. В същото време той задейства изграждането в Jenkins чрез извикване на REST API.
3. Дженкинс изпълнява изграждането и след завършване изпраща уебкукичка с резултатите от изпълнението до микроуслугата на Дженкинс.
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, докато човешката фигура показва, че преходът се извиква ръчно от човек. Нека разгледаме няколко пътя, по които една задача може да поеме в този работен процес.

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

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

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

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

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

2. Разработчикът приема задачата за работа. След завършване той преминава в състояние НА ПРЕГЛЕД.

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

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

5. Вътре в услугата Flow:

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

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

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

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

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

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

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

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

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

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

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

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

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

Какво следва?

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

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

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