Обробка залежностей

У системах на основі одного рішення або одного рішення, розбитого на
частини, залежності та порядок складання визначаються посиланнями на проекти.
Сценарії збірки таких систем нескладні, тому що від них вимагається просто
запустити 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 .*".

Переваги

Використання номерів версій з автоматичним збільшенням
забезпечує наступні переваги.

Недоліки

Застосовуючи номери версій з автоматичним збільшенням, ви стикаєтеся
з наступними недоліками.

Використання статичних номерів версій

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

Переваги

Застосування статичних номерів версій дає наступні переваги.

Недоліки

Статичним номерами версій властиві такі недоліки.

Увага Якщо ви не змінювали версію збірки із суворим ім'ям і
намагаєтеся встановити її в 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, зверніть увагу на наступне.

Не змінюйте шлях до результатів складання

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

Сценарій збірки

На рис. 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 eg Debug and Release – Повторюється
для всіх необхідних конфігурацій, наприклад Debug і Release
Build solution file with devenv.exe – Збірка вирішення за допомогою
devenv.exe
NOTE: Only for Multi-Solution Systems – ПРИМІТКА: тільки для систем на
основі кількох рішень
Copy in output to LatestDebug OR LatestRelease folder – Результати
складання копіюються з папки в папку in LatestDebug або
LatestRelease
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-IY-O @ .. SSafeOut_Label.txt-LVersion1." &
Version & SSafeProj, 1, true

Витяг останнього набору вихідних файлів

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

У наступному фрагменті сценарію показується, як в командному рядку
VSS виконати операцію get.

"Номер поточної версії зберігається у змінній Version
WSHShell.Run "ss Get-IY-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 не потрібна, тому що використовуються посилання на проекти, а
НЕ файлові посилання, що вказують на внутрішні збірки. У таких системах
сценарій складання може просто архівувати результати складання в папку з
ім'ям, що відповідає номеру версії.

Проте в системах на основі декількох рішень після компіляції
кожного рішення вихідних складання всіх проектів рішення необхідно
скопіювати в папку LatestRelease або LatestDebug, щоб
гарантувати, що проекти, які в подальшому будуть збиратися в
складі інших рішень, будуть посилатися на останні версії збірок.

Примітка За кількістю рішень, що вказуються в командному
рядку, сценарій складання може визначити, з якою системою він має справу
– На основі одного або декількох рішень. Якщо число рішень більше
одного, збірку потрібно скопіювати в папку Latest. Інакше цю операцію
можна пропустити.

Упорядкуйте вихідні збірки, що розміщуються в підпапках папки Latest

Насправді збірки копіюються в підпапки папок LatestRelease і
LatestDebug. Імена підпапок визначаються іменами проектів. Причини, по
яким застосовувати такий підхід кращий, ніж поміщати всі вихідні збірки
прямо в папки LatestRelease, полягають у більш строго впорядкування
вихідних зборок і можливості використовувати дві зовнішні збірки з
однаковими іменами (наприклад, дві збірки від сторонніх постачальників),
включаються в різні проекти.

Не забувайте, що зовнішні збірки не збираються в ході складального
процесу і що їх потрібно включати в проекти, які повинні до них
звертатися. Може виявитися (хоча це малоймовірно), що два проекти
використовують різні версії однієї і тієї ж збірки від стороннього постачальника
(З одним ім'ям). Розподіл вихідних зборок по різних папках
гарантує, що ці 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.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*