Встроенные стробированные строчки на основе XAML с одинаковым определением не могут выполняться параллельно. Я считаю, что это преднамеренное ограничение. Цель стробированной сборки состоит в том, чтобы предотвратить «сломанный» код из когда-либо совершенного в репозиторий.
Когда вы ставите в очередь стробированную сборку, она использует последнюю версию кода в репозитории, а также полку, содержащую изменения, которые вы только что совершили. Если сборка преуспевает, то shelveset фиксируется и становится последней версией кода. Если сборка выходит из строя, то shelveset не привязан к репо.
Если вторая стробированная сборка была поставлена в очередь и запущена одновременно, то она не может знать, будет ли первая сборка успешной или неудачной, и, следовательно, какая версия будет построена (если она использует последнюю версию или полки, которые в настоящее время подтверждено). Если первая сборка завершится неудачей, вторая сборка будет в порядке. но если первая сборка выполнена успешно, вторая сборка не компилируется против правильной версии кода. Хуже того, второй полк может содержать изменения, которые несовместимы с первым полками, оставляя вас с возможностью конфликтов слияния или сломанного кода, если вторая сборка завершается успешно. Это побеждает цель стробированной сборки.
Закрытые проверки приходят, чтобы скоро построить vNext, но я ожидаю, что они будут иметь одинаковые ограничения.
Gated builds vs "CI" builds.
Gated: как описано, стробированные сборки не могут работать параллельно. Они должны использоваться, когда правильность важнее скорости.
CI: CI-сборка в TFS - более традиционная сработавшая сборка. Когда разработчик проверяет это изменение, он привязан к репо и запускается сборка. На этом этапе код может быть взломан (не скомпилирован, что приводит к сбоям в модульных тестах и т. Д.). CI-сборки могут работать параллельно, но увеличивают риск того, что сломанный код превратится в репо, а одна ошибка разработчиков может повлиять на остальной состав команды.
Мысли: В зависимости от вашей стратегии ветвления вы можете использовать смесь типов сборки. Например, CI основывается на ветвях dev, которые имеют большой оборот изменений, но если сборка разбита на несколько минут в день, то это еще не конец света. На них воздействует только команда разработчиков, и они могут быстро устранить любые проблемы. Используйте Gated-сборки для филиалов с меньшим оборотом. Например, ваша основная или релизная ветвь, которая может быть обновлена только в конце спринта.
Мнение: Ворот строят звук, как хорошая идея, в принципе, они предотвращают сломанный код от осквернения вашего управления источником репо.Это хорошая вещь. Однако для меня важна быстрая обратная связь. IMHO Gated builds - это скорее прокладка для предотвращения «невнимательных» разработчиков, которые не проверяют свой код, компилируются или проходят тесты перед фиксацией. Конечно, мы все можем ошибаться, но существуют оба типа сборок, чтобы сказать нам об этом и дать нам возможность исправить ошибку.
По сути, я думаю, я говорю это.
CI: Могу ли я доверять коду?
Gated: Могу ли я доверять разработчикам?
Если у вас есть политика «без сломанного кода когда-либо», тогда вам придется жить с ограничениями стробированной сборки. Если вы можете быть немного более гибкими, и вы доверяете остальной части своей команды, чтобы не делать ничего глупого/невнимательного, тогда вы можете использовать сборки CI и получать преимущества параллельных сборок.
Только для вашей информации стробированные сборки vNext входят в обновление 2: https://www.visualstudio.com/en-us/news/release-archive-vso.aspx – Rodders