Вопрос

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

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

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

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

Предварительно, у меня есть проект визуальной сборки, который делает это:

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

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

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

Это было полезно?

Решение

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

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

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

Другие советы

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

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

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

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

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

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

<appSettings file="Local.config">

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top