Как обеспечить масштабируемость проекта со старта и подстроить CI/CD под свои цели? Основано на реальных событиях

Привет, Хабр. На связи Михаил, я бэкенд-разработчик в Clevertec. Компания специализируется на разработке финтех-решений. Моя работа связана с проектом, который начинался с создания личного кабинета клиента и развился в экосистему, растущую вместе с бизнесом. На его примере я расскажу, как можно изменять подход к CI/CD, чтобы не тормозить рост проекта и оптимизировать работу команды.

Стартуем MVP

Мы начали проект с нуля, имея лишь одного системного аналитика, двух бэкенд-разработчиков и одного фронтенд-разработчика. Решили создать MVP на своей стороне. Оценили результаты, выстроили микросервисную архитектуру, определились с БД и ждали решения о дальнейшей судьбе проекта. Вскоре заказчик дал добро на реализацию и попросил заложиться на будущий рост.

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

Учитывая микросервисную архитектуру проекта, мы выделили место на нашем удаленном сервере и решили использовать docker-контейнеризацию с утилитой docker-compose для развертывания сервисов.

Но со временем мы столкнулись с проблемами: 

• ограниченное количество стендов

• сложность обновления микросервисов

• недостаток мониторинга

Следующим этапом автоматизации процессов развертывания стало внедрение GitLab CI, позволяющее автоматически деплоить коммиты и обновлять сервисы с помощью docker-контейнеризации. Это значительно ускорило и упростило процесс разработки.

Первые проблемы роста: расширяем и оптимизируем CI/CD

С ростом проекта стало ясно, что одного экземпляра сервисов недостаточно. Для начала мы организовали работу посредством GitFlow. Далее появились 4 отдельных стенда: 3 песочницы и production, и был настроен автоматический деплой основных веток на соответствующие стенды dev-test-stage-production. Это дало нам возможность тестировать и проверять взаимодействие сервисов на различных окружениях – и проект стал работать стабильнее. 

Изменяем стандартный Git Flow и уходим от веток

Проект рос, у бэкенда становилось все больше задач, в то же время разработчики много занимались CI/CD.   

На этом этапе есть два пути: 

1. расширять команду разработчиков

2. делегировать задачи выделенной DevOps-команде

В нашей команде заведено, что бэкенд-разработчики универсальные и с основной работой по CI/CD могут справляться сами. Считаем это нормальной практикой, если она оговорена на старте.

Мы приняли решение перейти на более удобные и гибкие методы управления версиями и развертываниями. Отказались от веток dev, test, stage и начали использовать непрерывное развертывание на разные стенды только из веток feature. Как результат – сохраняются четыре стенда и появляется возможность оперировать фичами, комбинировать их и раскатывать, как нужно по ситуации. 

Разработчик создает ветку feature, делает коммит, но автоматически ничего не раскатывается. Работает новая функциональность – настроены пайплайны и возможности: деплой любой ветки feature в любой тестовый стенд dev-test-stage. Теперь разработчики могут безопасно выпускать новые функциональности и исправления ошибок, используя соответствующие пайплайны и механизмы релизов.

Сценарий мечты – множество стендов

Процесс CI/CD налажен и стабилен. Но все еще есть проблемы, которые крадут время и усилия разработчиков. 

Например, когда готовим релиз нескольких фич, то приходится объединять ветки в одну общую релизную. Это неудобно, и вот почему.

Тестировщики тестируют одну фичу на стенде, вторую, третью… Потом они говорят: теперь объединяйте всё, будем катить. Объединяем. Но релиз одной фичи отменяется, и разработчики уходят ее выпиливать. Это лишние движения, которых можно избежать, если иметь много стендов, а не стандартные четыре.

Идея в том, чтобы запараллелить процессы и не мешать друг другу. Пока одни стенды заняты тестировщиками, а разработчик хочет безопасно протестировать свою новую доработку на стенде и ничего не сломать в чужих, он выбирает произвольное окружение. Выделяется часть машины, создается база – и фича раскатывается. И это можно повторять неограниченное количество раз. Как только тест окончен – одним нажатием дополнительный стенд удаляется. И все счастливы.

Мы уже начали новый этап оптимизации процесса разработки. Как мы это делали, с какими трудностями столкнулись и удалось ли с помощью изменений приблизиться к идеалу, расскажу после внедрения.

А вы поделитесь в комментариях своим опытом организации непрерывной интеграции и развертывания – обсудим.