Мы используем марионетку для распространения нашего собственного программного обеспечения (то есть того, что мы пишем, которое мы хотим запускать на наших собственных серверах). Так что где-то мы должны скомпилировать это программное обеспечение.
Для меня имеет смысл использовать git pull и скомпилировать его на мастере марионеток. Скомпилируйте один раз, распространите, наши машины однородны, а двоичные файлы работают на своих помеченных хостах.
Но когда мы обновляем хосты, различные библиотеки изменятся, и нам может потребоваться перекомпиляция для нового набора библиотек.
Кажется правильный поступок заключается в том, чтобы упаковать наше программное обеспечение, передать эти файлы себе, а затем просто использовать директивы пакета в марионетке.
Q1: Звучит правильно / Я пропустил что-то важное?
Q2: Тогда как deb упаковывается и выгружается? Это процесс выпуска вручную? Это означает, что мы обновляем тестовый сервер до новых версий ОС и библиотек, чтобы скомпилировать и упаковать.
Q2B: Теперь предположим, что я устанавливаю этот CI-сервер, и я постоянно говорю своей команде, что я приступлю к установке. Насколько я могу судить, CI-сервер ничего не знает о dist-upgrade. Так должна ли эта часть оставаться ручной?
Ваш процедура сборки может быть либо ручным, либо автоматическим через CI с помощью ряда триггеров. Например (и это только один пример), вы можете пометить новую версию в Git или переместить существующий тег, и ваше приложение CI наблюдает за этим репозиторием или этим тегом и создает / загружает ваш пакет.
Ваш процедура выпуска также может быть ручным или автоматическим.
ensure => latest на твоей марионетке package ресурсы, чтобы, как только вы публикуете пакеты в своем репозитории, они выбираются и устанавливаются вашими узлами.ensure => 'x.y.z' чтобы привязать пакет к определенной версии. При таком подходе вы можете вручную запускать версии на определенных узлах / ролях / средах.Вы можете использовать гибридный подход, объединяющий два вышеупомянутых, используя hiera и параметризуя свои модули - вы можете гарантировать latest в вашей среде разработки / сборки и x.y.z в вашей производственной среде, например.
Вы можете полностью удалить Puppet из уравнения и выполнять выпуск вручную с помощью такого инструмента, как Capistrano.
Отдельное решение - использовать непрерывную доставку и обрабатывать ваши серверы как крупный рогатый скот, а также полностью обновлять их с каждым выпуском - см. Блог Мартина Фаулера для получения дополнительной информации об этом.
Важная заметка: В строить и релиз в идеале процедуры должны быть полностью независимыми и не должны взаимодействовать друг с другом, хотя для успешной сборки мог запустить автоматический выпуск в среду UAT, например, а затем использовать ручную / другую процедуру выпуска для производства.