welke continuous delivery server past het best om te werken met

WELKE CONTINUOUS DELIVERY SERVER PAST HET BEST
OM TE WERKEN MET VERSCHILLENDE PROJECTEN IN
VERSCHILLENDE TALEN EN HOE ZET JE DIE HET BEST OP
VOOR EEN DATEX2 PARKING API IN C#.
PROMOTOR: DIETER ROOBROUCK
ONDERZOEKSVRAAG UITGEVOERD DOOR
SERGIY SKIRIDOV
VOOR HET BEHALEN VAN DE GRAAD VAN BACHELOR IN DE
NEW MEDIA AND COMMUNICATION TECHNOLOGY
HOWEST | 2015-2016
WELKE CONTINUOUS DELIVERY SERVER PAST HET BEST
OM TE WERKEN MET VERSCHILLENDE PROJECTEN IN
VERSCHILLENDE TALEN EN HOE ZET JE DIE HET BEST OP
VOOR EEN DATEX2 PARKING API IN C#.
PROMOTOR: DIETER ROOBROUCK
ONDERZOEKSVRAAG UITGEVOERD DOOR
SERGIY SKIRIDOV
VOOR HET BEHALEN VAN DE GRAAD VAN BACHELOR IN DE
NEW MEDIA AND COMMUNICATION TECHNOLOGY
HOWEST | 2015-2016
CONTINUOUS DELIVERY - DATEX2 – C#
SERGIY SKIRIDOV
Woord vooraf
Hallo, mijn naam is Sergiy Skiridov. Ik ben momenteel
laatstejaars New Media & Commucation Technology (NMCT)
student aan de Hogeschool West-Vlaanderen (Howest).
Geboren in Oekraïne maar getogen in België. Vanaf mijn
tienerjaren werd ik geïnteresseerd in informatica. Alles dat te
maken had met computers vond ik boeiend. Het was dan ook
mijn beste keuze om in 3e graad secundair onderwijs te veranderen
naar Toegepaste Informaticabeheer. In Koninklijk Atheneum Oudenaarde heb ik dan de basis
gelegd voor mijn toekomstige carrière in IT. Na enkele jaren heb ik mijn interesses voor
Software Development ontwikkeld. Omdat ik tijdens mijn opleiding voornamelijk met C# en
Java geprogrammeerd heb, zijn deze twee talen ook mijn meest favoriete.
De laatste maanden van mijn bachelor opleiding sluit ik af met een stage bij Flow NV. Ik heb
voor Flow gekozen als mijn stagebedrijf vanwege een interessante opdracht waarvan ik veel
kan bijleren. Ik krijg de kans om technologieën zoals verkeersstandaard Datex2 of
Continuous Delivery te ontdekken. Ik geloof dat deze laatste steeds meer zal gebruikt
worden vanwege zijn enorme voordelen.
Dit is dan ook de aanleiding voor het thema van mijn bachelor proef. Hiermee hoop ik de
referentiepunt te leggen voor mensen die beginnen met Continuous Delivery. Verder zal ik
uitleggen wat het precies inhoud, welke soorten tools er zijn en hoe je een Continuous
Delivery server opzet.
HOWEST | 2015-2016
|4|
CONTINUOUS DELIVERY - DATEX2 – C#
SERGIY SKIRIDOV
Verklarende woordenlijst
Builden, compileren:
De code vertalen van een hogere programmeertaal (zoals C#, Java) naar een lagere
programmeertaal (zoals Assembly, machinecode).
Change advisory board:
Wijzigingscommissie, verantwoordelijk voor het plannen en beoordelen van alle wijzigingen.
Command-line-interface (CLI):
Een vorm van interactie met een programma waarbij de gebruiker commando’s uitvoert op
het programma via de Command-Line-Interface
Committen, pushen, mergen:
Een reeks van veranderingen permanent maken. Toevoegen aan de trunk.
Dependency:
Binnen software development wordt met dependency bedoeld: een object, file of een library
waar de software afhankelijk van is.
Hosten:
Een applicatie of een website op een server plaatsen en deze toegankelijk maken voor
gebruikers.
Reposirory:
Een opslagplaats voor pakketten van software, pakketbron, softwarebron.
Manifest:
Een beknopte puntsgewijze weergave van de standpunten van een thema of een persoon.
Releasen, deployen:
De software verplaatsen naar de productieomgeving.
Trunk, mainline, master branch:
Een hoofd tak (versie) van een VCS.
Version Control System (VCS):
Een applicatie dat de versies van de software beheert.
HOWEST | 2015-2016
|5|
CONTINUOUS DELIVERY - DATEX2 – C#
SERGIY SKIRIDOV
Inhoudstafel
Woord vooraf ............................................................................................................................. 4
Verklarende woordenlijst ........................................................................................................... 5
Continuous Delivery ................................................................................................................... 8
Inleiding .................................................................................................................................. 9
Agile Software Development ............................................................................................... 10
Continuous Delivery ............................................................................................................. 10
Deployment Pipeline ............................................................................................................ 12
Continuous Delivery, Continuous Deployment, Continuous Integration ........................... 12
Hoe werken Continuous Integration en Continuous Delivery? ........................................... 13
Opmerking ........................................................................................................................ 14
Waarom Continuous Delivery? ............................................................................................ 15
Fouten worden sneller opgemerkt en dus sneller opgelost ............................................ 15
Snelle feedback voor een goed product .......................................................................... 15
Besparing op tijd én geld .................................................................................................. 16
Uitdagingen .......................................................................................................................... 16
Continuous Delivery servers .................................................................................................... 16
Jenkins .................................................................................................................................. 17
System requirements ....................................................................................................... 17
Go CD .................................................................................................................................... 17
System requirements ....................................................................................................... 18
Bamboo ................................................................................................................................ 19
System requirements ....................................................................................................... 20
Spinnaker .............................................................................................................................. 20
System requirements ....................................................................................................... 20
Vergelijking ........................................................................................................................... 21
Besluit ................................................................................................................................... 21
Technisch .................................................................................................................................. 22
Het proces ............................................................................................................................ 23
Builden.................................................................................................................................. 23
Testen ................................................................................................................................... 24
HOWEST | 2015-2016
|6|
CONTINUOUS DELIVERY - DATEX2 – C#
SERGIY SKIRIDOV
Unit Tests.......................................................................................................................... 24
Integration tests ............................................................................................................... 25
System tests ..................................................................................................................... 25
Acceptance tests .............................................................................................................. 25
Deployen .............................................................................................................................. 25
Docker .............................................................................................................................. 25
Octopus Deploy ................................................................................................................ 27
MidVision RapidDeploy .................................................................................................... 29
Besluit ................................................................................................................................... 29
Voorbeeld set-up ...................................................................................................................... 30
Set-up Jenkins....................................................................................................................... 31
Installatie .......................................................................................................................... 31
Overzicht .......................................................................................................................... 32
Nieuwe project ................................................................................................................. 33
Version Control System .................................................................................................... 33
Builden.............................................................................................................................. 35
Testen ............................................................................................................................... 35
Deployen .......................................................................................................................... 36
Plug-ins ............................................................................................................................. 36
Voorbeeld flow ..................................................................................................................... 37
Besluit ................................................................................................................................... 37
Bronnen .................................................................................................................................... 38
Bronnen ................................................................................................................................ 38
Figuren.................................................................................................................................. 39
HOWEST | 2015-2016
|7|
CONTINUOUS DELIVERY - DATEX2 – C#
SERGIY SKIRIDOV
Continuous
Delivery
HOWEST | 2015-2016
|8|
CONTINUOUS DELIVERY - DATEX2 – C#
SERGIY SKIRIDOV
Inleiding
Tot voor kort werd de waterval methode (ook de traditionele methode genoemd) de meest
gebruikte methode voor het ontwikkelen van software. Tijdens deze proces loopt het project
door een aantal fases. De belangrijkste fases houden in: analyse, ontwerp, bouw, test en
productie. De volgende fase wordt pas gestart als de huidige fase volledig afgewerkt is. Zo’n
fase kan soms weken tot maanden duren.
Figuur 1 Flow van de waterval methode (http://xbsoftware.com/wp-content/uploads/2014/10/software-development-lifecycle.png)
Dit is de eerste methode dat werd geïntroduceerd en is eenvoudig te verstaan. Dit is ook een
eenvoudige methode om mee te werken als het om kleinere projecten gaat. Het kan echter
snel mis gaan bij grote en complexe projecten.
Tijdens de eerste fase van de ontwikkeling van de software wordt zeer uitbundig overlegd
met de klant over hoe zijn product er moet uit zien en wat het moet inhouden. Daarna zien
de ontwikkelaars de klant een lange tijd niet meer. Dit op zicht is
You can't just ask
vaak al een probleem, omdat klanten zich vaak bedenken en
customers what they
nieuwe ideeën krijgen. Indien dit tijdens een latere fase
want and then try to give
voorkomt, moet de team terug naar de eerste fase keren. Hierna
that to them. By the time
moeten ze de fases terug vanaf begin doorlopen. Hetzelfde geldt
you get it built, they'll
als er een fout ontdekt wordt. Om de oplossing voor die fout te
want something new.
implementeren moet de team terug naar de analyse keren en
- Steve Jobs
aanpassen waardoor het ontwerp kan veranderen. Omdat elke
fase van lange duur is, is terugkeren een dure handeling.
Een andere nadeel bij de waterval methode is dat een werkende stuk software pas laat in
het proces ontstaat. Hierdoor duurt het lang voor dat de team de eerste feedback krijgt. Het
is niet ongewoon dat een team maandenlang aan een overbodige of slechte feature werken
HOWEST | 2015-2016
|9|
CONTINUOUS DELIVERY - DATEX2 – C#
SERGIY SKIRIDOV
omdat ze geen feedback krijgen. Het is ook zeer moeilijk om de tijd en de kosten van het
project in te schatten. En er ontstaan vaak problemen bij het verplaatsen van software,
omdat de computer van programmeurs andere configuratie heeft dan de computer van de
testers en productie.
De waterval methode is dus niet de ideale manier van werken voor complexe projecten. Er
zijn ondertussen al andere methoden ontworpen samen met verschillende tools en
technieken die de vlotte ontwikkeling van software proberen te garanderen.
SCRUM is één van de technieken dat de laatste jaren populariteit kreeg, maar werd soms
onjuist toegepast waardoor het weinig of geen verbetering bracht. Indien wel correct
toegepast door het volledige team, biedt deze techniek een verbetering op de
watervalmethode voor complexe projecten. SCRUM is een vorm van agile software
development.
Agile Software Development
De term Agile Software Development wil duiden op een manier van softwareontwikkeling
waarbij de planning mee met het project groeit. Het Engelse woord “agile” betekent:
behendig, lenig. Als de betekenis van de term duidelijk wordt, valt de term zelf eenvoudiger
te begrijpen. Mits het product groeit, veranderen de vereisten voor het project waardoor de
oplossingen wijzigen. Agile Software Development speelt hierop in doordat het
aanpassingen aan de planning aanmoedigt. Het stimuleert het team om flexibel met de
planning om te gaan en de wijzigingen snel te implementeren.
Hoewel er praktijken die onder de naam “agile” vallen, bestaan sinds het begin van de
softwareontwikkeling, valt de geboorte van agile als term en concept terug te brengen tot
het Agile Manifesto. Deze manifest werd in februari van 2001 door 17
softwareontwikkelaars opgesteld en somt 12 principes op. Samengevat geeft de Agile
Manifesto enkele waardes weer.
Individuen en interacties staan boven tools en technieken. Werkende software is
belangrijker dan een goede documentatie. De manifest moedigt de medewerking tussen de
klant en de team aan in plaats van het opstellen van een contract. Snel reageren op de
veranderingen is beter dan een plan volgen. Dit zijn de richtlijnen van het agile manier van
werken.
Continuous Delivery
Bedrijven die doorheen de laatste jaren Agile Development - net als SCRUM - adopteerden,
zagen hun aantal releases verhogen. Hieruit zijn Continuous Delivery en DevOps ontstaan.
DevOps is kort samengevat het idee en de implementatie van de samenwerking van de
developers en operations team. Continuous Delivery maakt gebruik van DevOps om kwaliteit
HOWEST | 2015-2016
|10|
CONTINUOUS DELIVERY - DATEX2 – C#
SERGIY SKIRIDOV
van het product te garanderen. Continuous Delivery valt onder de term Agile Software
Development en houdt het volgende in:
-
Iedereen in de developers team moet op zijn minst één keer per dag zijn code
committen
De software is klaar om gereleased te worden doorheen zijn levenscyclus
De volledige team moet de prioriteit stellen om de software releasable te houden
boven het maken van nieuwe features
Iedereen moet in staat zijn om snel feedback te krijgen van hun nieuwe feature
na het committen
Continuous Delivery wordt bereikt als de software continu geïntegreerd wordt bij de trunk.
Tijdens de integratie wordt de nieuwe software gebuild en door verschillende tests
ondergaan. Verder wordt de software gedeployed naar een omgeving gelijkaardig aan
productie. Dit wordt mogelijk gemaakt met de Deployment Pipelines.
Figuur 2 Deployment Pipeline (http://blog.xebialabs.com/wp-content/uploads/2016/02/continuous-deploymentpipeline.png)
HOWEST | 2015-2016
|11|
CONTINUOUS DELIVERY - DATEX2 – C#
SERGIY SKIRIDOV
Deployment Pipeline
Een van de uitdagingen van Continuous Delivery is het snel verkrijgen van feedback. Dit kan
enkel als de software een reeks stappen doorloopt die de code op verschillende manieren
testen. Hier komen de Deployment Pipelines ter sprake. Zo’n pipeline is het proces, een
reeks van stappen, die de code in de mainline builden, testen en releasen tot bij de
gebruiker. Om de tijd tot release zo min mogelijk te houden, wordt de Deployment Pipeline
best geautomatiseerd en geparallelliseerd waar mogelijk.
Figuur 3 Parallelle flow van een Deployment Pipeline (https://www.go.cd/images/home-image1.png)
Een Deployment Pipeline staat dus centraal binnen Continuous Delivery en verschilt van
project tot project. De tests binnen de pipeline moeten zeer goed opgesteld worden zodat
de team op elk moment met veel vertrouwen de software kan deployen. Het is ook niet de
bedoeling dat de Deployment Pipeline in het begin volledig geconfigureerd wordt. Dat zou
ook heel moeilijk worden, nog moeilijker dan dat het al is. Het is eerder de bedoeling dat de
pipeline meegroeit met het project.
Continuous Delivery, Continuous Deployment,
Continuous Integration
Continuous Delivery wordt vaak verward met Continuous Deployment en Continuous
Integration. Zoals hierboven werd besproken is Continuous Delivery een techniek waarbij de
programmeurs in kleine stukken coderen en committen. Elke commit is dan een kandidaat
voor productie. Of het naar productie gedeployed wordt, kan over beslist worden maar de
mogelijkheid moet er zijn. Met Continuous Deployment daarentegen wordt bedoeld dat elke
gepushte stuk effectief gereleased wordt.
Dan is er nog Continuous Integration. Met Continuous Integration wordt bedoeld dat de
developers meerdere keren per dag/week de veranderingen mergen met de mainline.
Continuous Integration tools nemen ook de taak op zich om de commits automatisch te
builden en te testen.
HOWEST | 2015-2016
|12|
CONTINUOUS DELIVERY - DATEX2 – C#
SERGIY SKIRIDOV
Om de relatie tussen de drie termen beter te snappen kun je stellen dat Continuous
Integration een onderdeel van Continuous Delivery en Deployment is. Continuous Delivery
en Deployment nemen de draad op waar Continuous Integration gestopt is. Namelijk
wanneer de code gebuild en getest werd, zorgen Continuous Delivery en Deployment dat de
build ook al dan niet automatisch gereleased wordt.
Hoe werken Continuous Integration en Continuous Delivery?
Figuur 4 Flow van een Continuous Integration Server (http://www.pepgotesting.com/wp-content/uploads/2015/02/CI.png)
De werking van Continuous Integration (zie boven) is vrij simpel. De developers werken aan
nieuwe features van het programma. Iemand is klaar met zijn stuk en pusht zijn of haar
veranderingen naar de mainline. De Continuous Integration server wordt automatisch
verwittigd of polst regelmatig naar de veranderingen. Bij elke push buildt en test de server
de nieuwe code. De resultaten worden bijgehouden en de team wordt verwittigd als de
server klaar is.
Continuous Delivery (zie onder) gaat een stap verder. Eens de tests gedaan zijn en indien
gewenst succesvol zijn, kunnen de nieuwe features gedeployed worden naar de productie
omgeving.
HOWEST | 2015-2016
|13|
CONTINUOUS DELIVERY - DATEX2 – C#
SERGIY SKIRIDOV
Figuur 5 Flow van een Continuous Delivery server
(https://upload.wikimedia.org/wikipedia/commons/thumb/c/c3/Continuous_Delivery_process_diagram.svg/2000pxContinuous_Delivery_process_diagram.svg.png)
Opmerking
Continuous Integration en Delivery servers hebben geen ingebouwde of bijgeleverde build,
test en deployment tools. Het is dus noodzakelijk om de nodige tools lokaal op de server
geïnstalleerd te hebben. Door middel van de Command-Line-Interfaces van de tools kan de
Continuous Delivery server verschillende taken uitvoeren. De server kan bijvoorbeeld
MSBuild.exe gebruiken om een C# project te builden. Daarna kan de server de CLI van NUnit
aansturen om de unit tests uit te voeren en de resultaten opslaan als een xml-bestand.
Standaard kunnen deze servers ook scripts of batch files uitvoeren om zo externe zaken te
besturen of op te roepen.
Continuous Integration en Delivery servers builden en testen dus niets zelf. Zij coördineren
eerder andere tools om de stroom van de pipeline te garanderen.
Sommige servers werken samen met agents (zoals Go CD en Bamboo bijvoorbeeld). In zo’n
geval coördineert de server de agents die dan de taken uitvoeren met lokale CLI’s.
Continuous Delivery server Bamboo kan zelfs het werk splitsen tussen de agents en de
server. Zo kan een agent die een bepaalde tool niet beschikt, gebruik maken van de tool op
de server of een andere agent.
HOWEST | 2015-2016
|14|
CONTINUOUS DELIVERY - DATEX2 – C#
SERGIY SKIRIDOV
Waarom Continuous Delivery?
Nieuwe methodes worden steeds ontworpen om de huidige manieren van werken te
verbeteren. Als je bijvoorbeeld naar de waterval methode kijkt, merk je zijn gebreken snel
op. Er is dus plaats voor verbetering. Bedrijven die Continuous Delivery model correct
implementeren als hun ontwikkelingsproces, zien een tal van voordelen.
Fouten worden sneller opgemerkt en dus sneller opgelost
Dankzij de Development Pipeline ondergaat elke verandering een reeks van tests. Indien de
tests grondig ontworpen zijn en de pipeline optimaal geparallelliseerd is, weet de team na
enkele minuten of de feature correct functioneert in de productie omgeving. Dit is ook het
enige moment dat het product waarde oplevert, in de productie.
Ingeval er toch een fout opduikt, wordt het zoeken ernaar veel sneller en makkelijker
doordat de veranderingen in kleine delen gesplitst worden. Dus als het programma crasht,
kan de fout maar in de laatste kleine stuk code dat werd toegevoegd zitten. In tegenstelling
tot de waterval methode waarbij een verandering soms tot duizenden lijnen code kan
bevatten, duurt het lang voor dat de fout ontdekt is. Dan is er nog een grote kans dat het
werk van iemand anders overschreven werd, wat tot meer problemen zorgt. Bij Continuous
Delivery ligt die kans veel lager, omdat de veranderingen frequent in kleine stukken
gebeuren.
Snelle feedback voor een goed product
Omdat elke nieuwe feature, bugfix of een andere verandering in het programma na enkele
momenten al in de productie komen, is er al meteen kans op feedback. Met deze snelle
feedback kunnen developers echt een product naar wensen maken. Moest het gebeuren dat
de developers van het pad afdwalen en een verkeerde of overbodige code schrijven, dan kan
dit dezelfde dag nog recht gesteld worden. Het wordt ook zeer gemakkelijk om zelfs tijdens
de constructie het programma aan te passen of uit te breiden. Handig als de klant zich
bedenkt of nieuwe ideeën krijgt.
Het is dus noodzakelijk dat de klant geëngageerd wordt met de ontwikkeling van zijn
product. De klant kan zo dagelijks het eindproduct, de productie omgeving, zien groeien.
Wanneer dit nodig is, kan hij ingrijpen om toch een product te krijgen dat hij echt wil.
HOWEST | 2015-2016
|15|
CONTINUOUS DELIVERY - DATEX2 – C#
SERGIY SKIRIDOV
Besparing op tijd én geld
Misschien de belangrijkste punt voor
de project managers is dat Continuous
Delivery geld en tijd uitspaart. Door de
hierboven vermelde redenen krijgen
de developers meer tijd om te werken
aan een product dat waarde opbrengt.
Wat op zijn beurt geld uitspaart,
aangezien de werkuren dalen.
Verder wordt het duidelijk na het
opstellen van de Deployment Pipeline
waar de pijnpunten in het programma
liggen. Hiermee kan daar de focus op
gelegd worden, en dus de kwaliteit van de software stijgt.
Uitdagingen
Hoewel de voordelen van Continuous Delivery sterk doorwegen heeft de implementatie
ervan toch wat uitdagingen. De grootste uitdaging ligt waarschijnlijk wel op de
organisatorische vlak. Aangezien het ontwikkelingsproces verschillende afdelingen betrekt
die soms tegengestelde doelen hebben. Bijvoorbeeld als de ene afdeling administrator
rechten nodig heeft maar een andere afdeling die beheert. Hiervoor moeten de leiders de
structuur van de afdelingen aanpassen om de barrières tussen de afdelingen af te breken en
communicatie daartussen aan te moedigen.
Een andere uitdaging is dat enkele processen van de traditionele methode Continuous
Delivery verhinderen. Bijvoorbeeld als een feature klaar is, moet deze vaak de Change
Advisory Board passeren. Dit kan soms een week lang duren. Als het maken van de feature
maar 1 of 2 dagen duurt, is de bijkomende tijd veel te lang. Deze processen moeten
gevonden worden en naar alternatieven gezocht.
Continuous Delivery servers
Er zijn tal van Continuous Delivery tools op de markt. Ze bestaan voor alle omgevingen, talen
en processen. Zowel open-source als betalend. Hier zullen er vier besproken worden die
mooie kandidaten vormen voor het bedrijf Flow NV alsook die de onderzoeksvraag kunnen
beantwoorden (uitdrukkelijk: servers die verschillende programmeertalen kunnen
verwerken).
HOWEST | 2015-2016
|16|
CONTINUOUS DELIVERY - DATEX2 – C#
SERGIY SKIRIDOV
Jenkins
Jenkins is een zeer populaire open-source cross-platform Continuous Integration server,
geschreven in Java. Deze is zeer gemakkelijk te installeren en eenvoudig te beheren. De
standaard mogelijkheden zijn vrij beperkt, maar dankzij de uitbreidbare aard van Jenkins kun
je tal van plug-ins installeren om alle mogelijke situaties optimaal te
verwerken. Er bestaan zo plug-ins om virtueel alle VCS’s en build tools
te ondersteunen. Alsook zijn er verschillende plug-ins om van Jenkins
een volledige Continuous Delivery/Deployment server te maken.
Het design van het platform is wat ouderwets, maar het is
eenvoudig te bedienen. Met behulp van enkele plug-ins wordt het
zelfs nog makkelijker en overzichtelijker. De meeste opties en input
velden zijn zelf verklarend. Indien er toch twijfels zijn, zijn er helpvelden beschikbaar doorheen de platform. Een andere meerwaarde aan
Jenkins is dat het een grote open community heeft. De meeste problemen zijn al bij iemand
voorgekomen en is er een oplossing beschikbaar op het internet.
Zoals een goede Continuous Delivery server zou moeten zijn, is Jenkins met een plug-in in
staat om de jobs in de pipeline parallel uit te voeren. Jenkins is zeker een goede keuze voor
zowel kleine als grote bedrijven.
System requirements
Jenkins draait op Java7 of hoger, maar Java8 is aangeraden. De server verwacht dat er
genoeg RAM ter beschikking staat, hoewel in begin 1Gb ruimschoots voldoende is. Voor de
rest worden er geen extra benodigdheden vermeld.
Go CD
De werknemers van Thoughtworks, de makers van Go CD (Go Continuous Delivery), werken
al sinds begin 2000 met de technieken en tools van Continuous Integration. Met hun
jarenlange ervaring hebben ze dan zelf een Continuous Delivery server gemaakt dat aan hun
noden voldoet. Een Continuous Delivery server waar dat de pipelines centraal staan. Go CD
is gemaakt om de pipelines snel en eenvoudig te creëren om dan een duidelijke overzicht te
krijgen van de flow van de pipeline.
HOWEST | 2015-2016
|17|
CONTINUOUS DELIVERY - DATEX2 – C#
SERGIY SKIRIDOV
Native ondersteunt Go CD server Ant, Nant en Rake build tools. Het is natuurlijk ook
mogelijk om een lokale build tool gebruiken zoals Maven of MSBuild. Er zijn ook een 40 tal
Figuur 6 Flow van de Deployment Pipeline in Go CD (http://arojgeorge.ghost.io/content/images/2014/Aug/Pipelinedependency.png)
plug-ins beschikbaar om de pipeline meer mogelijkheden te bieden. Dit op vlak van builden,
testen, deployen of meldingen weergeven.
Wat Go CD onderscheidt van zijn concurrenten is dat het zeer sterk is in het UI en eenvoudig
qua gebruik. Go CD server is zeer aantrekkelijk en duidelijk om mee te werken. Het overzicht
van de deployment pipeline wordt grafisch uitgebeeld, waardoor je de flow van complexe
pipelines moeiteloos kunt volgen.
Zoals eerder vermeld werd, werkt Go CD met een server en één of meerdere agents
(clients). De server is de coördinator van het hele Deployment Pipeline. De agents voeren
dan het echte werk uit zoals het builden en testen van de code. In deze geval moeten de
agents over de noodzakelijke tools beschikken, en niet de server.
System requirements
Net als Jenkins heeft Go CD Java7 nodig. Qua hardware hangt natuurlijk veel af van het
aantal pipelines en agents Go CD moet ondersteunen. Thoughtworks raadt het volgende
aan: minimum van 1Gb RAM, 2 CPU cores van 2GHz en op zijn minst 1Gb aan geheugen (om
mee te beginnen).
Thoughtworks raadt ook zeer sterk aan om de Go server op een aparte partitie te draaien.
Aangezien de volume snel vol kan geraken en de server zich dan onvoorspelbaar zal
gedragen.
HOWEST | 2015-2016
|18|
CONTINUOUS DELIVERY - DATEX2 – C#
SERGIY SKIRIDOV
Bamboo
Wat Bamboo zo interessant maakt is het feit dat
deze server hand in hand werkt met o.a. Bitbucket,
Jira platform en HipChat Atlassian. Deze applicaties
zijn namelijk gemaakt door hetzelfde bedrijf:
Atlassian. Aangezien Flow NV al met Confluence en
andere Atlassian producten werkt, is Bamboo zeker
een potentiële keuze.
Eens Bamboo volledig geïnstalleerd en draaiend is,
werkt hij zoals de andere Continuous Delivery
servers. De deployment Pipeline wordt opgesteld
met taken zoals builden van de code, unit tests
uitvoeren en resultaten opslaan en/of deployen van
het gebuilde code. Specifiek gaat het om taken als
Grunt, MSBuild, JUnit, Maven, Docker alsook enkele
andere. Natuurlijk is het mogelijk om andere externe
applicatie of tools aansturen met een script of batch
file. Net als Jenkins en Go CD is Bamboo uitbreidbaar
met plug-ins voor extra functionaliteit. Maar heeft in
tegenstelling tot Go CD meer plug-ins ter
beschikking.
Figuur 7 Verschillende software van Atlassian
(http://www.r3d.com/wpcontent/uploads/2014/11/ExpertsAtlassian2.png)
De werking en het design van Bamboo is misschien wel
professioneler dan die van Jenkins, maar het is dan ook moeilijker om de Deployment
Pipeline op te stellen. Enkele opties die beschikbaar gesteld worden zijn specifiek voor
sommige situaties en kunnen een beginnende gebruiker verwarren. Dit zal wel niet het geval
zijn binnen professionele bedrijven waar de ingenieurs de structuur van het bedrijf
binnenste buiten kennen. Hierdoor kunnen zij de pipeline perfect optimaliseren binnen het
structuur van het bedrijf.
In tegenstelling tot de twee Continuous Delivery servers die hiervoor werden besproken, is
Bamboo niet open-source. Er hangt een prijskaartje aan vast van minstens $800 voor een
server on-premise. Er is wel een instap optie beschikbaar van $10 voor zeer kleine teams.
Goed voor 10 jobs. Dit komt overeen met een 5tal projecten. Bamboo biedt ook de server
aan in de cloud. Bamboo server draait dan op Amazon cloud, waardoor je ook over een
Amazon account moet beschikken. Hierdoor moet je dan maandelijks betalen voor zowel de
Bamboo server als voor de Amazon account.
Bamboo biedt ook de mogelijkheid aan om Jenkins snel te ‘upgraden’ naar Bamboo.
HOWEST | 2015-2016
|19|
CONTINUOUS DELIVERY - DATEX2 – C#
SERGIY SKIRIDOV
System requirements
Net als de vorige twee Continuous Delivery servers is Bamboo een Java applicatie. De
volledige installatie van Java 1.8 JDK is daarom verplicht. Verder wordt er aangeraden om op
zijn minst 4 cores CPU te gebruiken met minstens 4Gb RAM.
Spinnaker
Net als Thoughtworks heeft de team van Netflix een eigen Continuous Delivery server
gemaakt. Deze is nu ook open-source en noemt Spinnaker. Voorlopig is Spinnaker een
minder interessante keuze, want de 3 omgevingen dat het ondersteunt zijn: Amazon Web
Services, Google Cloud Platform en Pivotal Web Services. Flow maakt momenteel gebruik
van Microsoft Azure en het zou een pluspunt zijn moest Flow daar ook gebruik van kunnen
maken. Daarom staat Spinnaker hier vermeld, MS Azure ondersteuning is in de maak. Het is
wel mogelijk om Spinnaker lokaal op een Linux machine te installeren. Dit is niet handig voor
.NET projecten.
Ondanks Spinnaker momenteel niet de beste keuze voor Flow is, wordt het toch even
besproken. Spinnaker werkt nauw samen met Jenkins. Het kan dus dezelfde taken uitvoeren
als een Jenkins server. Verder werkt Spinnaker gelijkaardig als de andere Continuous
Delivery servers en gebruikt dezelfde tools en technieken als andere besproken servers.
Spinnaker is een pak moeilijker om te configureren, geven ze zelf toe. Spinnaker linkt
namelijk allerlei processen op een
personaliseerbare manier. Dit brengt dan
zijn moeilijkheidsgraad met zich mee. Er
zijn wel handleidingen beschikbaar om de
installatie en de set-up van Spinnaker zo
goed mogelijk op te stellen.
System requirements
Spinnaker focust zich vooral op het
hosten in de cloud omgeving. In die
Figuur 8 Logo Spinnaker (https://blog.pivotal.io/wpsituatie hoeven de gebruikers zich geen
content/uploads/2015/11/sfeatured-spinnaker-alt.png)
zorgen maken om de onderliggende
hardware. Indien een bedrijf Spinnaker
toch lokaal wil draaien, kan het. Er worden wel geen hardware specificaties voorzien.
HOWEST | 2015-2016
|20|
CONTINUOUS DELIVERY - DATEX2 – C#
SERGIY SKIRIDOV
Vergelijking
Jenkins
Open-source
Go CD
Thoughtworks
Bamboo
Atlassian
Spinnaker
Netflix
Ja
Java
Ja
Java
Nee
Java,
Bamboo cloud
Ja
AWS, GCP, PWS
(MS Azure)
Alle
Alle
Alle
Alle
Alle
Alle
Alle
Alle
CPU (minimum)
2 cores
2 cores
4 cores
n.v.t.
RAM (minimum)
1Gb
1Gb
4Gb
n.v.t.
Bedrijf
Open-source
Omgeving
VCS’s
Talen
Besluit
Het is moeilijk te zeggen dat de ene server beter is dan de andere. Ze hebben allemaal sterke
punten. Qua werking is hun basis hetzelfde. Een gebruiker kan eenvoudig zijn code laten
builden, testen en deployen op alle servers. Voor beginnende bedrijven is er geen foute
keuze hier. De gebruiker moet wel in acht nemen dat Bamboo niet open-source is en dat er
dus een prijskaartje aan hangt. Deze prijskaart wordt groter naarmate de server meer
remote-agents moet ondersteunen. Zoals de naam zelf zegt, is zo’n remote-agent een client
dat op afstand werkt, niet lokaal op het netwerk.
Jenkins, Go CD en Spinnaker zijn wel open-source en dus ook gratis om professioneel te
gebruiken. Wat Jenkins onderscheidt van de rest is dat het een grote en actieve community
heeft tot op vandaag. Deze mensen hebben ondertussen al voor vrijwel alles een plug-in
geschreven. Hoewel Go CD ook over enkele plug-ins beschikt, is de lijst minder uitgebreid
dan bij Jenkins. Go CD biedt wel ondersteuning voor bedrijven aan voor minstens $5000 per
jaar.
Spinnaker is het minst gedocumenteerde product van de vier keuzes. Samen met Bamboo is
Spinnaker in staat om te draaien in de cloud. Zo hoeft het bedrijf geen rekening houden met
hun hardware.
HOWEST | 2015-2016
|21|
CONTINUOUS DELIVERY - DATEX2 – C#
SERGIY SKIRIDOV
Technisch
HOWEST | 2015-2016
|22|
CONTINUOUS DELIVERY - DATEX2 – C#
SERGIY SKIRIDOV
Het proces
De procedure van de Development Pipeline binnen Continuous Delivery is altijd hetzelfde.
De code wordt gebuild, daarna worden de tests uitgevoerd. Eens de vorige stappen
succesvol zijn, brengt een gekozen applicatie de software tot in de productie. Hoewel het
ontleedde proces hetzelfde is, verschillen de concrete stappen per project. Zo kan een
project bestaan uit verschillende services waarbij de services in verschillende talen
geprogrammeerd zijn. Sommige services hebben bepaalde tests die ze moeten doorstaan
terwijl andere services andere soorten tests nodig hebben. Een andere mogelijke scenario is
dat de sub-projecten op verschillende servers worden gehost. De sub-projecten
communiceren dan onderling om de gebruiker een naadloze ervaring te bezorgen.
Dit allemaal is geen enkel probleem voor de Continuous Delivery servers. De vier besproken
servers zijn uitermate personaliseerbaar per project. Ze staan de gebruiker toe om
verschillende startpunten op te richten (voor elk sub-project) alsook om het project op
verschillende momenten op te splitsen om de delen apart en/of parallel te verwerken. Het
deployen is eveneens configureerbaar. De operations team kan een deployment server
gebruiken waar zij het liefst mee werken. De mogelijkheid bestaat zelfs om verschillende
tools te gebruiken om te deployen naar andere omgevingen.
Eén van de redenen waarom bedrijven overstappen naar Continuous Delivery is zodat ze
sneller feedback kunnen krijgen over de nieuwe features in het product. Voordat ze hun
feedback krijgen, moet het proces door een error gestopt zijn of volledig verwerkt zijn. Dit
laatste kan soms uren duren als de pipeline ineffectief gemaakt werd. De duur van het
proces hangt voornamelijk af van de testfase. Het builden en deployen van software mag
niet langer dan een 5tal minuten duren (als er een goede internet connectie is). De rest van
tijd gaat naar de tests. Het is aan de operations team om de pipeline zo ideaal mogelijk op te
zetten zodat het proces snel kan eindigen. Om en bij de tien minuten is ideaal, maar het kan
wat uitlopen ingeval er veel tests zijn die serieel lopen.
Builden
De meeste projecten moeten eerst gebuild (gecompileerd) worden voordat ze uitgevoerd
kunnen worden. Dit geldt bijvoorbeeld voor alle C# en Java programma’s. Tijden het bouwen
van de code worden files zoals DLL’s of JAR’s aangemaakt. Het zijn deze files dat het
programma nodig heeft om op te starten en te draaien. Dit is dus een cruciale stap om de
software uit te brengen en wordt als eerste uitgevoerd.
Zoals eerder vermeld werd, voert de Continuous Delivery server zelf geen taken uit als
builden. Hij coördineert eerder andere tools om het gewenste resultaat te krijgen: de
foutloze software uploaden naar een webserver. Hierdoor maakt de server het mogelijk om
vrijwel alle tools te gebruiken die de code builden. Tools zoals Ant, Maven of Gradle voor
Java en Nant, Cake of MSBuild voor C# komen in aanmerking. Ook andere tools kunnen
HOWEST | 2015-2016
|23|
CONTINUOUS DELIVERY - DATEX2 – C#
SERGIY SKIRIDOV
gebruikt worden, zolang zij aangesproken kunnen worden via een Command-Line-Interface.
De Continuous Servers slaan alle aangemaakte files op en bieden de mogelijkheid om te
interageren met externe repositories. Door deze files in repositories op te slaan, kan de
operations team ze gebruiken voor hun doeleinden.
Testen
Een zeer belangrijke fase binnen de Deployment Pipeline is de testfase. Deze fase moet
ervoor zorgen dat er geen fouten doorslippen naar de productie. Omdat snelheid belangrijk
is, moeten zo veel mogelijk tests geautomatiseerd zijn. In sommige gevallen is het wel
noodzakelijk voor menselijke interactie, maar de situaties worden best vermeden om de
snelheid te garanderen.
Het is zeer belangrijk dat de team de tests goed ontwerpt. Juist omdat er weinig tot geen
menselijke interactie in de testfase voorkomt, moeten de automatische tests het product
grondig evalueren. Deze tests moeten zowel wijd als in detail de software beproeven. Ze
moeten de software op alle mogelijke vlakken proberen crashen. Indien de operations team
aan de kwaliteit van de software na de pipeline twijfelt dan zijn de tests niet diepgaand
genoeg. De bedoeling van deze fase is dat de team snel en zorgeloos de kwaliteit van het
programma kan verzekeren.
Er zijn veel soorten tests en technieken om de software te controleren. Sommige kunnen
geautomatiseerd worden, sommige niet. Ze variëren ook van niveaus waarop en momenten
wanneer ze testen. In het algemeen worden er vier niveaus erkend.
Unit Tests
Unit- of Component Tests verwijzen
naar het testen van specifieke
stukken code. Deze tests controleren
de functionaliteit van een bepaalde
functie. Ze worden door de
developers zelf tijdens de
ontwikkeling van het product
geschreven. Een functie kan ook
meerdere unit tests bevatten om
verschillende scenario’s in acht te
nemen.
Met Unit Tests alleen kan de
functionaliteit van een deel van de
software niet gecontroleerd worden.
Het is echter zo dat unit tests de
HOWEST | 2015-2016
Figuur 9 Unit Tests staan los van de productie code, en verwijzen naar lossen
bouwstenen van het product
(http://martinfowler.com/bliki/images/unitTest/sketch.png)
|24|
CONTINUOUS DELIVERY - DATEX2 – C#
SERGIY SKIRIDOV
bouwstenen van de software los van elkaar controleert.
Integration tests
De volgende logische stap is de bouwstenen samenvoegen om ze als een groep te
inspecteren. Deze stap gebeurt na de Unit Test waarbij hij de geteste modules samen
bundelt en controleert volgens een vooraf gedefinieerde plan. De output van deze fase is
een geïntegreerde systeem dat klaar is voor een System Test.
System tests
Ook bekend als end-to-end tests, is system test een volledige controle van het programma.
In deze stap controleert men of de verschillende functionaliteiten correct werken en of de
vereisten behaald zijn. Zo’n test kan bestaan uit: inloggen, profielpagina aanpassen, een item
toevoegen, bepaalde data uitprinten en uitloggen. Voor deze tests is het niet nodig om de
onderliggende code te begrijpen.
De volgende tests kunnen een deel uitmaken van de system test: GUI test, performance test,
load test, security test, regression test, smoke test etc.
Acceptance tests
Tijdens de Acceptance Test wordt ook gekeken of de vereisten die afgesproken werden
behaald zijn. In tegenstelling tot System Test wordt hier gecontroleerd uit het standpunt van
de gebruiker. Men kijkt of de noden van de gebruiker bevredigd zijn met de software.
Deployen
Omdat de meeste problemen pas ontstaan tussen de ontwikkeling en de productie van de
software, kunnen deze fases veel tijd in beslag nemen. Jez Humble, hoofd consultant van
Thoughtworks, noemde deze laatste stuk “the last mile”. Continuous Delivery streeft ernaar
om deze laatste mijl te automatiseren. Als het volledige proces van na de ontwikkeling tot in
de productie geautomatiseerd is, kan het bedrijf hun software deployen met één klik op de
knop. Dit is dan ook het streefdoel. De bedoeling is dat het deployen van software iets saais
wordt. Het moet een doorsnee taak worden, geen helse taak.
Er zijn natuurlijk enkele applicaties op de markt die exact dit doen. Sommige applicatie
focussen zich op het releasen van software naar een specifieke omgeving. Terwijl andere
neutraal blijven qua doelomgeving, ten koste van gebruiksvriendelijkheid.
Docker
Opgericht door Solomon Hykes in Frankrijk werd Docker gebruikt als een interne project bij
dotCloud. Later, in maart van 2013, werd Docker uitgebracht als een open-source project,
waarna het snel veel populariteit kreeg. In 2015 toonde een analyse aan dat IBM, Google, en
Cisco een van de grootste bijdragers waren voor het populaire open-source project.
Wat doet Docker
Wat doet Docker? Dockers functie bestaat uit het verpakken, runnen en deployen van
software. De reden waarom het zo populair is, is omdat het de software verpakt samen met
HOWEST | 2015-2016
|25|
CONTINUOUS DELIVERY - DATEX2 – C#
SERGIY SKIRIDOV
zijn dependencies. Hierdoor wordt het verplaatsen van de software foutloos. Het maakt niet
meer uit dat de computer van de ontwikkelaar andere configuraties heeft dan de computer
van de tester, de operations team of de manager. Alle configuraties en andere nodige
elementen worden met de software meegeleverd. Docker voert alles perfect uit ongeacht de
omgeving waarin het zich bevindt.
Figuur 10 Verschil in de infrastructuur tussen Virtual Machine (links) en container (rechts)
(http://zdnet4.cbsistatic.com/hub/i/r/2014/10/02/1f130129-49e2-11e4-b6a0d4ae52e95e57/resize/770xauto/2598bf8706f23f291a520c42165e6b1f/docker-vm-container.png)
Een andere voordeel van Docker is dat het zeer licht (en dus ook snel) is. Docker gebruikt
containers om zijn eigen omgeving te maken waarin het zijn software draait. Een container is
vergelijkbaar met een Virtual Machine. Het verschil zit hem in het feit dat een VM een
volledige computer virtualiseert (met al zijn hardware) en de container enkel een
besturingssysteem (zonder alle overbodige onderdelen). Door het gebruikt van containers is
Docker licht genoeg om verschillende instanties naast elkaar te draaien, mogelijk op
verschillende servers.
Hoe werkt Docker
Docker is een Linux applicatie, waardoor het niet meteen toegankelijk is voor Windows. Er is
ondertussen hier een omweg voor gemaakt. In tegenstelling tot Linux waarop Docker
rechtstreeks kan worden geïnstalleerd, moet men eerst VirtualBox installeren op Windows
en daarin een Docker Daemon aanmaken om Docker te runnen. De effectieve container
waarin de applicatie leeft wordt aangemaakt via een image. Een image bevat een versie van
de applicatie met al zijn configuraties en dependencies. Een Docker image wordt op zijn
beurt aangemaakt door middel van een Dockerfile. Het is deze image dat de team onderling
kan doorgeven om de software te gebruiken. Docker voorziet ook van een repository voor
HOWEST | 2015-2016
|26|
CONTINUOUS DELIVERY - DATEX2 – C#
SERGIY SKIRIDOV
de Docker images. Met DockerHub kan het bedrijf hun verschillende versies van de software
toegankelijk maken voor publiek. Zo hebben bedrijven producten als Wordpress, Java, Php,
Tomcat en veel andere projecten beschikbaar gemaakt voor publiek.
Dockerfile
Een Dockerfile is een gewone tekstbestand met de commando’s voor het creëren van een
Docker image. De meest gebruikte commando’s zijn “FROM” (om de basis over te erven van
een andere Dockerfile), “COPY” (om de bestanden van de applicatie te kopiëren naar de
image) en “RUN” (om de Linux commando’s uit te voeren zoals apt-get).
Docker en .NET
Momenteel is het niet mogelijk om gewone .NET applicaties te runnen in Docker. Docker
draait op Linux en .NET en Linux gaan niet samen. Microsoft brengt daar nu verandering in.
Vanaf ASP.NET5, een open-source versie van ASP.NET, is het wel mogelijk om .NET te
draaien op andere omgevingen (Linux en OSX). ASP.NET5 gebruikt ASP.NET Core, een lichte
versie van .NET Framework.
Microsoft werkt nu ook samen met de team van Docker om het product ook native in
Windows te ondersteunen. Dit willen ze doen met Windows Container. Een variant van LXC
Container (Linux Container) of Docker Container, maar native compatibel met Windows.
Windows containers zijn momenteel al beschikbaar mits de gebruiker Windows 10 build
10586 of later gebruikt.
Octopus Deploy
Een andere deployment applicatie dat een mooie kandidaat vormt, is Octopus Deploy.
Microsoft heeft Octopus Deploy gemaakt voor het vereenvoudigen van releasen van
ASP.NET applicaties, Windows services en databases. Octopus Deploy is niet open-source en
focust zich op de Windows omgeving. Deze deployment software werkt enkel met ingepakte
bestanden. Het begon enkel met NuGet pakketten, maar vanaf versie 3.3 werd ook
compatibiliteit voor zip en tar files voorzien.
Deze applicatie is eenvoudig te gebruiken. Het werkt met een client-server model waarbij de
client, genaamd Octopus Tentacle, de doelomgeving is. Na de installatie van de server en de
client moet de gebruiker de connectie tussen de twee services leggen (dit is heel eenvoudig
met behulp van een goede documentatie van Microsoft) en een project definiëren. Eens dit
gedaan is, gebeurt het deployen met één druk op de knop.
HOWEST | 2015-2016
|27|
CONTINUOUS DELIVERY - DATEX2 – C#
SERGIY SKIRIDOV
Figuur 11 De plaats waar Octopus Deploy werkt binnen de Deployment Pipeline van een Continuous Delivery server
(http://docs.octopusdeploy.com/download/attachments/3048178/howOctopusFitsIn.PNG?version=1&modificationDat
e=1386847875634&api=v2)
Microsoft heeft ook een Command-Line-Interface voorzien voor het gebruik van Octopus
Deploy. Dit zorgt ervoor dat Octopus Deploy met elke Continuous Delivery server kan
werken. Of het nu Jenkins of Bamboo is, de operations team creëert gewoon een plan om
het product van het bedrijf te verpakken in een NuGet package, waarna zij deze pakket via
Octopus CLI versturen naar een Octopus Tentacle.
Natuurlijk is er ook de mogelijkheid om de software te deployen naar de cloud platform van
Microsoft, Azure.
NuGet
NuGet is een gratis open-source package manager gemaakt voor Microsoft omgeving. Sinds
zijn start in 2010 is NuGet gegroeid naar een centrale systeem voor .NET tools en services.
Vanaf Visual Studio 2012 wordt NuGet standaard meegeleverd met de
ontwikkelingsapplicatie. Met deze package manager bundelt de gebruiker alle nodige files
om zijn applicatie, service of tool te gebruiken. Vervolgens wordt het zeer eenvoudig om
deze package via internet te versturen.
Opmerking: officiële NuGet repository ondersteunt geen packages verpakt met de NuGet
van Octopus Deploy zelf. De NuGet van Octopus Deploy maakt een andere infrastructuur
binnen de pakket, waardoor het niet bruikbaar is door de NuGet repository.
Prijs Octopus Deploy
Octopus Deploy is geen open-source software, Microsoft verkoopt deze applicatie voor een
aardig prijsje. Beginnend bij een gratis versie voor vijf projecten, gaande tot $700 voor
twintig projecten en tot $5000 voor geen limiet op projecten. Voor grote bedrijven biedt
HOWEST | 2015-2016
|28|
CONTINUOUS DELIVERY - DATEX2 – C#
SERGIY SKIRIDOV
Microsoft een optie om verschillende Octopus Deploy servers te draaien binnen het bedrijf.
De prijs bedraagt dan minstens $20.000.
MidVision RapidDeploy
Een meer cross-platform optie is RapidDeploy. RapidDeploy, gemaakt door MidVision, werd
geschreven in Java en werkt gelijkaardig aan Octopus Deploy. Om een project te deployen
naar een bepaalde omgeving moet de RapidDeploy server een connectie maken met een
RapidDeploy agent op de juiste server. Als de applicatie in de cloud gehost wordt, kan
RapidDeploy verbinding met Amazon Web Services en Microsoft Azure maken.
RapidDeploy is niet open-source maar is gratis te gebruiken tot 20 projecten. Genoeg om als
een klein bedrijf mee aan de slag te gaan.
Besluit
Tijdens het kiezen van een deployment software moet de team vooral op hun noden letten.
In welke omgeving werd de software geschreven, in welke omgevingen moet het draaien.
Als het bedrijf uitsluitend met Microsoft producten werkt, dan is Octopus Deploy een
aanrader. Moet het product andere omgevingen (als OSX of Linux) ondersteunen dan moet
het bedrijf bezien of Docker geen oplossing biedt. Met RapidDeploy is virtueel alles mogelijk.
Wat Continuous Delivery servers zo interessant maakt is dat de gebruikers hun keuzes
kunnen combineren. Een bedrijf hoeft niet enkel en alleen met Octopus Deploy werken.
Indien een scenario zich voordoet, kan de operations team een mix van twee (of meer)
deployment software gebruiken. Zo kunnen de .NET projecten met Octopus Deploy
gedeployed worden en een javascript toepassing met Docker.
HOWEST | 2015-2016
|29|
CONTINUOUS DELIVERY - DATEX2 – C#
SERGIY SKIRIDOV
Voorbeeld
set-up
HOWEST | 2015-2016
|30|
CONTINUOUS DELIVERY - DATEX2 – C#
SERGIY SKIRIDOV
Het eerste deel van de onderzoeksvraag, “welke Continuous Delivery server past het best
om te werken met verschillende projecten in verschillende talen”, werd al eerder
beantwoord. Er is geen duidelijke winnaar. De keuze moet gebaseerd worden op de taken
dat het bedrijf moet uitvoeren. Heeft het bedrijf al enkele tools waarmee ze werken, zoals
die van Atlassian? Misschien heeft de operations team een voorkeur voor een bepaalde
manier van werken?
Het feit is, de vier besproken Continuous Delivery servers doen de kern van de zaak
hetzelfde. Ze verschillen enkel in details. Bamboo werd gemaakt om samen te werken met
andere applicaties van Atlassian. Thoughtworks heeft Go CD gemaakt met de nadruk op het
configureren van de Deployment Pipeline. Jenkins is meer een allround keuze dankzij een
grote open community.
Verder zal een korte uitleg beschreven zijn over de basis functionaliteit van Jenkins om zo de
flow van een Continuous Delivery beter te begrijpen. Met een goede kennis van de werking
van een Continuous Delivery server is het eenvoudig om de alternatieven te verkennen.
Hiermee kan een gebruiker aan de slag gaan om een keuze te maken dat bij hem het best
past.
Set-up Jenkins
Om de tweede deel van de onderzoeksvraag te beantwoorden, “hoe zet je een Continuous
Delivery het best op voor een C# API project”, wordt hier Jenkins als voorbeeld genomen.
Jenkins heeft een lage drempel voor beginnende gebruikers en is dus een uitstekende keuze
om een korte demo mee voor te stellen.
Installatie
De Jenkins applicatie is vrij te downloaden op hun website “jenkins-ci.org”. Het is een opensource applicatie geschreven in Java. Indien een versie van Java7 of hoger op de computer
geïnstalleerd is, kan de gebruiker Jenkins installeren.
Jenkins biedt de mogelijkheid aan om Jenkins te installeren als een Windows service. Door
het te installeren als een service kan Jenkins mee met Windows opstarten zonder te hoeven
in te loggen. Als Jenkins opgestart is, moet de gebruiker naar de configuratie van Jenkins
gaan, “Beheer Jenkins” (in het hoofdmenu aan de linker kant) en daarna op “Installeer
Jenkins als een service” klikken. Jenkins doet vervolgens de nodige aanpassingen in Windows
en start zicht opnieuw op.
HOWEST | 2015-2016
|31|
CONTINUOUS DELIVERY - DATEX2 – C#
SERGIY SKIRIDOV
Overzicht
HOWEST | 2015-2016
|32|
CONTINUOUS DELIVERY - DATEX2 – C#
SERGIY SKIRIDOV
Op de overzicht pagina staan een aantal nuttige zaken. Linksboven staat het hoofdmenu,
daaronder een wachtrij voor de projecten dat nog uitgevoerd moeten worden. Helemaal
onderaan in de linker kolom staat een lijst van de geregistreerde gebruikers. De rest van de
scherm geeft een overzicht van de aangemaakte projecten weer.
Nieuwe project
Een nieuw project wordt aangemaakt door te klikken op “Nieuwe item” in het hoofdmenu
waarna de gebruiker “Een vrij project” moet kiezen.
De volgende pagina dat de gebruiker krijgt, dient om het project helemaal te configureren.
Hier bepaalt de gebruiker welke Version Control System (VCS) het project gebruikt, welke
stappen het uitvoert in welke volgorde. Hij kan ervoor kiezen dat het project volledig
blokkeert ingeval er een fout opduikt. Hij kan het computergeheugen vrij maken door de
oude processen van het project automatisch te verwijderen of hij kan kiezen om logs bij te
houden.
Indien de gebruiker dit nodig heeft, kan hij een map specifiëren waarin het proces moet
draaien. Dit zijn de meest eenvoudige opties, maar ze kunnen uitgebreid worden met
verschillende plug-ins uit de Jenkins community (wordt verder besproken).
Version Control System
Verder op dezelfde pagina kan de gebruiker het project laten starten vanuit een VCS. Dit zal
meestal het geval zijn voor projecten die nog gebuild moeten worden. Een gebruiker kan
deze stap overslaan als hij een andere Jenkins project ontworpen heeft die zijn applicatie
buildt.
HOWEST | 2015-2016
|33|
CONTINUOUS DELIVERY - DATEX2 – C#
SERGIY SKIRIDOV
Standaard ondersteunt Jenkins CVS en Subversion als VCS. Hier werd een plug-in
geïnstalleerd om Git te mogen gebruiken. Na het selecteren van het VCS moet de gebruiker
het URL van het project opgeven samen met de login gegevens waar Jenkins mee moet
werken. Vervolgens specifieert de gebruiker welke branch Jenkins moet gebruiken en
eventuele extra taken dat Jenkins moet uitvoeren.
De mogelijke opties (zie rechts)
bestaan uit het opruimen van de
werkmap, geavanceerde opties
om de bestanden van het project
te downloaden of selectief zijn
met de bestanden waar Jenkins
mee mag werken.
HOWEST | 2015-2016
|34|
CONTINUOUS DELIVERY - DATEX2 – C#
SERGIY SKIRIDOV
Builden
Verder op de pagina staan de eerste opties voor het bouwen van de applicatie. Om het
netwerk niet te veel te belasten, is het handig om de build te starten wanneer er nieuwe
code gecommit werd. Men kan ook kiezen om dit Jenkins project te starten na het succesvol
beëindigen van een ander Jenkins project, of om periodisch te beginnen.
De eerstvolgende stap is builden. Het kan zelfs heel eenvoudig zijn. Het minimum dat een
gebruiker moet ingeven is het build tool dat Jenkins moet gebruiken alsook het relatieve pad
naar de build file. Voor Visual Studio projecten zijn “.sln” of “.csproj” de build files. De build
tool moet lokaal op de computer staan zodat Jenkins die kan gebruiken.
Veel situatie zullen vereisen om extra parameters mee te geven aan de build tool. In deze
voorbeeld zegt de gebruiker dat het programma als een release versie gebuild wordt. Let
ook op de extra parameter voor OctoPack. Deze tool hoort bij Octopus Deploy en zorgt
ervoor dat tijdens het builden van de applicatie ook een NuGet pakket aangemaakt wordt.
Deze NuGet package gebruikt Octopus Deploy later om te deployen
Testen
Hieronder staat een dropdown list waaruit de gebruiker extra taken kan uitvoeren. Deze lijst
telt standaard een 5tal opties maar met wat plug-ins kan het uitbreiden. Er bestaan namelijk
plug-ins om bijna alles te kunnen realiseren.
In deze voorbeeld voert Jenkins een reeks van batch commando’s uit. Specifiek gaat het om
NUnit (een test tool) die de dll van het Unit Test project test en de resultaten opslaat als een
xml bestand met een dynamische naam.
HOWEST | 2015-2016
|35|
CONTINUOUS DELIVERY - DATEX2 – C#
SERGIY SKIRIDOV
Vervolgens, als laatste stap in deze situatie, duidt de gebruiker de resultaten van de tests
aan. Hiermee kan Jenkins aan de slag om de resultaten weer te geven in een bescheiden
grafiek op de overzicht van het Jenkins project.
Deployen
Omdat de gebruiker zelf wil beslissen wanneer het project gereleased moet worden, moet
het deployment stap in een aparte Jenkins project gedefinieerd worden. In het nieuwe
project slaat de gebruiker de VCS- en buildstap over en voert meteen de batch commando’s
uit voor Octopus Deploy. De NuGet package werd in het vorig project opgeslagen.
Plug-ins
In dit document werd veel gezegd dat Jenkins zeer uitbreidbaar is dankzij de plug-ins. Vele
gebruikers hebben hun noden van Jenkins vervuld door zelf een plug-in te schrijven. Er is dus
praktisch niets dat Jenkins niet kan. Momenteel zijn er meer dan 200 plug-ins beschikbaar.
Als Jenkins toch iets mist, kan ook jij een plug-in schrijven.
Om de plug-ins te beheren, ga naar de configuratie van Jenkins (“Beheer Jenkins”) en klik
daarna op “Beheer plugins”. Op de volgende scherm krijgt de gebruiker een overzicht van
beschikbare plug-ins, geïnstalleerde plug-ins of plug-ins waarvoor er updates beschikbaar
zijn.
HOWEST | 2015-2016
|36|
CONTINUOUS DELIVERY - DATEX2 – C#
SERGIY SKIRIDOV
Voorbeeld flow
Eerst en vooral, is het belangrijk dat de applicatie die gedeployed moet worden een
OctoPack NuGet package installeert. Als de nieuwe feature gecommit wordt kan Jenkins al
dan niet automatisch de code downloaden en ze dan met MSBuild compileren. De compiler
maakt de nodige dll en exe files aan. Dankzij de OctoPack package en één extra commando
voor MSBuild wordt ook een NuGet package gemaakt voor de applicatie.
De test tool, NUnit, gebruikt de dll file(s) van de Unit Test project en genereert een trx file
met de resultaten. Jenkins kan dan met een plug-in de file lezen en in een grafiek
weergeven.
Zodat Octopus Deploy de applicatie kan deployen, stuurt Jenkins de NuGet package uit de
build stap door naar de built-in repository van Octopus Deploy. Zo weet Octopus Deploy
welke package hij moet versturen naar de gekozen server, Microsoft Azure in dit geval.
Besluit
Voor kleine projecten met weinig sub-projecten en maar één webserver is het opzetten van
een Continuous Delivery server zeer eenvoudig. Om de flow van de ontwikkeling proces bij
grote bedrijven volledig te optimaliseren vraagt het meer tijd en moeite. In praktijk zal er
wel een team van specialisten voor deze taak aangeduid worden.
HOWEST | 2015-2016
|37|
CONTINUOUS DELIVERY - DATEX2 – C#
SERGIY SKIRIDOV
Bronnen
Bronnen
Inleiding
https://nl.wikipedia.org/wiki/Watervalmethode
https://en.wikipedia.org/wiki/Waterfall_model
http://istqbexamcertification.com/what-is-waterfall-model-advantages-disadvantages-andwhen-to-use-it/
Agile Software Development
https://nl.wikipedia.org/wiki/Agile-softwareontwikkeling
https://en.wikipedia.org/wiki/Agile_software_development
http://www.seguetech.com/blog/2013/07/05/waterfall-vs-agile-right-developmentmethodology
Continuous Integration, Delivery, Deployment
https://en.wikipedia.org/wiki/Continuous_delivery
https://www.thoughtworks.com/continuous-delivery
https://en.wikipedia.org/wiki/Continuous_integration
http://kief.com/the-conflict-between-continuous-delivery-and-traditional-agile.html
http://martinfowler.com/delivery.html
https://www.youtube.com/watch?v=skLJuksCRTw
https://www.youtube.com/watch?v=ZLBhVEo1OG4
Deployment Pipeline
http://continuousdelivery.com/2010/09/deployment-pipeline-anti-patterns/
Continuous Delivery tools
https://jenkins-ci.org/
http://spinnaker.io/
https://www.go.cd/
https://www.atlassian.com/software/bamboo/
Builden
https://nl.wikipedia.org/wiki/Compiler
https://en.wikipedia.org/wiki/Building_code
Testen
https://en.wikipedia.org/wiki/Software_testing
https://en.wikipedia.org/wiki/Unit_testing
https://en.wikipedia.org/wiki/Integration_testing
https://en.wikipedia.org/wiki/System_testing
HOWEST | 2015-2016
|38|
CONTINUOUS DELIVERY - DATEX2 – C#
SERGIY SKIRIDOV
https://en.wikipedia.org/wiki/Acceptance_testing
http://stackoverflow.com/questions/15944902/system-testing-vs-acceptance-testingdifference-in-test-cases
Deployen
https://www.docker.com/
https://docs.docker.com/
http://help.octopusdeploy.com/discussions/questions/4292-java-applications
https://en.wikipedia.org/wiki/Octopus_Deploy
https://octopus.com/
http://www.midvision.com/product/rapiddeploy
Figuren
Voorblad:
http://derberg.github.io/documentation-continuous-delivery/img/continuous-deliverycycle.jpg
Woord vooraf:
https://image-store.slidesharecdn.com/c1a03458-b5cc-4687-9c05-584f257e2743-large.jpeg
Titelblad, Continuous Delivery:
http://www.omnirms.com/assets/uploads/images/Continuous%20Improvement.png
Pagina 15, Grafiek:
http://www.forexmarkt.be/wp-content/uploads/2015/02/voordelen-forex-handel.png
Pagina 16, Logo Jenkins:
https://blog.rosehosting.com/blog/wp-content/uploads/2014/11/jenkins.png
Titelblad, Technisch
https://lm-shop.s3.amazonaws.com/cache/concept_photo_original/719843a3-d603-4ea4b518-85be555fb289/32d034c8283505061cfac1d0f6b13280.png
HOWEST | 2015-2016
|39|