Комментарии 7
Ура! Спасибо команде разработки.
Есть Waypoint vs. Other Software | Waypoint by HashiCorp (waypointproject.io)
Идея М. Хашимото в том, что деплой артефактов и релиз (публикация запущенного приложения) должны быть разделены на уровне воркфлоу. Навскидку кажется, что идея годная.
Можете прокомментировать? Возможно ли взять лучшее и там, и тут?
Честно говоря, нет понимания, что подобное разделение может привнести в классический подход с контурами и как оно укладывается в непрерывную доставку в целом.
У нас во всех проектах при каждом коммите автоматически создаётся CI-пайплайн. В нём собираются образы, выполняются тесты, приложение для отладки и оставшихся проверок выкатывается на различные Kubernetes-контуры, и если всё хорошо — изменения доходят до конечного пользователя.
Условно следующий набор шагов:
werf build # сборка образов
werf run || werf compose up # произвольное количество шагов тестирования компонентов
werf compose --env review-<ID> # выкат на легковесный ревью контур
werf compose --env staging # выкат на production-like контур
werf compose --env production # выкат на production
p.s. количество шагов / пайплайнов, а также зависимости (вручную, автоматически, при изменении определённой ветки ...) произвольны.
Werf поддерживает данное разделение публикации артефактов и релиза с помощью т.н. бандлов: https://werf.io/documentation/v1.2/advanced/bundles.html
werf bundle publish
готовит и публикует в container registry бандлы — артефакты, состоящие из собранных образов и инструкций для их развертывания;werf bundle apply
выкатывает бандл из container registry (доступ к Git-репозиторию уже не требуется, только к container registry).
деплой артефактов и релиз (публикация запущенного приложения) должны быть разделены на уровне воркфлоу
Имеется в виду публикация артифактов? Если да, то ИМХО обычно сегодня так и делают.
werf v1.2 — стабильный релиз Open Source-утилиты для доставки приложений в Kubernetes