Улучшение вашего процесса сборки

Или фактически наладить процесс сборки, когда его для начала не так много.

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

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

Соответствующие инструменты: Visual Build Source Safe 6.0 (я знаю, но ничего не могу поделать, используем ли мы Source Safe в настоящее время. Возможно, это будет следующая битва, с которой я буду сражаться.)

Ориентировочно у меня есть проект Visual Build, который делает это:

  1. Получите исходный код и поместите в локальный каталог, включая необходимые библиотеки DLL, необходимые для проекта.
  2. Получите файлы конфигурации и переименуйте их по мере необходимости (мы храним их в специальном подкаталоге, который не является частью фактического приложения, и они называются в соответствии с использованием).
  3. Сборка с помощью Visual Studio
  4. Выполните предварительную компиляцию с использованием командной строки, скопировав то, что будет директорией "сборки"
  5. Скопируйте в место назначения.
  6. Получите любые необходимые дополнительные ресурсы - в основном такие вещи, как документы, изображения и отчеты, связанные с проектом (и помещенные в каталог с шага 5). Этого много, и я не хотел включать это раньше. Однако я собираюсь копировать только измененные элементы, так что, возможно, это не имеет значения. Я не был уверен, действительно ли я хотел включить это в более ранние шаги.

Для всего этого мне все еще нужно немного выйти из Visual Build, но я еще не в той точке, где мне нужно это делать.

Есть ли у кого-нибудь какие-либо советы или предложения? Замечу, что в настоящее время мы не используем проект развертывания. Я полагаю, это удалит некоторые шаги, необходимые в этой сборке (например, замена web.config).

Ответов (8)

Решение

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

  1. Сначала скомпилируйте код за один шаг с помощью программы автоматической сборки (например, nant / msbuild). Я не буду спорить, какой из них лучше. Найдите тот, который вам удобен, и используйте его. Сделайте сценарии сборки живыми вместе с проектом в системе управления версиями.
  2. Выясните, как должна запускаться автоматическая сборка. Независимо от того, подключается ли он к CruiseControl или запускает ночную задачу сборки с помощью запланированных задач. CruiseControl или TeamCity, вероятно, лучший выбор для этого, потому что они включают множество инструментов, которые вы можете использовать, чтобы упростить этот шаг. CruiseControl бесплатен, а TeamCity бесплатна до такой степени, что вам, возможно, придется заплатить за это в зависимости от размера проекта.
  3. Хорошо, к этому моменту вы уже достаточно освоитесь с инструментами. Теперь вы готовы добавить больше задач в зависимости от того, что вы хотите сделать для тестирования, развертывания и т. Д.

Надеюсь это поможет.

Мы используем UppercuT. UppercuT использует NAnt для сборки, и он чрезвычайно прост в использовании.

http://code.google.com/p/uppercut/

Вот несколько хороших объяснений: UppercuT

У меня есть набор скриптов 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, производный от Task, который переопределяет функцию Execute, а затем ссылаться на него из вашего XML-файла сборки .

Здесь есть довольно хорошее введение: введение

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

Я предлагаю вам разбить его на отдельные шаги, потому что будут моменты, когда вы захотите перестроить, но не получить последнюю версию, или, возможно, вам просто нужно будет перестроить. Наши скрипты также могут обрабатывать сборку из разных ветвей, так что учитывайте это также с любым разрабатываемым вами решением.

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

Наша система сборки - это make-файл (или два). Было довольно забавно заставить его работать, так как он должен работать в обоих окнах (как задача сборки под VS) и под Linux (как обычная задача «make bla»). По-настоящему забавно то, что сборка получает фактический список файлов из файла .csproj, строит из него (другой) make-файл и запускает его. В процессах make-файл фактически вызывает сам себя.

Если эта мысль не пугает читателя, то (либо они сумасшедшие, либо) они, вероятно, могут заставить make + «ваш любимый обработчик строк» ​​работать на них.

Одна вещь, которую я бы посоветовал, убедиться, что ваш сценарий сборки (и проект установщика, если это актуально в вашем случае) находится в системе контроля версий. Я обычно использую очень простой скрипт, который просто проверяет \ получает последнюю версию «основного» скрипта сборки, а затем запускает его.

Я говорю это b / c. Я вижу команды, которые просто запускают последнюю версию сценария сборки на сервере, но либо никогда не помещают ее в систему управления версиями, либо когда они это делают, они только проверяют ее на случайной основе. Если вы заставите процесс сборки «получить» из системы управления версиями, это заставит вас хранить там самый последний и лучший сценарий сборки.