НОУ ІНТУІТ, Лекція, Рекомендації по роботі у великих проектах

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

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

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

Логічна послідовність операцій у великих проектах

На рис.10.1 представлено типову схему спільної роботи кількох підгруп над створенням складного додатка та проілюстровано ключові моменти роботи у великому проекті:

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

Рекомендації щодо керування версіями

Працюючи над великим рішенням, що включає десятки проектів, можуть виникнутипроблеми з його масштабованістю рішення (. Sln) Visual Studio. У цьому випадку слід розподіляти керування версіями підсистем або підпрограм, використовуючи кілька файлів рішень і не створюючи головного рішення для всього додатка. На рис.10.2 продемонстровано підхід із використанням кількох рішень, який зазвичай застосовується у великих групах.

Одне з головних завдань при обслуговуванні структури з кількома рішеннями – забезпечити відсутність циклічних посилань між рішеннями, що потребує складних сценаріїв складання та явного відображення залежностей. За такої структури неможливо повністю зібрати додаток у Visual Studio; доводиться вдаватися до TFS Team Build.

Рекомендації з розгалуження та злиття

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

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

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

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

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

• Development- контейнер для активних гілок розробки

• Team 1

• Feature A- ізольована гілка розробки

• Source

У цю структуру включено:

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

Рекомендації щодо виконання збирання

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

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

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

При роботі з великими рішеннями, що включають десятки проектів, можуть виникнути проблеми масштабування рішення (.sln) Visual Studio . У цьому випадку слід розбити структуру системи керування версіями на підсистеми або підпрограми та використовувати кілька файлів рішення.

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

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

---