Основное

Тут рассказано про весь цикл CI/CD – от набора строк кода до выпуска новых фич в доступ для каждого.

Сервисы и плагины

Для деплоя сервисов мы используем ArgoCD, для плагинов – git-sync.

Все сервисы, плагины и прочие кастомные решения проходят через свои пайплайны – в чем-то схожие, но все равно разные – и версионирование, различное для каждой из сред.

Для сборки Docker образов мы используем селфхостед GitHub Actions раннеры – получаем больше производительности и не тратим минуты от Github Free for organizations.

Прочие решения

Для прочего опенсорсного ПО, которое мы используем (базы данных, прокси-менеджеры, брокеры сообщений и т.д.) мы соблюдаем IaC (Infrastructure as Code) принципы. Все манифесты, конфиги, секреты и прочие Kubernetes ресурсы сохраняются в текстовом формате и включаются в резервные копии. Благодаря такому подходу, в критическом случае, мы имеем возможность несколькими командами поднять достаточную инфраструктуру, чтобы проект мог дышать, и погрузиться в расследование возникнувшей проблемы и оценку ущерба.

Процесс разработки

Репозитории ветками условно разделены на три части:

• main – главная ветка, которая уходит на прод. Билды для этой ветки версионируются, имеют зависимости для обновлений и строгое ревью.

• dev – второстепенная ветка, которая уходит на дев. Сюда попадают готовые и прошедшие ревью фичи, улучшения и несрочные багфиксы.

• ветки, отделенные от dev – ветки, направленные на конкретные изменения – будь то фикс или новая фича. Ветки имеют формат <issue_id>/<краткое_название> .

В кратце, полный жизненный цикл, который проходит каждое изменение, выглядит так:

пуш в отдельную ветку -> ревью изменений -> мердж в дев -> тестирование в dev окружении -> повторное ревью -> мердж в main -> выпуск в продакшен