Нужны советы или указатели по стратегиям управления релизами

Question

Я присматриваю за внутренней веб-системой (Java, JSP, Mediasurface и т. Д.), Которая постоянно используется (24/5).

Пользователи собирают заявки на улучшения, исправления ошибок и другие бизнес-изменения. Эти проблемы подписываются индивидуально и передаются одному из трех или четырех разработчиков.

Как только проблема завершена, она создается и код передается только в SVN. Измененные файлы (шаблоны, html, классы, jsp) затем копируются на сервер разработчика и фиксируются в другом хранилище, из которого они извлекаются на сервер UAT для тестирования. (для этого часто требуется перезапуск службы Tomcat, а иногда и службы Mediasurface).

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

В случае отклонения разработчик вносит соответствующие изменения и снова запускает процесс выпуска.

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

Я бы хотел перенести это на более контролируемый и автоматизированный процесс, где весь исходный код и выходные файлы хранятся в SVN и выпускаются в Dev, UAT и Live, управляемые системой CI (у нас есть TeamCity для нашей .NET приложения).

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

Есть ли способ управлять этим с помощью SVN и CI, или мне просто придется жить с текущей системой.

Answer 1

Мне кажется, что откат изменений, которые помещены в ветку Release , кажется мне нормальной практикой в ​​вашем случае, что, я думаю, может быть неуместным.

Одна вещь, которую я нахожу немного удивительной, заключается в том, что зачем пользователям тестировать изменения, а затем либо отклонять, либо утверждать релиз? ИМХО тестирование изменений и проверка того, что это исправляет проблемы, поднятые пользователями, должно быть задачей группы тестирования. Пользователи не тестеры. Если есть группа тестирования, у вас может быть ветвь Testing (скажем), куда вносятся исправления / изменения, и группа тестирования использует эту ветку для тестирования и квалификации изменений. Как только изменения будут проверены группой тестирования, вы можете отправить изменения в Release Branch (скажем) и выполнить развертывание оттуда. Даже при таком подходе у пользователей могут возникнуть проблемы с внесенными изменениями, но при проведении внутреннего тестирования группой тестирования необходимость отката станет скорее исключением, чем нормой.

Answer 2

Мы решили использовать многопотоковый подход. По сути, каждый разработчик работает над новой веткой для каждого изменения, и когда изменения готовы, они объединяются в поток Dev, за этим наблюдает TeamCity и приложение, созданное и отправленное на сервер Dev для тестирования интеграции.

Если это проходит, то изменения объединяются из исходной ветви в поток UAT. Опять же, это передается TC на сервер UAT.

После того, как изменение подписано, оно снова объединяется с исходной веткой в ​​прямой поток, и TC передает его на текущий сервер.

Следует отметить, что соответствующий поток должен быть объединен с веткой перед каждым выпуском, чтобы позволить тестирование разработчиком.

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

Большое спасибо за все комментарии и предложения выше.

Answer 3

Я думаю о ветвлении функций, а не о том, что я бы попытался использовать Subversion.

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

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

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

Поиск и устранение проблемы не всегда означает, что она должна быть развернута немедленно. Иногда вы можете договориться с вашим клиентом; «Это нормально, если мы выпустим это исправление вместе с нашим следующим регулярным выпуском?».

Вся бухгалтерия и администрирование шансов, оперативных исправлений и внеплановых выпусков становятся слишком сложными очень быстро, я бы избегал этого как можно больше. Если у вас есть 4 исправления, а 1 еще не в порядке, а остальные 3 могут подождать ... иди по этому маршруту.