Стратегии ветвления с Maven, teamcity и TFS - PullRequest
Новая
       33

Стратегии ветвления с Maven, teamcity и TFS

5 голосов
/ 08 декабря 2011

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

Фон

В настоящее время у нас есть одна монолитная сборка / приложение, которое действительно нужно разделить как минимум на 4 приложения с некоторыми общими библиотеками. В настоящее время мы не разветвляемся, если мы не обязаны это делать. У нас есть сборка teamcity, которая основывается на каждой регистрации в TFS. Когда мы будем готовы к выпуску, мы зафиксируем код и исправим только исправления ошибок, найденных в QA. Очевидно, это ужасная практика, и мы наконец-то получили одобрение на ее изменение.

Предлагаемые решения

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

Ветвление - Прямо сейчас у нас просто есть основной ствол в управлении исходным кодом. Я думаю, что мы хотим разветвиться от ствола, когда мы будем готовы к выпуску, и обновить ветку для ошибок, найденных в QA. Когда сборка будет готова к выпуску, объедините изменения ветви обратно в ствол.

Вот как я планировал настроить TFS. 

+Apps
    +App1
        +Components
            +Core
            +Web
        +Branches
    +App2
        +Components
            +Core
            +Web
        +Branches
    +Libraries
        +Lib1
        +Lib2
        +Branches

Размышление об управлении всеми POM и версиями в POM кажется СЛИШКОМ слишком сложным сейчас. Я прочитал о плагине Maven Release, но я не уверен, что он сможет работать так, как я думаю.

Следующая проблема - заставить команду работать. Я думал о том, чтобы иметь 3 проекта teamcity для каждого приложения. Проект разработчика, который всегда указывает на соединительные линии, проект QA для тестирования сборки QA и производственный проект для создания изменений для исправлений. Каждый раз, когда в QA приходит новый выпуск, мне приходилось обновлять проект QA teamcity, чтобы указывать на новую ветку релиза, и обновлять номер сборки релиза в teamcity. Когда этот выпуск пройдет QA, мне придется обновить производственный проект teamcity, чтобы указать, что ветвь, которая только что прошла QA, и обновить номер сборки до номера сборки, который только что прошел QA.

Конечно, есть лучшая стратегия, чем эта.

Вопросы

Куда мне класть эти ветки?

Должны ли сборки QA быть моментальными снимками до тех пор, пока сборка не будет готова к производству?

Как вы настраиваете teamcity для получения этих веток без изменения пути к источникам для каждого выпуска?

Должны ли быть родительские POM для каждого приложения, которые разработчики используют, чтобы убедиться, что все их зависимости скомпилированы и обновлены?

1 Ответ

0 голосов
/ 17 января 2012

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

Как эти отдельные приложения связаны друг с другом? Есть ли какая-либо зависимость между ними (возможно, через общую библиотеку)? Они общаются друг с другом? Они развернуты вместе?

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

...