Continuous Delivery 3.0

Haal meer uit je data

Een introductie tot Data Mining met CRISP-DM

Het belang van data

Data is altijd al een belangrijke factor geweest in de zakenwereld, maar nog nooit was het zo makkelijk om data te verzamelen als tegenwoordig. Giganten zoals Google en Facebook hebben ons geleerd, dat hoe meer data je tot je beschikking hebt, des te beter kan je groeien als bedrijf. Hierbij wordt snel vergeten dat je alleen met pure data niet veel kan zeggen. Het is een heel proces en ook een bepaalde manier van kunst om van je data inzichten te genereren en dat is waar de echte waarde pas tot stand komt. Om je hierbij te helpen werd CRISP-DM bedacht. In het vervolg van dit artikel worden voorbeelden gebruikt binnen het domein van websites en webapplicaties om het proces van CRISP-DM beter te verduidelijken.

 

CRISP-DM

CRISPDM-Extended.png

CRISP-DM staat voor Cross Industry Process for Data Mining en is het standaard proces met betrekking tot het genereren van inzichten uit ruwe data. De complete CRISP-DM methodology bestaat uit meerdere levels van abstractie, maar in dit artikel wordt hoofdzakelijk op de 6 fasen ingegaan. Daarnaast worden de desbetreffende generieke taken besproken om een beter beeld van de fasen te kunnen krijgen. Deze zes fasen zijn als volgt:

 

  1. Business Understanding

  2. Data Understanding

  3. Data Preparation

  4. Modeling

  5. Evaluation

  6. Deployment

 

CRISP-DM gaat uit van een flexibele aanpak, het moet dus altijd mogelijk zijn om van een fase naar een vorige fase te kunnen gaan.

Business Understanding

De eerste fase is een belangrijke fase, die vaak over het hoofd wordt gezien. De focus ligt bij een goed begrip krijgen van de projectdoelstellingen en -vereisten vanuit een zakelijk perspectief. Binnen deze fase hoor je de probleemdefinitie en het voorbereidend plan op te stellen voor je doelstellingen. Zorg er dus voor dat je weet waar je naar op zoek bent en met welke middelen je aan de slag wil gaan om deze doelstelling te bereiken.

Een website met doel te informeren zal een metric, die beschrijft hoe lang een gebruiker op een pagina blijft, interessanter vinden, dan een webwinkel, die meer wil weten over het gedrag voordat een conversie plaatsvindt.

Data Understanding

ai-artificial-intelligence-blur-546819.jpg

In deze fase ga je dieper in op je data, die je van plan bent om te gebruiken. Bekijk goed welke bronnen je ter beschikking hebt en in hoeverre deze bij dragen aan het behalen van je doelstellingen. Het identificeren van kolommen die missende of onbetrouwbare informatie bevatten is cruciaal. Je zult vast moeten leggen in hoeverre deze data nog bruikbaar is of beter genegeerd kan worden. Hier komt nog bij dat bepaalde metrics verschillende definities kunnen hebben afhankelijk van de persoon die deze vraagt.

Zorg er dus voor dat elke metrics een duidelijke definitie heeft en dat deze definitie ook gedeeld wordt met de personen die de data moeten interpreteren of gebruiken.

Een voorbeeld zou de metric sessieduur zijn. Om deze metric goed te kunnen interpreteren is het van belang om te weten wanneer een sessie start en stopt. Definitie één kan zijn: “De sessieduur is gelijk aan de tijd dat men ingelogd is”. Een andere definitie kan als volgt zijn: “Een sessie start bij de eerste interactie van een gebruiker en nadat de gebruiker 15 minuten inactief is geweest zal deze sessie stoppen; De sessieduur is de tijd tussen de eerste en laatste interactie”. Dan stelt zich wel weer de vraag, wat is een interactie? Alleen clicken, of ook scrollen?

