Исходники.Ру - Программирование
Исходники
Статьи
Книги и учебники
Скрипты
Новости RSS
Магазин программиста

Главная » Статьи по программированию » .NET - Все статьи »

Обсудить на форуме Обсудить на форуме

Процесс сборки
В этой главе рассказывается о роли сервера сборок и автоматизированного сценария сборки, применяемого для компиляции системы. Чтобы продемонстрировать основные концепции, дается пример сценария сборки.
 

Аннотация

В этой главе рассказывается о роли сервера сборок и автоматизированного сценария сборки, применяемого для компиляции системы. Чтобы продемонстрировать основные концепции, дается пример сценария сборки.

Это глава 5 руководства по групповой разработке в среде Visual Studio® .NET и Visual SourceSafe. Чтобы получить полное представление о данном руководстве, начните отсюда.

В этой главе рассматриваются следующие вопросы:

  • управление версиями и зависимостями;
  • автоматизация сборки с применением соответствующих инструментальных средств и сценариев;
  • формирование и распространение выходных сборок.

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

Основная задача сценария сборки - обеспечить возможность раз за разом автоматически генерировать сборки системы, соблюдая ее целостность. Обычно сценарий сборки запускают по ночам, чтобы не создавать в рабочее время лишнюю нагрузку на сервер сборок, сервер VSS (Microsoft® Visual SourceSafe) и сеть.

Сценарий сборки обращается к VSS, используя модель автоматизации VSS или вызывая VSS из командной строки. Он помечает и извлекает последние версии исходных текстов и файлов проектов, а затем вызывает Microsoft Visual Studio® .NET (выполняя в командной строке команду devenv.exe), чтобы собрать ваше решение (или решения). Сценарий сборки обычно формирует и отладочную, и финальную версии вашей системы.

Обработка зависимостей

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

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

Управление версиями сборок

Версия сборки задается атрибутом AssemblyVersion (определяемым в файле AssemblyInfo.cs или AssemblyInfo.vb). Номер версии физически состоит из четырех частей - чисел, разделенных точками:

<старший номер версии>.<младший номер версии>.<номер сборки>.<ревизия>

Нет необходимости явно задавать и изменять каждую часть, так как можно воспользоваться символами подстановки, чтобы автоматически генерировать номера сборки и ревизии. Visual Studio .NET генерирует исходный файл AssemblyInfo, содержащий атрибут AssemblyVersion, который определен так:

[assembly: AssemblyVersion("1.0.*")]

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

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

Примечание Когда в проекте на Microsoft Visual Basic® .NET атрибут AssemblyVersion равен "1.0.*", версия сборки обновляется только в первый раз, когда проект заново собирается в Visual Studio .NET IDE. В дальнейшем, когда проект заново собирается в том же экземпляре Visual Studio .NET, номер версии не меняется. Это не проблема, поскольку версия сборки используется лишь при получении информации о сборках без строгого имени (strong name). В сборках со строгими именами избегайте применения символов подстановки в атрибуте AssemblyVersion (почему - об этом рассказывается в следующем разделе).

В проектах на C#, если атрибут AssemblyVersion равен "1.0.*", версия сборки обновляется каждый раз, когда проект собирается заново.

Использование номеров версий с автоматическим увеличением

Для формирования номеров версий с автоматическим увеличением в атрибуте AssemblyVersion указывается используемый по умолчанию шаблон "1.0.*".

Преимущества

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

  • Номера сборки и ревизии автоматически задаются Visual Studio .NET. Координатору сборки или сценарию сборки не приходится присваивать им значения.
  • Гарантируется, что разные версии сборки никогда не получат одинаковые номера версий.

Недостатки

Применяя номера версий с автоматическим увеличением, вы сталкиваетесь со следующими недостатками.

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

Использование статических номеров версий

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

Преимущества

Применение статических номеров версий дает следующие преимущества.

  • Полностью контролируется точный номер версии.
  • Можно синхронизировать номера версий сборок с номером версии системы.

Недостатки

Статическим номерам версий свойственны следующие недостатки.

  • Номера версий задаются координатором сборки вручную или сценарием сборки.
  • Если номер версии не увеличивается при каждой сборке, может получиться так, что у вас окажется несколько версий одной и той же сборки с одинаковыми строгими именами. Это нежелательно и может создать проблему, если сборка устанавливается в GAC (Global Assembly Cache).

