Настройка SVN для Best Suit Dev -> QA -> Prod - PullRequest
6 голосов
/ 05 марта 2009

Извините, если об этом уже спрашивали, но я не смог найти ответ, специфичный для этой ситуации:

Для нашего веб-приложения у нас есть 3 системы: dev, QA и production. Прямо сейчас третье лицо поддерживает код, но скоро он будет в наших руках. У нас будет отдельная среда сборки для каждого этапа. Кроме того, мы используем RAD для разработки кода, поэтому на самом деле будет основной шаг, test / sandbox.

В идеале мы хотели бы как-то изолировать репозитории для каждого этапа, чтобы мы извлекали из DEV, вносили некоторые изменения, тестировали их локально и возвращали обратно в DEV. Если на Dev все в порядке, мы проверим QA и т. Д.

Должны ли мы иметь отдельные репозитории для каждого, или это подпадает под 'ветвление', где у нас будет отдельная ветвь для dev, QA и prod. Не могли бы вы также предоставить наилучшие способы реализации идеального маршрута?

Дайте мне знать, если есть еще вопросы.

Спасибо Chris

Ответы [ 6 ]

6 голосов
/ 05 марта 2009

использовать ветвление и слияние

Мы делаем следующее:

Когда мы выпускаем, мы создаем ветку текущего выпуска. Мы делаем исправления ошибок здесь между выпусками, а затем объединяем их обратно в наш ствол.

Мы разрабатываем на транке, и когда мы готовы к выпуску, мы делаем ветку QA. Мы тестируем и исправляем его, а затем выталкиваем, и он становится нашей текущей веткой релиза.

3 голосов
/ 05 марта 2009

Проверьте сообщение в блоге Скотта Коуэна:

http://sleepoverrated.com/archive/2007/12/buildknowledgepromotingyourbuild/

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

1 голос
/ 06 марта 2009

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

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

В идеале это означает, что что-либо объединенное с транком не нарушит сборку, и это означает, что вы не боитесь зафиксировать свой код для создания хрупкой сборки.

Я часто использую несколько веток для одной проблемы, тестируя разные решения, но при этом получаю преимущества SCM.

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

Во многих наших веб-системах используется svn: externals, которые указывают на конкретные версии зависимостей, таких как библиотеки и код поставщика. Развертывание берется из внешних источников, а не из прямой проверки или экспорта.

1 голос
/ 06 марта 2009

У нас есть похожая схема. В SVN у нас есть 3 филиала: trunk, PREPROD и PROD. Всякий раз, когда новая функция готова попробовать, она объединяется с веткой PREPROD (используя только определенные номера ревизий и только для определенных файлов), если она проходит QA, она фиксируется и объединяется в ветку PROD. Когда изменения фиксируются в ветви PROD, они автоматически развертываются на всех производственных серверах. За исключением тестирования новых функций, PREPROD и PROD равны.

1 голос
/ 05 марта 2009

Это прекрасно работает, если вы работаете над одним потоком разработки с легко подтвержденными задачами. Но это окажется более сложной задачей с несколькими потоками разработки и возможностью того, что задачи будут отодвинуты или отложены. Тогда вам понадобится какая-то временная зависимость в вашем приложении. Вы также можете использовать что-то вроде ветвей функций, которые объединяются обратно в ствол после создания этой функции.

1 голос
/ 05 марта 2009

У вас должен быть один репозиторий, который можно извлечь или экспортировать в процессе развертывания.

У нас тоже есть похожая настройка. Разработчики проверяют локальную рабочую копию и разрабатывают в своей среде разработки. Когда мы готовы выполнить развертывание или выполнить QA, как вы его называете, мы выполняем экспорт SVN в эту среду (часто в голову, но мы всегда отслеживаем конкретную версию).

В процессе QA мы продолжаем разрабатывать в dev и развертывать в QA.

Наконец, когда мы готовы к производству, мы экспортируем правильную версию из репозитория в производственную среду.

Отлично работает!

[Edit: насколько «это ветвление» - то, что вы описываете, вероятно, больше похоже на отслеживание изменений. ветвление, однако, является очень важной техникой для управления различными линиями разработки. это не следует путать с наличием разной ветви для каждой стадии (dev, stage, live), обязательно]

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...