Data Preparation

            Als het goed is heb je een goed begrip daarvan hoe je data uit ziet aan de hand van de vorige fase. Iets dat je opgemerkt zou kunnen hebben, is dat de een kolom data bevat die dezelfde elementen soms anders weergeeft. Een andere opmerking zou kunnen zijn, dat de data die je hebt gemeten verschillende eenheden bevat binnen dezelfde kolom of de verkeerde data types. Het is de bedoeling van deze fase om deze kolommen op te schonen, zodat er geen misverstanden zijn en alle daten aan dezelfde eisen voldoen.

            Stel je voor jou website bevat een formulier waar gebruikers in kunnen vullen hoe groot ze zijn. Nu heeft jouw website internationale gebruikers en vullen deze soms in cm, m of feet in. Aan de hand van je gedefinieerde metrics in de vorige fase, zul je deze kolom kloppend moeten maken, zodat elk getal of cm, m of feet is.

Modeling

            In deze fase is het de bedoeling de data zo te transformeren en te modelleren, dat deze klaar is om gevisualiseerd te worden. Afhankelijk van de complexiteit van je vraagstuk zal deze fase voor uitdaging kunnen zorgen. In vele gevallen wil men een trend waar kunnen nemen binnen bepaalde classificaties of groeperingen, waardoor vaak aggregaties toegepast worden.

            Voor dit voorbeeld hebben wij een webshop en het vraagstuk is wat voor invloed de sessieduur heeft op het koopgedrag. Bij deze aanpak groeperen wij de gebruikers per 3 minuten die ze doorbrengen op de website, omdat de gemiddelde sessieduur 8 minuten is. Hierdoor krijgen wij 5 groeperingen met een voldoende aantal gebruikers om er een mening over te vormen. De overigen gebruikers filteren wij weg, gezien deze voor ruis zorgen. Voor elk van deze groep berekenen wij de som van het aantal conversies die ze hebben gepleegd elke dag. Nu kunnen wij deze tabel makkelijk visualiseren om er uiteindelijk een conclusie uit te kunnen halen.

Evaluation

            Dit is de fase, die beslist of de ontdekkingen voldoen aan de criteria. Hierbij wordt terug gekeken naar het gehele process hoe men tot deze statistieken is gekomen. Je vraagt je af of de data die gebruikt werd, compleet en toepasselijk is, men controleert of er geen fouten zijn ontstaan tijdens de data preparation en modeling en als alles klopt kan men doorgaan naar Deployment. Is dit niet het geval, gaat men terug naar de desbetreffende stap gaat vanuit daar weer verder. Een fenomeen dat regelmatig voorkomt, is dat er inzichten waargenomen worden, die voor het desbetreffende partij al eerder heeft waargenomen, dit kan afhankelijk van de situatie handig zijn of betekenen dat je met een nieuw vraagstuk aan de slag moet.

Deployment

Dit is de laatste fase waar men alleen terecht komt als de evaluatie geslaagd is. Activiteiten binnen deze fase is een deployment plan schrijven, kijken hoe men deze inzichten voortdurend kan monitoren & onderhouden en het maken van het Final Report en/of Presentation. Met andere woorden er wordt ervoor gezorgd, dat de inzichten duidelijk weergegeven, goed beschikbaar gesteld en bijgehouden worden, zodat er bedrijfsdoelen of keuzes gevormd kunnen worden.

Het generaliseren van Jenkins Pipelines binnen een complexe omgeving/organisatie.

In een complexe en dynamische omgeving wilt men waar mogelijk, altijd iets generaliseren om de complexiteit te verminderen. In een omgeving waar alle teams CD (Continuous Delivery) enabled moeten zijn, is het dus handig dat nieuw gevormde teams gelijk aan de slag kunnen met Continuous Delivery. In plaats van dat de teams alles opnieuw moeten uitvinden, terwijl dat binnen de organisatie al meerdere keren gedaan is, kan het team gelijk aan de slag met de kennis die vergaard is door de jaren heen binnen de organisatie.

Jenkins Pipelines.png

Een voorbeeld: hoe je nieuwe teams CD enabled inricht.

Door een standaard pipeline te bieden voor de teams, waarmee ze gelijk aan de slag kunnen, richt je CD enabled in. Als het ware creëer je dan een pipeline als product voor deze teams. Door verschillende standaard pipelines aan te bieden is het mogelijk om de complexiteit voor de omgeving te minimaliseren. In deze blog laat ik je zien hoe je hiermee begint en de manier waarop je pipelines implementeert door middel van Jenkinsfiles (Pipeline als code/script).  Met dit blogaritkel geeft Ewan inzicht in één van de oplossingen voor een gegeneraliseerde Jenkins pipeline, maar natuurlijk zijn er nog velen manieren.

 

