Изучаваме инструменти за автоматизиране на сглобяването на софтуер от ново поколение
Опростяване на процеса на тестване с CruiseControl и SCons
Преди около десет години, когато разработването на софтуер стана моя професия, аз и моят екип написахме код, проведохме няколко местни теста и след това създадохме окончателната работна версия. Тъй като броят на необходимите тестове беше толкова голям, всеки разработчик провеждаше само свой собствен набор от тестове. Всяка вечер в 20:00 ч. Се изпълняваше задача за cron, която компилира изходния код и стартира процеса на тестване на интеграцията. Периодично веднъж на няколко дни се оказва, че кодовите фрагменти от два различни разработчика работят добре в изолирана среда, но не работят при интеграционно тестване.
Бързият темп на разработка на софтуер през последните десет години доведе до осъзнаването, че се нуждаем от нови, по-добри инструменти за тестване на интеграцията. Тук на помощ идва софтуерът CruiseControl (вижте Ресурси за връзка), който е подобен на Makefile, но се различава само по това, че е базиран на Python. По този начин не е нужно да изучавате друг специфичен за системата език за изграждане като make или jam.
Непрекъсната интеграция
Процесът на непрекъсната интеграция предполага, че системата за компилация проверява изходния код, компилира го и изпълнява тестовете за интеграция на определени интервали (например на всеки 2 часа). Разработчиците се уведомяват, когато при интеграционните тестове възникнат грешки при компилация или грешки. При желание всеки разработчик може да създаде своя собствена уеб страница, съдържаща статистика за изграждане, информация за източниците на грешки и т.н.
Работа с CruiseControl
CruiseControl се интегрира безпроблемно с широка гама от инструменти, включително система за едновременни версии (CVS), Subversion, Git, Perforce, Microsoft® Visual SourceSafe и IBM® Rational® ClearCase®. Тази статия използва системата за контрол на версиите Subversion, тъй като е най-популярната.
Можете да изтеглите CruiseControl от началната страница на проекта (вижте връзката в раздела Ресурси). По време на настоящото писане последната версия е 2.8.4; той се използва във всички примери.
В основата на системата CruiseControl е файл config.xml, който изгражда и тества в отговор на промените в кода и уведомява за резултатите. CruiseControl дефинира няколко маркера, които често се използват в XML файлове:, и
Създаване на конфигурационен файл
Основният конфигурационен елемент се нарича cruisecontrol и няма атрибути. Обикновено коренният елемент съдържа един или повече елементи на свойството. Елементите на свойствата съдържат двойки име-стойност и по очевиден начин дефинират параметри за директории, регистрационни файлове и т. Н. Прост пример за конфигурация е показан в Листинг 1.
Листинг 1. Добавяне на свойства към конфигурацията
Следващият и може би най-важният конфиг таг е
. Конфигурационният файл може да съдържа няколко маркера
, всеки от които определя отделен проект. Ако имате няколко проекта, които искате да стартирате паралелно, тогава трябва да използвате маркера
Листинг 2. Конфигурация за сървъри с многоядрени процесори
За всеки таг
атрибутът на името трябва да бъде зададен. Листинг 3 демонстрира използването на множество маркери
Листинг 3. Добавяне на множество проекти към CruiseControl
има някои интересни атрибути. Най-интересните за нас са атрибутите buildafterfailed и requireModification. Ако атрибутът buildafterfailed е True, тогава CruiseControl ще продължи да се опитва да изгради проекта, дори ако последното изграждане е неуспешно. Това може да бъде полезно в случаите, когато системата има много зависимости: например, ако изходните файлове се съхраняват в отдалечено хранилище, достъпът до който може да бъде нарушен или ако част от информацията се извлича от база данни, която може да не връща отговор на заявка навреме ... По подразбиране атрибутът buildafterfailed е False, а атрибутът requireModification е True. Последният атрибут казва на CruiseControl да се възстанови само ако в основата на изходния код се появят знаци за промяна. Ако трябва да изградите с определена честота, независимо дали изходният код е променен или не, задайте този атрибут на False. Следващият пример демонстрира използването на тези два атрибута.
След това трябва да конфигурирате йерархията на дъщерния маркер за всеки отделен проект. На първо място, трябва да разберете как да свържете изходния код към маркера
. Има ли специален етикет за това? Разбира се, да. Точно това прави етикетът. Листинг 4 показва как да получите достъп до хранилището на източника Subversion от CruiseControl.
Листинг 4. Конфигуриране на хранилището на източника в CruiseControl
Ако предпочитате да изграждате от локално копие на хранилището, можете да използвате атрибута LocalWorkingCopy, както е показано в Листинг 5.
Листинг 5. Изпълнение на компилация от проверено локално копие на източника
Имайте предвид, че трябва да използвате или атрибута RepositoryLocation, или атрибута LocalWorkingCopy в маркера. Атрибутите за потребителско име и парола са незадължителни и трябва да се използват само ако се изисква от системата за удостоверяване. Други контроли за източник използват подобни маркери като и. Кодът в Листинг 5 води до следващия интересен въпрос: Ако е посочено само локалното работно копие, кой е отговорен за поддържането му винаги актуално? Отговорът на този въпрос ни отвежда до маркера. В зависимост от използваното хранилище, маркерът може да има дъщерни тагове, например или. Листинг 6 показва автоматична настройка на системата за конфигурацията в Листинг 5.