В прошлой статье Prequel рассматривался деплой приложений с использованием инструмента werf от компании Флант, цель которого была упростить развертывание для разработчиков и по сути разгрузить девопсов(чтобы они не тратили время на деплой приложений по крайне мере дева, так как по сути это все копипаст), уменьшить time to market, в этой статье хочу поделиться опытом этого решения на реальных проектах в ретроспективе, что оказалось не удобно к чему в итоге пришли.

Проблематика

1. Проблема с чартами

   Изначально для разных языков программирования — PHP, Go и JavaScript — были разработаны отдельные Helm-чарты. Это быстро стало неудобным для поддержки. Например, при добавлении функциональности (например, VPA) в чарт для PHP, ту же модификацию приходилось вручную переносить в чарты для других языков. Поддержание консистентности между ними оказалось сложным.

2. Версионирование и несовместимости

   Так как чарт поддерживает семантическое версирование, а сам чарт подгружается на лету при деплое(у нас была указана минорная версия), в случае если кто то напутал с версиями при добавлении фичи в чарт и случилось так что версия не совместима или вообще поломана, но тегнута как патч, может случится так что упадут все деплои при запуске, мы не контролируем обновление чарта.

3. Проблемы с настройками GitLab CI

   У разработчиков сразу появились проблемы с настройками переменных в GitLab

   • У кого-то не было доступа.

   • Кто-то не знал, где найти нужные переменные.

   • Были частые случаи путаницы со значениями переменных(даже у DevOps).

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

4. Сложность CI/CD пайплайна

   Со временем шаблон CI/CD стал слишком большим и сложным. Разработчикам приходилось тратить значительное время на его изучение, несмотря на наличие шаблонов и примеров. Это приводило к постоянным вопросам и коммуникациям между разработчиками и DevOps-специалистами, что замедляло процесс работы.

5. Проблемы с управлением чартами в Git

   Отсутствие гитерминизма — серьёзная ошибка. Всё, что касается приложения, должно быть под версионным контролем. В нашем случае Helm-чарты находились вне репозитория Git, хотя они являются частью приложения. Это привело к разрыву в управлении версиями и ухудшило контроль над инфраструктурой.

Fixs

1. Унификация Helm-чартов

   Мы создали единый Helm-чарт, подходящий для всех используемых языков программирования, что значительно упростило поддержку и расширение. Теперь этим чартом деплоятся проекты на PHP, Go, JavaScript и Java, Payton. Это устранило дублирование и необходимость синхронизировать изменения в разных чартах.

2. Отказ от автоматического выкачивания чартов в CI/CD

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

   Мы решили эту задачу с помощью скелетона для приложений. Например, для Go мы создали скелетон, который:

   • Устанавливает базовую структуру приложения.

   • Автоматически загружает нужный Helm-чарт.

   Разработчику остаётся лишь писать бизнес-логику и настраивать values для деплоя. Такой же подход мы можем применить для PHP и других языков.

3. Упрощение CI/CD и избавление от лишних переменных

   Так как мы убрали автоматическое выкачивание чарта в CI/CD, ненужные переменные в пайплайнах больше не нужны. Это снизило нагрузку на разработчиков и уменьшило количество ошибок при деплое.

4. Шаблоны CI/CD для упрощения деплоя

   Чтобы избавить разработчиков от необходимости вникать в тонкости CI/CD, мы вынесли шаблоны деплоев в общие templates. При установке приложения через скелетон все нужные шаблоны подключаются автоматически. Пример подключения:

   include:

   - project: 'helm-charts/helm-chart'

   file: '/templates/.gitlab-ci-laravel.yml'

   Этот подход также позволяет легко поддерживать шаблоны в одном месте. Например, если нужно добавить стейдж линтинга для Go, мы меняем только один шаблон, и изменения применяются ко всем проектам.

5. Управление зависимостями через Git

   Теперь все зависимости приложения, включая Helm-чарты, находятся под управлением Git. Это решило проблему, когда ранее после клонирования репозитория можно было не найти папку с чартами — что нарушало принцип гитерминизма и усложняло работу. Сейчас все необходимые компоненты деплоя доступны в репозитории приложения.

Итог

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

Мы также разгрузили DevOps-команду: теперь разработчики самостоятельно деплоят свои приложения в dev и staging окружения, а деплой в production проходит через ревью-процесс. Этот подход хорошо зарекомендовал себя на практике. Самое важное — разработчики теперь понимают не только то, как писать код, но и что именно они деплоят и куда.

Послесловие

Зачем я написал этот пост? Просто знаю, что многие команды идут похожим путём, и кто-то уже задавал мне вопросы о реализации. Мне захотелось поделиться опытом, накопленным при работе с реальными проектами и взаимодействии с командами разработчиков и DevOps (и да, я сам разработчик, а не DevOps).

Я старался сделать этот пост простым и понятным, без углубления в сложные технические детали, чтобы он был доступен всем читателям. Надеюсь, мой опыт окажется полезным для тех, кто сталкивается с похожими задачами в своих проектах или тем кто уже работает по похожим схемам и чувствует, что что-то идёт не так.

Ребятам из Флант больше спасибо за то что вы делаете.