Stap 1: inventariseer de huidige oplossingen binnen de organisatie

Allereerst, is het van belang om de huidige oplossingen binnen de organisatie te inventariseren, bijvoorbeeld: wat voor tools gebruiken de teams? Hierdoor maak je de variatie tussen de teams en de complexiteit van de organisatie zichtbaar. Vervolgens ga je op basis van deze variatie beslissen, welke tools je in de pipeline gebruikt, en welke teams een andere werkwijze volgen om de standaarden van de organisatie te volgen. De oplossingen die gemaakt zijn binnen de organisaties kun je ook inventariseren. Wie weet komen daar weer hele andere oplossingen uit, die je als gegeneraliseerde/standaard Jenkins pipeline zou kunnen toepassen.  

 

Stap 2: bouwen/verzamelen scripts

Binnen deze stap is het belangrijk om als basis vanuit de volgende denkwijze een gegeneraliseerde Jenkins pipeline te realiseren: zorg er allereest voor dat alles ´Configuration as Code’ is. Iedere Jenkins server, pipeline of job moet als code uitgeschreven staan. Hierdoor voorkom je dat er handmatig beheer nodig is via een UI, wat foutgevoelig kan zijn als de verkeerde mensen het gebruiken. Omdat alles in code is geschreven, komt het regelmatig voor dat je zelf handmatig een script moet schrijven in plaats van een plugin in Jenkins gebruikt, die je via de UI werkend krijgt. Mogelijk moet je voor elke tool die je in de pipeline toepast een script schrijven. Binnen complexe organisaties zijn er vaak al scripts bruikbaar die ergens in een repository staan. Wanneer je deze scripts allemaal gebouwd of verzameld hebt, kan je deze scripts runnen vanuit een job om het overzichtelijk te houden.

 

Stap 3: creëer downstream jobs

In deze stap zorg je ervoor dat je downstream jobs maakt, die een enkele script uitvoeren voor een specifieke tool. Op deze manier is het mogelijk om Jenkinsfiles flexibel te creëren. Het uitvoeren van meerdere downstream jobs achter elkaar vanuit de upstream job, zorgen ervoor dat je gemakkelijk een pipeline maakt door blokjes (downstream jobs) aan elkaar te koppelen. Hierdoor is het heel makkelijk om standaard Jenkinsfiles te maken, omdat dit alleen een kwestie is van aangeven welke blokjes je kiest. Verder zit de implementatie ver weg gestopt voor de teams, waardoor zij met beperkte kennis gemakkelijk aan de slag kunnen. Daarnaast is het voor de teams belangrijk dat zij de juiste parameters meegeven aan de downstream jobs om er voor te zorgen dat de pipeline succesvol wordt afgerond.

Jenkins logo.png

 Stap 4: maak standaard Jenkinsfiles

Zoals eerder beschreven, hoeft de Jenkinsfile alleen maar downstream jobs aan te roepen. Hierdoor zijn de Jenkinsfiles redelijke basaal en komt er niet veel bij kijken. Om het allemaal nog eenvoudiger te maken, is het mogelijk om ervoor te kiezen om in de Jenkinsfile nog een stukje code toe te voegen. Hierdoor laden de parameters zich automatisch in uit de repo van een team, waardoor het team alleen een bestand nodig heeft waar de variabele in staan. Op deze manier is de instapdrempel voor de teams nog lager en is het mogelijk om direct aan de slag te gaan. Uiteindelijk zit in de repo van het team alleen een file waar de variabele in staan, en een Jenkinsfile die de juiste Jenkinsfile inlaadt die nodig is voor die specifieke applicatie. Deze Jenkinsfile staat dan in een repository samen met alle configuraties voor de downstream jobs (CI/CD Library).

Stap 5: Laat de teams het gebruiken

Nu de standaard Jenkinsfiles klaar zijn, kun je de gegeneraliseerde Jenkins pipelines implementeren bij de teams. Met de vergaarde gegevens en feedback zijn aanpassingen in de pipeline zo gedaan. Wanneer een team er een nieuwe tool bij wil? Beslis met je team of het daadwerkelijk nodig is en werk het indien nodig uit als een nieuwe block. Verder is het mogelijk om de teams zelf functionaliteiten en tools toe te laten voegen door middel van pull requests op je CI/CD Library. Omdat het allemaal als code staat in een repo kun je alles community-driven laten draaien. Hierdoor heb je er zelf ook minder werk aan!

