Улучшение вашего процесса сборки
Или фактически наладить процесс сборки, когда его для начала не так много.
В настоящее время моя группа почти всегда сталкивается с такой ситуацией. В первую очередь мы занимаемся разработкой веб-приложений (но в настоящее время не занимаемся разработкой настольных компьютеров). Развертывание программного обеспечения уродливо и громоздко даже с нашими скромными приложениями, и за те два года, что я был частью этой команды (и компании), у нас возникло слишком много проблем. Пришло время что-то с этим сделать, и в результате мы сможем убить двух зайцев Джоэла Теста одним выстрелом (ежедневные сборки и одношаговые сборки, ни одна из которых не существует в какой-либо форме).
Я хочу получить общее представление о том, что мне нужно делать или о чем думать, от людей, которые занимаются разработкой программного обеспечения дольше меня, а также имеют больший мозг. Я уверен, что это будет большинство людей, которые в настоящее время публикуют сообщения о бета-версии.
Соответствующие инструменты: Визуальная сборка Source Safe 6.0 (я знаю, но я ничего не могу поделать, используем ли мы в настоящее время Source Safe. Возможно, это будет следующая битва, в которой я буду сражаться.)
Ориентировочно у меня есть проект Visual Build, который делает это:
- Получите исходный код и поместите в локальный каталог, включая необходимые библиотеки DLL для проекта.
- Получите файлы конфигурации и переименуйте их по мере необходимости (мы храним их в специальном подкаталоге, который не является частью реального приложения, и они называются в соответствии с использованием).
- Сборка с помощью Visual Studio
- Выполните предварительную компиляцию с использованием командной строки, скопировав то, что будет директорией "сборки"
- Скопируйте в место назначения.
- Получите любые необходимые дополнительные ресурсы - в основном такие вещи, как документы, изображения и отчеты, связанные с проектом (и помещенные в каталог с шага 5). Этого много, и я не хотел включать это раньше. Однако я собираюсь копировать только измененные элементы, так что, возможно, это не имеет значения. Я не был уверен, действительно ли я хотел включить это в предыдущие шаги.
Для всего этого мне все еще нужно немного выйти из Visual Build, но я еще не в той точке, где мне нужно это делать.
Есть ли у кого-нибудь какие-либо советы или предложения? Замечу, что в настоящее время мы не используем проект развертывания. Я полагаю, это удалит некоторые шаги, необходимые в этой сборке (например, замена web.config).
Ответы 8
У меня есть набор скриптов Powershell, которые делают все это за меня.
Сценарий 1: Сборка - этот простой, он в основном обрабатывается вызовом msbuild, а также создает мои сценарии базы данных.
Сценарий 2: Пакет - в нем используются различные аргументы для упаковки выпуска для различных сред, таких как тестовая, и подмножества производственной среды, состоящей из множества машин.
Сценарий 3: развертывание - запускается на каждом отдельном компьютере из папки, созданной сценарием пакета (сценарий развертывания копируется как часть упаковки)
Из сценария развертывания я проверяю корректность таких вещей, как имя машины, чтобы что-то случайно не было развернуто в неправильном месте.
Для файлов web.config я использую
<appSettings file = "Local.config">
возможность иметь переопределения, которые уже есть на производственных машинах, и они доступны только для чтения, поэтому они случайно не будут перезаписаны. Файлы Local.config не регистрируются, и мне не нужно переключать файлы во время сборки.
[Edit] Эквивалент appSettings file = для раздела конфигурации: configSource = "Local.config"
Я работал только над парочкой проектов .Net (в основном на Java), но я бы порекомендовал использовать такой инструмент, как NAnt. У меня настоящая проблема с привязкой моей сборки к IDE, это в конечном итоге делает настройку серверов сборки реальной проблемой, так как вам нужно выполнить полную установку VS на любом компьютере, из которого вы хотите собрать, в будущее.
При этом любая автоматизированная сборка лучше, чем никакая автоматическая сборка.
Мы перешли от использования Perl-скрипта к MSBuild два года назад и не оглядывались назад. Создание решений Visual Studio можно выполнить, просто указав их в основном файле xml.
Для чего-то более сложного (получение исходного кода, выполнение модульных тестов, сборка пакетов установки, развертывание веб-сайтов) вы можете просто создать новый класс в .net, производный от Задача, который переопределяет функцию Execute, а затем ссылаться на него из вашего XML-файла сборки .
Здесь есть довольно хорошее введение: вступление
Наш процесс сборки - это набор самодельных Perl-скриптов, которые развивались за десять лет или около того, ничего особенного, но он выполняет свою работу. Один сценарий получает последний исходный код, другой строит его, а третий размещает в сети. Мы занимаемся разработкой настольных приложений, поэтому наш промежуточный процесс также создает установочные пакеты для тестирования и, в конечном итоге, отгрузки клиентам.
Я предлагаю вам разбить его на отдельные шаги, потому что будут моменты, когда вы захотите перестроить, но не получить последнюю версию, или, возможно, вам просто нужно будет перестроить. Наши скрипты также могут обрабатывать сборку из разных ветвей, так что учитывайте это также с любым разрабатываемым вами решением.
Наконец, у нас есть выделенная машина для сборки, которая каждую ночь перестраивает магистральную и обслуживающую ветви и отправляет электронное письмо с любыми проблемами или в случае успешного завершения.
Наша система сборки - это make-файл (или два). Было довольно забавно заставить его работать, так как он должен работать в обоих окнах (как задача сборки под VS) и под Linux (как обычная задача «make bla»). По-настоящему забавно то, что сборка получает фактический список файлов из файла .csproj, строит из него (другой) make-файл и запускает его. В процессах make-файл фактически вызывает сам себя.
Если эта мысль не пугает читателя, то (либо они сумасшедшие, либо) они, вероятно, могут заставить make + «ваш любимый обработчик строк» работать на них.
Когда вы беретесь за проект, в котором никогда не было автоматизированного процесса сборки, проще реализовать его поэтапно. Не пытайтесь проглотить слишком много за один раз, иначе вы можете почувствовать себя подавляющим.
- Сначала скомпилируйте свой код за один шаг с помощью программы автоматической сборки (например, nant / msbuild). Я не буду спорить, какой из них лучше. Найдите тот, который вам удобен, и используйте его. Сценарии сборки должны быть размещены вместе с проектом в системе управления версиями.
- Выясните, как должна запускаться автоматическая сборка. Независимо от того, подключается ли он к CruiseControl или запускает ночную задачу сборки с помощью запланированных задач. CruiseControl или TeamCity, вероятно, лучший выбор для этого, потому что они включают множество инструментов, которые вы можете использовать, чтобы упростить этот шаг. CruiseControl бесплатен, а TeamCity бесплатна до такой степени, что вам, возможно, придется заплатить за это в зависимости от того, насколько велик проект.
- Хорошо, к этому моменту вы уже достаточно освоитесь с инструментами. Теперь вы готовы добавить больше задач в зависимости от того, что вы хотите сделать для тестирования, развертывания и т. д.
Надеюсь это поможет.
Одна вещь, которую я бы посоветовал, убедиться, что ваш сценарий сборки (и проект установщика, если это актуально в вашем случае) находится в системе контроля версий. Я обычно использую очень простой скрипт, который просто проверяет \ получает последнюю версию «основного» скрипта сборки, а затем запускает его.
Я говорю это b / c. Я вижу команды, которые просто запускают последнюю версию сценария сборки на сервере, но либо никогда не помещают ее в систему управления версиями, либо когда они это делают, они только проверяют ее на случайной основе. Если вы заставите процесс сборки «получить» из системы управления версиями, это заставит вас хранить там самый последний и лучший сценарий сборки.
Мы используем UppercuT. UppercuT использует NAnt для сборки, и он чрезвычайно прост в использовании.
http://code.google.com/p/uppercut/
Вот несколько хороших объяснений: Апперкот