НОУ ІНТУІТ, Лекція, Знайомство з Team Build

Як визначити стратегію збирання

Для визначення стратегії складання виконайте такі дії:

  1. З'ясуйте, хто користуватиметься збіркою.
  2. Перегляньте сценарії рішення.
  3. Виявіть поширені труднощі.

Визначення споживачів збирання

Більшість команд розробників створюють складання для одного або кількох типів споживачів:

  • команди розробників;
  • команди тестувальників;
  • внутрішні контролери;
  • зовнішні контролери бета-версії;
  • замовники.

У споживачів кожного типу свої вимоги до якості складання та частоти їх випуску. Як правило, їх можна розділити на дві групи: одним потрібні планові зборки, що випускаються за розкладом, іншим - складання, що оперативно створюються на основі подій, що відбуваються. Планові збирання зазвичай створюються щодня, але це може відбуватися як частіше, так і рідше. Складання, керовані подіями, зазвичай ініціюються поверненням вихідного коду в систему і призначені для швидкого надання команді розробників інформації про якість коду. Якщо у розробників виникли проблеми з непрацюючими складаннями, спробуйте використовувати модель повернення коду з контролем якості (gated check-in), в якій складання тестуються, перш ніж дозволяється їхнє розміщення в дерево вихідного коду.

Сценарії складання

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

  • Щоденне складанняВикористовується у більшості команд для надання тестувальникам таіншим споживачам узгоджених двійкових файлів.
  • Щоденне складання та безперервна інтеграціяУ деяких командах для оперативного надання розробникам інформації про якість коду використовуються збірки з безперервною інтеграцією - при кожному поверненні вихідного коду. Система безперервної інтеграції в чистому вигляді цілком підходить для невеликих команд розробників, а ось великі команди з частим поверненням вихідного коду та тривалим складанням ризикують перевантажити сервер складання. Якщо це сталося, спробуйте використати ковзну збірку (rolling build). Складання при цьому створюються не так часто, але й час між поверненням коду та отриманням результату зростає незначно.
  • Кілька лабораторій збирання, в кожній з яких використовуються щоденні збирання та безперервна інтеграціяУ дуже великих командах для підвищення якості та своєчасності збирання необхідні більш складні рішення. Для скорочення кількості збоїв можна використовувати повернення коду з контролем якості, відхиляючи ненадійний код, перш ніж він потрапить у дерево. Команди з підрозділами можуть використовувати кілька серверів складання (по одному для кожного підрозділу), щоб забезпечити концентрацію кожної групи на виконанні певного завдання. Наприклад, один підрозділ створює складання інтеграції, інший - складання розробки.
Планові зборки

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

Найчастіше споживачами планових зборок є:

  • тестувальники;
  • внутрішні контролери збирання;
  • зовнішні контролери.

Щоб створити планове складання, виконайте такі дії:

  1. Створіть пакетний файл для збирання з командного рядка.
  2. Використовуйте планувальник Windows для виконання пакетного файлу за розкладом.

Більш детальну інформацію ви знайдете у лекції 9.

Безперервна інтеграція

При безперервній інтеграції збірка запускається щоразу, коли відбувається повернення коду після редагування. Призначення такого збирання - максимально швидке отримання інформації про якість збирання. Споживачами безперервної інтеграції зазвичай є команди розробників.

Виберіть одну з наступних стратегій залежно від розміру команди, розміру складання та частоти повернення коду:

  • Складання відразу після повернення коду.
  • Ковзаюча збірка після вказаної кількості повернень коду або через певний період часу.

Більш детальну інформацію ви знайдете у лекції 8.

Повернення коду з контролем якості

Повернення коду з контролем якості означає, що код, що повертається, повинен задовольняти певним стандартам якості, щоб його можна було додати в дерево вихідного коду. За рахунок виконання низки тестів знижується кількість збоїв складання та підвищується її якість.

Типові проблеми

Особливості великих проектів

Під час роботи у великих проектах слід враховувати такі відмінності великих команд:

  • вимагають більш складної структури розгалуження та злиття;
  • часто вимагають управління залежностями між різними рішеннями та командними проектами;
  • частіше виникає необхідність підтримувати кілька збірок для компонентів та команд розробників.

Працюючи у великих командах розробників, враховуйтенаступні міркування:

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

Налаштування складання

Інформація про збирання, наприклад, сервер збирання, місце накопичення, каталог збирання, задається у файлі TFSBuild.proj . Він містить значну частину відомостей, необхідних для виконання командного складання, включаючи розташування складання та вказівки на те, чи потрібно виконувати статичний аналіз коду та модульні тести. Щоб змінити цю інформацію, відредагуйте файл TFSBuild.proj , виконаючи такі дії:

  1. Вийміть файл із системи керування вихідним кодом.
  2. Оновіть інформацію у файлі.
  3. Поверніть файл у систему керування вихідним кодом.

Team Build заснована на системі MSBuild. Вона інтегрується з сервером TFS на рівні програми та взаємодіє з робочими елементами, покриттям коду тестами, тестовими даними та звітами.

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