Ga je binnenkort met Jenkins aan de slag en heb je nog vragen? Laat het mij dan vooral weten.

Unit Testen versus Integratie Testen

Integration Testing vs Unit Testing.jpg

De meeste software bedrijven maken al gebruik van Unit Testen. Benieuwd naar de verschillen en in wat voor scenario je welke vorm van Testing gebruikt? In deze blog zullen we je aan de hand van voorbeelden laten zien, wanneer je Unit Testen gebruikt en kiest voor Integratie Testen. Doe er dus je voordeel mee!


Unit Testen

Om je geheugen op te frissen zullen we beiden Testen eerst verder toelichten. We beginnen met ‘Unit Testen.’ De term geeft het eigenlijk al aan: Unit Testen worden gebruikt om een unit van een code te testen. Daarbij wordt het kleinste mogelijke stukje code dat van nut is getest. Dit is in praktijk meestal een methode. Bij een methode verwacht je een vaste output bij een bepaalde input. Dit concept is wat Unit Tests testen. Een Unit Test is voornamelijk bedoeld voor programmeurs; zij kunnen hiernaar kijken en begrijpen de uitkomst van de test. Het doel van Unit tests is om te bewijzen dat de unit correct is in ieder omstandigheid.

 

Integratie Testen

Een breder begrip vormen Integratie Testen. Dat wil zeggen dat je meerdere componenten met elkaar samen gaat testen. Integration Testen worden toegepast om te bewijzen dat de componenten samen met elkaar kunnen werken. In tegenstelling tot bij Unit Testen zijn de uitkomsten van Integratie Testen voor buitenstaanders wel interessant, omdat deze makkelijker te begrijpen zijn. Voorbeelden van Integratie Testen zijn:

 

  •   Een web client testen die met de backend praat.

  •   Het testen van een component die praat met de database.

 

De belangrijkste verschillen tussen Unit Testen en Integratie Testen

De begrippen Unit Testen en Integratie Testen zijn nu duidelijk. In de onderstaande tabel staan de verschillen tussen beiden testvormen op een rijtje:

Unit Testen versus Integratie Testen

Beiden Testen toepassen

Integration Testen zijn vaak moeilijker te schrijven. Daarom is het belangrijk om verschillende en kwalitatief goede Unit Tests te hebben. In de praktijk is dit ook vaak het geval. Wanneer je genoeg unit tests hebt geschreven kun je ervan uit gaan dat de componenten het doen. Verder hoef je in deze situatie ook niet opnieuw door middel van Integration Testen uit te voeren, waardoor je je kunt focussen op de interactie tussen de componenten.

 

Daarnaast is het belangrijk om Unit Testen en Integration Testen met elkaar te combineren.
Als twee componenten veel met elkaar communiceren en het over belangrijke complexe data gaat, kun je niet zonder Integratie tests, want je moet kunnen garanderen dat de dataoverdracht tussen de componenten goed verloopt en dat fouten goed worden afgehandeld. Je kunt je voorstellen dat dit meer tijd kost om te schrijven dan een unit test, maar op deze manier wordt wel op de juiste manier de integratie tussen beiden componenten getest. Dit wordt ook wel de interactie genoemd. Daarnaast is investeren in Unit Testen en Integratie Testen een goed idee om het product schaalbaar te houden voor de toekomst. De meeste programmeurs gebruiken hierin de volgende opzet, wanneer het gaat om Testen:

  • Unit Testen (80%)

  • Integratie Testen (10%)

  •     Systeem Testen (10%)

 

Unit testing versus integration testing.jpg


Learning: zorg dat Unit Testen niet op elkaar afhankelijk zijn!

In deze blog delen we tot slot nog een learning. Het volgende gaat namelijk in de praktijk vaak mis: dat Unit Tests op elkaar afhankelijk zijn. Hierbij doet de volgende situatie zich voor: één unit test data verandert en de andere unit gaat deze data vervolgens gebruiken. Een unit test moet namelijk onafhankelijk van elkaar kunnen runnen. Het is de bedoeling dat één stuk code getest wordt en als deze afhankelijk is van een ander gaat het al snel mis. Houdt hier dus rekening mee bij de opzet van een Unit Test.

 

