Конфигурации сборки для Git Flow

Как люди настраивают свои конфигурации сборки при использовании Git и Git-flow? У меня есть несколько задач, которые я хочу выполнить:

  • Фиксация - компилировать, запускать статический анализ кода, модульный тест, пакет
  • Integration Test - запускать интеграционные тесты
  • Развернуть для тестирования - развернуть приложение в тестовой среде.
  • Функциональный тест - выполнение сквозных функциональных тестов
  • Развертывание в QA - ручное включение в среду QA, которая запускает дымовые тесты

Мне любопытно, как люди сопоставляют их с процессами сборки с ветвями основных, разрабатываемых и выпускаемых функций.


git git-flow teamcity build-automation
person Colin Bowern    schedule 03.07.2013    source источник

Ответы (2)


arrow_upward
2
arrow_downward

В настоящее время у нас есть

  • CI Build
    • The VCS Root has a branch specification that includes develop, feature/*, release/*, hotfix/* and master
    • Триггер фиксации VCS для всех веток
    • Запрос на извлечение веток функций сборки и ссылки на результаты сборки и утверждение
    • Мастер автоматического слияния -> разработка
  • Release notes build
    • A snapshot on CI Build
    • Создает примечания к выпуску из коммитов и фиксирует их
  • Deploy to Dev Build
    • A snapshot on CI Build
    • Планируется развертывание дважды в день
    • Развернута только ветка разработки
  • Deploy to UAT Build
    • Manual step
    • Снимок на CI Build
    • В UAT можно развернуть только release / *, hotfix / * или master.
  • Deploy to Prod
    • Manual step
    • Снимок при развертывании в сборку UAT
    • Здесь может быть развернут только мастер (при закрытии релиза или hoftix мастер должен быть сначала развернут в UAT для дымового тестирования)

Автоматическое слияние Teamcity не допускает подстановочных знаков, поэтому мы работаем над нашим собственным методом для синхронизации веток.

  • мастер -> разработка, выпуск / *, исправление / *
  • разработка -> особенность / *
person JonSquared    schedule 23.03.2015
comment
Мне нравится процесс, который вы объяснили в своем ответе. Единственная часть, которую я не понимаю, - это развертывание в сборку UAT, когда вы автоматически объединяете мастер - ›разработка. Зачем мне это делать, если сборка была сделана из ветки выпуска или исправления? Разве вы не хотите использовать окончательное исправление / выпуск gitflow после завершения развертывания в Prod, чтобы убедиться, что производство синхронизировано с основной веткой? - person Ali B; 31.03.2015
comment
@AliB, спасибо, что не в том месте. На самом деле это часть сборки CI для основной ветки, то есть когда исправление или выпуск закрываются и объединяются. Я обновил свой ответ - person JonSquared; 31.03.2015
comment
@JohSquared, я все еще думаю, что вам нужно объединить мастер для разработки, когда вы находитесь в конфигурации Deploy to Prod Build. Основная ветвь должна быть зеркальным кодом того, что у вас есть в производстве, и если вы объедините его раньше, ваша основная ветка и Prod выйдут из синхронизации. Создание исправлений становится проблемой, когда вам это нужно. - person Ali B; 01.04.2015
comment
@AliB Вы должны синхронизировать мастер для разработки, как только фиксация поступает в мастер, в случае GitFlow, когда выпуск или исправление закрываются. В моем случае, когда совершается фиксация в любой ветке, запускается сборка CI. Так, например, когда релиз протестирован и готов к выпуску. выпуск закрывается и объединяется с мастером - ›Запускается сборка CI на мастере -› ​​в случае успеха мастер сливается с разработкой - ›Развертывание в UAT Сборка запускается для мастера (быстрый дымовой тест) -› Выполняется сборка Deploy to Prod - person JonSquared; 01.04.2015

arrow_upward
0
arrow_downward

Это мой рабочий процесс:

Branch-per-Feature (dymitruk.com)

это адаптировано из nvie's

person Adam Dymitruk    schedule 03.07.2013