Как реализовать эту стратегию ветвления и развертывания с использованием TeamCity и Octopus

Question

Я занимаюсь исследованиями и пытаюсь найти оптимальную стратегию ветвления и развертывания для выполнения нижеприведенных требований. Может быть, я что-то пропустил, но это сложнее, чем кажется. В идеальном случае у нас будет только одна постоянная ветвь, «мастер», которая может иметь определенные фиксации, помеченные для маркировки выпусков к выпуску.

Наша нынешняя стратегия основана на Git Flow и имеет постоянного мастера ветвей (только выпуски для производства) и «развивается». Основное, что усложняет использование модели с несколькими постоянными ветвями, - это концепция «продвижения» одной и той же сборки из промежуточной среды в производство. В настоящее время это необходимо сделать в отдельной ветке исходного кода (развертывание в стадии разработки происходит из «разработки», развертывание в prod происходит из «master»).

Инструменты: Git (VSTS), Teamcity, Octopus Deploy

Требования (функция и исправления жизненных циклов):

• Весь код проверяется с помощью выдвижных запросов (исполнение с помощью политики филиалов)
• Весь код развертывается в промежуточной среде для тестирования
• Мы можем быстро вернуться к любому снимку кода, который был deplo Yed ранее
• Если тестирование прошло успешно, то же сборка может быть «повышенно» из нашей промежуточной среды производства (нет необходимости строить заново)

Особенность накапливается с течением времени, прежде чем выталкивая производства как единая выпуск. Исправления должны быть в состоянии пройти, не попав в «все или ничего» следующего регулярного выпуска.

Мне нравится идея иметь одну постоянную ветку с тегами (re: Разделение мастера/разработки является избыточным, http://endoflineblog.com/gitflow-considered-harmful), но наличие дополнительных постоянных ветвей может лучше облегчить развертывание на разные жизненные циклы/версии (функция и исправление) до Octopus ,

Я боролся с тем, как лучше всего снять это, и я, возможно, слишком усложняю ситуацию. Любые отзывы приветствуются.

Answer 1

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

---

Весь код проверяются с помощью выдвижных запросов (насильственных с помощью политики филиалов)

Я не смотрел на VSTS для возрастов, но я ожидаю, что они уже поддерживают политику филиалов и тянуть -requests, поэтому не уверен, что здесь есть что-то, что вам нужно, кроме настроек в ваших репозиториях.

В случае, если VSTS не поддерживает это, вы можете перейти к инструменту, который, например, BitBucket, GitHub и т. Д. Оба они имеют внутреннюю версию, если вы не можете (или не хотите) использовать версию, размещенную в облаке.

Весь код развертывается в промежуточную среду для тестирования

Вы добиться, что с настройкой lifecycles in Octopus Deploy, чтобы убедиться, что развертывание/акции следовать последовательности вы хотите.

Мы можем быстро вернуться к любому снимку кода, который был развернут ранее

У вас уже есть системы управления версиями, так что все, что вам сейчас нужно прослеживаемость от кода, который развернут в среде, версию развертывания в Octopus Deploy, задание сборки в TeamCity, ветку и точное коммитирование в вашем исходном элементе управления.

Там несколько вещей, которые вы можете сделать, чтобы добиться того, что:

1. Определение схемы управления версиями, которая работает для вас. Мне нравится использовать семантическое управление версиями. «Major» и «Minor» версии определяются разработчиками, а «Патч» - это автоматически увеличивающееся число из TeamCity (% build.number%). Каждый git push создает код и генерирует уникальную версию сборки (% major%.% Minor%.% Build.number%)

2. Как часть шагов сборки в TeamCity перед компиляцией кода убедитесь, что ваш источник файлы исправлены с помощью номер версии, назначенный каждой сборкой, совершить хеш от вашего источника управления, и название филиала. например если вы используете .NET, убедитесь, что все файлы AssemblyInfo.cs обновлены с этой версией, так что версия встроена в двоичные файлы. Это позволяет любому пользователю запрашивать версию, изучающую свойства двоичных файлов, а также позволяет отображать версию приложения в самом приложении (например, строка состояния, нижний колонтитул, подпись, поле и т. Д.).

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

4. Имейте Octopus, чтобы тег вашего источника с номером версии развертывания и именем среды, чтобы вы могли быстро увидеть (от вашего источника) то, что было развернуто где.

Шаги 1 и 2 являются самыми важными, действительно. 3 и 4 просто приятны. Большую часть времени вы будете просто открыть приложение в среде, проверить фиксацию хэш в «О», и сделать git checkout к этому совершить хэш ...

Если тестирование прошло успешно, то же самое строить можно «поощрять» из нашей промежуточной среды производства (нет необходимости строить заново)

опять же, Octopus Deploy lifecycles, и убедитесь, что ничего другого в каждой среде определяется в файле конфигурации приложения, который обновляется во время развертывания Octopus, используя environment-specific variables.

С точки зрения рабочего процесса филиала это последнее требование обязывает объединять изменения в master (или независимо от того, какая ваша ветка «производства») до начала жизненного цикла развертывания.