- Создание / проверка версии HEAD ("основная ветка")
- Разработка кода и синхронизация с основной веткой - как минимум - ежедневно
- После завершения разработки напишите и запустите модульные тесты
- Пройдите проверку кода и отправьте код / изменения в основную ветку
- Разрешить непрерывному сборщику запускать все модульные и системные / интеграционные тесты в основной ветке
- Когда все будет готово, выберите вишню ревизии и интегрируйте их в ветку QA
- Запуск системных и интеграционных тестов, исправление обнаруженных ошибок или откат при необходимости; это повторяет шаги 4-7
- После выхода из QA интегрируйте изменение QA в ветвь релиза
- Запуск модульных тестов, системных / интеграционных тестов в ветке релиза
- Развертывание в производство и запуск тестов работоспособности.
Промежуточный сервер - это копия вашей производственной среды, которая максимально обновлена. В моем текущем проекте мы можем сохранить каждый выпуск независимым друг от друга, поэтому наш «промежуточный сервер» - это наш производственный сервер, доступ к которому осуществляется с другого URL.
Примечания и несоответствия:
Все шаги имеют некоторые различия в зависимости от размера вашего проекта. Чем больше ваш проект, тем лучше выгода от сбора вишни и разделения окружающей среды. В небольших проектах это могут быть просто временные затраты, и их часто игнорируют или игнорируют.
Для пояснения есть стек разработки, стек QA и Staging stack. В зависимости от размера вашего проекта, QA может быть поэтапным, Production может быть поэтапным или какой-либо их комбинацией. Разделение стеков Dev и QA является наиболее важным.
В приведенных выше шагах я предполагаю, что код и соответствующие данные имеют версии или отслеживаются. Процесс выпуска и сборки, учитывающий управляющие данные, делает выпуск очень и очень простым.
В небольшом проекте может существовать или не быть ветвь релиза; это зависит от частоты смены кода. Кроме того, в зависимости от частоты изменения кода и размера вашего проекта, вы можете интегрировать полную ветку QA в ветку Release или выбрать определенные ревизии для интеграции в ветку Release.
FWIW, я обнаружил, что "сценарии миграции" не имеют большого значения. Они всегда одноразовые сценарии с небольшим повторным использованием и делают откат болью в заднице. Я бы сказал, что гораздо проще иметь приложение, обратно совместимое. После нескольких выпусков (когда откат вызывает смех), при необходимости следует выполнить очистку данных.