Ветвление в TFS для ежегодного расписания?

Question

Вопрос: Какова наилучшая практика для создания филиалов для разработки и выпуска на основе информации, представленной ниже?

фон: Я работаю в небольшой команде разработчиков (2,25 фронтэнда, 2 бэкэнда), и у нас есть годовой график выпуска. Наша среда делает не разрешает патчи или пакеты услуг в середине года, но каждый раз, когда изменяется наша пользовательская среда, мы выпустим «перекомпилированную» версию с несколькими исправлениями ошибок, которые были добавлены (в текущей стабильной версии).

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

Способ, которым TFS выполняет свои ветви, имея новую «папку» в элементе управления источником, и он начинает немного засоряться.

Мысли: Может быть так, как мы делаем это правильно, но это просто чувствует, как в течение нескольких лет будет большое количество ветвей, которые никогда не собираются трогать ... казалось бы, когда-либо. Возможно, можно создать единственную строку «Stable Release», в которой есть каждая новая версия, помеченная на ней, а затем, если нам нужно вернуться к выпуску в середине года, тогда ее можно восстановить из этой единственной строки.

Answer 1

• Обновите свою среду до 2010 года ASAP - ветвление TFS 2010 значительно превосходит, включая управление.

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

• Вам просто нужно жить с версиями, накапливающимися. Это имеет смысл - пока вы полностью не уйдете на пенсию (и «никогда» здесь не реально, я уверен, что через 7-8 лет вы убьете старую версию), просто нет другого пути.

Answer 2

несколько мест, я работал бы справиться с этим, как это:

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

Преимущество в том, что у вас только 2 филиала. Это облегчает работу с некоторыми задачами, связанными с SCM, поскольку вам не нужно иметь дело с изменениями имен папок и т. Д.