Bescheiden continuous integration met Jira, Jenkins en Subversion

Een tijdje terug sprak ik een aantal conculega’s die nog nooit van ‘continuous integration’ (CI) hadden gehoord. Ze hingen dan ook aan mijn lippen toen ik vertelde hoe ons (scrum)project ondersteund wordt door Jira, Jenkins en Subversion.

Nu is onze CI uitwerking helemaal geen rocket science – en dat hoeft ook helemaal niet gezien het formaat van ons project – maar feit is dat zelfs een simpele implementatie niks hoeft te kosten (tijd/geld) en enorm veel kan opleveren (tijd en kwaliteit).

Aan het einde van het gesprek werd gevraagd of ik onze inrichting zou willen toelichten, welnu bij deze:

Als eerste is het belangrijk te begrijpen dat we een aantal uitgangspunten hebben gesteld.

  1. Ontwikkelaars moeten onafhankelijk van elkaar kunnen werken, zonder elkaar in de weg te zitten.
  2. Ontwikkelaars moeten hun eigen werk kunnen testen en het werk van anderen ‘collegiaal kunnen toetsen’.
  3. Ontwikkelaars dienen zich geen zorgen te maken over de het bouwen, configureren en distribueren van hun software over de systemen.
  4. De relatie tussen code en stories/bevindingen is zo zichtbaar mogelijk.

Versiebeheer

Om invulling te geven aan deze doelen zijn we begonnen met het installeren van een versiebeheersysteem. Hoewel een decentraal-versiebeheersysteem wellicht logischer zou zijn (immers doel 1), hebben we in dit geval gekozen voor Subversion(SVN). Primair omdat ons team daar de meeste ervaring mee heeft, secundair omdat Subversion het maken van branche‘s ondersteund, waarmee we precies invulling geven aan de decentrale eis.

De toegang tot SVN is aan de ontwikkelaars zelf. In de praktijk zien we dat sommigen het liefst werken met de Eclipse plugin, anderen prefereren de (windows)shell-extensie ‘Tortoise-SVN’.

Issue tracking & Scrum-board

Voor wat betreft het kunnen registreren/managen van stories en issues hebben we JIRA+Agile geïnstalleerd. Jira is in de basis een issue-tracker, waarin je met wat configuratie de hele developmentflow in kwijt kan. In ons geval wilt dat zeggen dat nieuw geregistreerde issues eerst beoordeeld dienen te worden door een Informatie Analist, deze beoordeeld/geeft prioriteit en wijst ze aan een developer toe. De developer pakt de issues op en na afronding komen ze in de ‘bak’ om collegiaal getoetst te worden door een andere developer. Na goedkeuring worden de issues doorgezet naar de testers, die een volledige integratietest uitvoeren op hun eigen ‘schone’ testomgeving.

Tijdens het gehele proces heeft men de mogelijkheid tijd te registreren & opmerkingen te plaatsen  over het verloop van de bevinding. Hierdoor zijn we in staat om binnen een handomdraai een release-document/samenvatting te maken. Aanvullend zorgt de Subversion-plugin er tevens voor dat wijzigingen in de code gekoppeld worden aan het issue/story, waardoor we het perfecte naslagwerk hebben mochten in de toekomst vragen ontstaan.

Screenshots van Jira + Scrumbord volgen.

Jenkins CI

Last but not least maken we gebruik van Jenkins. Jenkins is het platform dat bijna al onze software ”test’, build’, ‘deployed’ en onze ontwikkelaars op de hoogte stelt wanneer zij code hebben ingechecked die niet functioneert. Dit zowel voor onze .NET als java aonderdelen.

Het configureren van Jenkins is belachelijk simpel, in het simpelste geval koppel je aan de .ant file van je eclipse-project, en specificeer met behulp van wat shell/bat opdrachten waar de resulterende .jar/.exe files naartoe moeten. Leuker wordt het echter wanneer je het uitvoeren je (unit,integratie & GUI) tests meeneemt en de verantwoordelijke developers automatisch op de hoogte stelt van het falen/slagen van de build.

Eigen omgeving per ontwikkelaar

De genoemde software hierboven draait bij ons op 1 server. Hoewel dit op het moment van builds & tests erg krap is, is het voldoende. Dit voornamelijk omdat alle developers beschikken over een eigen sandbox, waarop ze werken totdat ze tevreden zijn over ‘hun’ code. Op dit moment wilt dat ‘slechts’ zoveel zeggen dat iedere developer beschikt over een eigen applicatieserver (Liberty profile 8.5.5. – of zwaarder, afhankelijk van de developer) waar hij ‘live’ zijn aanpassingen kan testen. Hierdoor is er altijd een werkende centrale-ontwikkel-omgeving waarop de developers elkaars werk kunnen testen en beoordelen – en zitten ze elkaar nooit in de weg.

Toekomst

Uiteraard is er ruimte voor veel verbeteringen, punt is echter dat ons project op dit moment niet veel meer nodig heeft dat wat we nu hebben. Developers kunnen ‘hun ding doen’, zitten elkaar niet in de weg en hoeven zich geen zorgen meer te maken over de configuraties. Onze testers ontvangen betere builds en de SCRUM master heeft altijd een up to date overzicht.

Ah, en wellicht mijn persoonlijke favoriet. Alles is traceerbaar!

Relevante links:

Subversion, Eclipse plugin voor Subversion, Windows Shell Client voor Subversion (Tortoise), Jira & Jira AgileJenkins

Screenshots volgen.

 

Leave a Reply

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