Внимание Если вы не изменяли версию сборки со строгим именем и пытаетесь установить ее в GAC с помощью средства Installer операционной системы Microsoft Windows®, то последняя версия DLL не установится, если в GAC уже есть DLL с таким же номером версии. Если вместо Windows Installer вы используете для установки сборки утилиту Gacutil.exe, обновленная DLL установится, даже если у нее тот же номер версии.

Централизованное формирование номеров версий сборок

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

  1. Поместите атрибут AssemblyVersion в один исходный файл, например в AssemblyVersionInfo.cs или AssemblyVersionInfo.vb.
  2. Сделайте этот файл общим для всех проектов, у которых в VSS должен быть один и тот же номер версии.

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

Структура папок сервера сборок

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

Хранение предыдущих версий

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

Структура папок на сервере сборок показана на рис. 5.1.

 

Latest Source Extracted From VSS - Последняя версия исходных текстов, полученная из VSS ProjectName1 - ProjectName1
Latest Build Output - Результаты последней сборки системы Debug - Отладочный режим компиляции (Debug)
Build Process - Сборочный процесс For multi-solution systems with file references only - Только для систем на основе нескольких решений с файловыми ссылками
Previous Builds - Предыдущие версии File references to build server with virtual drive letter - Файловые ссылки на сервер сборок с указанием буквы виртуального диска
Project - Проект Developer Workstation - Компьютер разработчика
System Name - Имя системы Referencing Assemblies from the Build Server - Обращение к сборкам, хранящимся на сервере сборок
Solution - Решение Local file refenreces with virtual drive letter - Файловые ссылки с буквой виртуального диска
Release - Режим компиляции Release Isolated Development - Изолированная разработка

Рис. 5.1. Структура папок на сервере сборок

Изучая рис. 5.1, обратите внимание на следующее.

  • Версии размещаются на сервере в соответствии с номерами сборок. Простой способ генерации номеров версий описывается далее в этой главе.
  • В папке Latest всегда содержатся результаты последней сборки системы - это такие же файлы, что и двоичные, которые находятся в папке с именем, являющимся самым большим номером сборки.
  • Содержимое выходной папки каждого проекта копируется сценарием сборки в подпапку папки Latest\Release. Имя этой подпапки соответствует имени проекта.
  • В системах на основе нескольких решений можно ссылаться на сборки, относящиеся к другим решениям и хранящимся в подпапках папки Latest\Release. Эти папки заполняются заново при каждой сборке системы; таким образом, гарантируется, что вы всегда ссылаетесь на самые "свежие" сборки с последними номерами версий.
  • Если нужна изолированная (и, возможно, отсоединенная) разработка системы на основе нескольких решений, разработчики должны скопировать результаты сборки на свои локальные компьютеры и ссылаться на локальные сборки с указанием буквы виртуального диска.

Не изменяйте путь к результатам сборки

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

  • Если размер сборки, на которую ссылается проект, превышает 64 Кб, сборочный процесс потерпит неудачу из-за ошибок блокировки. Скорее всего эту проблему решат в будущих версиях Visual Studio .NET.
  • Когда вы ссылаетесь на сборку, которая находится в папке, являющейся выходной для ваших проектов, может возникнуть еще одна проблема: не исключено, что Visual Studio .NET не удастся создать локальную копию сборки, так как при копировании окажется, что исходная папка и папка назначения совпадают. Если вы потом удалите ссылку из проекта, Visual Studio .NET удалит "локальную" рабочую копию. А поскольку локальная папка совпадает с исходной, будет удалена исходная сборка.

Сценарий сборки

На рис. 5.2 показаны операции, выполняемые сценарием сборки.

Manual or automatic initiation of build process - Инициация сборочного процесса вручную или автоматически
Generate build number - Генерируется номер версии
Label source file set with current build number - Набор исходных файлов помечается текущим номером версии
Extract latest labeled source file set from VSS to the build server - Последний помеченный набор исходных файлов копируется из VSS на сервер сборок
Rename Latest Folder to LatestBackup and create new Latest folder - Папка Latest переименовывается в LatestBackup и создается новая папка Latest
Repeat for required configurations e.g. Debug and Release - Повторяется для всех требуемых конфигураций, например Debug и Release
Build solution file with devenv.exe - Сборка решения с помощью devenv.exe
NOTE: Only for Multi-Solution Systems - ПРИМЕЧАНИЕ: только для систем на основе нескольких решений
Copy \bin output to \Latest\Debug OR \Latest\Release folder - Результаты сборки копируются из папки \bin в папку \Latest\Debug или \Latest\Release
Yes - Да
No - Нет
More solutions? - Есть еще решения?
All solutions successful? - Все ли решения успешно собраны?
Rename Latest as LatestBroken and rename LatestBackup as Latest - Папка Latest переименовывается в LatestBroken, а папка LatestBackup - в Latest
Copy contents of Latest to correct build number folder - Содержимое папки Latest копируется в папку, имя которой соответствует номеру версии
Greate BuildVersion.txt In Latest folder - В папке Latest создается файл BuildVersion.txt
Delete LatestBackup folder - Папка LatestBackup удаляется
Generate and Send Build Summary E-mail - Генерируется и отправляется почтовое сообщение о результатах сборки
Generate and Send Build Summary E-mail with attached build log - Генерируется и отправляется почтовое сообщение о результатах сборки, в которое вложен журнал сборки
Fix broken build - Устраняются проблемы, обнаруженные в процессе сборки
Re-execute build script using the same build number - Сценарий выполняется заново с использованием того же номера версии