Dit blogartikel heeft je inzichten gegeven in de verschillen tussen Unit Testen en Integratie Testen. Met welke vorm van Testing ga jij binnenkort aan de slag? Kun je hier wel wat hulp bij gebruiken? Neem dan vrijblijvend contact met ons op.

Continuous Integration met GitLab

Door Freek Schoenmakers

Logo_gitlab.png

Bij softwareontwikkeling is samenwerking essentieel. Vaak werken een heleboel ontwikkelaars tegelijk aan hetzelfde softwareproject. Het is daarom van belang dat versiebeheer goed geregeld is. Hier biedt GitLab goede ondersteuning voor. Met GitLab kun je heel gemakkelijk versies beheren en verzoeken plaatsen om een nieuwe feature aan een release toe te voegen. Maar dat is niet het enige. Een andere – zeer nuttige – functie van GitLab zijn de zogenoemde pipeline tools. Hiermee wordt het build-, test-, deployment- en provisioningproces geautomatiseerd. Naast vele softwarebedrijven zoals Ticketmaster, Uber, ING en Alibaba maakt ook Universiteit Utrecht succesvol gebruik van GitLab.


Wat is het?

Pipeline tools ondersteunen softwareontwikkeling door het automatiseren van taken zoals testen. Een pipeline is een groep jobs die worden uitgevoerd in stages. De jobs worden parallel uitgevoerd; als ze allemaal succesvol uitgevoerd zijn gaat de pipeline verder naar de volgende stage. Deze jobs en stages kunnen van alles omvatten, maar heel standaard zijn de build en test stages.

Hieronder zie je een schematische weergave van een pipeline uit een softwareproject van Freek Schoenmakers, een van onze Young Professionals. Deze pipeline bestaat in totaal uit drie stages (build, test en deploy) en vier jobs.

Freek_pipeline_1.png

In de build stage wordt een oplossing gecompileerd en wordt het resultaat eventueel opgeslagen als artifact. Vervolgens worden in de test stage twee jobs uitgevoerd. In deze jobs wordt een serie geautomatiseerde tests losgelaten op de artifacts van de build stage. De testresultaten worden opgeslagen als artifact en als alle tests succesvol doorlopen zijn is de job voltooid. Je ziet in het schema een test codestyle. De projectgroep had afgesproken om volgens een vaste stijl te werken, zodat alle code op elkaar lijkt en daardoor goed leesbaar is. De oplossing uit de build stage werd getest op deze codestyle. Dat scheelt de code reviewers een hoop tijd!

Als laatst wordt in het voorbeeld de deploy stage doorlopen. Hierbij wordt een release-build van de oplossing gecompileerd en bewaard. Op die manier is het heel makkelijk om een oudere versie opnieuw te downloaden en te vergelijken. Dit kan bijvoorbeeld handig zijn bij een vergadering met een opdrachtgever. Merk op dat hier in de deploy stage alleen een release-build gemaakt is. Voor dit project was niet meer nodig. Echter, in professionele omgevingen zou de deploy stage bijvoorbeeld de nieuwe versie naar een server kunnen uploaden en zo automatisch de server bijwerken.

“Pipelines bieden veel flexibiliteit en mogelijkheden rondom projectontwikkeling en automatiseren taken die anders veel tijd zouden kosten.”

Je kunt zelf met een kort script precies definiëren hoe de pipeline verloopt. Welke stappen moeten er worden doorlopen vóór het starten van de pipeline, welke stages bevat deze, uit welke jobs bestaat iedere stage, wat houdt elke job precies in, et cetera. Dit biedt veel flexibiliteit en mogelijkheden rondom projectontwikkeling en automatiseert taken die anders veel tijd zouden kosten.

Freek_pipeline_2a.png

In GitLab kun je overigens verschillende statistieken zien over de pipelines, zoals hiernaast en hieronder weergegeven. De statistieken die je hier ziet hebben betrekking op het softwareproject dat net beschreven is.

Freek_pipeline_2b.png

verschillen met GitHub

