Каков хороший рабочий процесс для филиалов «вишня» для развертывания?

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

У нас также есть «промежуточная» ветвь, которая указывает текущее состояние промежуточного сервера.

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

Я уверен, что есть лучший способ сделать это, но я не уверен, куда идти:

  1. когда разработчик завершает элемент и готов к постановке, поместите его в папку тегов, например / tags / readyforstaging /? Затем переместите содержимое после каждого развертывания в нечто вроде / tags / archive /? (но будет ли это беспорядок с историей пересмотра?)
  2. Такая же идея, как и # 1, но создайте новую корневую папку, чтобы избежать путаницы со статическим характером тегов, например / ready / staging / and / ready / archive /?

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

Кто-нибудь знает хороший способ сделать это, чтобы у нас был однозначный список всего, что было готово, но не наносит ущерба истории изменений / графикам?

Solutions Collecting From Web of "Каков хороший рабочий процесс для филиалов «вишня» для развертывания?"

Это в любом случае не «хороший способ», но, по крайней мере, он работает в реальных проектах

В случае строгой политики «Филиал за задание» вы можете использовать игру «Нестабильная магистраль»:

  • Магистраль имеет только слияния из ветвей задач (автор должен объединить готовые собственные ветви в магистраль, интеграционные тесты должны выполняться после каждого слияния, исправления для ответвления в вопросе применяются и повторные слияния выполняются, если необходимо )
  • Для чистой, хорошо читаемой истории соединительной линии ни одно из обратных объединений не должно быть добавлено в магистраль (когда тест интеграции не удался, до исправления), «Ready4Staging» может быть дополнительным специальным URL-адресом в репо и должен быть единственным авторитетным источником для слияния с Staging филиал