Как синхронизировать активность CI (Hudson) с существующим автоматизированным процессом сборки (phing, svn)?
НАШ ТЕКУЩИЙ ПРОЦЕСС СБОРКИ
Мы - небольшая команда разработчиков (от 2 до 4 человек в зависимости от проекта), которые в настоящее время используют Phing для развертывания кода в промежуточной среде перед запуском в эксплуатацию. Мы храним наш код в репозитории SVN, где магистраль содержит текущую активную разработку, и в определенное время мы создаем ветви, которые тестируем, а затем (в случае успеха) помечаем и экспортируем в промежуточную среду. Если и там все пойдет хорошо, мы, наконец, развернем их на производственных серверах. Действия в высшей степени автоматизированы, но всегда инициируются вмешательством человека.
СОМНЕНИЕ
Теперь мы хотели бы внедрить непрерывную интеграцию (с Хадсоном) в процесс; к сожалению, у нас есть некоторые сомнения по поводу синхронизации активности, так как мы боимся, что CI может несколько помешать нашему процессу сборки и вызвать определенные проблемы.
Учитывая, что автоматизированный цикл CI имеет определенную частоту автоматически выполняемых действий, мы видим 2 возможных примеры "интеграции", каждый со своими проблемами:
Случай A: каждый цикл CI создает новую ветвь со своим собственным именем; мы используем такое имя, чтобы вручную (через phing, как это происходит сейчас) экспортировать код из SVN в промежуточную среду. Проблема, которую я вижу здесь, заключается в том, что (если не будут приняты конкретные контрмеры, т. Е. Удаление) Количество ветвей, которые у нас есть, может легко выйти из-под контроля ( предположим, что мы часто фиксируем, чтобы у нас была новая новая сборка/ветвь каждые N минут).
Случай B: каждый цикл CI создает новую ветвь с именем "текущая", которая затем помечается уникальным именем только тогда, когда мы вручную решаем экспортировать ее в промежуточную; текущая ветвь в любом случае удаляется, как только запускается следующий цикл CI. Проблема, которую мы видим вот что может дать толчок новому циклу в то время как кто-то находится пометка/экспорт "текущего" ответвление на промежуточную стадию, таким образом, создавая несогласованную сборку (но, возможно, здесь Я просто слишком пессимистичен, так как признаюсь, что не знаю, является ли SVN обеспечивает некоторую встроенную защиту против этого).
Учитывая все сказанное, мне было интересно, может ли кто-нибудь с подобным опытом быть настолько любезен, чтобы дать нам некоторые подсказки по этому вопросу, поскольку ни один из описанных выше подходов не выглядит для нас полностью удовлетворяющим.
Есть ли что-то важное, что мы только что полностью упустили из виду в общей картине? Спасибо за ваше внимание и (заранее) за вашу помощь!
2 answers
В обоих вариантах вы начинаете с "каждый цикл CI создает новую ветвь". Не делай этого. Вы хотите свести количество филиалов к минимуму и всегда держать их под контролем (созданным вручную), чтобы избежать того, чтобы ваш проект превратился в беспорядок. Решение о том, готова ли разработка в магистрали, и вы можете создать кандидата на выпуск (ответвление от магистрали), не является тривиальным.
Циклы CI запускаются изменениями в коде, чтобы гарантировать, что интеграция этих изменения не нарушают работу приложения. Поэтому вы бы предпочли создать проект в Гудзоне для каждого активного потока разработки, это один для основной линии, один для ветки, представляющей производственную версию (для исправления ошибок), и, в конечном счете, один для RC.
Статья Мартина Фаулера о непрерывной интеграции является отличным руководством по причинам и способам реализации CI.
Подход, который мы использовали в нашем проекте, заключался в том, чтобы запускать сборки CI только при изменении кода. Это может быть настроено в вашей SVN в качестве крючка для фиксации сообщений. Затем вы можете удаленно запускать сборки в ХАДСОНЕ по аутентифицированному URL-адресу. Проблема, которую я вижу, заключается в том, что, поскольку рабочие места должны быть созданы, если ваша система сборки не поддерживает это, Хадсон не сможет выяснить, что в репозитории есть новая ветвь, и создать для этого задание.