Правильное использование SVN & CI - PullRequest
2 голосов
/ 09 марта 2010

Я сейчас настраиваю среду разработки для своего стартапа. Я использую Hudson для непрерывной интеграции исходного кода. Он опрашивает SVN-репозиторий на предмет изменений каждые 10 минут и, если они есть, развертывает их на LIVE-серверах с наших DEV-серверов.

Хотелось бы, чтобы у меня была еще одна работа в Гудзоне, которая разворачивалась из DEV в TEST. Я хочу иметь возможность зафиксировать код в SVN, а затем вручную развернуть его в TEST, выполнить ручную проверку качества и затем передать ее в LIVE.

Есть ли способ, которым я могу сделать это с ветвями и транками в SVN? Я хотел бы, чтобы он все еще проводил опросы каждые 10 минут, поскольку есть много случаев, когда он должен переходить прямо из DEV в LIVE. Я подумал, что, может быть, я смогу зафиксировать ветку, затем сделать так, чтобы hudson автоматизировал развертывание в TEST, а затем, если все получилось, зафиксировать ветку в транке. Я прав?

Заранее спасибо

Ответы [ 2 ]

3 голосов
/ 09 марта 2010

Я не понимаю, зачем вам нужен отдельный шаг теста, если все еще есть «множество случаев, когда он должен перейти прямо из DEV в LIVE», что, как говорит @Hightechrider, звучит рискованно. Я бы так и сделал:

  • Пусть Хадсон обнаруживает изменения каждые 10 минут и развертывается в ТЕСТ
  • Проведите ручное тестирование
  • Напишите еще одно задание Hudson, в котором развертывается только что проверенная версия SVN из TEST в LIVE на основе триггера, например, отправка электронного письма на сервер Hudson, если тесты пройдены (см. вики Hudson для подробности)

Если ваши ручные тесты не пройдут на шаге 2, я предполагаю, что вы захотите, чтобы ваши разработчики исправили код и повторили шаги 1 и 2 перед развертыванием в рабочей среде.

Мне интересно, неправильно ли мы понимаем ваш сценарий - если да, пожалуйста, добавьте еще некоторые подробности о том, почему вы иногда хотите развернуть в TEST, а в других случаях прямо в LIVE.

1 голос
/ 09 марта 2010

То, что мы делаем с помощью TeamCity, - это сборка, а затем регистрация двоичных файлов в отдельный BINARY SVN для ТЕСТА с использованием SVN LOAD_DIRS. Разверните эти биты на серверах TEST. Если они хорошо выглядят, вручную запустите другую задачу CI, которая использует SVN LOAD_DIRS второй раз, чтобы скопировать биты в репозиторий PRODUCTION SVN, а затем развернуть эти биты в рабочей среде.

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

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

Еще одним преимуществом является то, что вы можете хирургическим путем заменить отдельные файлы контента в производстве на последнюю версию, проверив только эти отдельные измененные файлы - удобная функция в 16:00 в пятницу, когда вы не рискуете полным развертыванием на случай, если некоторые другие изменения проникли в двоичные файлы.

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

...