DAX 2012 R2 and TFS builds

[hardcore]

Мы к сожалению до билдов еще не дошли, но TFS используем как вершен контрол. Может вы уже в курсе, если нет, то есть такой документ "Change management and TFS integration for multi developer projects_AX2012.docx" он доступен на кастомер и партнер соурсе,
там есть такая инфа:
Administrator: Apply a label to the latest version of your files
As a prerequisite to enabling the creation of Microsoft Dynamics AX builds, the administrator, on a periodic (daily) basis, should apply a label to the latest version of the project files in the TFS central repository. The label is used as the identifier of the daily/periodic build (example label: v1.0.1). The administrator should incrementally change the label every time a new label is applied. The label value should be based on the project milestones.
In TFS, let you take a snapshot of your files, so that you can refer back to that snapshot later. By using your label, you can view, build, or even roll back a large set of files to the state they were in when you applied the label.
For information about how to apply labels, see the MSDN (http://msdn.microsoft.com/en-us/library/ms181439)

Может это поможет, я так понимаю есть возможность пометить отдельно файлы которые связаны с задачами з1 и з3.
Хотя это не дает ответ на вопрос что делать если часть кода из з1 и з2 у вас в одном классе (файло то один тогда будет). Другой вариант это использование веток в TFS (создаете ветку удаляйте от туда задачу з2 и вперед в билд), правда потом может возникнуть задача с мерджингом веток (если найдете баг уже когда код будет в проде, то его надо править в векте и сливать с основным кодом). Плохо то, что переключение между ветками ведет к переимпорту всех кастомизаций в АХ (удаляется весь кастомный код и заливается из ветки)

[Dozer]

Да, я читал этот документ.
Лейблы вроде как решение, но тут возникает вопрос - кто и как эти лейблы будет делать.
С одной стороны делать их должен билд администратор, который в нашем случае не девелопер. Представим что з2 это комплексное решение затрагивающее пол сотни различных объектов в АОТе. Каким образом билд администратор будет определять что включить а что исключить в лейбл?
Коммит кода происходит через встроенный клиент в аксапте, и при этом есть возможность привязать коммит к определённому заданию в проекте TFS, и таким образом администратор может увидеть последний чендж сет через TFS viewer, но вот поможет ли это?..

[hardcore]

Цитата:

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

Коммит кода происходит через встроенный клиент в аксапте, и при этом есть возможность привязать коммит к определённому заданию в проекте TFS, и таким образом администратор может увидеть последний чендж сет через TFS viewer, но вот поможет ли это?..

Если задача комплексная пол сотни классов то администратор не справиться.

Вообще так как код еще не прошел тестирование, то мне кажется, что взаимодействовать должны тестировщик и разработчик (администратор может что-то делать только с помощью разработчика, т.к. это манипуляция с кодом).