Hudson та безперервна інтеграція django-проектів, DOU
Налаштування тестової конфігурації
Самому ностесту не під силу запустити джанго тести через саму ж джангу. І тому потрібен окремий стартер тестів, проксі до ностеста. Можна написати свій, але можна встановити джанго-ніс і не витрачати свій дорогоцінний час. Після встановлення треба прописати налаштування у конфігураційний файл проекту:
І запускати тести стандартним для джанго способом (через manage.py test). Якщо викликати допомогу з налаштованим джанго-носом (manage.py help test), то можна побачити всі параметри, які підтримує джанго та в додатку ті, що підтримує ностест.
Встановлення Гудзона
За замовчуванням Гудзон запускається на порту 8080, що не завжди зручно, а то взагалі не запуститься, тому що саме цей порт зайнятий вже іншим додатком. У такому разі доведеться змінити порт, виправивши конфіг Гудзона.
У бунті конфіг розташований у файлі /etc/default/hudson. А порт змінюється за допомогою редагування параметра HUDSON_ARGS. Наприклад:
Якщо змінюєте конфіг, то й Гудзон треба обов'язково перезапустити.
Білд-скрипт
У джанго-проектах, які ми розробляємо, пишеться ant-скрипт build.xml, і потім у каталозі з ним запускається команда ant, щоб перевірити, що скрипт працює та тести успішно виконуються. Коли скрипт готовий, можна труїти його Гудзону.
Цей скрипт запускає тести з додатковими параметрами —where — визначає, де розташовані ваші тести —noinput — спеціальна опція, яка пропускає всі запити користувача на введення. Таке може статися, коли джанго після падіння тестів не видалила тестову базу даних, а при новому старті запитує «чи не хочете видалити вже існуючу тестову базу? ». Звичайно, колискрипт буде виконуватися на сервері без цього параметра виконання тестів може просто повиснути. —with-xunit — опція, яка згенерує xml з форматом junit звітів. Пізніше в Гудзон задамо одну з опцій. —xunit-file — вказує на який файл треба зберегти звіт.
Створення проекту у Гудзоні
Насамперед бачимо таку картину:
"New Job" - саме те, що нам потрібно. Як тільки перейшли на сторінку зі створенням, Гудзон запропонує створити один із типів проекту. Сміливо вибирайте "Build a free-style software project", вводимо назву проекту та натискаємо на кнопку "ОК".
Далі у вас безліч опцій, більшість з яких вам швидше за все не знадобиться спочатку. Найбільш значущі це "Source Code Management", "Build Triggers" та "Build". На скріншоті наведено приклад налаштування проекту з чистого аркуша.
Коли вводиться урл до репозиторію проекту, Гудзон дасть посилання на окреме вікно, щоб ви ввели логін і пароль, якщо репозиторій закритий від зайвих очей. Також підтримує ssh-ключики, але я їх не намагався використовувати з Гудзоном.
У опції «Build» вказуємо націлення, які будуть виконані. У нас в build.xml у проекті стоїть атрибут default="nosetests", це означає, що якщо викликати ant без таргетів, то виконається таргет nosetests. Тому можна просто вибрати Ant і нічого не вводити в інші поля, що з'явилися.
Ще момент із Build Trigger. Хто не знайомий із кроном, п'ять зірочок означає «перевіряти кожну хвилину». Формат MINUTE (0-59) HOUR (0-23) DAY (1-31) MONTH (1-12) DAYOFWEEK (0-7)
Окремим пунктом є опція «Post-build Actions». Це саме місце, де відбувається головна магія генерації звітів. У build.xml вказано параметр, куди треба зберігати звіт, тому заповнимо пункт з «Junit»відносним шляхом до зі звітом згенерованого ностестом.
Зберігаємо і чекаємо, поки настане час білда. Якщо все успішно, то після кількох запусків тестів на головній сторінці проекту з'явиться графік.
Додаткові фішки (плагіни)
З усього набору ми використовуємо два найбільш значущі для нас на даний момент плагіни.
Cobertura дозволяє згенерувати звіт щодо покриття коду тестами. Violations показує графіки дублювання коду або дотримання pep8, це все як приклад. Насправді там 9 типів порушень, які можна використовувати, але ми використовуємо тільки 2.
Для кобертури необхідно поставити coverage-пакет, додатково плагін для ностестів nose-xcover, і трохи змінити білд-скрипт.
Як видно, додалися опції —with-xcoverage і —cover-package=dou . Друга опція ставить саме той пакет, який ми тестуємо, пропускаючи зайві. І нацькувати кобертуру на згенерований після виконання тестів через пункт Publish Cobertura Coverage Report. Для нас було достатньо вказати рядок «Cobertura xml report pattern» у **/coverage.xml.
Для violations встановлюємо додатково пакети pylint та clonedigger. І доповнюємо наш білд-файл новими таргетами, які потім вказуємо в налаштуваннях проекту в Гудзоні.
Додатково Гудзону необхідно знати, звідки брати нові звіти, для цього заповнюємо в конфігурації розділ «Report Violations» пункти cpd і pylint. За прикладом мого білд-файлу та структури каталогів вони набувають значення в **/tests/reports/clonedigger.xml для cpd та **/tests/reports/pylint.txt для pylint відповідно.
Окрема подяка Ігорю Кононученку за допомогу у підготовці матеріалу.