DAX 2012 R2 and TFS builds

[Dozer]

Добрый день.
Неделю назад закончили настраивать систему серверов вида Dev -> TFS -> Build -> Test -> UAT -> Prod.
Написали автоматизированый скрипт для создания билдов, тра-ла-ла, все дела, тесты вроде проходят без проблем.
Теперь вот возник теоритический вопрос, с которым раньше не приходилось сталкиваться, но ситуация случиться может.

К примеру у нас есть три независимые задачи з1, з2 и з3. Все были выполнены на девелоперском уровне и закомитчены в TFS. Далее по процессу запускается билд и все три изменения попадают скажем в билд номер 8. Далее тестеры измываются над системой и дают вердикт - з1 и з3 проходят, а з2 провалилась по ключевым требованиям. Времени на починку з2 и проведения нового цикла нет, решено что з1 и з3 должны пройти в Продакшен.
И вот внимание вопрос - как сгенерировать новый билд в котором не будут включены изменения по з2? Скрипт сейчас работает довольно прямолинейно, просто берёт последние версии всего что находится в проекте.
К сожалению это моё первое знакомство с TFS и я не вполне владею инструментом.

[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]

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

[hardcore]

Цитата:

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

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

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

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

[Dozer]

Вот с ветками я пока что не разбирался. Можете посоветовать документ где бы по шагам было расписано как работать с ветками проекта в аксапте?

[hardcore]

К сожалению, я такого документа не встречал. Мы их тоже не используем по причинам не надобности, у нас другой процесс (более простой). О ветках имею мнение так как мы используем их в разработки на .NET.
Думаю надо почитать документацию на msdn о ветках в TFS её очень легко найти.
Для использования веток в АХ: в настройках системы контроля версий есть поле где можно указать ветку. После указания конкретной ветки надо синхронизироваться с TFS (ваш код должен удалиться и залиться новый код из ветки), основная загвостка в том, что заливка больших объемов кода через синхронизацию TFS не желательна (это указано в том документе) и выполеняется не быстро (пока все хпо заимпортяться пока все синхронизируется с бд) это минусы. Тоесть делать так очень часто наверное будет накладно.