My<cod/>.net
Улучшение Процесса Сборки
Или, на самом деле, создание процесса сборки, когда его не так много, чтобы начать с него.
В настоящее время это в значительной степени та ситуация, с которой сталкивается моя группа. Мы занимаемся главным образом разработкой веб-приложений (но в настоящее время нет разработки настольных компьютеров). Развертывание программного обеспечения уродливо и громоздко даже с нашими скромными приложениями, и у нас было слишком много проблем, возникших за два года, когда я был частью этой команды (и компании). Пришло время что-то сделать с этим, и в результате мы сможем убить двух испытательных птиц Джоэла одним камнем (ежедневные сборки и одношаговые сборки, ни одна из которых не существует в какой-либо форме).
То, что мне нужно здесь, - это общее представление о том, какие вещи мне нужно делать или думать, от людей, которые занимаются разработкой программного обеспечения дольше, чем я, а также имеют большие мозги. Я уверен, что это будет большинство людей, которые в настоящее время публикуют в бета-версии.
соответствующие инструменты: Визуальная Сборка Source Safe 6.0 (я знаю, но я ничего не могу поделать с тем, используем ли мы Source Safe в настоящее время. Возможно, это будет моя следующая битва.)
Предварительно, у меня есть визуальный проект сборки, который делает это:
- Получить исходный код и разместить в локальном каталоге, включая необходимые DLLs, необходимые для проекта.
- Получите конфигурационные файлы и переименуйте их по мере необходимости (мы храним их в специальном подкаталоге, который не является частью фактического приложения, и они называются в соответствии с использованием).
- Сборка с помощью Visual Studio
- Предварительная компиляция с помощью командной строки, копирование в то, что будет каталогом "build"
- Копировать в пункт назначения.
- Получите все необходимые дополнительные ресурсы-в основном документы, изображения и отчеты, связанные с проектом (и помещенные в каталог с шага 5). Там много всего этого, и я не хотел включать это раньше. Однако я собираюсь только скопировать измененные элементы, так что, возможно, это не имеет значения. Я не был уверен, действительно ли я хотел включить этот материал в более ранние шаги.
Мне все еще нужно добиться некоторого выхода из Visual Build для всего этого, но я еще не достиг того момента, когда мне это нужно сделать.
У кого-нибудь есть какие-нибудь советы или предложения? Я замечу, что в настоящее время мы не используем проект Deployment. Я предполагаю, что это удалит некоторые шаги, необходимые в этой сборке (например, web.config swapping).
Когда вы принимаете проект, в котором никогда не было автоматизированного процесса сборки, вам проще выполнить его поэтапно. Не пытайтесь проглотить слишком много за один раз, иначе вы можете почувствовать себя подавленным.
- Во-первых, получите компиляцию кода с одним шагом, используя программу автоматической сборки (т. е. nant/msbuild). я не собираюсь спорить, какой из них лучше. Найдите тот, который вам удобен, и используйте его. Пусть сценарии сборки живут вместе с проектом в системе управления версиями.
- Выясните, как вы хотите, чтобы ваша автоматическая сборка была запущена. Будь то подключение к CruiseControl или запуск ночной задачи сборки с использованием запланированных задач. CruiseControl или TeamCity, вероятно, лучший выбор для этого, потому что они включают в себя множество инструментов, которые вы можете использовать, чтобы сделать этот шаг проще. CruiseControl-бесплатно, а TeamCity-бесплатно до такой степени, что вам, возможно, придется заплатить за него в зависимости от того, насколько велик проект.
- Хорошо, к этому моменту вы будете довольно комфортно работать с инструментами. Теперь вы готовы добавить дополнительные задачи, основанные на том, что вы хотите сделать для тестирования, deployment и т. д...
Надеюсь, это поможет.
У меня есть набор скриптов Powershell, которые делают все это для меня.
Script 1: Build - этот простой, он в основном обрабатывается вызовом msbuild, а также создает скрипты моей базы данных.
Сценарий 2: пакет-Этот сценарий использует различные аргументы для упаковки выпуска для различных сред, таких как тест, и подмножеств рабочей среды, которая состоит из многих машин.
Сценарий 3: развертывание-выполняется на каждой отдельной машине из папки, созданной сценарием пакета (сценарий развертывания копируется как часть упаковки)
Из сценария развертывания я делаю проверку вменяемости таких вещей, как имя машины, чтобы вещи случайно не были развернуты в неправильном месте.
Для web.config файлов я использую
<appSettings file="Local.config">
функция должна иметь переопределения, которые уже находятся на производственных машинах,и они доступны только для чтения, чтобы их случайно не переписали. Файлы Local.config не регистрируются, и мне не нужно делать никаких переключений файлов во время сборки.
[Edit] эквивалент appSettings file= для раздела конфигурации - это configSource= " Local.config"
Мы перешли от использования сценария perl к MSBuild два года назад и не оглядывались назад. Построение решений visual studio можно выполнить, просто указав их в главном файле xml.
Для чего-либо более сложного (получение исходного кода, выполнение модульных тестов, построение пакетов установки, развертывание веб-сайтов) можно просто создать новый класс в .net, производный от задачи , которая переопределяет функцию Execute, а затем ссылаться на него из файла build xml.
Здесь есть довольно хорошее введение: вступление
Я работал только над парой проектов .Net (я сделал в основном Java), но одну вещь я бы рекомендовал использовать такой инструмент, как NAnt . У меня есть реальная проблема с соединением моей сборки с IDE, это в конечном итоге делает его реальной болью, чтобы настроить серверы сборки вниз по дороге, так как вы должны пойти сделать полную установку VS на любой коробке, которую вы хотите построить в будущем.
Тем не менее, любая автоматизированная сборка лучше, чем отсутствие автоматизированной сборки.
Наш процесс сборки-это куча доморощенных скриптов Perl, которые эволюционировали в течение десятилетия или около того, ничего особенного, но он выполняет свою работу. Один скрипт получает последний исходный код,другой строит его, а третий отправляет его в сетевое расположение. Мы занимаемся разработкой настольных приложений, поэтому наш промежуточный процесс также создает пакеты установки для тестирования и в конечном итоге доставки клиентам.
Я предлагаю вам разбить его на отдельные этапы, потому что будут моменты, когда вы захотите перестроить, но не получите последнюю версию, или, возможно, просто нужно будет перестроить. Наши скрипты также могут обрабатывать построение из разных ветвей, поэтому учитывайте это также с любым решением, которое вы разрабатываете.
Наконец, у нас есть специальная машина сборки, которая перестраивает ствол и ветви обслуживания каждую ночь и отправляет email с любыми проблемами или если он успешно завершен.
Одна вещь, которую я бы предложил, чтобы ваш сценарий сборки (и проект установщика, если это уместно в вашем случае) находился в системе управления версиями. У меня, как правило, есть очень простой скрипт, который просто проверяет out\gets последний сценарий сборки "main", а затем запускает его.
Я говорю это b/c я вижу, что команды просто запускают последнюю версию скрипта сборки на сервере, но либо никогда не помещают его в систему управления версиями, либо когда они это делают, они только проверяют его на случайной основе. Если вы сделаете процесс сборки в "get" из системы управления версиями, это заставит вас хранить там самый последний и самый большой сценарий сборки.
Наша система сборки-это makefile (или два). Было довольно весело заставить его работать, поскольку он должен работать как на windows (как задача сборки под VS), так и под Linux (как обычная задача "make bla"). Самое интересное, что сборка получает фактический список файлов из файла .csproj, строит (другой) makefile из этого и запускает его. В процессах make-файл фактически называет себя self.
Если эта мысль не пугает читателя, то (либо они сумасшедшие, либо) они, вероятно, могут заставить make + "your favorite string mangler" работать на них.
Мы используем UppercuT. UppercuT использует NAnt для сборки и чрезвычайно прост в использовании.
http://code.google.com/p/uppercut/
Некоторые хорошие объяснения здесь: UppercuT