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

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

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

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

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

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

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

Мне все еще нужно вывести некоторые из них из Visual Build, но я еще не дошел до того момента, когда мне нужно это сделать.

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

18.08.2008 16:48:50
8 ОТВЕТОВ
РЕШЕНИЕ

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

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

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

18
18.08.2008 18:07:27

У меня есть набор скриптов Powershell, которые делают все это для меня.

Сценарий 1: сборка - эта простая, в основном она обрабатывается вызовом msbuild, а также создает сценарии моей базы данных.

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

Сценарий 3: развертывание - выполняется на каждом отдельном компьютере из папки, созданной сценарием пакета (сценарий развертывания копируется как часть упаковки)

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

Для файлов web.config я использую

<appSettings file="Local.config">

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

[Edit] Эквивалент файла appSettings = для раздела конфигурации - configSource = "Local.config"

9
18.08.2008 16:55:46

Я работал только над парой .Net проектов (я делал в основном Java), но я бы порекомендовал использовать такой инструмент, как NAnt . У меня есть реальная проблема с подключением моей сборки к IDE, в результате чего очень сложно настроить серверы сборки в будущем, так как вам нужно выполнить полную установку VS на любой ящик, из которого вы хотите собрать в будущее.

При этом любая автоматизированная сборка лучше, чем автоматическая сборка.

1
18.08.2008 16:58:47

Мы перешли от использования Perl-скрипта к MSBuild два года назад и не оглядывались назад. Создание визуальных студийных решений можно сделать, просто указав их в основном XML-файле.

Для чего-то более сложного (получение исходного кода, выполнение модульных тестов, сборка пакетов установки, развертывание веб-сайтов) вы можете просто создать в .net новый класс, производный от Task, который переопределяет функцию Execute, а затем сослаться на это из файла xml сборки ,

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

5
18.08.2008 17:11:15

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

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

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

1
18.08.2008 17:23:13

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

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

0
18.08.2008 17:42:45

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

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

1
29.08.2008 18:26:25

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

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

Несколько хороших объяснений здесь: UppercuT

0
18.05.2009 15:02:11