Один з найбільш істотних ризиків, з яким стикається команда розробників, полягає в тому, що самі розробники працюють з кодом окремо, незалежно один від одного, в результаті чого складна програма не працює, як очікується при складанні напрацьованого коду. Залежно від того, коли була виявлена несумісність в проекті, налагодження програми може відбуватися довше, ніж при більш ранньої інтеграції, особливо в разі зміни інтерфейсу програми або після імплементації серйозних правок основних частин програми.
Якщо Ви хочете створити просту комп'ютерну програму, яка складається з одного файлу, Вам просто необхідно зібрати і зв'язати весь написаний вами код в цей файл. На самому звичайному проекті, яким займається команда розробників, існують сотні, навіть тисячі файлів. Це «сприяє» тому, що процес створення здійсненним програми стає все більш складним і трудомістким: ви повинні «збирати» програму з різних компонентів.
Практика застосовується, наприклад, в Microsoft і деяких інших компаніях, що займаються розробкою ПЗ, полягає в щоденній збірці (білдованіі) програми, яка доповнюється димовим тестуванням. Щодня, після того, як кожен файл зібраний (сбілдован, побудований), пов'язаний (слінкован), і об'єднаний в здійсниму програму, сама програма піддається досить простому набору тестів, мета яких полягає в тому, щоб побачити, «димить» чи програма під час роботи. Ці тести і називаються димовими (від англ. Smoke - дим). Найчастіше цей процес досить добре автоматизований (або повинен таким бути).
ПЕРЕВАГИ. Цей простий процес забезпечує кілька суттєвих переваг.
Мінімізація ризику при інтеграції
Один з найбільш істотних ризиків, з яким стикається команда розробників, полягає в тому, що самі розробники працюють з кодом окремо, незалежно один від одного, в результаті чого складна програма не працює, як очікується при складанні напрацьованого коду. Залежно від того, коли була виявлена несумісність в проекті, налагодження програми може відбуватися довше, ніж при більш ранньої інтеграції, особливо в разі зміни інтерфейсу програми або після імплементації серйозних правок основних частин програми.
У надзвичайних випадках, помилки інтеграції можуть послужити причиною скасування проекту.
Щоденна сборка и прогін димових тестів дає можливість знизити ризик інтеграційних помилок, вчасно реагувати на них і не допускати їх накопичення.
Зниження ризику низької якості програмного продукту
Низька якість продукту безпосередньо залежить від невдач і проблем при інтеграції. Щоденна прогін мінімального набору димових тестів не дає помилок і проблем взяти верх на проекті. Якщо ви довели проект до стабільного стану раз, він буде залишатися стабільним завжди. Цим ви ніколи не допустите зниження якості до рівня, на якому і виникають помилки.
Допомога в діагностиці помилок
Якщо в один прекрасний день продукт не зібрався (зібрався з помилками), то за допомогою щоденної збирання і прогону набору димових тестів набагато простіше знайти причину проблеми. Працюючий продукт вчора і не працюючий сьогодні - це явний натяк на те, що щось не лагідний сталося між двома збірками.
Поліпшення морального духу
Якщо продукт працює і з кожним днем обростає все більш новими якостями і функціями, моральний дух розробників, по ідеї, повинен рости і абсолютно не важливо, що ж саме повинен робити цей продукт. Розробнику завжди приємно спостерігати за своїм працюючим «дітищем», навіть якщо продукт виводить на екран прямокутник :)
Використання щоденного білдованія і димових тестів
Основоположним принципом цього процесу є проста ідея білдованія і прогону димових тестів ЩОДЕННО.
Ось кілька подробиць цього принципу.
Щоденна збірка додатки
У деяких компаніях прийнято збирати проект не кожен день, а раз на тиждень. Ця система є хибною, тому що в разі «поломки» в проекті на поточному тижні, може пройти ще пара тижнів до наступної вдалою збірки. У такому випадку компанія втрачає всі переваги системи щоденної збирання проекту.
Перевірка на невдалу збірку
У разі щоденної збирання проекту мається на увазі, що проект повинен працювати. Однак, якщо ж проект виявляється не робочим, то його лагодження стає завданням з пріоритетом 1.
На кожному проекті є свій стандарт і ознака того, що називається «поломка при складанні». Цей стандарт повинен задавати рівень якості, який є достатнім для того, щоб відслідковувати незначні дефекти і не випускати з уваги дефекти, «блокуючі» проект.
Доброю складанням є та, при якій як мінімум:
- успішно компілюються всі файли, бібліотеки та інші компоненти;
- посилання на всі файли, бібліотеки та інші компоненти дійсні;
- не містяться ніяких стійких системних, що виключають можливість правильної роботи прикладної програми, які блокують помилок;
- всі димові тести проходять.
Щоденні димові тести
Димові тести повинні виконуватися на всьому проекті від початку до кінця. Вони не повинні бути вичерпними і всебічними, але повинні містити перевірку всіх основних функцій. Димові тестування повинно бути досить глибоким, щоб, в разі вдалого їх проходження, можна було назвати проект стабільним і назвати його таким, що може піддаватися більш глибокому тестування.
Сенс щоденної збирання втрачається без димового тестування. Цей процес стоїть на сторожі якості продукту і не допускає ніяких інтеграційних проблем. Без цього процес щоденної збирання є марною тратою часу, мета якої - перевірка компіляції.
Димові тестування повинно розвиватися на рівні з проектом. На початку, димові тести будуть перевіряти щось просте, наприклад, чи може проект видавати повідомлення «Hello, World!». З розвитком системи, димові тести стають більш глибокими. Час, який витрачається на перші димові тести, обчислюється декількома секундами, однак зі зростанням системи зростає і кількість необхідного для димового тестування часу. В кінці проекту димове тестування може тривати протягом годин.
Визначення групи збірки
Додавайте ревізію в збірку тільки якщо це має сенс
Зазвичай, розробники окремо пишуть код досить повільно, щоб можна було додавати значущі зміни в систему щодня. Вони повинні працювати над великою частиною коду і інтегрувати його в систему раз у кілька днів.
Введіть систему штрафів за зрив випуску черговий збірки (випуск не робочої збірки).
На більшості проектів є система штрафів за зрив випуску черговий збірки. На самому початку проекту варто чітко дати зрозуміти, що збереження робочого проекту є завданням самого високого пріоритету. Зрив випуску черговий збірки може бути винятком, але ні як не правилом. Наполягайте на тому, щоб розробники залишали все справи до тих пір, поки система знову не запрацює. У разі частого зриву збірки (випуску не робочої збірки) досить важко повернути проект в нормальне русло.
Незначні штрафи підкреслюють високу ступінь необхідності стежити за якістю складання системи. На деяких проектах розробникам, з вини яких збірка «падає», видають льодяники за випуск непрацюючої збірки. На дверях кабінету такого розробника висить відповідна вивіска до тих пір, поки він не полагодить збірку (за умови, що у розробників окремі кабінети :)). На інших проектах винні розробники повинні носити штучні цапині роги або вносити певну суму в «фонд морального духу» (приклади взяті з історії реальних компаній).
Але на деяких проектах вводяться більш серйозні штрафні санкції. Наприклад, розробники компанії Microsoft, що складаються в проектах з високим пріоритетом (Windows NT, Windows 95, Excel), носили пейджери і, в разі виявлення перевірки, вони повинні були прибути на роботу. Навіть якщо поломка або помилка були виявлені в 3 ранку.
Збирайте систему і «диміте» її навіть під тиском
Коли тиск графіка випуску проекту посилюється, робота по щоденній перевірці складання системи може здаватися безглуздою тратою часу. Однак це не так. У стресових ситуаціях розробники часто припускаються помилок. Вони відчувають такий тиск необхідності випускати імплементації, якого в звичайних умовах просто немає. Вони перевіряють свій код unit-тестами куди менш уважно, ніж зазвичай. У таких ситуаціях код прагне до стану ентропії набагато швидше ніж в менш стресових ситуаціях.
Як би там не було, щоденна збірка підсилює дисципліну і тримає тенденцію прагнення коду до стану ентропії під контролем.
Хто виграє від цього процесу? Деякі розробники протестують проти щоденних збірок, обґрунтовуючи свої протести непрактичностью цього заняття і його великими часовими витратами. Але все складні системи останнього часу піддавалися щоденним збірок і прогоні димових тестів. До моменту свого випуску, Microsoft Windows NT 3.0 містила в 40 000 файлах 5,6 мільйона рядків. Повна збірка займала 19 годин і виконувалася на декількох комп'ютерах. Незважаючи на це, розробники примудрялися щодня збирати систему. Будучи професійною командою, група розробників NT, своїм успіхом багато в чому зобов'язана щоденної збірці. Ті розробники, які працюють на менш складних проектах і, тому, не користуються перевагами процесу щоденної збирання, повинні задуматися над тим, щоб придумати собі якісь розумні пояснення.