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

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

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

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

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

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

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

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

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

Ответ 1

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

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

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

Ответ 2

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

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

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

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

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

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

<appSettings file="Local.config">

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

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

Ответ 3

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

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

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

Ответ 4

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

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

Ответ 5

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

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

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

Ответ 6

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

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

Ответ 7

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

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

Ответ 8

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

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

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