Me tegelt teeme tööd ka veel

Loodetavasti ei ole nüüd siin muljet jäänud nagu prooviksime digi tehnoloogiablogi feimi endale rabada ja tegeleksime ainult Wiiiitamise ja mobiilidega iTunesi juhtimisega. Mõtleisn, et teen puhkuse ajal teoks ühe ammuse lubaduse ja alustan (esialgu planeeritud) kolmeosalise sarjaga Continuous Integrationist ehk eestikeeli popilt pidevintegratsioonist. Varem olen ma juba seda teemat servast puudutanud, kirjutades WebLogicu scriptimisest aga ma luban, et ma ei korda ennast ;-)

Tõenäoliselt on teist enamik juba lugenud Martin Fowleri klassikut ning teavad enamvähem millest jutt. Minu lähem kokkupuude CIga algas paar kuud tagasi kui ühe vähe mahukama ja pikemajalisema projekti käigus otsustasin asja omal nahal järgi proovida. Selle kliendi projektidega on meil juba ajalooliselt olnud hulgaliselt integreerimispeavalu ning esmane kasu mida ma lootsin CI rakendamisest saada oli oluline kokkuhoid Ibuprofeni, Paramaxi ja teiste analoogiliste tablettide arvelt.

Et teid säästa konkreetse keskkonnaga seotud probleemide detailidest (neist ehk huvi korral kunagi hiljem) ütlen vaid, et esimeses järgus tahtsin olla pidevalt kursis sellega, kas suvalisel ajahetkel CVSist tõmmatud koodi on võimalik edukalt kompileerida ja deployda ning kas paralleelsed checkinid pole mingit juba valminud omadust katki teinud.

Ehk siis põhimõtteliselt oli ülesanne lihtne:

  1. Muudatuste korral koodibaasis teha CVSist checkout ja kompileerida kood
  2. Deployda kompileeritud kood aplikatsiooniserverisse
  3. Jooksutada koodil integratsioonitestid

Ega siin polekski võibolla midagi erilist kirjutada, sest build automationi tutoriale on veebis mitmeid nii, et võite vabalt Google poole pöörduda. Miks ma sellest ikkagi kirjutan on see, et lisaks traditsioonilisele build automationile tahtsin ma automatiseerida aplikatsiooni deploymist Weblogicusse ning kasutada integratsioonitestideks Watiriga tehtud web-teste. Viimase tõttu tuli kasutada ka üsna ebatraditsioonilist automation platvormi – Windowsi. Aga kõigest järgemööda. Kuivõrd tegemist oli projektiga, mille buildimiseks oli olemas Anti scriptid otsustasin automatiseerimiseks kasutada CruiseControlit.

CruiseControl

Väga lühidalt on CruiseControl proge, mis pollib perioodiliselt lähtekoodi repositoryt, käivitab vajadusel buildimise ning avaldab seejärel kompileerimise käigus tekkinud info XMLi kujul. Soovi korral saab proget juhtida (näiteks buildi katkestada) sisseehitatud JMX serveri kaudu. Lisaks sellele on paketis kaasas nn. Reporting veebirakendus, mis kuvab buildimiste tulemusi, näitab statistikat ning sisaldab JMX töölauda proge juhtimiseks. Selle rakenduse saab deployda (ma arvan et) suvalisse JSPd toetavasse aplikatsiooniserverisse. Community on valmis nikerdanud ka analoogilisi veebirakendusi PHPs.

CruiseControl buildima saada ei ole raske. Config.xml-i scriptimise dokumentatsioon on üsna hea ja Antiga kokkupuutunule lennult omandatav. Siiski tasub oma projekti kataloogide struktuur eelnevalt läbi mõelda (eriti kui on samas serveris plaanis mitut projekti buildida).

Struktuur, mis mulle tundus suhteliselt paindlik ja samas kompaktne

c:\cruise\config.xml
kõikide projektide konfiguratsioonifail
c:\cruise\project_1_name
projektikataloog. Sisalab CVSist välja chekitud koodi, buildfaile jne.
c:\cruise\logs\project_1_name
projekti logide kataloog
c:\cruise\logs\project_1_name\status.txt
projekti buildimise staatusfail

Veel mõned tähelepanekud:

  1. Selleks, et reporting aplikatsioonis JMX kontrollpaneel tööle saada on vajalik, et buildserveri nimi resolvitaks IP aadressiks – Windowsi all on üsna tõenäoline, et resolvitakse hostname järgi valesti (kui see peaks nii olema lisa konfi cruisecontrol.jmxhost parameeter IP aadressiga)
  1. Kui reporting app on konfitud töötama mitme projekti modes siis projekti tulemuste näitamisel kasutatakse logide asukoha pathi koostamisel build failis olevat projekti nime. See tähendab siis, et (vähemalt Windowsi all) on vajalik, et projekti nimi on sama nagu kataloog, milles asuvad tema logid. Näiteks kui config.xml-is on defineeritud projekt nimega myproject ja reporting appi konfis on logide asukoha baaskataloogiks antud (parameeter logDir) väärtus c:\cruise\logs siis selle projekti logid peavad asuma kindlasti kataloogis c:\cruise\logs\myproject. Iseenesest on see muidugi loogiline aga kuna config.xml-is määratakse logide jaoks full path võib see asjaolu tähelepanuta jääda ja segadust tekitada.
  1. Element schedule config.xml-is saab küll sisaldada mitu buildi targetit aga ühe buildimise käigus käivitatakse neist ainult üks.

