Перенос кастомизаций между средами

[ZooY]

Коллеги, поделитесь опытом, кто как организовал процесс переноса кастомизаций (форм, представлений, кнопок) между средами.
Собсвтенно в чем проблема...
Есть среды: DEV, TEST, PROD.
На DEV-среде добавили две кнопки, вынести в TEST на тестирование. Но в PROD, по каким-то причинам, одну кнопку нужно выносить, а вторую нет.
С формами такая же проблема - в рамках одного бизнес-процесса нужны одни поля,в рамках другого - другие, но однy процесс выносим, а другой нет...
Кто ка решает такие проблемы?

[scr1pt]

Административно решаем.
"На прод можем установить после того как будет протестирована доработка ХХХ".
Пока проблем не было, более того, если тестирование на стороне заказчика - дополнительная мотивация поскорее завершить тестирование)

[a33ik]

Непростой вопрос и решение нетривиальное. Лично я такого не делал, но вот как поступил бы я:
Риббон для одной сущности - монолит, как и форма. Чтобы вычленить только определенные куски кастомизации для перенеса в другую среду потребуется выгрузить кастомизации, распаковать, открыть customizations.xml и вырезать из него все части, которые не должны переноситься, сохранил файл, запаковал обратно и импортировал это измененное решение.

[avm]

У нас это встречается часто. Решаем эту проблему развернутой еще средой PREPROD. Переносим с теста протестированный функционал в PREPROD, на PROD уже переносим с PREPROD.
p.s. AX 2009

[БАХ43]

С точки зрения Ax2009. А чем в проде помешает излишний функционал? Переносите все, а лишнее (кнопки-формы) отключите конфигурационными ключами или правами пользователей.

[Артем Enot Грунин]

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

[ZooY]

Цитата:

Сообщение от Артем Enot Грунин

Или целиком, или никак.

Оно конечно да, если это закаазная доработка. Но у меня внутренний заказчик и есть объективные причины (готовность со стороны смежных команд, внешних партнеров, бизнеса или законодельства), по которым часть функциональности выноситься, а другая нет

[Артем Enot Грунин]

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

Если хотите опыт, то он есть. Делается отдельное (говно)решение под релиз или фичу (даже не типа "патч") куда мы забираем компоненты, которые (как мы надеемся) в сумме дают нам переносимую функциональность. В случае с кнопками и другим заметным глазу функционалом, соседняя команда использовала фича-флаги, но мы просто отключали, или скрывали то что не готово, но придется переносить. Например, делали всегда ложное правило видимости для кнопки.

Далее эти "полу-патчи" как-то протоколировались в ворде, чтобы потом не забыть что и как мы переносили. В последствии, когда случался "совсем релиз", мы брали эти файлики ворд и на основе устаревших воспоминаний собирали (уже на тестовой площадке) новое решение для говно-релиза и несли его на прод. Тут нужно отметить, что у нас еще были сторонние сайты, веб-сервисы, службы и т.д. Их тоже нужно было переносить.

Заканчивается такая практика всегда одинаково: ваше решение больше неуправляемо. В какой-то момент, не существует версии вашего решения CRM, которую можно развернуть на чистую базу. Создание новой среды осуществляется копированием прода. Тестовая среда теперь в большей степени соответствует среде разработки, так как там финализируются те фичи, которые выбрал для переноса клиент. Да-да, все верно: ваш дев уже не консистентен и ушел далеко вперед! Он больше не годится для баг фиксинга.

В общем, очень быстро наступает жопа. Если не получается избежать этого ссаного фиче селекшена - делайте фича-флаги, переносите весь релиз и отключайте незавершенные фичи. В любом случае, это порочная практика гнать впереди паровоза и других команд. Если столь нужно работать на перспективу - уходите в CI и ведите две ветки: поддержка текущей и next.