Обробка залежностей, ASP, Програмування, статті

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

Проте в системах на основі декількох рішень після компіляції кожного рішення вихідні складання всіх проектів рішення необхідно скопіювати в папку 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>

*

*