Какой конвейер CD предотвратит задержку релиза плохим коммитом? - PullRequest
Новая
       22

Какой конвейер CD предотвратит задержку релиза плохим коммитом?

0 голосов
/ 31 мая 2018

У нас есть система управления исходным кодом в стиле Gitflow / trunk в Git, где выпуски проходят следующий процесс:

  1. Разветвление ветки разработчика master
  2. Запрос разработки от разработчиков вmaster
  3. После объединения PR сборка происходит со средой "QA"
  4. Код командных тестов QA
  5. Мы делаем релиз с master (от разработчиков PR до master, мы проводим некоторое тестирование, а затем делаем релиз).

Теперь у данной «сборки» для QA может быть несколько кусков работы.Проблема в том, что если проблема обнаружена на шаге 4) выше, у нас есть только следующие варианты:

  1. Исправить код (медленно)
  2. Перейти к работе с проблемой (риск)

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

Как мы можем это исправить?

Этомои идеи, с точки зрения моих предпочтений:

  1. Использовать конвейер 'release', например: enter image description here Означает, что каждый коммит проходит набор этапов.Если «новая» работа не проходит стадию, она не продвигается.Другими словами, мы можем освободиться от «последней известной хорошей сборки».Для этого можно использовать что-то вроде Octopus Deploy.
  2. Использовать ветки 'release' в Git.После того, как что-то протестировано, мы перемещаем его в ветку 'release'.
  3. Cherry-pick good commits в Git.Вид похож на 2.

Есть предложения?Каковы лучшие методы решения этой проблемы?

1 Ответ

0 голосов
/ 31 мая 2018

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

Это то, что я описываю в « Обработка ветвления git для тестированияи производство"

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

(Gitworkflow более подробно описан в rocketraman/gitworkflow)

В вашем случае вы должны сначала использовать эфемерную ветвь QA / интеграции, запустить тест и обновить master, если эти тесты пройдены (и вызватьвыпуск в производство)

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

...