AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Администрирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 15.08.2023, 22:17   #1  
virtuoso is offline
virtuoso
Участник
 
40 / 15 (1) ++
Регистрация: 06.06.2007
Перенос между ветками ms tfs с нарушением порядка следования
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:

X++:
class A
{
void methodA();
}
changeset_2:
X++:
class A
{
void methodA();
void methodB(); 
}
Шаг 1 (methodA на данный момент неготов):
PROD

changeset_2 + руками ставим в комментарий неготовый код:
X++:
class A
{
//void methodA();
void methodB(); 
}
Шаг 2:
PROD

changeset_1 + changeset_2(повторно):
X++:
class A
{
void methodA();
void methodB(); 
 }

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

Последний раз редактировалось virtuoso; 15.08.2023 в 22:22.
Старый 16.08.2023, 06:51   #2  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,303 / 3533 (124) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Странный вопрос.
Никакого нарушения порядка следования changeset-ов tfs не допустит и никаких ошибок со стороны tfs тут не появится.
Другое дело, что в указанном примере methodB() в ветке PROD появится раньше, чем methodA(), что может привести к ошибкам компиляции, если methodB() прямо или опосредованно вызывает methodA(). Но это тогда уже вопрос к разработчику или сборщику - как так получилось, что переносится модификация, зависящая от той модификации, которая еще не перенесена.
А дальше события могут развиваться по таким сценариям:
1. Да, действительно зависимость между модификациями есть. Откатываем переносимую модификацию и ждем доработки первой модификации (с methodA())
2. Зависимости нет - это ошибка разработчика - он убирает ссылку на methodA() и появляется другой changeSet с исправленным methodB() - в этом случае methodA() переносится, но он остается лежать "мёртвым грузом", т.к. ссылок на него нет

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

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

Мы в разработке применяли такой принцип - сначала кодим функционал и только на последнем этапе вставляем ссылки на его использование. Более того - в ветку DEV не переносим неготовые модификации и тщательно следим за зависимостью модификаций друг от друга. Ну и конечно чем чаще релиз - тем проще следить за версией кода.
Т.е. легко можно на рабочую базу перенести недоделанную модификацию, которая нигде не вызывается и никому не мешает.
__________________
Возможно сделать все. Вопрос времени
За это сообщение автора поблагодарили: virtuoso (1).
Старый 16.08.2023, 09:49   #3  
virtuoso is offline
virtuoso
Участник
 
40 / 15 (1) ++
Регистрация: 06.06.2007
Спасибо за развёрнутый ответ.

Цитата:
Никакого нарушения порядка следования 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.

Последний раз редактировалось virtuoso; 16.08.2023 в 10:00.
Старый 16.08.2023, 11:13   #4  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,303 / 3533 (124) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от virtuoso Посмотреть сообщение
Исправление руками делаем в PROD.
В ближайший перенос может быть changeset_1 или changeset_3: changeset_1 затрёт последние изменения, но это опять же правится руками на PROD (или повторной установкой changeset_2) после чего восстанавливается status quo. А в случае changeset_3 выполняем всё то же самое, что c changeset_2, и так вплоть до установки пропущенного changeset_1.
Разумеется, это ложится дополнительной нагрузкой на администратора, но данный случай полагается пока исключительным.
Ну собственно говоря - также выходили из ситуации. С дополнительной нагрузкой на администратора.
Понятно, что в идеальном случае либо получаются задержки, либо команда должна быть маленькой. Неудобство безусловно было - старались максимально разделять задачи, чтобы было минимум пересечений + некие ежедневные небольшие совещания по задачам с озвучиванием ситуации, чтобы минимизировать нагрузку на администратора и переложить обязанность по комментированию на автора разработчика. Но без работы администратор все равно не оставался ))
__________________
Возможно сделать все. Вопрос времени
За это сообщение автора поблагодарили: virtuoso (1).
Старый 16.08.2023, 17:46   #5  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,039 / 1630 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Переносить можно. Проблемы будут, я даже писал статью какие. https://denistrunin.com/d365fo-tfs

их можно минимизировать путем разделения модификаций как писал sukhanchik выше , такой способ переноса называется cherry-picking. Почему это плохо, можно почитать к примеру здесь - https://stackoverflow.com/questions/...stent-workflow
За это сообщение автора поблагодарили: Logger (3), virtuoso (1).
Теги
d365fo, tfs

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
i-neti: Перенос кастомизации между слоями в Dynamics AX 2012 Blog bot DAX Blogs 1 10.08.2017 12:53
The Death of Reason: #wpc13 US Dynamics: Where is MS Going in 2014? Blog bot DAX Blogs 2 12.07.2013 13:19
перенос данных между методами класса exodus DAX: Программирование 7 01.11.2007 05:07
Перенос элементов бизнес-логики между слоями Maxim Gorbunov DAX: База знаний и проекты 0 11.12.2001 20:07

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 02:12.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.