Niet alle services hebben deze pipeline tools op dezelfde manier geïntegreerd. Zo heeft GitHub externe services nodig, bijvoorbeeld Travis CI. Hierdoor ontstaat het risico om  een ‘radertje in de machine’ te worden. GitLab daarentegen zet de pipeline tools centraler neer, waardoor deze de bron vormen van alle activiteiten.

verschillen met Azure DevOps

Echter, ook bij GitLab is er nog altijd ruimte voor verbetering. Zo kan het gebruiksvriendelijker. Op dit moment maak je een configuratiebestand aan en vervolgens pikt GitLab dit bestand automatisch op. Ter vergelijking: Azure DevOps heeft hier een mooie grafische interface voor. Hier kun je gemakkelijk jobs en stages toevoegen en nieuwe pipelines configureren zonder direct in script bestanden te rommelen.

Een ander voordeel van Azure DevOps is dat het doorlopen van het deployment-proces beter is ingebouwd. Door deze integratie kunnen de resultaten van een pipeline gemakkelijk gedeployed worden zonder tussenkomst van een externe service. Dit is ook mogelijk in GitLab, maar daar zijn extra services voor nodig waardoor het minder eenvoudig is dan bij Azure. Zo is er bijvoorbeeld integratie mogelijk met Prometheus voor performance monitoring en Kubernetes voor clustermanagement.

Al met al zijn er veel voordelen van Continuous Integration en ik hoop je te hebben geïnspireerd om te profiteren van de services die GitLab hiervoor biedt. Meer informatie? Ga naar onze Continuous Delivery 3.0 of Continuous Intelligence pagina.

A/B testing

Door Ewan Klomp

directionalsign_83858.png

Veel mensen denken dat A/B testing enkel iets is voor grote bedrijven, met heel veel gebruikers zoals Facebook of Amazon. Maar niets is minder waar. Met de komst van tooling zoals Google Optimize is het mogelijk om ook bij kleine bedrijven A/B tests effectief uit te voeren. A/B testing met weinig moeite en zeer beperkte kosten. Op deze manier ontstaat een nog betere en completere teststraat. Ook kan de Product Owner nog beter inzicht krijgen in het softwaregebruik.

Wat is A/B Testing ook al weer?

Om nog even het geheugen op te frissen: bij een A/B test krijgen gebruikers applicatieversie A of applicatieversie B. Op basis van tevoren bepaalde metrics wordt uiteindelijk één van de versies als definitieve versie gekozen voor alle gebruikers.

Door A/B tests kan een softwareproducent betere beslissingen nemen op het gebied van User Interfaces, door bijvoorbeeld te kijken naar welke versie correleert met de grootste conversie.

Google Optimize als A/B test tool, biedt een goede integratie met Google Analytics.

Google Optimize

In dit artikel gaan we dieper in op Google Optimize. Optimize biedt een goede integratie met Google Analytics. Daarnaast heeft het een gratis versie waardoor je snel alle opties kunt onderzoeken. Uiteraard zijn er meer tools waarmee A/B tests uitgevoerd kunnen worden, zoals the A/B testplatform van VWO of het experimentenplatform van Optimizely. Welke het best bij jouw organisatie past is afhankelijk van je teststrategie.

google-optimize-logo-480x480-1-140x140@2x.png

Implementatie A/B Testing

Een A/B test opstellen is in feite een experiment uitvoeren. Je begint met een hypothese, verandert een element en bekijkt de statistieken (lees resultaten) van de vooraf bepaalde metrics.

Google Optimize heeft een editor waarmee je webelementen gemakkelijk kunt bewerken. Je meet met deze webelementen de metrics vanuit je Google Analytics doelen. Een andere nuttige functionaliteit van Google Optimize is dat je je direct op op bepaalde gebruikers kunt richten, op basis van bijvoorbeeld gedrag of locatie.

A/B Testing en Continuous Delivery 3.0

Met A/B testing leg je ook een directe link met het Continuous Intelligence en Continuous Planning gedeelte van Continuous Delivery 3.0. Op deze wijze krijg je nog meer informatie van gebruikers, op basis van de verzamelde metrics. Hier kan de Product Owner de backlog prioritering op aanpassen

AB_testing.png

Het figuur toont hoe de resultaten van A/B testing het Continuous Intelligence proces en Continuous Planning proces voeden

