Лучшие практики для марионеточного управления модулем с подходом жизненного цикла разработки программного обеспечения?
Как люди организуют свои Марионеточные декларации и модули в Вашем репозитории исходного кода? Я не вижу очевидного способа реализовать изменения в Марионетке поэтапным способом на единственном Марионеточном ведущем устройстве.
Как другие люди управляют этим? Один экземпляр главного сервера на группу серверов / фаза SDLC? Я очень хотел бы использовать те же Марионеточные модули в каждой фазе и просто использовать подверсию для изменения, к какой версии Марионеточных модулей относятся каждая группа серверов / фаза SDLC, таким образом, я могу развернуть изменения в поэтапном подходе. Я ищу способ усилить те же модули и избежать несчастных случаев и изменения, должного копировать модули.
У меня есть убивание серверов, которыми я смотрю на использование марионетки для управления с несколькими SDLC (жизненный цикл разработки программного обеспечения) фазы для покрытия. Аварийное восстановление, Производство, Подготовка, Тестирование Приемлемости для пользователя, Тест, Разработка, Обучение
Редактирование для разъяснения 2-й части:
И как Вы поддерживаете свои ответвления в Вашем источнике repo? Например, с dev и тестовыми ответвлениями и файлом, который определяет, где я получаю свои патчи от.
Сделайте Вы редактируете:
repo:/dev/patchessource.txt для содержания "patchserver/dev"
repo:/test/patchessource.txt для содержания "patchserver/test"
и имейте те отличающиеся файлы, и должны поддержать то различие со слиянием и всем от dev, чтобы протестировать или сделать, люди имеют другой файл для каждой среды и перемещают их в целом:
repo:/dev/devpatchsource.txt для содержания "patchserver/dev"
repo:/dev/testpatchsource.txt для содержания "patchserver/test"
тот путь при слиянии dev repo с тестом repo Вы, не должен волноваться о dev определенной установке, перезаписывающей Ваш тест определенные настройки?
Я не вижу очевидного решения сделать это простым для последующих администраторов, которые не могут быть хорошо сведущими в инструментах управления исходным кодом.
Любые подсказки значительно ценились бы.
Environments is how this is solved. С помощью окружения можно определить конфигурации для производства, постановки, ua тестирования, тестирования, разработки, обучения и т.д.
Глубокое объяснение, как это сделать, немного обширно, но вот несколько ссылок, которые можно прочитать для начала:
- Puppet Labs Docs - About Environements
- Dynamic Environments with R10K (я рекомендую целую серию статей, а не только эту часть).
- R10K документация по GitHub
В главном репозитории у вас есть ветка для разработки , тестирования и производства (или чего-либо ещё, что соответствует вашему рабочему процессу). Вы счастливо пишете свой кукольный код в ветке разработки, коммите, коммите, push. Ваш Мастер Куклы обновляется (по R10K), когда вы проталкиваете (через какой-нибудь Git-крюк или задание cron), и ваши узлы получают обновление в своё время по расписанию.
Предположительно, у вас есть узел, который установлен в окружение development, так что изменения, которые вы перенесли в ветку development, могут быть перенесены в ветку development. Вы можете протестировать всё это.
Вы довольны своими изменениями, слияние в следующую ветвь рабочего процесса - скажем production. Нажмите на объединённые изменения и цикл начнётся - Мастер кукол получит изменения в среде production, а производственные узлы применят новую конфигурацию.
--
Теперь, как я вижу, есть общая путаница, которая есть у людей. Ветвь development для Control Repo не означает "это конфигурация для машин программистов". Нет, это значит, что это ваша ветка разработки кукол.
Итак, как вы поддерживаете набор серверов, скажем, Web-сервер, для 3-х команд - Dev, QA и Pproduction. Т.е. каждая из этих групп имеет веб-сервер, который настроен практически так же, но имеет нюансы, так как одна из них является живой производственной системой, другая - группой контроля качества, а третья - Dev.
Для этого вы используете Hiera. Каждый узел будет иметь те же самые классы, но нюансы в параметрах или в том, что вы установили с помощью Hiera.
Конечно, вы могли бы использовать ветки, чтобы также означать "тип управляемой машины" вместо Hiera, но это немного смешно, потому что вы бы не использовали Git-ветку для их реальной цели. Ответвление было бы совершенно другим, и вам пришлось бы вручную "сливать" их путём копирования/вставки из одного в другой. Это было бы ужасно.