Вивчаємо інструменти автоматизації збирання програмного забезпечення нового покоління
Спрощуємо процес тестування за допомогою CruiseControl та SCons
Років десять тому, коли розробка програмного забезпечення стала моєю професією, ми з моєю командою писали код, виконували кілька локальних тестів, а потім приймали остаточну робочу версію. Оскільки кількість необхідних тестів була дуже великою, кожен розробник виконував лише певний набір тестів. Щовечора о 20:00 виконувалося завдання cron, яке компілювало вихідний код та запускало процес інтеграційного тестування. Періодично, раз на кілька днів, з'ясовувалося, що фрагменти коду двох різних розробників добре працюють в ізольованому середовищі, але не працюють при інтеграційному тестуванні.
Швидкий темп розробки програмного забезпечення протягом останніх десяти років призвів до розуміння, що нам потрібні нові, досконаліші інструменти для інтеграційного тестування. Тут і приходить на допомогу програмне забезпечення CruiseControl (див. посилання в розділі Ресурси), яке аналогічне Makefile і відрізняється лише тим, що засноване на Python. Таким чином, вам не доведеться вивчати ще одну специфічну для певної системи мову складання, на зразок make або jam.
Безперервна інтеграція
Процес безперервної інтеграції передбачає, що система складання перевіряє вихідний код, компілює його та запускає інтеграційні тести через задані інтервали часу (наприклад, через кожні 2 години). У разі виникнення помилок компіляції або помилок в інтеграційних тестах розробники одержують відповідні повідомлення. За бажанням кожен розробник може створити свою Web-сторінку, що містить статистику складання, інформацію про джерела виникнення помилок і т.д.
Робота з CruiseControl
CruiseControl прозоро інтегрується з доситьвеликою кількістю інструментів, включаючи Concurrent Versions System (CVS), Subversion, Git, Perforce, Microsoft Visual SourceSafe та IBM Rational ClearCase. У цій статті використовується система управління версіями Subversion, оскільки вона є найпопулярнішою.
Ви можете завантажити CruiseControl з домашньої сторінки проекту (див. посилання у розділі Ресурси). На момент написання цієї статті останньою була версія 2.8.4; вона використовується у всіх прикладах.
В основі системи CruiseControl лежить файл config.xml, який виконує складання та тестування у відповідь на зміну коду, а також повідомляє про результати. У CruiseControl визначено кілька тегів, які зазвичай використовуються у XML-файлах: , , , і
Створення конфігураційного файлу
Кореневий елемент конфігурації називається cruisecontrol і не містить атрибутів. Зазвичай кореневий елемент містить один або кілька елементів property. Елементи property містять пари "ім'я-значення" і очевидно задають параметри директорій, log-файлів і т. д. Приклад простої конфігурації наведено в лістингу 1.
Лістинг 1. Додавання властивостей у конфігурацію
Наступний і, ймовірно, найважливіший тег конфігурації – це тег
. Конфігураційний файл може містити декілька тегів
, кожен із яких визначає окремий проект. Якщо у вас є кілька проектів, які ви хочете запускати паралельно, необхідно використовувати тег
Лістинг 2. Конфігурація для серверів із багатоядерними процесорами
Для кожного тега
необхідно задати атрибут name. У лістингу 3 продемонстровано використання кількох тегів
Лістинг 3. Додавання кількох проектів у CruiseControl
є кілька цікавих атрибутів. НайцікавішимиДля нас є атрибути buildafterfailed і requireModification . Якщо атрибут buildafterfailed має значення True, то CruiseControl продовжуватиме спроби виконання складання проекту навіть якщо останнє складання завершилося з помилкою. Це може бути корисним у випадках, коли в системі є багато залежностей: наприклад, якщо вихідні файли зберігаються у віддаленому сховищі, доступ до якого може бути порушений, або якщо якась інформація витягується з бази даних, яка може не повернути відповідь на запит вчасно . За умовчанням атрибут buildafterfailed має значення False, а атрибут requireModification – значення True. Останній атрибут вказує CruiseControl на те, що повторне складання має виконуватися лише в тому випадку, якщо в базі вихідного коду з'явилися позначки про зміну. Якщо необхідно виконувати збірку із заданою періодичністю незалежно від того, був змінений вихідний код чи ні, встановіть значення цього атрибута False. У наступному прикладі показано використання цих двох атрибутів.
Далі необхідно налаштувати ієрархію дочірніх тегів для кожного окремого проекту. Насамперед необхідно зрозуміти, як зв'язати вихідний код із тегом
. Чи є для цього спеціальний тег? Звісно так. Саме це завдання виконує тег. У лістингу 4 продемонстровано, як отримати доступ до репозиторію вихідних кодів Subversion із CruiseControl.
Лістинг 4. Конфігурування репозиторію вихідних кодів у CruiseControl
Якщо ви вважаєте за краще виконувати збірку з локальної копії репозиторію, можна використовувати атрибут LocalWorkingCopy , як показано в лістингу 5.
Лістинг 5. Запуск складання з перевіреної локальної копії вихідного коду
У тезі потрібно використовувати або атрибутRepositoryLocation, або атрибут LocalWorkingCopy. Атрибути username і password є необов'язковими і їх необхідно використовувати лише якщо цього вимагає система автентифікації. Для інших елементів керування вихідним кодом використовуються аналогічні теги, наприклад, . Код із лістингу 5 наводить на наступне цікаве запитання: якщо вказано лише локальну робочу копію, то хто відповідає за те, щоб вона завжди була актуальною? Відповідь це питання призводить нас до тегу . Залежно від використовуваного репозиторію тег може мати дочірні теги, наприклад, або . У лістингу 6 продемонстрована автоматична установка системи заданий стан для конфігурації з лістингу 5.
Лістинг 6. Перевірка вихідного коду за допомогою bootstrapper
Тег вказує CruiseControl на локальну копію вихідного коду, до якої необхідно застосувати команду оновлення перед запуском процесу збирання.
Отже, вихідний код налаштовано. Тепер потрібно визначитися з тим, коли має запускатися процес складання та яку команду слід запускати для цього. Як ви вже можете припустити, нам знадобиться новий тег. Отже, зустрічайте тег, використання якого демонструється у лістингу 7.
Лістинг 7. Виконання складання за допомогою тега schedule
Тег (дочірній тег ) виконує вказану команду або сценарій як частину процесу складання для зазначеної в атрибуті workingdir директорії. У випадку, якщо збірка завершиться з помилкою, передбачений атрибут errorstr , за допомогою якого можна задати рядок користувача, що містить повідомлення про помилку. Якщо необхідно виконувати збірку із заданою періодичністю незалежно від того, чи було змінено вихідний код у репозиторії, чи ні, можна використовувати атрибут interval тега , в якому вказується часовий інтервал (у секундах)між складаннями, як показано в лістингу 8.
Лістинг 8. Завдання часового інтервалу (1 година) між складаннями
Після того як процес складання буде запущений, може виникнути необхідність відстеження її статусу. Ймовірно, найпростіше використовуватиме для цього Web-інтерфейс. Так ми підійшли до розгляду дочірнього елемента тега
під назвою listeners. Особливий інтерес для нас є тег, який записує статус збірки у файл. Якщо потрібно явно вказати директорію, в якій повинні створюватися log-файли складання, використовуйте для цього тег та його необов'язковий атрибут dir . Тег містить дочірній тег, який використовується для поєднання різної інформації інтеграційного тестування у вигляді файлу журналу CruiseControl. Команда
об'єднує всі файли XML з директорії dir-name в один log-файл CruiseControl. Це корисна функція, якщо вам необхідно бачити загальну картину двох процесів – збирання та тестування. Така конфігурація наведена у лістингу 9.
Лістинг 9. Оновлена конфігурація
Ми майже закінчили, якщо не брати до уваги кількох дій, що виконуються після закінчення складання. Наприклад, потрібно буде надсилати повідомлення розробникам або помістити весь вихідний код у zip-файл. Тут нам може допомогти тег
. Цей тег має багато дочірніх тегів, що дозволяють виконувати різні дії після закінчення процесу складання. Для наших цілей можна використовувати найпоширеніший підхід – надсилання повідомлень електронною поштою. У цьому випадку тег
можна використовувати з його дочірнім тегом або, як показано у лістингу 10.
Лістинг 10. Додавання функції сповіщення електронною поштою
Ще одним відмінним інструментом автоматизації збирання програмного забезпечення є SCons. SCons означаєsoftware construction (конструювання програмного забезпечення) і легко замінює собою make . Навіщо використовувати SCons, якщо у нас вже є make ? Перш за все, make , automake , autoconf та інші інструменти мають спеціальний синтаксис, тоді як SCons заснований на Python. Крім того, синтаксис SCons набагато простіше запам'ятати, а з файлами SConstruct (аналог Makefile) простіше працювати. Також SCons має спеціалізовану підтримку файлів C/C++ і Java™ і має всю функціональність make , використовуючи набагато менше коду.
SCons та Python
У цій статті використовується версія SCons 2.1, яка не підтримує версії Python старше 2.3.5.
Додаток "Hello, World" на SCons
У лістингу 11 представлений код простої програми "Hello, World", написаний C++ .
Лістинг 11. Програма "Hello, World" на C++
Нижче наводиться вміст SConstruct-файлу для створення файлу, що виконується:
Якщо ви порівняєте це з варіантом використання make , то одразу відчуйте всі переваги SCons. Функція Program носить назву builder_method і є API-інтерфейсом Python, який говорить SCons про те, що потрібно виконати складання файлу, що виконується. Можна одночасно виконувати збірку декількох виконуваних файлів і виводити в процесі складання різні повідомлення, як показано в лістингу 12.
Лістинг 12. Складання декількох файлів, що виконуються, з виведенням додаткових повідомлень
Для чого тут використовується env? У термінах SCons ми створюємо середовище конструювання, а об'єкт env містить різну інформацію про компілятор, прапори компонувальника і т.д.
Корисні прийоми використання SCons
Нижче наведено кілька типових завдань, які можна виконувати за допомогою SCons:
-
Присвоєння виконуваному файлудовільного імені. Наприклад, при складанні вихідного файлу hello2.cpp необхідно отримати файл, що виконується, з назвою newworld2. Для цього вкажіть потрібне ім'я як перший аргумент Program:
Складання виконуваного файлу з кількох вихідних файлів. Наприклад, файл newworld2 залежить від файлів hello2.cpp та world3.cpp. У цьому випадку SConstruct-файл має виглядати так:
Часто буває необхідно виконати компонування з певними бібліотеками, наприклад pthread або math . Функція Program може працювати з додатковими аргументами, які містять змінні LIBS та LIBPATH. Нижче показано, як можна виконати компонування з бібліотекою pthread :
Що якщо для створення файлу, що виконується, потрібні всі cpp-файли, що зберігаються в директорії? На щастя, немає необхідності перераховувати їх усі. Це завдання спрощує функція Glob:
За допомогою SCons дуже просто зібрати статичну бібліотеку. Для цього просто викличте функцію Library:
Зверніть увагу, що внутрішні механізми SCons створюють файли math1.o , math2.o і math3.o , потім ar rc libarith.a math1.o math2.o math3.o і, нарешті, ranlib libarith.a .
Створити спільно використовувану бібліотеку в SCons так само просто, як і статичну:
Може виникнути потреба скомпілювати різні вихідні файли з різними опціями. Наприклад, якщо необхідно передати у вихідний код опцію DX86_64 , що означає оптимізацію для 64-розрядних платформ, то SConstruct-файл буде виглядатинаступним чином:
Зверніть увагу на нову функцію компонувальника Object. Функція Program може виконувати складання виконуваних модулів з об'єктних файлів, тому немає потреби вказувати вихідні файли, як це робилося раніше.
У цій статті я згадував про те, що ім'я цільового файлу має бути першим аргументом. Якщо ви хочете зробити все навпаки або пограти з порядком аргументів, то можна зробити так:
Зверніть увагу, що source і target – це спеціальні ключові слова SCons.
Хоча Program, SharedLibrary та інші функції є членами об'єкта env, їх можна використовувати без зазначення префікса env. Таким чином, допустимо використовувати наступний SConstruct-файл:
Висновок
З цієї статті ви дізналися про CruiseControl і безперервну інтеграцію, а також про найважливіші теги ( , , і ). Також ми застосували систему SCons для збирання невеликого проекту на C++ і дізналися, як виконувати збирання статичних та спільно використовуваних бібліотек. Обидва ці інструменти мають набагато більші можливості, ніж розглядалося в цій статті, тому обов'язково зверніться за додатковою інформацією до розділу Ресурси.
Ресурси для скачування
Схожі теми
- Оригінал статті: Learning next-generation build tools for software management (EN).
- Дізнайтесь більше про CruiseControl (EN).
- Дізнайтесь більше про SCons (EN).
- Порівняйте SCons з іншими системами автоматизації збирання на сторінці SCons wiki (EN).
- Завантажте останню версію CruiseControl (EN) з веб-сайту проекту.
- Завантажте SCons версії 2.1 (EN) із Web-сайту SourceForge.
- Отримайте додаткову інформацію та завантажте систему Subversion (EN).