Рис. 5.2. Сборочный процесс

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

Генерация номеров версий сборок

Формируемые друг за другом версии сборок идентифицируются по уникальным номерам сборок (build numbers). Эти номера используются, чтобы задавать имена выходных папок, содержащих результаты данной сборки, и чтобы помечать в VSS исходные файлы.

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

Пометка исходных файлов

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

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

В следующем фрагменте сценария показывается, как использовать командную строку VSS, чтобы пометить набор файлов в заданной папке VSS-проекта. Чтобы пометить все исходные файлы вашей системы, следует указать в VSS в качестве папки верхнего уровня папку $/Projects/SystemName.

' Запускаем VSS, указав команду Label с параметрами, отключающими UI
' и задающими, что на все вопросы подразумевается "да".
' Указываем местонахождение выходного файла журнала, записываемую метку
' и помечаемый VSS-проект. Пометка выполняется рекурсивно, поэтому
' достаточно лишь одной команды для VSS-проекта верхнего уровня.
' Текущий номер версии содержится в переменной Version.
WSHShell.Run "ss Label -I-Y -O@..\SSafeOut_Label.txt -LVersion1." &
Version & SSafeProj, 1, true

Извлечение последнего набора исходных файлов

Сценарий сборки выполняет операцию get, чтобы получить из VSS последний набор исходных файлов. Для получения именно того набора файлов, который нужен, используется присвоенная ранее метка. Исходные файлы извлекаются в общую структуру папок на сервере сборок, показанную на рис. 5.1.

В следующем фрагменте сценария показывается, как в командной строке VSS выполнить операцию get.

' Номер текущей версии хранится в переменной Version
WSHShell.Run "ss Get -I-Y -O@..\SSafeOut_Get.txt -VLVersion1." &
 Version & SSafeProj, 1, true

Создание папки Latest

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

Сценарий сборки сначала переименовывает текущую папку Latest в LatestBackup, а затем создает новую (пока пустую) папку Latest. Благодаря этому сценарий может выполнить откат к результатам предыдущей сборки, если текущая сборка потерпит неудачу.

Сборка решений в Devenv.exe

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

' Вызываем devenv, указывая в командной строке ключ rebuild (задающий 
' уничтожение результатов предыдущей сборки), требуемую конфигурацию,
' ключ out (чтобы выводить журнал в файл) и, наконец, файл собираемого
' решения. Count используется при получении имени файла журнала, чтобы
' в системе на основе нескольких решений при сборке каждого решения
' генерировался свой файл журнала.
WSHShell.Run "devenv /rebuild " & Config & " /out buildoutput"
&Count& ".txt " & SolutionName, 1, true

Сценарий сборки анализирует генерируемый Devenv.exe файл журнала сборки, чтобы определить, успешно ли закончилась сборка последнего решения.

В системах на основе нескольких решений, в которой для задания зависимости решений друг от друга используются файловые ссылки, финальная версия всегда должна генерироваться перед отладочной, чтобы любые ссылки на файлы можно было разрешить. При этом предполагается, что файловые ссылки указывают на сборки в папке Release, как рекомендовалось в разделе Создавая файловые ссылки, всегда указывайте финальные версии сборок главы 4 "Управление зависимостями".

Копирование результатов в папку Latest

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

Однако в системах на основе нескольких решений после компиляции каждого решения выходные сборки всех проектов решения необходимо скопировать в папку Latest\Release или Latest\Debug, чтобы гарантировать, что проекты, которые в дальнейшем будут собираться в составе других решений, будут ссылаться на последние версии сборок.

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