Java Service Wrapper

Et CruiseControlis töötavat buildi võiks tõesti automatiseerituks nimetada peaks ta töötama ilma kasutaja vahelesegamiseta. Kuna tegemist on tavalise Java programiga saab *nix keskkondades selle taustale tööle panna olematu vaevaga. Windowsis võib loomulikult jätta kasutaja sessiooni lahti ning sinna jooksma käsureaakna aga eeldades, et keegi tahab selle masina peal veel ka midagi muud teha pole see kindlasti hea lahendus. Java programmi servicena tööle panemine Windowsi all ei ole aga üldsegi mitte triviaalne. Mina kasutasin selleks Tanuik Software poolt kirjutatud Java Service Wrapper nimelist vahendit.

Üldiselt on see vidin päris hästi dokumenteeritud ja selle installimine üsna lihtne aga konfiguratsiooni, eriti classpathide “korda saamine” vajas siiski veidi mängimist. Lõpuks oli see midagi sellist (siit on osa konfi, mida ma ei muutnud puudu):

wrapper.java.command=java
wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp
wrapper.port=1777
wrapper.working.dir=c:/projects
wrapper.java.classpath.1=%CRUISE_HOME%/main/lib/*.jar
wrapper.java.classpath.2=%ANT_HOME%/lib/*.jar
wrapper.java.classpath.3=%CRUISE_HOME%/main/dist/cruisecontrol.jar
wrapper.java.classpath.4=%JAVA_HOME%/lib/*.jar
wrapper.java.classpath.5=%CRUISE_HOME%/main/dist/cruisecontrol-launcher.jar
wrapper.java.library.path.1=%CRUISE_HOME%/main/lib
wrapper.java.additional.1=-Djavax.management.builder.initial=mx4j.server.MX4JMBeanServerBuilder
wrapper.java.additional.2=-Dcc.library.dir=%CRUISE_HOME%/main/lib
wrapper.java.additional.3=-Dcc.dist.dir=%CRUISE_HOME%/main/dist/
wrapper.app.parameter.1=CruiseControl
wrapper.app.parameter.2=-jmxport
wrapper.app.parameter.3=8000

Sellise lahendusega õnnestus CruiseControl Windowsi all servicena tööle saada. Täpsustuseks ütlen, et kergema vastupanu teed minnes panin service jooksma oma kasutaja accoundi alt (vajalik build skripti kaudu CVSi accessimise jaoks). Tõenäoliselt just sellega kaasnes “feature” et CruiseControl ei suuda buildi õnnestumise/ebaõnnestumise puhul helifaile mängida aga see ei olnudki mulle kõige olulisem.

Peale paarikuist katseperioodi on muljed üldiselt positiivsed. Veidi häirivaks probleemiks on CruiseControli kohatine hang-up, mis väljendub selles, et projekt jääb igavesti buildima – build tsükkel ei lõppe kunagi. Googeldades olen selle probleemi põhjuseks pannud väga pikalt aega võtvad CVSi päringud aga nüüd ei õnnestunu mul enam seda kohta leida, millele tuginedes mul selline arvamus tekkis. Igatahes vajab CC (Windowsi all) nii nädala kahe tagant restarti.

Et postitus liiga pikaks ei läheks jääb ta sel korral katki. Järgmine kord kirjutan siis sellest kuidas automatiseerida WebLogic serveri restartimist ning integreerida CruiseControlit ja Watiri teste. Stei tjuund.

One thought on “Me tegelt teeme tööd ka veel”

  1. > Java programmi servicena tööle panemine Windowsi all ei ole aga üldsegi mitte triviaalne

    Hm.. Windowsis suvalise softi service’na käima panek on triviaalne. St. sama triviaalne kui selle softi käsurealt käima tõmbamine. Näiteks kui cygwin masinas on installitud (ma ei tea, miks peaks windowsi masin ilma selleta olema):

    $ cygrunsrv -I service_nimi -p /path/to/exe
    $ net start service_nimi

    exe kusjuures ei pea olema päris .exe fail vaid võib olla ka skript, selline, mida cygwini prompti otsast käivitada saab.

    > Sellise lahendusega õnnestus CruiseControl Windowsi all servicena tööle saada

    Nii palju vaeva vaja näha? Kas sa CruiseControl.NET ka proovisid? Sellel on out of the box olemas võimalus CC.NET servicena jooksutada – ei mingit häkkimist, installimise ajal lihtsalt vaja linnuke panna, et tahad servicena teda kasutada. Ja kui ma õigesti mäletan, siis on talle sisse ehitatud ka ant’i tugi (või oli see nant). Aga vahet pole, sest CC.NET oskab käima panna suvalisi asju, kui tiba rohkem kirjutada.

Leave a Reply

Your email address will not be published. Required fields are marked *