Должен ли сценарий развертывания быть артефактом сборки?


13

Это веб-проект, написанный на Java.

Итак, я пишу сценарии сборки и развертывания. Для создания сборки я использовал муравей. Непрерывная сборка выполняется с помощью Jenkins.

Сборка генерирует 3 разных артефакта:

  1. Файл войны
  2. Почтовый индекс с макетами
  3. Почтовый индекс с изображениями

Пока все хорошо, но теперь мне нужно написать сценарий развертывания, который должен:

  • Разверните войну (артефакт 1) на коте, работающем на сервере 1
  • Поместите артефакт 2 на сервере 1 в определенный каталог
  • Поместите артефакт 3 на сервер 2 в определенную директорию

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

Так что был бы другой сценарий, который бы:

  • Скачать артефакты Дженкинса
  • scp к каждому серверу и разместите там файл deploy.xml
  • удаленно вызвать файл deploy.xml

Что делает меня немного неудобным, так это наличие файла deploy.xml в качестве артефакта сборки. Мотивация заключается в том, чтобы иметь возможность выполнять развертывание без необходимости иметь доступ к репозиториям VCS, поэтому сборка будет автономной, то есть любая сборка может быть запущена в производство только с тем, что было сгенерировано Jenkins.

Где должны быть размещены сценарии развертывания? Должны ли они быть только в VCS или они тоже должны быть артефактами сборки?


этот вопрос хороший / он заставляет нас хотеть плюс-один / хотел бы я ответить
amara

Ответы:


6

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

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


3

Все, что написал Питер Роуэлл, верно, кроме того, я бы:

Для файла сценария развертывания

  • если он был написан кем-то, он должен быть в управлении версиями.
  • если он был сгенерирован и может быть сгенерирован снова, он обычно не входит в контроль версий.

Для процесса развертывания:

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

Это скорее зависит от вашего процесса и от того, как вам нравится обрабатывать развертывания.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.