Реализация сборки одного скрипта - непереносимые зависимости

Question

Похоже, что наилучшей практикой для системы сборки является наличие единого сценария, который может собрать весь исходный код и упаковать релизы.См. Joel Test # 2

Как вы учитываете непереносимые зависимости?Например, если вы кодируете для .net 4, то вам нужно установить .net 4 на коробке.Стандартный MS выпуск .net 4 не может быть развернут xcopy (разве я не ошибаюсь?).Я вижу несколько путей:

1. зависимости четко указаны в некотором файле ресурсов (вики, txt, что угодно).Когда вы вызываете скрипт сборки, сборка завершится неудачно, если у вас не установлена ​​зависимость.Это приемлемый результат.
2. Сценарий сборки отвечает за настройку среды.Поэтому, если вам требуется .net 4, а его нет в коробке, он установит его для вас.
3. Вариант # 2 - вместо установки зависимостей скрипт создает предварительно упакованный образ (виртуальная машина, AmazonEC2 AMI), который настроен со всеми зависимостями
4. ???

Answer 1

Для реализации сценария сборки вы должны спросить себя, сколько работы вы хотите / можете потратить на это.Это приводит к вопросу о том, как часто вам приходится настраивать среду сборки.Я вижу, что # 2 было бы идеальным решением, но мне потребовалось бы много работы, так как обычно у вас более одной непереносимой зависимости.

Поэтому мы используем # 1 одну.И это работает довольно хорошо.Самое главное, что скрипт сборки начинается с какого-то самотестирования.Он ищет все, что необходимо для сборки всего программного обеспечения, и выдает ошибку, если что-то не найдено.И это дает четкое сообщение об ошибке, так что любой новый парень знает, что нужно сделать, чтобы запустить его.Конечно, как и в случае с большим количеством программного обеспечения, оно почти никогда не заканчивается и расширяется по мере необходимости.Недостаток в том, что этот тест может занять несколько секунд, незначителен, когда весь процесс сборки требует больше минуты.

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

Сам скрипт сборки представляет собой набор из множества разных вещей, которые выбираются по необходимости.Он начинается с пакета (мы используем Windows), который вызывает много других вещей.Другие партии, MSBuild, домашние инструменты.Каждый шаг сам по себе проверяет свои собственные зависимости, чтобы проблема была локальной, и через три строки вы можете увидеть, зачем нужна эта особая вещь.

Answer 2

Номер 2 гласит: «Можете ли вы сделать сборку за один шаг?»Как описано, это означает, что для эффективности команды разработчиков процесс сборки должен быть максимально простым, чтобы уменьшить количество ошибок в процессе сборки и обеспечить согласованность.Это особенно важно, поскольку команда становится больше.Вы хотите убедиться, что все строят одно и то же.(То, что сделано с этим пакетом, также должно быть простым, но это не так важно, ИМХО.) Msbuild хорош в этом;они предоставляют средства для настройки сервера сборки, который получает независимый доступ к системе управления исходным кодом, поэтому действия разработчиков не могут повредить среду сборки.Я настоятельно рекомендую настроить сервер сборки с использованием TFS - многие проблемы со сборкой исчезнут, и вы получите сборку в один клик, как описывает Джоэл.

Что касается ваших замечаний о том, что этот пакет делает для развертывания - у вас есть много вариантов с MS, но чем больше «одним кликом», тем лучше.Я считаю, что это немного отличается от №2 Джоэла.В своем примере он описывает изменение того, какое программное обеспечение он будет использовать для установки, не потому, что выполняется меньше шагов, а потому, что его можно включить в одношаговую сборку.