Bijvoorbeeld: als de conversie met de nieuwe versie niet is verhoogd, kan je een work item aanmaken waarin je onderzoekt hoe je de conversie wel kunt verhogen.

Via de bovenstaande aanpak kun je laagdrempelig kennismaken met de mogelijkheden om je product en je ontwikkelprocessen te verbeteren met A/B Testing, Continuous Intelligence en Continuous Planning. Ik hoop je geïnspireerd te hebben om A/B testen te implementeren in jouw teststraat! Download nu de whitepaper over A/B-testing.

Continuous Delivery 3.0 Maturity Model

Door: Ewan Klomp & Jan Vlietland

In 2016 hebben we het Continuous Delivery 3.0 Platform ontwikkeld. In dit artikel introduceren we het bijbehorende Continuous Delivery 3.0 model.

Tijdens de implementatie van het platform bij softwarebedrijven hebben we een patroon opgemerkt in de implementatiestappen. Bijvoorbeeld een unit testset wordt doorgaans eerder gemaakt dan de acceptatie testset.

Deze afhankelijkheden hebben geleid tot het onderstaande Continuous Delivery 3.0 Maturity Model.

ContinuousDelivery30 Maturity Model v1.0.png

Verticaal staan de 5 Continuous Delivery 3.0 gebieden, zijnde Intelligence, Planning, Integration, Testing en Deployment. Horizontaal staan de 5 stappen naar volwassenheid.

 

Introductie Ewan Klomp - DevOps Engineer / Continuous Delivery

20180815_195621.jpg

Hallo, mijn naam is Ewan Klomp en ben bij Search4Solutions werkzaam als Continuous Delivery Expert.

Als eerste Young Professional heb ik het programma en de groep zien groeien in professionaliteit en kennisdeling. We zijn begonnen met een kleine club informaticastudenten die een passie voor software development hebben. Inmiddels zijn we uitgegroeid tot een grote club young professionals die met passie aan onze projecten werken.

Zelf heb ik mij kunnen specialiseren op het gebied van Continuous Delivery, door intern een traineeship te volgen. Daarna met de opgedane kennis in het bedrijfsleven te stappen, in projecten die mij deze kennis liet benutten. Deze projecten waren leuk en succesvol. Eveneens heb ik in die tijd mijn studie Informatiekunde met veel plezier afgerond. 

Nu maak ik als Young Professional de stap naar voltijd. Ik kijk er zeer naar uit om deze stap te mogen maken en ik ben benieuwd wat het mij gaat brengen.

In de tussentijd wil ik mijn opgedane kennis delen met de community die we hebben opgebouwd. In de komende tijd komen er op deze pagina daarom artikelen die u zou kunnen helpen met uw Continuous Testing processen. Vorige week is een artikel uitgekomen over cross platform UI Testing met Xamarin als voorproefje op deze reeks.

In de volgende delen zal u meer kunnen lezen over AT testen, performance testen en A/B testing. Wilt u eerder meer weten? Neem dan contact met ons op.

Cross-platform UI testing met Xamarin

Door: Ewan Klomp

Nadat Microsoft begin 2016 Xamarin overnam, heeft Microsoft grote stappen gezet om cross-platform applicaties met goede performance in C# te bouwen. De snelheid is nog niet helemaal als Native code. Maar door de mogelijke code sharing tussen de twee platformen (iOS en Android) is het een degelijke optie. Zeker wanneer er geen zware computationele berekeningen nodig zijn. Dit artikel gaat dieper in op hoe je User Interface tests uit één project, op beide platformen draait.

Simpele werkwijze

De user interface test van Xamarin werken met een interface. De user interface test library heet Xamarin.UITest en de interface de IApp interface. Xamarin kan met dezelfde interface beide platformen bedienen. Door de IApp interface is het klikken van een object op iOS en Android heel simpel, met dezelfde app.Tap(string) method call.

Creëren van test cases

De methoden die de IApp interface heeft zorgen dat er diverse, geavanceerde test cases gecreëerd kunnen worden. De mogelijkheden zijn vergelijkbaar met die van grotere test platformen zoals Selenium. Ook kan je met Xamarin objecten makkelijk vinden door middel van naam of XPath. Vervolgens kun je ze klikken of er tekst bij invoeren. Natuurlijk bevat Xamarin specifieke methoden voor gestures zoals drag/drop, pinching, en swiping om een gebruiker zo goed mogelijk na te bootsen.

