Перенос между ветками ms tfs с нарушением порядка следования

[virtuoso]

D365FO

Здравствуйте.

Прошу поделиться опытом переноса программных компонент между ветками ms tfs с нарушением порядка следования changeset'ов:

1. можно ли после временного нарушения порядка установки changeset'ов вернуться к строгому следованию такому порядку?
1.1 будет ли tfs воспринимать эту ситуацию как аварийную?

2. можно ли после "неправильной" установки отметить некоторые changeset'ы к повторной установке (чтобы не забыть, что их придётся установить заново по готовности пропущенных)?
2.1 можно не устанавливать changeset'ы повторно, а ограничиться исправлением вручную (после установки пропущенных)?

Для разработки и установки модификаций на рабочее приложение используются две ветки ms tfs: DEV, PROD. Интересует случай, когда устанавливаем changeset'ы не в порядке их следования: 1,2, а с нарушением: 2,1. См. рис. ниже.

DEV
changeset_1:

class A
{
void methodA();
}

changeset_2:

class A
{
void methodA();
void methodB(); 
}

Шаг 1 (methodA на данный момент неготов):
PROD

changeset_2 + руками ставим в комментарий неготовый код:

class A
{
//void methodA();
void methodB(); 
}

Шаг 2:
PROD

changeset_1 + changeset_2(повторно):

class A
{
void methodA();
void methodB(); 
 }

Заранее благодарю.

[sukhanchik]

Странный вопрос.
Никакого нарушения порядка следования changeset-ов tfs не допустит и никаких ошибок со стороны tfs тут не появится.
Другое дело, что в указанном примере methodB() в ветке PROD появится раньше, чем methodA(), что может привести к ошибкам компиляции, если methodB() прямо или опосредованно вызывает methodA(). Но это тогда уже вопрос к разработчику или сборщику - как так получилось, что переносится модификация, зависящая от той модификации, которая еще не перенесена.
А дальше события могут развиваться по таким сценариям:
1. Да, действительно зависимость между модификациями есть. Откатываем переносимую модификацию и ждем доработки первой модификации (с methodA())
2. Зависимости нет - это ошибка разработчика - он убирает ссылку на methodA() и появляется другой changeSet с исправленным methodB() - в этом случае methodA() переносится, но он остается лежать "мёртвым грузом", т.к. ссылок на него нет

Вручную можно исправить - вопрос в какой ветке? Если в DEV - то это изменение отразится сразу у всех разработчиков. Если в PROD - то это исправление будет "жить" до ближайшего переноса какого-нибудь changeset-а с этим кодом и проблема встанет снова.

Для TFS совершенно без разницы - как Вы наполняете ветку PROD - это уже Ваши личные заботы. Последовательность changeset-тов никогда не нарушится - будет только возрастать.

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

[virtuoso]

Спасибо за развёрнутый ответ.

Цитата:

Никакого нарушения порядка следования changeset-ов tfs не допустит..

я понимаю под нарушением порядка именно порядок changeset'ов, который установился на DEV и установку на PROD в обратном порядке.

Цитата:

...как так получилось, что переносится модификация, зависящая от той модификации, которая еще не перенесена.

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

Цитата:

1. Да, действительно зависимость между модификациями есть. Откатываем переносимую модификацию и ждем доработки первой модификации (с methodA())

в примере подразумевается, что между changeset_1 и changeset_2 нет логической связи, т.е. changeset_2 можно простыми комментариями "отвязать" от changeset_1, и результат от этого не пострадает.

Цитата:

Вручную можно исправить - вопрос в какой ветке?

Исправление руками делаем в PROD.

Цитата:

Если в PROD - то это исправление будет "жить" до ближайшего переноса какого-нибудь changeset-а с этим кодом и проблема встанет снова.

В ближайший перенос может быть changeset_1 или changeset_3: changeset_1 затрёт последние изменения, но это опять же правится руками на PROD (или повторной установкой changeset_2) после чего восстанавливается status quo. А в случае changeset_3 выполняем всё то же самое, что c changeset_2, и так вплоть до установки пропущенного changeset_1.
Разумеется, это ложится дополнительной нагрузкой на администратора, но данный случай полагается пока исключительным.

Вопрос достаточно актуальный, потому что в разнородных командах очевидно не получается

Цитата:

тщательно следить за зависимостью модификаций друг от друга

, что приводит только к простоям changeset_2 (в ветке DEV) в ожидании готовности changeset_1. Т.е. установка одного из проектов (к нему относится changeset_2) просто искусственно задерживается до готовности всех модификаций в прорядке check-in'ов на DEV.

[sukhanchik]

Цитата:

Сообщение от virtuoso

Исправление руками делаем в PROD.
В ближайший перенос может быть changeset_1 или changeset_3: changeset_1 затрёт последние изменения, но это опять же правится руками на PROD (или повторной установкой changeset_2) после чего восстанавливается status quo. А в случае changeset_3 выполняем всё то же самое, что c changeset_2, и так вплоть до установки пропущенного changeset_1.
Разумеется, это ложится дополнительной нагрузкой на администратора, но данный случай полагается пока исключительным.

Ну собственно говоря - также выходили из ситуации. С дополнительной нагрузкой на администратора.
Понятно, что в идеальном случае либо получаются задержки, либо команда должна быть маленькой. Неудобство безусловно было - старались максимально разделять задачи, чтобы было минимум пересечений + некие ежедневные небольшие совещания по задачам с озвучиванием ситуации, чтобы минимизировать нагрузку на администратора и переложить обязанность по комментированию на автора разработчика. Но без работы администратор все равно не оставался ))

[trud]

Переносить можно. Проблемы будут, я даже писал статью какие. https://denistrunin.com/d365fo-tfs

их можно минимизировать путем разделения модификаций как писал sukhanchik выше , такой способ переноса называется cherry-picking. Почему это плохо, можно почитать к примеру здесь - https://stackoverflow.com/questions/...stent-workflow