Комментарии 7
1000 строк грувибаша, ну зачем?)
Как будто с ним можно сделать всё, что может werf? :-) Как будто вообще есть такое универсальное средство, удовлетворяющее ещё и другим критериям (используемый стек, производительность и дальше по списку).
Хорошо, когда есть выбор. А уж как его делать — тема для других статей. Здесь же можно увидеть, что предстоит, если выбрать конкретный путь.
Проблема в том, что чтобы настроить werf и CICD с ним, надо произвести действий больше, чем просто настроить CI/CD, без него. И есть более простые и универсальные инструменты для этого. Мегабайты грувибаша нечитаемы и в них сложно разобраться. Если вдруг уволится человек, который это все настраивал, проще все выкинуть и настроить заново.
Повторюсь, статья о том как можно интегрировать werf, если у вас уже налаженные процессы на Jenkins. Практика нашей работы показывает, что если вы не стартап, а средняя или большая компания, то прыгать по простым и универсальным инструментам, выходящим на рынок каждый месяц, с кучей налаженных процессов, идея так себе. У нас же есть возможность интегрироваться в среду и постепенно и безболезненно, а главное гибко привносить что-то новое.
По поводу того кто это настраивал и вдруг уволился. Если есть фидбек, который хорошо описывает сложность в использовании нашего продукта, то мы всегда рады его выслушать, чтобы учесть это и поправить.
Сейчас для настройки нужно 13 переменных, всего 4 из которых могут потенциально меняться. У нас есть полная документация на русском и английском языках, чат в телеграмме, issues в гитхабе, если новому человеку трудно зайти в документацию почитать или задать вопрос в канале чтобы совладать с тем как работает продукт который используют у них в компании, то я даже не знаю что это за специалист.
Какие преимущества появляются после интеграции? Где в итоге выигрыш?
Что конкретно умеет werf, чего нельзя реализовать другими способами?
Прописать в CI мы и так можем все, что угодно. «Гибкость» — вопрос тоже неоднозначный.
В настоящий момент все описанные выше шаги с учетом этих решений уже встроены в команду werf ci-env для GitLab CI/CD и GitHub Actions. Пользователям других CI-систем необходимо реализовывать аналогичные действия самостоятельно — подобно тому, как описано в этой статье для примера с Jenkins.
Вот тут непонятно, зачем все это, если для GitLab CI/CD и GitHub Actions есть свои инструменты, а для другого все равно надо все настраивать самостоятельно.
Вот конкретно в данном конкретном случае. Я еще понимаю, что, допустим, взамен проблемного дженкинса с какой-то новой тулзой я смогу получить более быстрое, более понятное и удобное решение. Но тут-то предлагается к существующей уже системе добавить еще одну аппликуху, которая что-то делает, никак не решая существующие проблемы и еще дальше усложняя все схемы.
Про что конкретно умеет — можно посмотреть список фич на сайте/гитхабе. Есть много всего по сборке, чтобы сделать её эффективной (быстрой с кэшами, инкрементными пересборками с учётом истории Git и т.п., распределенной). Content-based tagging (писали про его фишки в отдельной статье). Удобные инструменты для отладки и при сборке, и при деплое. Деплой в Kubernetes в духе GitOps (автоматизированное поддержание реального состояния инфраструктуры и приложения в соответствии с тем, что в репе). Умная автоматическая очистка образов (про нее тоже была статья). Главное удобство — что все эти части жизненного цикла управляются из одного места, "склеиваются" в нем и благодаря самому этому факту возможно (можно отслеживать нужные образы, чтобы что-то с ними делать).
Да, основную часть вещей можно сделать другими способами. Однако изначальный посыл, что это будет проще и удобнее, вряд ли тогда сработает. А смотреть на всю историю CI/CD и его реализации надо именно так комплексно, а не один какой-то выбранный кусок.
Настраиваем Continuous Integration для Jenkins и Bitbucket с werf