Subversion, непрерывная интеграция и Scrum

Question

Как мы устанавливаем политику Subversion, чтобы мы могли легко «отбросить» целую историю изменений, сохраняя непрерывную интеграцию?

---

В моем месте бизнеса, мы получаем Scrum туда, где мы не имели процесса/«ковбой кодирования» раньше. Это очень весело (определение крепости гномов), но не в центре внимания этого вопроса.

В Scrum у нас есть возможность, чтобы владелец продукта имел право произносить «нет» на завершение истории или, возможно, работать не «делал» историю во время спринта. Идея состоит в том, что если что-то не «сделано», оно не развертывается. Внутри есть разногласия: некоторые люди говорят, что мы должны развернуть половину готового материала, «связанного», чтобы его нельзя было использовать, но я категорически не согласен (это совсем другая тема).

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

Если мы постоянно совершаем какие-либо ветви, называем это ветвью спринта, что происходит, когда мы (редко!) Добираемся до конца спринта и имеем историю, которая не может быть развернута? Мне нужно «размотать» любые изменения, которые поддерживали эту историю из ветви развертывания. Существует ли стратегия ветвящейся политики/фиксации, которая делает это относительно выполнимым, без крупномасштабного ручного взаимодействия? Должен ли я даже беспокоиться об этом?

Похожие: Subversion with Continuous Integration

Answer 1

Я не думаю, что есть какое-либо простое решение. После того, как вы «разблокируете/отмените» свои изменения, что может быть сложно, вам придется перепроверить все. Лучшая стратегия, если вы окажетесь в случае, когда у вас есть ветка, которая не может перейти на производство, - это развернуть старую сборку, которая готова. Затем новая ветка может быть развернута, когда она будет готова.