Как я могу остановить Chef от развертывания кода с неудачными тестами?

На прошлой неделе я активно использовал Chef и готовился (эмоционально и оперативно) прекратить использование Capistrano. (Мы размещаем приложение Rails.)

Мы следуем потоку GitHub, а это означает, что у нас есть только основная ветка и множество функциональных веток. Прямо сейчас мы используем Jenkins для непрерывной интеграции и непрерывного развертывания, а Capistrano — для развертывания master на наших серверах, но только после того, как наши модульные, интеграционные и приемочные тесты пройдены.

Я использую ресурс Chef deploy_revision и в восторге от того, насколько хорошо он работает. Мне не терпится перейти от «толкать» к «тянуть». Но я не хочу развертывать код, если наши тесты не пройдены. Я застрял на выборе между альтернативными подходами к достижению этого эффекта:

  1. Укажите Chef на тег (например, 2.0) и периодически обновляйте этот тег в наших рецептах развертывания. (Мне это не нравится, потому что на самом деле это не непрерывное развертывание. Теперь мы снова держим наш код в руках каждый раз, когда хотим его выпустить.)
  2. Укажите шеф-повару на ветку, чтобы Дженкинс объединил master -> release после прохождения набора тестов. (Мне это не нравится, потому что теперь мой сервер Jenkins имеет доступ для чтения/записи к моему репозиторию.)
  3. Не настраивайте Chef на периодический запуск, вместо этого запустите Jenkins chef-client через SSH. (Мне это не нравится, потому что я с нетерпением ждал того дня, когда наша машина Jenkins больше не будет иметь SSH-доступ к нашим серверам.)
  4. Разверните код, но отмените фиксацию, если впоследствии тест не пройден. (Слишком подвержен ошибкам, на мой взгляд.)

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

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


continuous-integration continuous-deployment chef-infra
person mesozoic    schedule 30.12.2012    source источник

Ответы (2)


arrow_upward
2
arrow_downward

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

Другим вариантом было бы иметь отдельный клон репозитория, в который Дженкинс объединяет master -> release, который не является вашим репозиторием разработки. Затем попросите Chef извлечь оттуда (или попросите Chef найти там ревизию и извлечь эту ревизию из исходного репозитория, что даст вам немного больше уверенности в том, что никто искусственно не испортил промежуточную фиксацию).

person Amber    schedule 30.12.2012
comment
Спасибо, Эмбер, это хорошие предложения. Я могу работать с последним вариантом, чтобы я мог регулярно запускать chef-client для обновления инфраструктуры без обязательного обновления нашего кода. Вы применяли что-то подобное на практике? - person mesozoic; 31.12.2012
comment
@АлексЛ. Похожий. Если вы посмотрите в расширенной конфигурации Git-часть вашей сборки, там есть варианты использования нескольких репозиториев. Вы можете настроить отдельный URL-адрес репозитория, в который будут отправляться успешные сборки. - person Amber; 31.12.2012
comment
Эй, я даже этого не видел. Для всех, кто еще бродит по этому ответу, в задании Jenkins этот параметр находится в разделе SCM > Git > Дополнительно > Параметры слияния > Слияние перед сборкой. (Необходимо несколько кликов, чтобы увидеть его.) Я собираюсь разобраться с этим. Еще раз спасибо! - person mesozoic; 31.12.2012

arrow_upward
0
arrow_downward

Одно из решений, которое я использовал, состоит в том, чтобы защитить фактическое развертывание кода в рецептах шеф-повара за переменной окружения (в частности, ENV['deploy_build']). Все, что не связано с фактическим развертыванием кода, остается за пределами этих охранников в рецептах, а chef-client радостно запускается каждые полчаса, обеспечивая готовность базовой системы.

Когда сборка и тестовый прогон завершаются успешно, система сборки запускает ssh вида:

ssh deploy_system deploy_build=true chef-client

что позволяет рецепту развернуть последнюю сборку. Это особенно помогает, поскольку нашей системе сборки необходимо развертывать обновления на серверах в определенном порядке, поэтому ее можно организовать из системы сборки (jenkins).

person quandrum    schedule 31.12.2012
comment
Таким образом, рецепт развертывания будет смотреть на значение deploy_build, если это true, рецепт продолжится, и как только он будет выполнен, он установит deploy_build в false, чтобы в следующий раз, когда автоматический запуск шеф-повара не запускал развертывание? - person Omar; 19.08.2013