Стратегия модели ветвления Git

Мы пытаемся следовать модели ветвления gitflow , но с изюминкой.

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

  • DevServer , где разработчики тестируют свои различные функции во время разработки. Разработчики не могут тестировать локально на своих машинах, они должны внести свои изменения на DevServer, чтобы иметь возможность тест
  • TestServer , где тестировщики QA тестируют несколько функций после того, как разработчики закончили
  • ReleaseServer , где релизы тестируются изолированно перед их перемещением в производство
  • ProductionServer . Производственный сервер

Мы стараемся сделать слияние / разрешение конфликтов как можно более простым, поэтому мы создали две дополнительные ветви, которые не являются частью модели gitflow.

Нормальный gitflow ветви

  • развивать
  • master (соответствует 'ProductionServer')
  • featureXXX
  • releaseXXX (еженедельные релизы развертываются на 'ReleaseServer')

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

  • dev-release (копия DevServer)
  • test-release (копия TestServer)

Тогда процесс происходит следующим образом:

  • разработчик создает свои "featureXXX" из "Development"
    • Несколько разработчиков объединяют свои различные "функции" в ветвь "dev-release", и ветвь "dev-release" выпускается на "DevServer", где все разработчики могут затем протестировать свои различные функции. Не все эти функции будут в том же следующем выпуске
  • Как только разработчики довольны своим тестированием dev выше, они объединяют свой "featureXXX" в ветку "test-release", и это развертывается в "Тестсервер". Не все функции здесь будут частью того же самого следующего выпуска.
  • Как только тестирование на' TestServer 'будет выполнено для featureXXX, разработчик может закрыть свой featureXXX в 'Development'.
    • Затем разработчик либо создает новый "releaseXXX", либо объединяет их "featureXXX" в существующий "releaseXXX".
  • ветвь releaseXXX развертывается на сервере ReleaseServer и тестируется.
  • Как только тестирование releaseXXX завершается, releaseXXX объединяется в Development и master, и развернут в "ProductionServer"

Мы испортили всю модель gitflow?

Вот наш процесс бранширования: Введите описание изображения здесь

2 3
git-flow branching-and-merging

2 ответа:

Чтобы ответить на ваш вопрос, нет, вы не путаете модель gitflow - больше расширяете ее для удовлетворения ваших потребностей.

Связывая среды с данной ветвью, вы даете себе гораздо больше гибкости, когда речь заходит о создании релизов. например, у вас есть две независящие функции (функция 1 и 2) в процессе выполнения, обе из которых были объединены в ветку "TestServer". Если функция 1 не проходит тестирование, функция 2 все еще может быть продвинута дальше без функции 1 - это потому что ваше слияние в "TestServer" является односторонним слиянием-ничего не выходит, никакой истории. Вместо этого ваша ветвь Feature 2 объединяется в "Development" и, в конечном счете, "master".

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

Окружающая среда

  • QA: для разработчиков, чтобы убедиться, что их функция тестируема.
  • этап: для менеджеров проектов / тест-менеджеров, чтобы курить-тест до тестирования UAT различными "владельцами бизнеса"
  • UAT: для полного тестирования и регистрации бизнеса "владельцами бизнеса"
  • бета-версия: просто тест развертывания / выпуска
  • жить: ..

Эти среды сгруппированы в две категории: "in-test" (QA, Stage и UAT) и "production" (BETA и LIVE).

Ветви

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

  • Master: представляет собой последнее производство выпуск
  • релиз-кандидат: набор функций для следующего выпуска производство выпуск
  • UAT: представляет среду UAT
  • стадия: представляет "QA" и "стадию"
  • Feature-xxx: для разработки функций

Мы также используем ветвь исправлений от Master по мере необходимости и подготавливаем производственные релизы в ветви "Pre-Production" (исправление пропущенных приращений версий и т. д. - незначительные вещи).

Диаграмма используемых нами ветвей: Схема наших филиалов в использовании:

Ветвление и слияние / рабочий процесс

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

  2. Как только функция готова к тестированию, она объединяется (односторонне) в "стадию". Это запускает сборку CI и развертывается в QA.

  3. Если сервер контроля качества выглядит стабильным, разработчик запускает автоматическое развертывание на этапе.

  4. Если требуются изменения, то сделайте их в особенности и повторяют. Если хорошо для бизнес-тестирования, после слияния с особенностью на ЕСХН. Это развертывается в UAT.

  5. Если функция не прошла бизнес-тестирование, внесите изменения в функцию и повторите. Если функция задерживается, то не предпринимайте никаких действий. Если функция в порядке и отключена, то выполните слияние для выпуска кандидата.

  6. Как только набор (1 или более) функций находится в релиз-кандидате, запускайте производственное развертывание путем слияния из релиза-кандидата в мастер (через Пре-Производство).

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

Наш рабочий процесс, использующий TFS, выглядит следующим образом:

Наш рабочий процесс, использующий TFS, выглядит следующим образом:

Рабочий процесс выпуска

И, наконец, каждое развертывание в среде / категории будет выглядеть следующим образом:

Поток развертывания

9

Git-это система управления версиями. Он поддерживает исходный код и их изменения. Развитие останавливается на стадии развития. После этого исходный код не должен меняться.

При переходе проекта на следующий этап (тест, релиз, prod) вы не должны предоставлять исходный код, а двоичные файлы, построенные из помеченной версии, потому что:

  • исходный код не изменяется в различных средах,
  • две сборки могут содержать два разных двоичных файла (изменить на зависимости)
  • поддержание различных версий будет затруднено. Например,
    • исправление ошибок. Представьте себе, когда новый релиз на тестовом сервере, и вам нужно сделать исправление из производства. Это исправление должно пройти через тот же поток (test, release, prod). Поэтому вам нужно перезаписать тестовую ветку с исправлением ошибки и после слияния вернуться к новой версии релиза. Что не очевидно, не обязательно и может привести к тому, что изначально предполагалось иметь другой код. На самом деле, с каждым слиянием, после разработки, возникает ненужный риск, что исходный код может отличаться от того, что предполагалось. И вы, возможно, потребуется, чтобы решить конфликт слияния в прод.
    • A/B тестирование

Таким образом, это может не мешать модели git-потока, но я думаю, что эти моменты заслуживают рассмотрения. На самом деле, я не большой поклонник стратегии gitflow. Если у вас есть минутка, дайте шанс на эту статью, она описывает почему:

Https://barro.github.io/2016/02/a-succesful-git-branching-model-considered-harmful/

0