Упорядочивайте выходные сборки, размещаемые в подпапках папки Latest

На самом деле сборки копируются в подпапки папок Latest\Release и Latest\Debug. Имена подпапок определяются именами проектов. Причины, по которым применять такой подход лучше, чем помещать все выходные сборки прямо в папки Latest\Release, заключаются в более строго упорядочении выходных сборок и возможности использовать две внешних сборки с одинаковыми именами (например две сборки от сторонних поставщиков), включаемые в различные проекты.

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

Копирование папки Latest в папку с номером сборки

Если сборка системы на основе нескольких решений завершилась успешно, содержимое папки Latest копируется в папку, именем которой является номер текущей версии сборки. Благодаря этому можно архивировать формируемые друг за другом сборки.

Переименование папки Latest в LatestBroken

Если сборка потерпела неудачу, сценарий сборки переименовывает папку Latest в папку LatestBroken, а папку LatestBackup - снова в Latest. Благодаря этому разработчики, которые в данный момент обращаются к папке Latest на сервере сборок, могут продолжать свою локальную разработку.

Устранение проблем, выявленных в процессе сборки

Координатор сборки должен принять меры к тому, чтобы как можно скорее устранить проблемы, выявленные в процессе сборки. Обычно оказывается, что один или несколько исходных файлов содержат ошибки. Требуется или обновить эти файлы в VSS, или отказаться от последних изменений в них.

Если вы решили обновить эти файлы в VSS, то должны вручную пометить их в VSS Explorer текущим номером версии сборки. Тогда у обновленных файлов будет правильный номер версии.

После обновления соответствующих файлов, если вы хотите заново собрать текущую версию системы, укажите для сценария сборки номер версии текущей сборки, передав его как аргумент командной строки. Отсутствие номера версии сборки означает, что генерируется новая версия. Если номер версии сборки указан, из VSS извлекаются относящиеся к ней версии исходных файлов (у которых исходный код помечен тем же номером версии).

Повторная сборка систем на основе нескольких решений

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

Чтобы избежать этой проблемы, следует перейти на изолированную разработку, о которой рассказывалось в разделе Изолированная разработка главы 4 "Управление зависимостями". Это очень удобно при работе над системами на основе нескольких решений. Тогда вам не будут мешать сборки системы, выполняемые в течение рабочего дня.

Рассылка по электронной почте информации о сборке

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

Чтобы не "зашивать" в сценарий сборки псевдонимы электронной почты, следует создать списки рассылки в соответствии с именами проектов или решений.

Упаковка результатов сборки

Сценарий сборки позволяет упаковать результаты сборки в MSI-файл (Microsoft Installer), который можно использовать, чтобы установить последнюю версию системы в тестовой среде (или среде разработки).

Для систем на основе одного решения (или одного решения, разбитого на части) можно добавить проект Setup and Deployment, предлагаемый в Visual Studio .NET (т. е. проект создания установочного пакета). Такие проекты служат для автоматического создания MSI-файлов при сборке решений.

Примечание Чтобы установочный проект не компилировался всякий раз, когда вы собираете решение на локальном компьютере, исключите этот проект в Configuration Manager в Visual Studio .NET (вызывается из меню Build). Если вы таким способом исключите проект из сборки решения, это не повлияет на файл решения с контролируемым исходным кодом. Изменения запоминаются в файле пользовательских параметров решения. Этот файл специфичен для разработчика и не находится под управлением системы контроля исходного кода.

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

Решать вопросы, связанные с установкой систем на основе нескольких решений, сложнее, так как один проект Setup and Deployment может поместить в установочный пакет результаты сборки только одного решения. В этом случае сценарий сборки может генерировать MSI-файлы с помощью программного обеспечения сторонних поставщиков или SDK Windows Installer.

Создание учетных записей сценария сборки

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

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

Дополнительная информация

Дополнительные сведения об автоматизации см. в Visual SourceSafe 6.0 Automation.

Это глава 5 из руководства Team Development with Visual Studio .NET and Visual SourceSafe. Следующую главу читайте по ссылке Работа с Visual SourceSafe.


Может пригодится:


Автор: Microsoft Corporation
Прочитано: 4759
Рейтинг:
Оценить: 1 2 3 4 5

Комментарии: (0)

Добавить комментарий
Ваше имя*:
Ваш email:
URL Вашего сайта:
Ваш комментарий*:
Код безопастности*:

Рассылка новостей
Рейтинги
© 2007, Программирование Исходники.Ру