HIerboven zie je een snippet van een Test case, geschikt voor zowel IOS als Android

HIerboven zie je een snippet van een Test case, geschikt voor zowel IOS als Android

Hoe het werkt

Als je dus binnen je test een object aan wil klikken genaamd ´buttonHome´, voer je de functie app.Tap(buttonHome) uit. Dit zoekt dan het object met id ´buttonHome´ op in de huidige views die open staan. Om er voor te zorgen dat de juiste view de juiste ID heeft moet de ID op de juiste plek in de layout files toevoegen: .xib voor iOS en .xaml voor Android.

  • Op iOS geef je een id op deze manier mee aan een element in de .xib file:
    <accessibility key="accessibilityConfiguration" identifier="buttonHome"/>

  • Bij Android in de .xaml op deze manier:
    android:id="@+id/buttonHome"

Let hier op

In principe is het mogelijk om een test te schrijven die draait op Android en IOS. Het probleem zit soms in het verschil van gedrag tussen de platformen op het gebied van views. Hier moet dan binnen 1 testcase een verschillende implementatie voor geschreven worden. Verder is het van belang dat elk element van een testcase waarmee je werkt zijn eigen unieke ID heeft en hetzelfde zijn op beide platformen. Bij een juiste implementatie is het enige verschil de initialisatie van de applicaties voor het testen. Let er op dat je de ID’s van de objecten gelijk houdt op beide platformen. Hierdoor kunnen juiste objecten op de juiste plek gevonden worden.

En nu jij

Hopelijk heb ik je enthousiast gemaakt en ga je zelf met Xamarin aan de slag. Als je hier meer over wilt weten kun je me bereiken via ons contactformulier:

Je applicatie hosten in containers

Het verplaatsen van de hosting van een eigen rekencentrum naar een cloud-omgeving kan veel besparing opleveren. Bedrijven verplaatsen daarom hun hosting op grote schaal naar de cloud.

Veel organisaties denken daarbij dat virtual machines dan de beste oplossing is. Jammer want ze missen dan de kans om software te hosten in containers. Hosten in containers heeft vele voordelen. In dit artikel leggen we uit wat containers zijn en wat de voor- en nadelen zijn van containers.

Wat zijn containers?

Een container biedt de mogelijkheid om het Operating Systeem te sharen over meerdere containers. Ze zijn daardoor veel goedkoper qua hosting dan virtual machines. 

Het Operating Systeem onder de container bevat alle benodigde libraries die een applicatie nodig heeft om te functioneren. De containers zelf zijn daardoor zeer compact en zijn binnen een paar seconden te creeren. Dit maakt ze niet alleen goedkoper, maar ook veel flexibeler.

Containerization is geen nieuw begrip. Het idee om de OS laag te virtualiseren bestaat al sinds begin deze eeuw. 

Het container framework ‘Docker’ heeft het begrip containers praktisch gepopulariseerd. Veel innovatieve bedrijven hebben Docker snel geadopteerd. 

 
VM_vs_Container_stack.png
 

De nadelen van containers.

Evenals de virtual machine niet de universele vervanger is van de fysieke server, is de container dit niet van de virtual machine. Beide technologieën hebben hun krachten. Containers floreren in een omgeving met microservices. Ze schalen mooi, doordat ze zeer snel te creeren zijn afhankelijk van het benodigde dataverkeer.

Containers zijn echter wel gevoeliger voor virussen doordat ze het onderliggende Operating Systeem delen. Ook kunnen ze diep reiken in het OS om überhaupt te functioneren. VM-instanties bieden deze controle en veiligheid wel. 

Overweeg containers

Bij veel bedrijven staat veiligheid op nummer één en kennis omtrent containers is vaak niet paraat, virtual machines zijn daarom een veilige keuze.

Jammer, want de toekomst van containers is veelbelovend en het zal niet lang duren voordat de meerderheid deze techniek adopteert, zoals dit nu gebeurt met VM-instanties in de cloud.

Meer informatie? Bekijk dan de volgende onderwerpen: Continuous Delivery 3.0, Cloud Software Engineering, Cloud Deployments en Testautomatisering.