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

Question

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

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

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

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

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

<appSettings file="Local.config">

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

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

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

Answer 6

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

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

Answer 7

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

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

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

Answer 8

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

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