Сьогодні ми продовжимо налаштування Buildbot’а. Сподіваюсь, читач вже знайомий з попереднім матеріалом на дану тему, тому тут будуть вказані типові запитання, вдосконалення, можливі проблеми без зайвих слів.
Tag Archives: python
Тонке налаштування Buildbot’а
Автоматизація процесу розробки: працюємо з Buildbot’ом
Як я й обіцяв в минулій статті, сьогодні ми дослідимо реальний приклад використання системи неперервної інтеграції під назвою BuildBot. Ні сам процес розробки, ні структура проекту не вважаються ідеальними, однак саме завдяки їм у мене зараз є можливість написати як можливо вижити в, здавалося б, такому хаотичному проекті.
Постановка задачі
Проект на Java(використовується система збирання Ant) в репозитарії Subversion знаходиться за адресою https://project.example.com/svn . Необхідно проводити аудит працездатності системи щоразу після внесення змін до нього. Результати збирання системи надсилаються автору змін у випадку успішного результату, або ж у список розсилки всього проекту, якщо процес пройшов невдало.
Вибір між CruiseControl, про який мені розповіли співробітники, та BuildBot, з яким я встиг познайомитись в якості розробника, був досить складний. Проект був вже тоді немаленький(на даний момент весь репозитарій складає 6Гб місця), після тестування його переносила на продуктивні сервери окрема людина. Enterprise, одним словом. І я, довірившись особистому знайомству, вибрав BuildBot. І не прогадав.
Автоматизація процесу розробки: системи неперервної інтеграції
Сьогодні, шановний читачу, ми продовжимо розмову про те, як можна автоматизувати процес розробки програмного забезпечення, зменшити витрати часу на допоміжні роботи в великому колективі і сконцентруватись на власне розробці.
У колективі, кожен член якого працює над окремою незалежною частиною, стадія інтеграції є заключною. Саме в ній виявляються проблеми сумісності всіх компонентів системи, через це кінцева дата випуску може бути відсунута на невизначений термін. Саме на зменшення часових та трудових витрат на процес інтеграції за рахунок раннього виявлення проблем та усунення помилок та протиріч спрямовані системи неперервної інтеграції.
Управління проектами з Trac
Задача: отримати багатоцільове open-source середовище для управління проектами з web-інтерфейсом, підтримкою Git та БД PostgreSQL, автентифікацією через LDAP.
Обираємо систему управління проектами
За інформацією для роздумів гугл нас привів на сторінку з вікіпедії. Як бачимо, вибір у нас досить великий. Вибрати з них що-небудь по собі з виконанням більшості критеріїв досить нескладно. Однак підтримку Git має в своїй реалізації лиш один проект — Trac, про який і йтиме мова далі.
Чому Trac
| Версія | 0.11 |
| Мова | Python |
| Сайт | http://trac.edgewall.org/ |
| Ліцензія | Модифікована ліцензія BSD |
Як вже було сказано, лише в нього я знайшов підтримку Git репозиторіїв. До того ж Trac має неабияку гнучкість: окрім базового набору, якого зазвичай не вистачає, купа функціоналу реалізована у вигляді плагінів, яких тут можна знайти на будь-який смак. Простий та зрозумілий з першого погляду інтерфейс, відсутність зайвих “свистілок” не може не порадувати людей, які від продукту очікують ефективну реалізацію функціоналу. Можливість адаптувати середовище на власний смак та за потребами проекту, будь то розробка програмного забезпечення, адміністрування, чи організація господарських робіт у себе на городі. Хоча незважаючи на можливість вести будь-які проекти в цій системі, все ж вона тісно інтегрована з ситемами контролю версій(Svn, Bazaar, Mercurial, Git), підсвіткою синтаксису “на льоту”(використовуються SilverLight, Enscript, а з версії 0.11 — ще й Pygments), розробкою документації (Doxygen, PyDoc, PerlDoc), і навіть системою управління тестами. Підтримка RSS-стрічок, wiki(до якої є теж купа розширень), і навіть ведення блогу додають практично всі необхідні інструменти для ведення сучасного проекту. Довершує все це добро документація по Trac, яка є в кожному новоствореному проекті на стоірнках wiki.
Установка та адміністрування
Ставити ми його будемо, звичайно ж, на Debian GNU/Linux, для якого поточною стабільною віткою вважається 0.10. Сподіваюсь, ви вже маєте налаштований Git репозиторій, інакше раджу взяти низький старт з цієї сторінки. Виконавши aptitude install apache2 libapache2-mod-python trac-core trac-git pcycopg2 та встановивши залежності й додаткові пакети за бажанням переходимо власне до конфігурації.
Першим кроком буде створення нового проекту. Де тримати проекти — справа кожного, хоча мені більше імпонує покласти їх до /var/trac/. Для промислового розгортання буде доцільним розгортати подібні середовища в домашніх директоріях користувачів. Отже, почнемо.
# mkdir /var/trac # cd /var/trac # trac-admin myproject initenv
В процесі установки система необхідно ввести деякі базові настройки, вибрати БД, з якою працюватимете, та вказати шлях до репозиторію. Якщо в якості репозиторію ви вказали Git, то система в кінці видасть попередження про відсутність його підтримки, однак все це можна сміливо ігнорувати, бо все це ми виправимо в подальших кроках.
Саме з цього моменту починають проявлятись особливості роботи з Trac: адміністрування проекту проводиться за допомогою консольної утиліти trac-admin. Отже, якщо ви не маєте доступу через SSH до свого сервера, годі й мріяти про установку цієї системи. І хоча деякі операції можливо перекласти на веб-морду, однак початкову ініціалізацію — зась. Якщо ж ви все ще з нами і вже готові до наступного кроку, то не гаймо часу.
Всі налаштування проекта знаходяться в одному файлі conf/trac.ini в директорії проекту. Зараз можна підправити загальні параметри проекту, однак я раджу відкласти цей крок на момент після тестового запуску проекту. Справа в тому, що будь-який згенерований проект з самого початку містить wiki-документацію, яка доступною мовою опише можливості та особливості налаштування системи. Знову повертаючись до Git, на сторінці GitPlugin ви зможете прочитати вичерпні пояснення щодо того, яким чином організувати співпрацю Trac та Git.
Для успішного старту проекту необхідно отримати можливість запускати Python-івські скрипти на запит веб-сервера. Це можна реалізувати через механізм CGI, FastCGI, або ж використовуючи mod_python, що ми, власне, і зробимо:
<Location/projects> SetHandler mod_python PythonInterpreter main_interpreter PythonHandler trac.web.modpython_frontend PythonOption TracEnvParentDir /var/trac PythonOption TracUriRoot /projects </Location>
Вище представлений шматок конфігураційного файлу веб-сервера, який дозволить вести нам безліч проектів, що лежатимуть в /var/trac Наступні рядки ж дозволять мати один обліковий запис для всіх проектів. Даний тип автентифікації приведений лише для прикладу. Автентифікація користувачів через систему LDAP буде описана в наступних статтях.
<LocationMatch"/projects/[^/]+/login"> AuthType Basic AuthName "Trac" AuthUserFile /var/trac/.htpasswd Require valid-user </LocationMatch>
Якщо всі кроки виконані успішно, ви мусите побачити вже працюючий проект за адресою:http://localhost/projects/myproject/
Додаткові плагіни
Деякі з плагінів потребують особливої уваги при роботі з ними. Тут розглянуті лиш два з них, хоча насправді проблеми можуть виникнути в багатьох плагінах, функціонал яких пов’язаний з іншими системами, зокрема плагіни, що реалізують автентифікацію.
GraphvizPlugin
Трохи помучитись змусив мене плагін, що реалізовує inline-вставку графічного представлення інформації за допомогою graphviz. Для тих, хто все ще не може отримати зображення, підкажу основні вимоги:
- директорія, в якій знаходиться кеш graphviz повинна бути доступна для запису користувачем www-data, під яким запущено веб-сервер. Крім того, якщо ви використовуєте tmpfs, то не робіть директорію для кешу в /tmp, оскільки для роботи graphviz необхідне існування директорії, а при наступному ж перезавантаженні вона просто зникне.
- необхідні пакети: graphviz та librsvg2-bin
WebAdmin
Для того, щоб не мати клопоту при роботі з цим плагіном, необхідно, щоб файли проекту в /var/trac/myproject були доступними користувачеві www-data для запису. Загалом же, плагін встановлюється та підключається без зайвих зусиль.
Trac та PostgreSQL 8.3
Якщо ви використовуєте Trac 0.10 зі стандартних пакетів Debian, то матимете клопіт з неможливістю перегляду звітів про помилки (tickets). При цьому ще й при додаванні такого звіту система може видавати помилки. Для того, щоб усунути цю помилку, необхідно змінити у файлі /usr/share/python-support/trac/trac/ticket/model.py рядок 296 з:
"ORDER BY time", (self.id, str(self.id), self.id))
на
"ORDER BY time", (self.id, str(self.id), str(self.id)))
Сподіваюсь, що за кілька днів після випуску даної статті ця порада стане непотрібною
Висновки
Закінчуючи статтю, хочеться підбити підсумки щодо системи в цілому. Особисто я вже використовую Trac для власних проектів, тому що ця система:
- проста, зручна, та ефективна
- має підтримку сучасних репозитаріїв, баз данних та прикладного програмного забезпечення
- дуже гнучка
- знаходиться в активній розробці
Хочете переконатися в цьому самостійно? Тоді ласкаво просимо до http://www.hosted-projects.com/trac/TracDemo/Demo , де ви зможете попрацювати з Trac без зайвого клопоту.
Серед недоліків даної системи щодо нашого ринку можу віднести майже відсутній хостинг з підтримкою Python та неможливість організації повного циклу життя проекту від його зародження і до закриття через веб-інтерфейс, хоча останнє скоро буде виправлене.
Exception 2008, або “Краще день загубити, потім за 5 хвилин долетіти”
Саме під таким (на мою думку) девізом успішно відбулась конференція Exception #07, присвячена динамічним мовам програмування. Все почалося, коли я отримав листа з повідомленням “Завтра відбудеться Exception Conference #07″, де поміж всього іншого проскочила кількість зареєстрованих осіб: 389(в дійсності ж прийшло десь 300). “Ого, скільки народу!”, — подумав я, і вже з нетерпінням почав очікувати завтрашній день. Прочитавши інформацію про проведення минулорічної конференції та задоволення організацією, я був трішки вражений “натовпом”, який зустрів мене ще до реєстрації. Мабуть, організатори просто не очікували такого ажіотажу, що і не дивно: минулого року (судячи з інфи в блогах) було десь сто чоловік. Повний перелік виступів, а також коротка інформація про авторів знаходиться на офіційному сайті конференції.
Read more »
Конференція Exception #07
Всередині березня в Києві планується провести наступну, вже сьому, конференцію розробників програмного забезпечення “Exception”. Конференція присвячена так званим динамічним мовам програмування, як-то: Python, Ruby, Smalltalk, Groovy та REBOL. В ній приймуть участь ведучі розробники України та Росії, серед яких є представники таких відомих компаній як EPAM Systems, Microsoft, російської телекомпанії “Спорт”, журналу “Системный Администратор” та люди, що приймали участь в розробці таких відомих соціальних проектів як ВКонтакте.ру і ВКадре.ру.
Оскільки тематика конференції дуже різнопланова, доповіді будуть відбуватись”в двох потоках” поділених тематично. Відвідувачі зможуть вільно пересуватись між двома конференц-залами вибираючи найбільш цікаві для себе теми. В розкладі є час для двох тривалих кофі-брейків, під час яких учасники конференції матимуть чудову можливість задати питання доповідачам у більш неформальній обстановці, або просто поспілкуватись з іншими. Місце, де відбуватиметься кофі-брейк буде облаштоване фліп-чартами з фломастерами для більш плідного спілкування та наглядної демонстрації. Розклад доповідей можна подивитись тут.
Конференція відбудеться в суботу 15 березня 2008-го року в приміщенні готелю “Русь”, що знаходиться за адресою м. Палац Україна, вул. Госпітальна, 4 (розташування готелю на мапі), яка славить своїми конференц-залами та якістю обслуговування. В роботі конференції задіяні дві зали: на 250 та 150 чоловік. Очікувана кількість відвідувачів – близько 400 осіб. Початок конференції об 11:00, закінчення – об 19:00. Вартість участі – 50 грн. (10$), реєстрація відкрита до 13 березня включно.
Для матеріального заохочення серед учасників відбудеться розіграш призів від компанії EPAM: MP3-плеєра Apple iPod Nano 8GB, мобільного телефону LG KG245 та Transcend 8GB JetFlash.

