HOE BEHOUD JE DE KWALITEIT VAN PROJECTEN DOOR DE ALM PROCESSEN TE VERBETEREN? PROMOTOR: MH DIETER DE PREESTER

HOE BEHOUD JE DE KWALITEIT VAN PROJECTEN DOOR DE ALM PROCESSEN TE VERBETEREN? PROMOTOR: MH DIETER DE PREESTER

PROJECT PERFORMED BY

STUDENT STIJN MOREELS TO ACHIEVE THE DEGREE BACHELOR IN THE

NEW MEDIA AND COMMUNICATION TECHNOLOGY HOWEST | 2015-2016

HOE BEHOUD JE DE KWALITEIT VAN PROJECTEN DOOR DE ALM PROCESSEN TE VERBETEREN? PROMOTOR: MH DIETER DE PREESTER

PROJECT PERFORMED BY

STUDENT STIJN MOREELS TO ACHIEVE THE DEGREE BACHELOR IN THE

NEW MEDIA AND COMMUNICATION TECHNOLOGY HOWEST | 2015-2016

STIJN MOREELS

ACADEMIEJAAR 2015-2016

HOE BEHOUD JE DE KWALITEIT VAN PROJECTEN DOOR DE ALM PROCESSEN TE VERBETEREN?

Woord vooraf Sinds het middelbaar is software ontwikkeling een passie geworden voor mij, het logische in het hele gebeuren spreekt me enorm aan. Hoe wiskunde en logisch denken met elkaar verweven zijn inspireert me nog steeds. Gedurende mijn opleiding in Howest (New Media and Communication Technology) is mijn passie verbreed naar software architectuur. Hoe stukken software gekoppeld zijn aan elkaar en hoe ze communiceren om een zo schaalbaar, aanpasbaar & onderhoudbare oplossing te creëren heeft me getriggerd om meer te leren over deze topic in de brede zin van het woord. Ik zou me graag op een dag software architect noemen. Mijn paper ging niet rechtstreeks over software architectuur maar heeft zeker een nauw verband met het topic en zorgde ervoor dat mijn visie over architectuur veranderde. Onder begeleiding van verschillende mensen heb ik dit tot een goed einde kunnen brengen: Ann Deraedt, voor haar eindeloze geduld die ze had toen ze me telkens hielp om meer duidelijkheid te brengen; mijn promotor: Dieter De Preester, voor zijn directe hulp en duidelijke communicatie tijdens de weken waar de topic “bachelorproef” alleen maar een black box was voor mij; mijn stagebegeleider: Thomas Houtekier, voor zijn technische mening over mijn paper & Fien Vandenbussche, voor haar mentale en administratieve hulp tijdens het schrijven van mijn bachelorproef. Bedankt allemaal voor de vele steun.

New Media and Communication Technology

3 | 64

STIJN MOREELS




4 | 64

STIJN MOREELS



Samenvatting Elk bedrijf heeft nood aan een goed georganiseerde ALM flow. Hoe dit echter uitgewerkt en verkocht wordt aan de developers is een ander paar mouwen. Iedereen heeft er sowieso baatbij dat er binnenin een bedrijf een duidelijk gestructureerde ALM flow ontstaat. Mijn bachelorproef gaat over het automatiseren & verbeteren van deze ALM flow en dus bij definitie een MUST voor ieder bedrijf. In de proef worden verschillende problemen en oplossingen voorgesteld en fases die ook voor andere bedrijven hergebruikt kunnen worden. Heeft jouw bedrijf problemen met automatisering, frustraties over verkeerd ingecheckte code of manuele acties die het project ophouden? Dan is een duidelijke en gestructureerde ALM flow de oplossing. Kernwoorden: ALM (Application Lifecycle Management); Planning, Development, Building, Deployment; itererende cyclus; TFS (Team Foundation Server); QA (Quality Assurance).


5 | 64

STIJN MOREELS



Verklarende woordenlijst Afkorting

Betekenis

Beschrijving

ALM

Application Lifecycle Management

Het proces vanaf het opstellen van requirements tot het onderhouden van een project.

API

Application Programming Interface

Een set van regels en routines om met een applicatie te communiceren.

CBAM

Cost Benefit Analysis Method

Methode die door de architect & project manager gebruikt wordt om een beslissingen te maken binnen een budget.

CBR

Content Based Routing

Een routing berichten die gebaseerd is op de inhoud van het bericht.

CI

Continuous Integration

Het automatisch testen van software die ervoor zorgt dat fouten sneller worden gevonden.

IC

Integration Cloud

Een product van Codit die een integratie oplossing biedt aan bedrijven.

IL

Intermediate Language

Tussen programmeer taal die hogere talen (vb. C#) transformeert in een meer machine gerichte taal.

IoT

Internet of Things

Een term die duidt op het connecteren van alles aan het internet.

PASM

Performance, Availability, Security & Modifiability

Afkorting met vier belangrijke aspecten voor een architect.

QA

Quality Assurance

Software wordt getest op kwaliteit.

TFS

Team Foundation Server

Microsoft product dat code management, source control, release management … biedt.

VM

Virtual Machine

Een virtuele computer zonder fysieke hardware. Dit wordt gebruikt voor verschillende doeleinden.

VS

Visual Studio

Omgeving voor development.


6 | 64

STIJN MOREELS



Afkorting

Betekenis

Beschrijving

VSIX

Visual Studio Extension

Een extensie (extra element) geschreven voor Visual Studio.

WCF

Windows Communication Foundation

Framework om service-oriënted applicaties te maken.

XML

Extensible Markup Language

Een manier van dataopslag in documenten die een set van regels beschrijft.

XSLT

Extensible Stylesheet Language Transformations

Manier om bestaande documenten te transformeren naar een ander type document.

Woord

Betekenis

Agile

Agile is een manier van software development waarbij requirements en solutions van een product evolueren tijdens itererende development cycles.

Architect

In een development team wordt de architect aangezien als de persoon die de architectuur van de software opstelt.

Azure

Azure is het Microsoft Cloud die meer dan 50 verschillende producten aanbiedt.

BizTalk

BizTalk is een Microsoft product die toelaat om verschillende soorten bedrijfssystemen te koppelen aan elkaar.

Build Tasks

In een Build is er een volgorde van verschillende Build Tasks die uitgevoerd worden voordat er een package gegenereerd wordt.

Build

Het “Builden” van software bestaat erin de geschreven code te bundelen in een uitvoerbare “package”.

Code Check-in

Met het “inchecken” van code wordt bedoelt dat de code nu “under source control” zit.

Deployment

Het deployen van software beschrijft alle activiteiten die uitgevoerd moeten worden vooraleer de software klaar is voor gebruik binnen een omgeving.

Extension

Een extensie binnenin software development is het uitbreiden van bestaande functionaliteit.

Façade Design Pattern

Facade is een software design pattern die een “simpelere” interface biedt tot een groter meer complexere achtergrond.


7 | 64

STIJN MOREELS



Woord

Betekenis

Lab Management

Binnenin een Team Foundation Project is lab management een manier om met VM’s een omgeving op te zetten (bijvoorbeeld gelijkaardig aan de productie omgeving) waar testen kunnen uitgevoerd worden.

Mapping (IC)

Het transformeren van je data van één formaat naar een ander.

On-Premise

On-Premise software zijn oplossingen die op de klant zijn infrastructuur draait en niet bijvoorbeeld op Azure.

Package

Een package van software is een gegroepeerde verzameling aan software die door verschillende instanties gebruikt kan worden.

Project Manager

In een team is de project manager verantwoordelijk voor de organisatie, planning en discipline binnen een team.

Refactoring

Refactoring in software ontwikkeling beschrijft het process waarbij de code hervormt wordt tot een beter geheel zonder het effectieve gedrag van de code aan te passen.

Reguliere Expressie

Een reguliere expressie is een manier van schrijven die toelaat om bepaalde regels vast te leggen voor een stuk tekst. Bijvoorbeeld de Reguliere Expressie [AZ] laat alleen maar tekst door met hoofdletters.

Release

Een software release is een prototype dat klaar is om te worden getest maar nog niet volledig af is en steeds fouten bevat.

Scrum

Scrum is een itererende manier van software development.

Source Control

Ook wel Version Control genoemd, is een systeem dat veranderingen (versies) binnen een software product bijhoudt.

Waterfall

Waterfall is een sequentiële manier van software development.

Workflows (IC)

Een workflow binnen Integration Cloud is een beschrijving van de weg die een binnen-/buitenkomend bericht aflegt.

Workitem

Binnen een Team Project in TFS kunnen er workitems opgesteld worden die elk afzonderlijk een specifieke taak beschrijven die uitgevoerd moet worden.


8 | 64

STIJN MOREELS



Inhoudsopgave 1

Introductie.......................................................................................................................... 13 1.1

Voorstelling Bedrijf ..................................................................................................... 13

1.2

Onderzoeksvraag ....................................................................................................... 14 1.2.1

2

Probleemstellingen ........................................................................................ 14

Analyse .............................................................................................................................. 17 2.1

2.2

2.3

2.4

2.5

2.6

Wat is ALM? ............................................................................................................... 18 2.1.1

Algemeen ...................................................................................................... 18

2.1.2

Requirements ................................................................................................ 18

2.1.3

Development ................................................................................................. 18

2.1.4

Testing ........................................................................................................... 19

2.1.5

Deployment ................................................................................................... 19

2.1.6

Maintenance .................................................................................................. 20

2.1.7

Document ...................................................................................................... 20

ALM Processen .......................................................................................................... 21 2.2.1

ALM volgens Microsoft .................................................................................. 21

2.2.2

ALM volgens Codit ........................................................................................ 22

2.2.3

Codit Integration Cloud.................................................................................. 23

Kwaliteit Projecten ...................................................................................................... 24 2.3.1

Static Validation ............................................................................................. 24

2.3.2

Dynamic Validation........................................................................................ 25

Workitem Management .............................................................................................. 26 2.4.1

Overzicht ....................................................................................................... 26

2.4.2

Workitem Types & Flow (Agile) ..................................................................... 27

2.4.3

Estimate Effort & Time Tracking ................................................................... 28

Branching & Merging .................................................................................................. 29 2.5.1

Scenario’s ...................................................................................................... 29

2.5.2

Merging strategy............................................................................................ 30

Configuration Management ........................................................................................ 32 2.6.1

Algemeen ...................................................................................................... 32

2.6.2

Integration Cloud Configuration .................................................................... 32


9 | 64

STIJN MOREELS



3

Oplossingen ...................................................................................................................... 35 3.1

3.2

3.3

Workitem Management .............................................................................................. 35 3.1.1

Kanban Board ............................................................................................... 35

3.1.2

Workitem Notifications................................................................................... 36

3.1.3

Service Hooks ............................................................................................... 37

Release Management ................................................................................................ 38 3.2.1

What to Deploy? Artifacts .............................................................................. 39

3.2.2

Where to Deploy? Environments .................................................................. 41

3.2.3

How to Deploy? Tasks .................................................................................. 42

Package Management ............................................................................................... 43 3.3.1

3.4

3.5

4

Package Management Feedback ................................................................. 44

Quality Assurance Best Practices .............................................................................. 45 3.4.1

Aanpak .......................................................................................................... 45

3.4.2

Documents .................................................................................................... 45

Uiteindelijk stappenplan ............................................................................................. 46 3.5.1

Algemeen ...................................................................................................... 46

3.5.2

Fases ............................................................................................................. 47

3.5.3

Schema ......................................................................................................... 48

3.5.4

Fase 1: Aanpak Naming Conventions ........................................................... 49

3.5.5

Fase 1: Validatie Naming Conventions ......................................................... 50

3.5.6

Fase 1: Naming Conventions Config File ..................................................... 51

Besluit ................................................................................................................................ 54 4.1

Bespreking van het project ......................................................................................... 54

4.2

Kritische reflectie ........................................................................................................ 55

4.3

Conclusies .................................................................................................................. 56

Figurenlijst ................................................................................................................................. 57 Bronnen- & literatuurlijst .......................................................................................................... 58 Overzicht van de bijlagen ......................................................................................................... 60


10 | 64

STIJN MOREELS




11 | 64

STIJN MOREELS



1 INTRODUCTIE 1.1 VOORSTELLING BEDRIJF Codit is een software bedrijf die gespecialiseerd is in de integratie wereld. Het is een bedrijf die consultency, technology & managed services biedt in business integration. Azure Components, Integration Cloud, API Management, Biztalk, IoT, … zijn de voornaamste producten die ze leveren aan hun klanten. Alleen Microsoft technologie wordt gebruikt binnen Codit, soms de producten zelf of eigen producten die bovenop een bestaand Microsoft product gebouwd zijn (bv. Integration Cloud). Het bedrijf bestaat nu uit 70 man verspreidt over België (Gent), Nederland (Utrecht), Frankrijk (Parijs), Portugal (Lissabon) & Zwitserland (Zurich) waarvan 50 gecertificeerde Integration Engineers.


13 | 64

STIJN MOREELS



1.2 ONDERZOEKSVRAAG 1.2.1

Probleemstellingen

Voor Codit zijn er verschillende probleemstellingen die in het vooruitzicht liggen om een deftige ALM structuur op te zetten. Het zijn er ook veel te veel om ze allemaal hier in dit onderzoek te bespreken maar de belangrijkste worden hier opgesomd. Volgende onderwerpen moeten zeker onderzocht en opgelost worden tijdens de stage: 

Source control management standaardiseren



Quality enablement (kwaliteit van de code en oplossing verhogen)



Workitem management



Release management (build en deploy)



Branching en merging strategy standaardiseren

De volgende probleemstellingen zullen voor Codit de grootste uitdaging worden: 

Hoe zullen we de Deployment flow organiseren? Hoe en wanneer updaten we de verschillende staging environments? Hoe ver gaan we in de automatisering ervan? Hoe gaan we om met environment specifieke settings?



Hoe zullen we de software geautomatiseerd testen (Unit en Scenario testen)?



Hoe zullen we het workitem management opzetten? Hoe doen we de dagelijkse planning?

Codit heeft al met bepaalde nieuwigheden rond ALM andere guidelines en rules in bepaalde “test” development teams geëxperimenteerd. Dit geeft een goede stap in de goede richting naar een nóg betere ALM oplossing. Tijdens de stage is het de bedoeling dat er een build & deployment omgeving wordt opgezet voor projecten binnen de Codit Integration Cloud. Parrallel met mijn Bachelorproef en mijn Stage, werkt Codit ook aan de guidelines om deze uitdagingen op te lossen. Daarom kan er niet altijd met 100% zekerheid gezegd worden wat er wel of niet zou moeten worden geïmplementeerd. Er zijn naast dit document ook naamgevingsregels opgesteld en voorstellen hoe deze problemen verder moeten aangepakt worden. Onderzoeksvraag: Hoe kan de kwaliteit van de projecten behouden blijven bij de komst van nieuwe technologieën (IoT, Azure ALM) door de Application Lifecycle Management processen (Develop, Build, Test, Deploy) te optimaliseren (automatiseren) in een bedrijf als Codit


14 | 64

STIJN MOREELS




15 | 64

STIJN MOREELS



2 ANALYSE In de analyse van deze paper wordt er stilgestaan bij volgende topics: ALM, de kwaliteit van de projecten & nieuwe technologieën. Met deze analyse verkrijg je een goede eerste basiskennis rond ALM en hoe dit dagelijks in de praktijk toegepast kan worden in projecten. Naast eigen research en eigen opgedane kennis kon er ook worden gerekend op de kennis binnen Codit. Doorheen het document wordt er een nadrukkelijke link met het bedrijf gemaakt. Naast die kennis is het ook vooral belangrijk dat er een eigen mening gecreëerd wordt over ALM en dat dit kan worden vergeleken met die van Codit. De uiteindelijke bedoeling is dat dit toepast wordt om bepaalde implementaties in vraag te kunnen stellen zodat de uiteindelijke implementatie beter is geworden. ALM is een enorm breed topic en dus wordt zeker niet alles opgelost maar in de analyse wordt er wel verscheidene topics te besproken waar onderzocht naar is gedaan. Aangezien IT in het algemeen zo veel verandert, is het onderzoek zelf naar betere implementatie technieken voor ALM een blijvend proces en kan dus gerust opnieuw gedaan worden. Denk maar aan de komst van nieuwe technologieën of het uitbreiden van het bedrijf.


17 | 64

STIJN MOREELS



2.1 WAT IS ALM? 2.1.1

Algemeen

ALM staat voor Application Lifecycle Management. Dit beschrijft het hele proces vanaf het voorbereiden van een product (de scope van het product, de fases dat het doorloopt, het plannen, …) tot het presenteren naar de klant, onderhouden & uitbreiden van het product. Het opstellen van de requirements, het ontwikkelen van het product, het testen van het product, het lanceren van het product & het onderhouden van het product is een eindeloze flow die application lifecycle management beschrijft. ALM wordt vaak beschreven als een vaste cyclus die overlopen wordt, maar in de praktijk is dit vaak een continue proces tijdens het ontwikkelen van het product en niet van een sequentieel opvolgen van verschillende stappen.

2.1.2

Requirements

Het is belangrijk dat de architect en/of project manager starten met het opstellen van de requirements (zie verder: in Epics & Use Cases). Het kan helpen dat de soorten requirements in categorieën (bv. per feature) worden opgesteld, zeker bij grotere projecten is dit quasi noodzakelijk. De architect is hierin verantwoordelijk voor een high-level software design en het maken van technische beslissingen die invloed hebben in de volgende stappen. Het is zijn/haar taak om een design te maken die aan volgende aspecten (PASM) zo veel mogelijk voldoet: Performance, Availability, Security, Modifiability. Hierin kan denken over abstractheid en schaalbaarheid een grote rol spelen. Daarnaast kan de architect in overleg met de project manager ook een CBAM (Cost Benefit Analysis Method) opstellen die bepaalt welke functies het product wel of niet moet hebben en daarbij samenhangend de kosten die de klant zich kan permitteren voor het product. Dit kan ook een zware impact hebben op architecturale beslissingen en het is aan de architect om een zo robuust mogelijk software design te ontwikkelen die enerzijds aan de vooraf opgenoemde aspecten voldoet en zich anderzijds binnen de mogelijkheden van de klant bevindt.

2.1.3

Development

De volgende stap beschrijft het development proces. Hierin verdeelt het development team de Epics & Use Cases in verteerbare dagelijkse taken (zie verder: 2.4 Workitem Management), zodat iedere developer zich hierin kan thuisvinden en dat de voorop gestelde requirements steeds gehaald worden. Het is ook belangrijk dat in dit proces de test cases niet achterwege worden gelaten maar dat er een voorbereiding wordt getroffen (een lijst van grote kanshebbers om testen voor te schrijven) om bepaalde testen zeker te schrijven rond een bepaalde omgeving of setup. Het verdelen van werk in deze fase kan op verschillende manieren, denk maar aan Scrum, Agile of Waterfall.


18 | 64

STIJN MOREELS



2.1.4

Testing

Het testen van software wordt veelal over het hoofd gezien ondanks dat dit een cruciaal deel is in het ALM verhaal. Unit & Integration tests zijn uiterst belangrijk, waarin met Unit tests een zo klein mogelijk onafhankelijk deel te testen bedoeld wordt en met Integration tests een integratie tussen 2 of meerdere componenten/modules. Maar volgende tests zijn ook belangrijk: 

load tests (meerdere users);



stress tests (non-functional testing);



security tests (Black, Gray & White box);



regression tests (consistentie test);



performance tests (schaalbaar);



behavior tests (volledige flow, gedrag oplossing);



…

Het is ook steeds belangrijk dat bij het maken van nieuwe features er een Acceptance deel in de flow zit, waarin meerdere personen het deel manueel kunnen testen en Code Reviews & Quality Checks kunnen uitvoeren. Dit kan onder andere de architect zijn die controleert of het systeem nog steeds voldoet aan zijn/haar voorop gesteld software design, maar kan evengoed een QA tester zijn die de usability test. Continious Integration is op de dag van vandaag bijna een normaliteit terwijl dit vroeger een echte uitdaging was om werkend te krijgen. CI staat ervoor in dat de testen die vooraf opgesteld zijn, gestart en uitgevoerd worden bij elke aanpassing door het development team. En dit allemaal “automatisch”. CI heeft ook invloed op de branching en merging strategy (zie 2.5 Branching & Merging). Bij een Feature branch bijvoorbeeld is het niet de bedoeling dat bij elke aanpassing de testen zouden moeten slagen, het is dan ook een Development omgeving. Bij een Main branch zou je dit bijvoorbeeld wel kunnen verwachten en kan je dus met Countinious Integration werken. Voor een Continious Integration setup is het vooral de bedoeling dat de testen snel moet verlopen en het proces niet ophoudt, daarom is het logisch dat in dit geval voor Unit tests gekozen wordt. Bij een nightly-build, waarbij er elke dag een test cyclus overlopen wordt en er niet in het development proces testen worden uitgevoerd, wordt vooral gecheckt als de veranderingen van die dag geen problemen met zich mee heeft gebracht. Regression tests zijn de validaties die worden uitgevoerd tijdens deze build.

2.1.5

Deployment

Deployment in het Application Lifecycle Management-verhaal moet steeds mogelijk blijven naar verschillende environments (DEV, TEST, PROD, …). Het is van uiterst belang dat de omgeving (evironment tests) getest wordt, zodat het product klaar is voor de “reality” en het niet alleen werkt binnen een development omgeving. “It works on my box!” Een productie omgeving kan werken met andere versies van een systeem, firewalls die beletten bepaalde data te raadplegen, andere hardware, … Daarom is het belangrijk dat het product getest wordt in een omgeving die het meest lijkt op de omgeving in de productie. Eens het in productie is geplaatst, moeten er natuurlijk ook testen worden gevalideerd.


19 | 64

STIJN MOREELS



Automatisering is in dit deel van ALM ook niet onbelangrijk, manuele deployment is bijna in alle mogelijke ontwerpen de minst effectieve oplossing. Iets dat geautomatiseerd kan worden laten doen door een persoon is gewoon een verspilling van tijd. Een deployment kan bijvoorbeeld starten als er een aanpassing gedaan door het development team.

2.1.6

Maintenance

Meestal is dit de langste fase in ALM en ligt ook aan het werk van de voorgaande fases. Als bepaalde issues of bugs uit goed geschreven tests gehaald worden, zal deze fase minder lang worden. Hoe meer het product in dezelfde lijn ligt als de gebruikers verwachten, hoe minder issues er zullen opgelost moeten worden. Indien er echter wel zijn, worden deze terug opgenomen in de requirements in het begin van het proces en doorloopt het terug de hele flow. In een Agile principe wordt de klant vaak uitgenodigd en kan er dus regelmatig om feedback gevraagd worden zodat er steeds een product gemaakt wordt die aan zo veel mogelijk requirements voldoet van de klant.

2.1.7

Document

Als laatste deel maar van uiterst belang is het documenteren van het hele proces. Het is zo dat bepaalde delen binnen ALM, als het nu gaat over de verdeling binnen het development team of het instellen van bepaalde opties binnen deployment, herhaald kunnen worden voor andere producten. Het is echter wel belangrijk dat bij aanpassing van bepaalde code, er een berg documentatie herschreven moet worden. De documentatie legt vooral principes en afspraken vast rond het project. Iedereen zal meer tevreden zijn als ze bepaalde zaken niet constant moeten uitvinden en er al een team voorafgaand is geweest die een duidelijke documentatie heeft opgesteld van hoe zij het hebben aangepakt. Iedereen binnen het bedrijf zal hiervan de vruchten plukken. Ook wanneer er nieuwe mensen in het team binnenkomen midden in de ALM flow, moet er quasi onmiddellijk verder kunnen gewerkt worden zonder dat er een week inleiding aan die persoon (personen) moet gegeven worden. Omgekeerd ook, wanneer er personen het team verlaten, mag de kennis in het team ook niet worden meegenomen, maar moet er een duidelijke documentatie bestaan van zijn/haar werk binnen het team (dat door iedereen leesbaar is en voldoet aan de architecturale beslissingen van de architect, dus ook bijvoorbeeld bedrijfsspecifieke naamgevingen).


20 | 64

STIJN MOREELS



2.2 ALM PROCESSEN 2.2.1

ALM volgens Microsoft

Microsoft heeft zijn eigen kijk op ALM en implementatie. Hieronder vindt u een overzicht van de verschillende items die dit beschrijven. 

Planning en opvolging (Plan & Track)



Design (architecture)



Development



Automated build



Testing (Develop-, performance- & QA-testing)



Test lab management (virtualization)

Waar experts vooral een nadruk op leggen, is het feit dat ALM een manier is om geen grote hoeveelheden geld te verliezen binnen het bedrijf. Zelfs kleine ondernemingen kunnen met ALM een veiligheid inbouwen om dit te voorkomen. Het is net bij de kleine ondernemingen dat dit misschien zelfs nog een grotere meerwaarde is want geld verliezen in een klein bedrijf heeft meer impact dan in een groter bedrijf. TFS (Team Foundation Server) is een manier om hierin te helpen. Hieronder vindt u een korte bird’s-eye view waar TFS in helpt tijdens de implementatie van ALM. 

Project management



Traceability



Streamline develop best practices



Situational awareness

TFS begeleidt hierin maar zet zeker geen verplichting op de gebruikers, het zijn nog altijd de gebruikers die dit effectief moeten uitvoeren.

Figure 1 Microsoft Logo New Media and Communication Technology

21 | 64

STIJN MOREELS



2.2.2

ALM volgens Codit

Hieronder vindt u de verkorte ALM flow voor BizTalk binnen Codit. De code quality is voor Codit een echte MUST aangezien het platform de Code Review echt als een block in het process zit en niet als een deel van de lifecycle. Dit houdt onder andere naamgevingsregels, testen, andere code reviews in. Het is de bedoeling in de toekomst dat Codit verplicht zijn werknemers code pas in te checken wanneer die code kan gekoppeld worden aan een workitem. Indien dit niet het geval is, mag de code niet ingecheckt worden. Dit zorgt terug voor een heel traceable systeem waarbij het bedoeling is dat elk stuk code terug te koppelen is aan een vooraf gedefinieerd workitem. Nu is echter niet al het vooropgestelde werk gekoppeld aan een workitem. Binnen Integration Cloud is er echter nog geen vaste ALM procedure. Veel stappen in het proces worden nu manueel gedaan (denk maar aan bepaalde business workflows die lokaal gemaakt worden en die manueel moeten opgeslagen worden in de Cloud) en het is de bedoeling dat deze geanalyseerd worden en in de toekomst geautomatiseerd worden.

Figure 2 Application Lifecycle Management for BizTalk and Azure integration development


22 | 64

STIJN MOREELS



2.2.3

Codit Integration Cloud

Integration Cloud (IC) is een product dat door Codit is ontworpen om een integratie oplossing te kunnen bieden aan hun klanten. IC is in het kort middleware die tussen verschillende endpoints staat en de connectie speelt tussen deze endpoints. Biztalk is één van de technologieën die Codit gebruikt maar dit product is niet gemaakt voor de Cloud, daarom bevindt zich binnen in IC een VM waar een Biztalk omgeving is geïnstalleerd. Aangezien IC ook op Azure gehost is, kan het dus zowel van de Biztalk mogelijkheden als de Azure Components gebruik maken. Door deze generische manier van werken kunnen dus verschillende soorten ingangen met nog andere soorten uitgangen verbonden worden. Kenmerken:    



IC werkt volledig binnen in met de Service Bus (en dus met een Publish/Subscribe) systeem; Routing binnenin gebeurt met een Context Based Routing system (CBR); Een “The Portal” biedt aan de klant de mogelijkheid om de binnengekomen berichten op te volgen en te monitoren; Binnenin wordt er gewerkt met een Canonical Format (centraal formaat) waardoor het aanpassen van één van de endpoints zonder problemen verloopt (de volledige flow moet niet aangepast worden); De configuratie van de IC gebeurt door: Mapping (Transformation door XSLT files), Workflows & Endpoints (Receive- en Transmit Endpoints)

Figure 3 Codit Integration Cloud


23 | 64

STIJN MOREELS



2.3 KWALITEIT PROJECTEN De bedoeling is dat Codit een volledig uitgewerkte branch- & merge strategy implementeert en dat met een vast aantal regels en afspraken om de kwaliteit van de projecten te garanderen. (Zie 2.5 Branching & Merging) Onder “de kwaliteit van projecten” is het de bedoeling dat deze zaken vastgelegd worden binnen Codit: 

STATIC VALIDATION: Validatie van de solution zonder zelf deze te builden of te starten. Deze validatie bestaat erin de code te analyseren. Gebruikte tools: Visual Studio Code Analysis & Style Cop.



DYNAMIC VALIDATION: Validatie van de solution na het builden in de vorm van testen, Unit tests.



RUNTIME VALIDATION: Validatie van de solution na het builden en deployen in de vorm van testen, Integration tests.



MANUAL TESTING: Naast de automatische tests wordt er ook steeds plaats gelaten voor het manuele testen van de solution.

Deze reeks aan punten bepaalt de kwaliteit van de code en dus het project. Codit streeft naar een duidelijke en strikte manier van code testing waar iedere werknemer zich best aan houdt als er een project uitgewerkt wordt. Naast het testen wordt er in Codit ook een grote nadruk gelegd op de name convention van de code (nu enkel voor de IC projecten). Door dergelijke manieren van werken wordt de code eenzijdiger, leesbaarder & architecturaal sterker.

2.3.1

Static Validation

Code styling/formatting, analysis & metrics values zijn de hoofdpunten van deze validatie. Het is van strikt belang dat de naming conventions worden gevolgd in de verschillende projecten. Codit gebruikt de Microsoft-way van guidelines om de code te stylen. Het bedrijf beschikt over een hele reeks extra naming conventions bovenop de bestaande om niet alleen de code maar ook de projecten, solutions, folders, … een duidelijke, éénduidige & veelzeggende naam te geven (de effectieve naamgevingsregels worden in dit document niet beschreven, zie de interne documentatie van Codit). Code Metrics beschrijven een set van regels die (na het uitvoeren van deze validaties) info geven rond de geschreven code, bijvoorbeeld het voorstellen om bepaalde blokken code in testen op te nemen. In Visual Studio zijn er verschillende Software Measurements die gevalideerd kunnen worden: 

Maintainability Index: bepaalt in welke mate blokken code maintainable (onderhoudbaar) zijn



Cyclomatic Complexity: bepaalt de complexiteit van code (flow van programma) en stelt testen voor indien dit te complex wordt en de maintainability niet gewaarborgd wordt



Depth of Inheritance: bepaalt de hiërarchische structuur en informeert indien dit te uitgebreid wordt



Class Couping: bepaalt de verbinding tussen classes (met parameters, return types, …) en informeert als deze te hoog wordt



Lines of Code: bepaalt de hoeveelheid van lijnen code (van de Intermediate Language) en informeert indien dit te lang wordt volgens de functionaliteit


24 | 64

STIJN MOREELS



2.3.2

Dynamic Validation

Naast de naamgevingsregels en andere styling & formatting regels wordt er ook een code analysis verwacht van de code. Dit bestaat erin dat er voorafgaand een aantal regels opgesteld worden en die tijdens de builds mee worden uitgevoerd en getest om zo een kwaliteitsvol project af te leveren. Het is ook de bedoeling dat deze set van regels kunnen hergebruikt worden over verschillende projecten. (TIP: custom project met in .csproj file een import naar de CodeAnalysis.targets ?) Unit tests worden gebruikt om de kleinst mogelijke, meest onafhankelijke blokken te testen op de werking. Codit beschrijft wat er in deze tests moet/kan staan (staat nog niet helemaal vast): 

Wat te testen? Null values, exception handling.



Locatie worden lokaal uitgevoerd tijdens het builden van de solution.



Duur Unit tests worden verwacht kort te runnen om zo constant gecheckt te worden zonder veel tijdverlies. Deze testen worden dus in een geïsoleerde omgeving uitgevoerd.

“Code Coverage” is vooral de term die in deze context gebruikt wordt. Zo veel mogelijk de code kunnen “coveren”, proberen voor zo veel mogelijk stukken code een test te schrijven. Maar er moet altijd in het achterhoofd gehouden worden dat dit niet het hoofddoel mag zijn van de Unit tests. Het is compleet nutteloos wanneer een Unit test geschreven wordt enkel om een hoger percentage aan “Code Coverage” te hebben. Verschillende code coverage criteria kunnen gehandhaafd worden: 

Statement coverage wordt het deel code uitgevoerd?



Branch coverage wordt elke geschreven/verwachte situatie uitgevoerd?



Path coverage wordt elke situatie gecoverd?



Condition coverage wordt elke conditie gecoverd?

Verschillende namen worden gegeven aan deze termen, net zoals er ook nog andere coverages bestaan.


25 | 64

STIJN MOREELS



2.4 WORKITEM MANAGEMENT 2.4.1

Overzicht

Workitems in TFS zorgen voor de requirements van het project voor de klant, in de Scrum template heet dit een “Backlog item” terwijl in de Agile template dit een “User story” heet. Op dit moment is het nog niet mogelijk om de project-template aan te passen (behalve als het project op onpremise gedeployd wordt) of een nieuwe custom te maken dus is er alleen maar Scrum & Agile beschikbaar. Deze workitems kunnen aan één of meerdere members worden toegekend. Naast de toekenning van een member kan het item op zich ook aan andere zaken gekoppeld worden: Storyboard, Build, Check-in, Implementation tasks, QA test cases, … Codit werkt aan een manier hoe workitems kunnen worden gemanaged. Het is niet zo vanzelfsprekend om werk in grote getale te verdelen over verschillende personen over verschillende projecten en teams. Ook de dagelijkse planning van deze items is niet eenvoudig. In deze analyse wordt vooral stilgestaan bij het workitem systeem en hoe het standaard gebruikt kan worden. Volgende situatie is de standaard configuratie: Je werkt in een team aan een project en je krijgt als developer taken toegewezen. Deze taken verschijnen in het Kanban Board (zie later) maar standaard krijgen we hierbij een email alert. Ook als we switchen tussen projecten kan dit een chaotisch probleem worden. (Zie 3 Oplossingen). Gelukkig bied TFS ook hier een oplossing: bij het aanmaken van een team project kan er gewerkt worden met Agile/Scrum templates en workitems. (Codit gebruikt Agile voor alle team projects). Dit vervangt de werkverdeling die anders in OneNote, Excel of Outlook zou gedaan worden. TFS zorgt ervoor dat het management van het project, taakverdeling, sprints/deadlines & code op één plaats te vinden is. De volgende beschrijving legt het acceptance criteria uit rond de workitems, dit is echter nog niet helemaal geïmplementeerd binnen Codit: De eerste stap van het proces wordt door de project manager en/of architect afgehandeld en bestaat uit de declaratie van user stories en de verschillende sprints die uitgevoerd moeten worden. Per sprint is het ook de taak van deze twee personen om meer in detail te treden omtrent de user stories zodat het ingedeeld kan worden in sprints. Per user story moet ook een acceptance criteria beschreven worden zodat duidelijk kan geïdentificeerd worden als een story afgehandeld is. Codit prefereert om de Gherkin syntax te gebruiken bij het beschrijven van de acceptance criteria. (Gherkin is een line-oriënted language die toelaat om gedrag te specifiëren zonder de eigenlijke logica erachter te beschrijven). Een extra regel is dat alleen user stories waar een acceptance criteria voor kan worden gedefileerd mag toegevoegd worden aan een sprint. De project manager/architect bepaalt welke acties er verder met deze stories moet gebeuren.


26 | 64

STIJN MOREELS



2.4.2

Workitem Types & Flow (Agile)

Hieronder vindt u de flow van een workitem in TFS (Agile, dit is de gebruikte template binnen Codit). Het geeft een duidelijk overzicht van welke workitems er bestaan binnen TFS en wat hun taak is in de flow. EPIC  Groot abstract user story gemaakt door Project manager/Architect.  Codit werkt met één Epic per IC business activity (bv. supply chain, invoicing, …). FEATURE:  Een feature beschrijft één functionaliteit van het grote Epic story. Gemaakt door Project manager/Architect. USER STORY:  Verschillende user stories kunnen beschreven worden per Feature. Workitems worden hier op dit niveau toegevoegd door ofwel de Project manager/Architect ofwel het Development team.  Acceptance criteria worden op dit niveau toegewezen. TASK:  Verschillende workitems per user story worden aangemaakt door het Development team om de user story te ontwikkelen. BUG:  Een bug mag alleen aangemaakt worden indien een defect is gevonden in één van de user stories (is nodig voor tracebility van de workitems). ISSUE:  Een issue workitem kan gemaakt worden indien het Development team vindt dat er zich een situatie voordoet die andere zaken blokkeert.  Dit wordt meestal met het Development team besproken tijdens de dagelijkse meetings en moet zeker blijvend getract worden


27 | 64

STIJN MOREELS



2.4.3

Estimate Effort & Time Tracking

Binnen TFS wordt er ook gewerkt met een relatieve schatting per workitem. Dit laat toe om een eigen, meer realistisch overzicht te hebben van het uit te voeren werk. Voor user stories wordt er gewerkt met een Story Point en bij standaard tasks met Tijd. Story points voor user stories kunnen later in Burndown charts gebruikt worden bijvoorbeeld om een realistisch beeld te krijgen van het gedane werk. Drie verschillende tijden worden getrackt bij een task: 

De beginwaarde die aan de task werd gegeven in het begin van de sprint (en dus voor de taak werd uitgevoerd om een voorafgaande schatting te maken).



De overgebleven tijd die aangeeft per dag hoeveel tijd er per task nog overblijft.



De volledige tijd die er aan een task is gespendeerd sinds de task is geregistreerd (op “active” geplaatst).

Codit beslist om bij user stories de volgende waardes in story points te geven om over een meer gelijklopende en repetitieve toekenning van story points te beschikken over verschillende projecten heen. (Deze afspraken liggen nog niet helemaal vast). Volgende waarden worden gebruikt: 1, 2, 3, 5, 8 & 13.


28 | 64

STIJN MOREELS



2.5 BRANCHING & MERGING Branching in version control is altijd al een heel belangrijk gegeven geweest in software development en de waarde of meerwaarde van deze topic wordt vaak onderschat. Het laat je toe om een duplicaat te nemen van je code dat onder source control staat om in een parallel gedeelte verder te werken. “Parallel Universes” was de term die werd gebruikt door “Jeff Atwood” (Software Developer) en covert de handel wel. Branching wordt bijvoorbeeld ook gebruikt om developers parallel aan features van het project te laten werken zonder voor elkaar problemen te veroorzaken. Op die manier worden de features geïsoleerd. Aan de andere kant is het ook zo dat je kunt over-branchen. Een gouden regel van Thomas Houtekier: “stel pas een branch op indien er geen andere opties meer zijn”. Best wordt eerst gekeken of het probleem niet opgelost kan worden door het onder te verdelen in verschillende fases en zo organisatorisch op te lossen. Branching is nefast voor het Continious Integration verhaal (waarbij code getest wordt bij het inchecken). Als code over verschillende branches verspreid is, wordt het moeilijk om CI uit te voeren (zeker indien je bijvoorbeeld met Feature branches werkt en waarbij het niet altijd de bedoeling is dat de ingecheckte code steeds voor alle testen slaagt).

2.5.1

Scenario’s

Men spreekt van verschillende scenario’s als men over branches spreekt en de manier waarop deze opgebouwd worden. 

SCENARIO 1: Geen (extra) branches worden aangemaakt, alleen een “Main tree” waar alle code gepushed wordt. Dit is een strategie die alleen maar voor kleine teams van toepassing is.



SCENARIO 2: Er wordt een branch voor de release aangemaakt (Dus 2: Main & Release). De bedoeling is hier om de releases stabieler te houden. De main wordt hierbij telkens met de release gemerged.



SCENARIO 3: Er wordt een extra branch voor de maintenance gemaakt. Op deze manier kan voorgaande productie builds niet gedestabiliseerd worden door nieuwere versies.



SCENARIO 4: Een extra branch per feature = development branch. Deze feature branches worden ook in een apart development branch aangemaakt. De bedoeling is om deze branches telkens terug te gaan mergen met de main tree.



SCENARIO 5: Per team wordt er een aparte branch gemaakt in de development branch. Dit laat toe om verschillende sub-teams onder te verdelen zonder dat teams elkaars werk beïnvloeden.

Meestal heb je ook verschillende soorten “levensduren” van branches. Je hebt je typische main die het hele project door blijft bestaan. Maar je hebt bijvoorbeeld ook bepaalde feature branches die maar een beperkte tijd blijven bestaan (een paar dagen gemiddeld). Hieronder zijn de meest voorkomende tijdschema’s opgelijst:

  

Not long-lived branches (vb. Fixes) Several days branches (vb. Feature) Constant branches (vb. Main)


29 | 64

STIJN MOREELS



2.5.2

Merging strategy

De tijdsbepaling wanneer branches worden gemerged is variabel en bedrijfsafhankelijk. De richting aan de andere kant is wel redelijk vast. Het mergen van de development branch naar de main branch is een normale flow, het effectieve developen gebeurt dan ook op de developer branch. Het mergen naar de main gebeurt alleen wanneer een feature is afgewerkt of bugs fixed (of patches). Dit zorgt ervoor dat de main branch stabiel blijft en betrouwbaar. Het is op deze branch dat volgende releases worden voorbereid. Een probleemsituatie wordt gecreëerd wanneer zich een error voordoet op de release branch en er een “snelle” aanpassing moet doorgevoerd worden (hotfix), de actie die wordt ondernomen is dat vanuit de release branch deze fout wordt opgelost of er een aparte branch wordt gemaakt en hierin de fout verder wordt afgehandeld. Het probleem verplaatsen naar een aparte branch wordt vaak gezien als een snelle production-fix, zodat het develop team verder kan werken aan de volgende features. Wanneer dit opgelost is wordt deze branch terug gemerged naar de overige branches (Release, Main, Develop, …), hierdoor wordt de oplossing ook in de volgende en huidige development cycle geïmplementeerd zodat de volgende release ook de oplossing bevat. Op deze manier scheiden we nog meer de verschillende delen en kan er apart gewerkt worden in een tussentijdse hot-fix branch. Hieronder vindt u een schema die een normale flow binnen een project illustreert. Bij de development wordt er telkens een check-in gedaan en bij een afgewerkt geheel een merge naar de main. Daarvan kan je dan naar een release versie gaan voor de klanten. Als er echter daar een fout gegenereerd wordt, kan er een check-in gebeuren om deze fout op te lossen en daarna een check-out gebeuren bij zowel de main als de development omgeving.

Figure 4 Kwaliteit van projecten


30 | 64

STIJN MOREELS



Dit schema is opgesteld tijdens de eerste ontmoeting met Codit. Het geeft direct een realistische kijk op development cyclussen en verbant het idealistische beeld dat er geen enkele fout meer in de release branch plaatsvindt. Eerder werd vermeld dat er twee soorten manieren zijn om een fout in de release op te lossen: 

Fout in de release branch zelf oplossen



Fout migreren naar een aparte branch en daar oplossen

Veronderstel het volgende scenario: in de MAIN branch is alles door de QA unit gecheckt en is klaar voor de volgende release (deze wordt naar de release gebracht, in een staging environment waar de klant verdere fouten kan melden). De fouten die dan in deze omgeving worden gevonden, worden ook onmiddellijk in deze branch opgelost. Wanneer deze testen afgehandeld zijn, wordt de versie naar de productie gebracht. Volgend scenario: wanneer er iets onmiddellijk moet worden gedeployed en niet kan gewacht worden op de volgende release of de goedkeuring van derden, kan er door het development team een aparte branch vanuit de productie afgezonderd worden. Wanneer deze klaar is, wordt dit gemerged met de productie en de main, of met de volgende release. Op deze manier kan er snel gereageerd worden op veranderingen.


31 | 64

STIJN MOREELS



2.6 CONFIGURATION MANAGEMENT 2.6.1

Algemeen

Het management van configuration gaat vooral over het doorvoeren van software updates en versies van hardware. Dit kan voor problemen zorgen binnen bijvoorbeeld een deployment van een product. Het gaat hier dus vooral om de integriteit van een product in productie, doorheen het ALM proces. De “artifacts” spelen hierin een rol, dit zijn specificaties (files, schema’s, scripts, documentatie, …) die het development/deployment proces mee helpen uitvoeren en die bepaalde configuraties bevatten omtrent het komende proces (bv. productie). Ook tussen verschillende teams kunnen artifacts uitgewisseld worden zodat iedereen met dezelfde soort versies bezig is tijdens het developen. Het branchen & merging speelt hierin ook een rol en kan helpen om bijvoorbeeld per branch (DEV, ACC, PROD, …) een andere omgeving op te zetten die andere configuration & artifacts heeft beschreven. Codit werkt echter met verschillende branches per versie, hier moet dus een oplossing worden gevonden om vanuit één branch verschillende staging environments (met verschillende configuration settings) te kunnen deployen. Het managen van dergelijk systeem, over verschillende projecten/teams heen, moet goed doordacht worden.

2.6.2

Integration Cloud Configuration

Als we het over de configuratie van de Integration Cloud van Codit hebben, hebben we het over drie verschillende zaken: 

Workflows: beschrijving van een flow die door de bericht genomen moet worden (met of zonder Custom Activities die geschreven worden = custom aan de flow);



Enpoints: Receive- en Transmit Endpoints;



Mapping: Transformation van berichten via XSLT files;

Bij elk project zitten deze drie zaken standaard in de flow van het klant bedrijf per Business Activity. Hoe IC nu ineen zit, zorgt ervoor dat elk van deze drie puntjes lokaal moet gemaakt worden en manueel op Integration Cloud moet opgeslagen worden. Het probleem dat hierbij gecreëerd wordt is dat elke test die moet uitgevoerd worden op bijvoorbeeld de workflows, telkens eerst opgeslagen moet worden op IC vooraleer er een test kan uitgevoerd worden of de workflow wel degelijk werkt. Dit zorgt niet alleen voor frustratie bij de werknemers, maar ook voor tijdverlies tijdens het development process.


32 | 64

STIJN MOREELS




33 | 64


STIJN MOREELS



3 OPLOSSINGEN 3.1 WORKITEM MANAGEMENT Probleem: Hoe zullen we het workitem management opzetten? Hoe doen we de dagelijkse planning?

Er zijn steeds verschillende features in development die het hele workitem management systeem terug beter maakt. Denk maar aan het verplaatsen van workitems over projecten heen. Dit zou een meerwaarde geven indien er standaard bepaalde zaken per project aangemaakt zouden moeten worden en dit dus telkens herhaald moet worden. De workitem form is ook in januari 2016 terug aangepast om een nog betere feedback te krijgen van je data, wat leidt tot een grotere usability. In volgende delen wordt er in grote lijnen over het workitem systeem binnen TFS gesproken.

3.1.1

Kanban Board

TFS beschikt al over een heel visuele tool om workitems te managen. “Kanban Board” is eerder een algemene term voor wat te vinden is in TFS. Het staat voor de visualisatie van het werk en de workflow, maar ook voor de hoeveelheid of de maximum hoeveelheid WIP (Work in Progress) die mag uitgevoerd worden. Per kolom in TFS kan er een maximum ingesteld worden dat die kolom mag bevatten, naargelang de grootte van het team en de hoeveelheid die verwerkt kan worden. Als startwaarde wordt voorgesteld om niet meer dan 2/3 workitems per member toe te kennen. Dit kan een goede start zijn als eerste test. Per item kan ook de relatieve effort weergegeven worden voor een realistisch overzicht van de workitems, net zoals de toekenning van personen en het bijhouden van de tijd. Dit wordt allemaal gedaan door TFS en kan dagelijks gemonitord worden. Voor de duidelijkheid van de figuur hieronder: Microsoft kiest om de user stories in het blauw aan te duiden en de bugs in het rood. Met de nieuwe build is er een hele hoop usability features toegevoegd aan het Kanban board: bepaalde velden die belangrijk zijn op een task en die meestal gezien wil worden. Een voorbeeld hiervan is het Id van de task of de persoon(en) aan wie de task is toegekend, maar ook een duidelijkere Prioriteit (volgorde) en Severity (impact)… Dit laat toe om met één kijk op het board een hele hoop informatie in één keer te verwerken zonder elke task te openen. Ook het inline aanpassen van tasks zit nu in de nieuwe versie zodat aanpassen ook kan zonder te details te zien van de task.


35 | 64

STIJN MOREELS



3.1.2

Workitem Notifications

Sinds TFS 2012 kunnen er Team- & Individual alerts gegenereerd worden als er bepaalde acties gebeuren rond workitems, maar ook rond builds of check-ins. Dit kan natuurlijk voldoende zijn maar het blijft een wat beperkte lijst. Dit is wel een oplossing voor directe veranderingen (misschien ook niet wanneer er verschrikkelijk veel veranderingen zijn en dus een overload aan notificaties). Notifications van TFS zelf lijkt me daarom wel een goede oplossing maar dit moet dagelijks kunnen getriggerd worden zodat iedereen gemakkelijk zijn takenpakket ziet (al dan niet zelf opgesteld). Met Power Shell kunnen scripts gemaakt worden om deze TFS notifications te triggeren en het script zelf kan dagelijks gepland worden. Dat lijkt me een mooie middenweg tussen het enerzijds afstappen van email verkeer en anderzijds het toelaten om dagelijkse berichten te ontvangen. De logica zelf kan ook eerst in C# geschreven worden om dan omgezet te worden naar een Power Shell script. In Visual Studio zelf kunnen er ook notifications getriggerd worden en daarom is het geen slecht idee om ook hier wat bij stil te staan. Als een werknemer zijn IDE opstart en daarin notifications krijgt van zijn workitems in zijn Team Room, moet hij/zij zelfs nooit online gaan zoeken naar dagelijkse taken. Dan kan de taak zelf direct uitgevoerd worden. Het is zo dat Visual Studio over een hele hoop extensions beschikt en er kunnen ook extensions worden toegevoegd door derden, dus in theorie is het ook mogelijk om een extension te schrijven die de email alerts van TFS zou vervangen door alerts in je IDE zelf. Dit lijkt mij niet alleen een handige maar ook een propere oplossing, want als developer lijkt het mij vooral interessant om mijn werk te zien, wat er van mij verwacht wordt. Het is aan de project manager/architect om de “big picture” te zien en constant in de gaten te houden. De werkverdeling zelf kan misschien nog door een persoon in het midden afgehandeld worden maar de developer zelf die de taak toegewezen krijgt, heeft daar minder zicht op. De plaats waar de notifications zouden opgestapeld worden is afhankelijk van het bedrijf; als het bedrijf gewoon is om samen met de klant de requirements en ook work items eerst in OneNote te maken, kan er misschien ook een link bestaan met de developer zelf en de work item in OneNote (Service Hooks).


36 | 64

STIJN MOREELS



3.1.3

Service Hooks

Per project is er ook de mogelijkheid om met service hooks te werken. Om bepaalde koppelingen te maken met activities die plaatsvinden in het TFS team project en notifications of andere acties buiten TFS is dit een goede optie. Slack, Trello, Zapier, Toggl … zijn maar een paar mogelijkheden. Zeker indien bepaalde individuen met andere platformen gewoon zijn om te werken, is dit een goede oplossing. Als er een bepaald workitem gekoppeld moet worden aan een developer, kan dit nu niet alleen in Visual Studio Online getoond worden maar in verschillende andere programma’s ook. Ook met de Azure producten kan dit gekoppeld worden (Service Bus & Storage), indien het bedrijf eigen tools heeft om dit te triggeren. OneNote werd ook soms gebruikt om user stories aan te maken, of Excel. TFS laat toe om import/export te doen van workitems zodat user stories niet herwerkt en herschreven moeten worden maar rechtstreeks vanuit een gebruikelijkere tool gemaakt kunnen worden (of door niet-technische personen) en toch geen tijd te verliezen in het doorstromen van informatie.


37 | 64

STIJN MOREELS



3.2 RELEASE MANAGEMENT Probleem: Hoe zullen we de Deployment flow organiseren? Hoe en wanneer updaten we de verschillende staging environments? Hoe ver gaan we in de automatisering ervan? Hoe gaan we om met environment specifieke settings?

De Microsoft Release Management tool zorgt voor een geautomatiseerde deployment van het project. Dit houdt rekening met de geschreven testen van het project en zorgt voor een volledige deployment in productie. Release management zorgt dus voor een volledige geautomatiseerde flow tot helemaal aan de productie kant. Het systeem bevat verschillende “release definitions” die per omgeving opgesteld kunnen worden. Deze definitions bevatten de verschillende taken die in de huidige omgeving uitgevoerd moeten worden. Bijvoorbeeld een releasedefinition: het deployen van een deel en testen voor dat deel laten lopen. Indien er eerst voor een bepaalde omgeving (bijvoorbeeld “Acceptance”) een check moet gedaan worden door de architect, tester of project manager; kan er gekozen worden voor “semi-automated”. Dit laat toe om eerst een check te laten uitvoeren door een derde persoon of om op on-hold te plaatsen voor on-demand deployments. Approvals kunnen zowel voor als na de uitgevoerde task zijn. Dit biedt een enorme flexibiliteit. Bepaalde QA cycles kunnen 2/3 weken duren waardoor er een wachtrij ontstaat bij elke development cycle die getest moet worden, daarbij is het handig om een permission te vragen aan je Approval (1). Indien er tijdens een QA tests errors ontstaan kan er na elke task binnenin een environment als exit nogmaals een approval gevraagd worden als de tasks verder moeten lopen met de huidige resultaten van de net afgelopen task. Naast de grote mogelijkheden van Release Management, beschikt het systeem ook over verschillende andere features die het systeem alleen nog aantrekkelijker maakt.

Figure 5 Release Environments New Media and Communication Technology

38 | 64

STIJN MOREELS



Belangrijke Features: 

Release management voorziet ook om niet alleen Cloud deployments maar ook om on-premises deployments.



Security via permissions en rols, hierin kan bepaald worden wie er kan een release managen. Dit kan uiteraard ook toegepast worden op de eerder gemaakte groepen van users, dit zorgt voor een goed onderhoudbaar systeem.



Notifications zitten standaard in Release management zodat iedereen up-to-date blijft van nieuwe builds, commits en nieuwe workitems die gemaakt zijn geweest voor de release.



Tracebility via een logs systeem kunnen alle aanpassingen bijgehouden worden en uitgezocht worden wie wat heeft approved.



Extendibility via marketplace, hierin kunnen verschillende custom tasks aan je release definitions toegevoegd worden. Ook kan er een eigen custom task gemaakt en gedeeld worden indien er bepaalde stappen in het proces (of in de omgeving of on-premise) te specifiek zouden zijn en die niet beschikbaar zijn in de marketplace.

3.2.1

What to Deploy? Artifacts

Artifacts zijn deployable components in je applicatie. Met Artifacts bepaal je welke componenten er deel moeten uitmaken van het resultaat van de build. Zo heb je een beperkte deployment met alleen de items die je echt wilt hebben. Het voordeel is dat via Artifacts de build time die nodig is om de geschreven code om te zetten tot een deployable package aanzienlijk verminderd wordt door na te gaan wat wel en niet gebuild moet worden in de Release.


39 | 64

STIJN MOREELS




40 | 64

STIJN MOREELS



3.2.2

Where to Deploy? Environments

De globale Release bevat verschillende Release Definitions. In deze definitions bevinden zich een verzameling van environments. De simpelste uitleg van wat dit is, is de volgende: Een environment is een beschrijving van waar de release moet worden deployed. Er bestaat een hele misvatting van wat environments nu eigenlijk zijn binnen Release Mangement. Veel wordt er verwezen naar een fysieke flow, waarbij je een “Dev” hebt die gekoppeld is aan een fysieke “Dev” database. Maar deze indruk is verkeerd, environments moet je zien als een fase binnenin je deployment cycle en niet als een vaste implementatie. Er kan evengoed een environment gemaakt worden: “Script Acc”, die gebruikt wordt om de deployment scripts door de architect te laten checken. Dit voorbeeld staat los van een fysieke database die “Script Acc” zou heten, er kan evengoed met dezelfde “Dev” database gewerkt worden. Verschillende environments kunnen ook sterk gelijkaardig zijn en daarom kunnen ze ook binnenin Visual Studio Team Services gecloned worden (een kopie eerder) van de environment waardoor bepaalde tasks per environment niet opnieuw telkens aangemaakt hoeven te worden. Wat ook enorm krachtig is aan environments, zijn de variables. Dit laat toe om bijvoorbeeld verschillende configurations per environment aan te passen met één enkele aanpassing. Want als je alle configurations (connection string, table storage account, …) in variables stopt en deze variable initialiseert in je environment, hoef je deze initialisatie alleen maar aan te passen als je een environment kopieert. Standaard zijn er bepaalde templates voor environments die toelaten om werk wat over te nemen, deze templates kunnen ook zelf aangemaakt worden om een nog betere custom environment te hebben. Voor Codit is dit echter niet genoeg want voor sommige omgevingen moet er een volledig object vervangen worden (inclusief properties), zodat dit object naar een ander endpoint kan verwijzen in verschillende omgevingen. Daarom zal er binnenin Release Management custom logica geschreven worden die verdere custom configuratie aanpakt.


41 | 64

STIJN MOREELS



3.2.3

How to Deploy? Tasks

Voobeelden: kopiëren van files, het runnen van verschillende testen (ook performance, load, …), clean up, …

Figure 6 Add Tasks

Voor een meer maintainably oplossing kan in een environment een “Azure Resource Group Deployment” task gemaakt worden die een hele hoop default variables kan instellen voor de hele environment die achteraf overschreven kunnen worden door andere build definitions. (dit brengt een enorme maintainability met zich mee).


42 | 64

STIJN MOREELS



3.3 PACKAGE MANAGEMENT Probleem: Hoe gaan we om met environment specifieke settings? Qualiteit enablement (kwaliteit van de code en oplossing verhogen)?

Het voordeel aan packages, is dat het een stuk eenvoudiger is indien bepaalde stukken opnieuw gebruikt moeten worden. Dit kan zowel binnen de organisatie zelf zijn of externe componenten. Het probleem dat zich direct voordoet zijn versies, versies van deze packages. Indien er een package binnen de organisatie gemaakt wordt om verdere projecten niet alleen op dezelfde manier te laten werken met een systeem maar ook om een snellere sprint te hebben, wordt dit over verschillende projecten heen gebruikt. Indien deze package geüpdatete wordt, moet er gemonitord worden welke projecten deze package gebruikt hebben en als het nog steeds werkt met de nieuw versie. Gewoon al aan de uitleg van het probleem voel je al dat deze manier van werken een vervelende aanpak is en niet houdbaar.

Figure 7 Package Management

Het Package Management systeem van Microsoft is een extension (Marketplace) voor Visual Studio Team Services die toelaat om verschillende packages te zoeken, installeren en publishen. Het systeem laat ook toe om deze packages dan in het ene team te sharen met andere teams. Het management systeem van deze extension bevat ook permissies zodat er steeds controle gehouden kan worden over wie toegang heeft tot welke packages. Aangezien deze paper een onderzoek is rond ALM, zou deze oplossing ook een mogelijkheid moeten bieden om in het ALM verhaal te passen. En dat is er ook. Dit systeem is sterk geïntegreerd met de workflows binnen TFS. Zo kan er bijvoorbeeld voor een solution binnenin een build een extra step aangemaakt worden met een NuGet installer die de juiste packages installeert voor deze solution. Samen met een path naar de .config file kan er bepaald worden welke versies nodig zijn voor de solution. Als de .config file een vaste structuur bevat en bedrijfsafhankelijk wordt, kunnen hier veel problemen optreden die in het voorgaande geval, zonder Package Management systeem uit de weg genomen worden. Alleen al de monitoring van de packages kan op een propere manier afgehandeld worden. In een flow kan niet alleen de NuGet packages geïnstalleerd worden, voor een eigen package in het bedrijf die via locale NuGet servers beschikbaar gesteld worden, kan er ook bijvoorbeeld ook een NuGet package aangemaakt worden en worden gepublishd. New Media and Communication Technology

43 | 64

STIJN MOREELS



Figure 8 NuGet Build Steps

3.3.1

Package Management Feedback

Door mijn interesse rond Software Design en Architectuur spreekt deze oplossing mij enorm aan want zo is er nog een abstractere connectie tussen verschillende componenten in het bedrijf. Zo wordt het hele management ook uit handen genomen en weten de componenten nog minder van elkaars mogelijkheden. Niet alleen de implementatie maar ook bijvoorbeeld de versie van de package is voor de componenten uit handen genomen.


44 | 64

STIJN MOREELS



3.4 QUALITY ASSURANCE BEST PRACTICES Probleem: Qualiteit enablement (kwaliteit van de code en oplossing verhogen)

3.4.1

Aanpak

Het probleem is dat met verschillende projecten/teams de documentatie, time tracking, workitems, code reuse, … zaken zijn die in een hoger niveau moet vastgelegd worden en als guideline dienen voor alle projecten, zodat niet alleen traceability binnenin het project wordt vergroot, maar ook switchen van projecten minder een probleem wordt. Bijvoorbeeld: het “Copy-paste programming” lijkt op het eerste zicht een de gemakkelijkste & snelste oplossing voor repetitieve code. Maar dit is echter zeer onstabiel en toekomstgericht onhoudbaar. Generic Libraries (bv. NuGet packages) kunnen hierbij bijvoorbeeld een oplossing bieden, waarbij het aanpassen in een local shared server eenmalig hoeft aangepast te worden. Ook de verschillende deployment scripts, test scripts, … zouden in een externe library moeten zodat iedereen met exact dezelfde zaken werkt. (Dit kan ook opgenomen worden in het “Package Management” zodat ook dit zo abstract mogelijk geregeld wordt en de verschillende versies gemonitord worden.) Deze aanpak zou de tijd die in deployment scripts gestoken wordt aanzienlijk verminderen en het voordeel van abstractie vergroten. Zo kan meer tijd gestoken worden in de business logica zelf van de klant. Het zou moeten de reflex zijn van iedere software developer om ervoor te zorgen dat code op een zo efficiënt mogelijke manier hergebruikt kan worden.

3.4.2

Documents

Het documenteren van zowel het environment als de documenten van de klanten zelf moet ook gelinkt worden aan het project management (& source control). Koppeling met SharePoint kan hier zeker een oplossing bieden. Attachments in Workitems zelf zou ook een mogelijkheid zijn om documenten op te slaan, maar dit is meer voor het workitem zelf en niet voor het algemene project. Als extra is het ook belangrijk dat software designs en andere architecturale beslissingen meegenomen worden in de source control en dus ook de documentatie binnenin het team project.


45 | 64

STIJN MOREELS



3.5 UITEINDELIJK STAPPENPLAN Probleem: Het probleem dat zich ontwikkelde binnen Integration Cloud bevond zich in de configuratie van de workflows, endpoints & mapping doordat deze lokaal moesten gemaakt worden en pas konden worden getest nadat deze zijn opgelslagen in IC.

3.5.1

Algemeen

In het voorgaande werd telkens een mogelijke oplossing aangeraakt die eventueel tot een uiteindelijke beslissing kan leiden. In dit deel wordt het stappenplan dat samen met Codit (Thomas Houtekier) werd opgesteld, overlopen. Dit biedt een uiteindelijke oplossing op het vlak van automatisering, kwaliteitscontrole & integratie binnen een ALM verhaal in functie van Codit. Tijdens de stage werden de drie fases besproken en uitgewerkt en de algemene indruk van deze fases zal ook in dit document uitgelegd worden. Het is echter zo dat vooral de eerste fase in dit document grondig zal worden uit de doeken gedaan aangezien mijn stage nog niet ten einde is en mijn bachelorproef wel. Daarom is het goed om dit document als een vooronderzoek te zien zoals eerder gezegd maar ook als een eerste stap in het bieden van een oplossing voor het probleem van ALM binnen Codit. De fases zelf bieden elk op zich een oplossing voor een bepaald probleem binnen ALM. De problemen werden één voor één aan mij voorgesteld maar het was mijn taak om deze problemen in een stappenplan op te lossen. De stage zorgde ervoor dat de verschillende zaken rond de interne processen binnen Codit niet alleen werden verbeterd op vlak van automatisering & kwaliteit maar ook in het kader van onder-houdbaarheid en aanpasbaarheid in de toekomst (bespreking fase 1). Daarom kan er met trotsheid teruggekeken worden op het geleverde onderzoek en analyses die werden uitgevoerd voor Codit.


46 | 64

STIJN MOREELS



3.5.2

Fases

Fase 1: Solution Template & Naming Validations In de eerste stap is het de bedoeling dat er een “template” gemaakt wordt die telkens opnieuw gebruikt kan worden over verschillende projecten heen in Integration Cloud. Deze template zal standaard aan een aantal naamgevingsregels voldoen. Verder wordt er een build opgezet die tijdens dit proces de regels rond naamgeving valideert. Uiteindelijk wordt er een package gegenereerd die later in het proces kan gedeployed worden. Met deze fase lossen we het probleem op rond kwaliteitscontrole in een project door de naamgevingsregels niet als optioneel te beschouwen maar als een verplicht deel van het ALM verhaal.

Fase 2: Package Deployment in Build In de tweede fase is het belangrijk dat de deployment cyclus bekeken wordt. Na het genereren van de package in de vorige fase moet dit gepubliceerd worden naar Integration Cloud. Op de dag van vandaag gebeurt dit manueel en dit kan voor veel frustratie zorgen, daarom wordt er in het tweede deel een oplossing gezocht. Het facade design pattern wordt toegepast op deployment niveau waarbij deze facade het genereerde package ontvangt en deployed naar de juiste plaats binnenin Integration Cloud. Deze deployment cyclus is niet de deployment in productie maar is een deel van het build proces binnen Codit.

Fase 3: Configuration Management In de derde fase wordt de effectieve configuratie van verschillende omgevingen bekeken en verbeterd. Verschillende omgevingen (Development, Test, Productie, …) bevatten allemaal andere configuratie en endpoints. Het management hiervan moet ook geautomatiseerd en gemanaged worden. Hiervoor wordt Release Management gebruikt die per omgeving bepaalde configuratie klaarzet zodat het project per omgeving anders wordt geconfigureerd. New Media and Communication Technology

47 | 64

STIJN MOREELS



3.5.3

Schema

Onderstaand schema geeft een globale indruk over de verschillende fases en de volledige flow dat is uitgewerkt tijdens de stage. Eerst wordt het package gegenereerd door de verschillende build steps. Daarna wordt er door release management het pakket aangepast voor de juiste omgeving (DEV, TEST, PROD, …). Als laatste stap wordt dit pakketje doorgegeven aan de façade op Integration Cloud die verder het pakketje installeert op de omgeving en alle configuratie verder aanpakt.

Figure 9 Schema Fases


48 | 64

STIJN MOREELS



3.5.4

Fase 1: Aanpak Naming Conventions

In Codit hebben we een Solution Template gemaakt die standaard al aan een hele hoop naam conventies voldeed. Hierdoor verminderen we de tijd die gestoken wordt aan het creëren van folders/files die standaard toch in elk project dezelfde zijn. Deze template hebben we voor iedereen in het bedrijf publiek gemaakt zodat iedereen met dezelfde start solution en dus met dezelfde correcte namen werkt voor de verschillende items. De template zelf is niet een gewone template die standaard door Visual Studio wordt aangeboden maar een Extensie (VSIX). Het probleem met een standaard template van VS is dat het niet toelaat om extra logica (Wizard) toe te voegen en om een multi-project solution te maken. Daarom is er voor een VSIX extension gekozen die ook in de toekomst kan uitgebreid worden met extra custom item template controls die door Codit eventueel nog moeten geleverd worden (bv. Custom Activities) binnen Integration Cloud. Ook werd er standaard een configuration file aangemaakt binnenin deze template die dynamisch andere content bevat naargelang de naam die gegeven is geweest voor de solution template. Doordat deze file in de solution meegegeven wordt en dus ook under source control meegestuurd wordt, kan later de build steps gecustomiseerd worden volgens de file die meegeven wordt in de solution (later meer duiding wat deze config file bevat van content).

Figure 10 Solution Template New Media and Communication Technology

49 | 64

STIJN MOREELS



3.5.5

Fase 1: Validatie Naming Conventions

Team Foundation Build laat toe om een volledig eigen build te maken voor je project. Indien we de vooraf besproken naamgevingsregels toepassen op alle projecten die voor IC gemaakt worden, kunnen we dit proces automatiseren omdat elke file/folder/… dan in elk project dezelfde structuur heeft. Wat er wel moet worden opgevangen, zijn de naamgevingsregels zelf. Hoe kunnen deze worden opgevangen? Custom Build Steps boden de oplossing, dit laat toe om een eigen build task extension te schrijven (lokaal) en die dan na het opslaan op TFS zelf, te sharen over verschillende team projecten. Lokaal werd er dus een extension gemaakt met een powershell script die de naamgevingsregels bekeek van de solution. Wanneer deze custom build step aan de build van het project wordt toegevoegd, kan er dus bij elke build niet alleen naar fouten binnen de code gezocht worden maar ook naar de bedrijfsspecifieke naamgevingsregels van Codit. Binnenin het PowerShell script werd gebruik gemaakt van een configuration file waarin de verschillende naamgevingsregels opgesteld zaten (Zie bijlage: 4.3.1.2 Bijlage 2: PowerShell script). De reden dat deze in een aparte file werden opgeslagen en niet gewoon als opties aan de custom build step werden meegegeven, is omdat verder in het ALM verhaal deze regels ook nodig zijn, voor de Deployment. Nu werd alleen maar besproken hoe we de build aanpassen op naamgevingsregels. We kunnen ook bij elke check-in van de developers deze validatie uitvoeren zodat de naamgeving deel wordt van de ALM flow en dus deel van de werking van het project.


50 | 64

STIJN MOREELS



3.5.6

Fase 1: Naming Conventions Config File

Wat staat er nu effectief in deze configuratie file? De file structuur (XML) werd zelf uitgedacht door analyse en is future proof aangezien dezelfde structuur gebruikt kan worden voor projecten die niet voor Integration Cloud gemaakt zullen worden. De boomstructuur met de naamgevingsregels die verplicht te volgen is, kan in deze file geschreven worden door middel de -tag. Dit laat toe om gelijk welke boomstructuur op te stellen, bijvoorbeeld: Elke -tag heeft de mogelijkheid om verschillende attributen te krijgen die telkens slaan op de specifieke regels die de solution moet volgen. 

template=”” : Dit laat toe om een Reguliere expressie mee te sturen die de naam van de folder beschrijft;



files=”” : Dit laat toe om een Reguliere expressie mee te sturen die de naam van de files binnenin de folder beschrijft;



ext : Dit laat toe om de extensie van de files mee te geven zodat het script kan zoeken naar de juiste files en niet al de files moet overlopen. (meerdere: *.xsd;*.xaml);



skip : Dit laat toe om een folder te beschrijven in de tree structuur maar om de folder zelf over te slaan om de files binnenin de folder te onderzoeken (bv: packages);

Bijvoorbeeld: Door deze eenvoudige en leesbare manier van werken kunnen extra folders ook manueel worden toegevoegd om zo een nog preciezere validatie te creëren voor het project.


51 | 64

STIJN MOREELS




52 | 64

STIJN MOREELS



4 BESLUIT 4.1 BESPREKING VAN HET PROJECT Voor de ontwikkeling van projecten binnenin Integration Cloud (product van Codit) is er nood aan een volledig geautomatiseerde ALM oplossing. Deze oplossing moet bepaalde handelingen die nu manueel worden uitgevoerd uit handen nemen. Op deze manier wordt het ontwikkelen van projecten voor Integration Cloud niet alleen gemakkelijker maar ook efficiënter. Tijdens het uitwerken van de oplossing werd constant bepaalde handelingen in vraag gesteld om een zo stabiel mogelijke oplossing te bereiken. Ook werden verschillende oplossingen besproken en geanalyseerd. Indien het voldeed aan de eisen van Codit kon het verder worden uitgewerkt en geïmplementeerd. De oplossing zelf is abstract opgebouwd zodat de implementatie in de toekomst telkens verbeterd kan worden. Integration Cloud is een custom made product van Codit waardoor het ook een custom made ALM flow nodig had. Door de uitwerking van dit project heeft dit product nu een eigen gestructureerde ALM oplossing.


54 | 64

STIJN MOREELS



4.2 KRITISCHE REFLECTIE Tijdens de uitwerking van dit project heb ik veel zaken geleerd. Mijn passie ligt in software architectuur en ondanks dat dit project op het eerste zicht niet direct in die branche ligt heeft het mijn visie en passie van architectuur alleen maar aangewakkerd. Het software architecture principe: YAGNI (You aren’t gonna need it) heb ik in dit project aan den lijve ondervonden. Aangezien Integration Cloud het enige custom made product is van Codit had het geen zin om bepaalde oplossingen generisch aan te pakken want het zou toch niet generisch gebruikt worden. Ook werden sommige idealistische beelden die ik had over architectuur en software discipline gewijzigd doordat ik de praktijk voor ogen zag. Ik heb het gevoel dat door praktische projecten mijn visie constant zal wijzigen en ik daardoor mezelf meer en meer bijschool tot de software architect die ik wil worden. Tijdens wekelijkse meetings besefte ik de kracht van communicatie en hoe snel bepaalde zaken verkeerd begrepen kunnen worden. Dit kan leiden tot groot tijdverlies. Daarom besef ik nu meer dan ooit dat tijdens meetings met klant, collega’s… communicatie de sleutel is tot een geslaagd project.


55 | 64

STIJN MOREELS



4.3 CONCLUSIES De onderzoeksvraag van deze bachelorproef was de volgende: Hoe behoud je de kwaliteit van projecten door de ALM processen te verbeteren? Doordat de vraag zelf een algemene vraagstelling is en een enorm breed gebied beschrijft is het antwoord op deze vraag ook niet met één zin te beschrijven. In het document zijn er verschillende oplossingen aangekaart en finaal een stappenplan opgesteld die geselecteerde oplossingen bundelt in één globaal schema. Dit schema kan als leidraad dienen om de oplossing beter in kaart te brengen. Door onderzoek is gebleken dat ALM binnen projecten geen optie is maar een MUST indien er kwaliteitsvolle projecten afgeleverd moeten worden. Ook kan er door deze aanpak verschillende operaties geautomatiseerd worden waardoor manuele tussenkomst beperkt wordt. De oplossing die hier beschreven werd beschrijft verschillende stappen in een proces om een custom made product om te vormen tot een waardevol ALM geïntegreerd product. 1. Naamgevingsregels die vooraf opgesteld zijn en niet alleen een duidelijk overzicht geven op het hele project maar ook een propere en kwaliteitsvol eindproduct afleveren. Deze regels moeten te allen tijde gevalideerd worden. Een vooraf opgestelde template kan hierin helpen om zo standaard al de correcte aanpak op te stellen; 2. Het Deployen van het product kan op een generische manier opgelost worden aangezien in deze stap de naamgevingsregels correct zijn en dus op voorhand de locatie van bestanden gekend is. Dan is het alleen maar een kwestie van de verschillende artifacts op te lijsten die nodig zijn in een verder deployment van het product; 3. Doordat er telkens verschillende Environments zijn moet er een “adapter” ingebouwd worden die de configuratie aanpakt per omgeving specifieke noden. Dit kan alleen maar als de configuratie in het begin van het proces op een abstracte manier is opgesteld en daardoor op een eenvoudige manier andere configuratie kan ingeplugd worden; Deze oplossing is specifiek gemaakt voor Integration Cloud maar door de globale aanpak en visie kan het een oplossing zijn voor elk custom made software product die nood heeft aan een ALM oplossing. Het is belangrijk om telkens deze drie puntjes in het achterhoofd te houden en zeker voor een abstracte oplossing te zoeken indien er meerdere custom made producten zijn. Het zal niet alleen een opluchting zijn voor het hele team dat automatische deployment gerealiseerd wordt maar ook een geruststelling dat de ALM oplossing de manuele taken, die altijd meer fouten kunnen bevatten, overneemt. In elk bedrijf is er nood aan een ALM oplossing en daarom is het belangrijk dat iedereen hier voor open staat en dit met een kritische geest implementeert.


56 | 64

STIJN MOREELS



FIGURENLIJST Figure 1 Microsoft Logo ................................................................................................................................... 21 Figure 2 Application Lifecycle Management for BizTalk and Azure integration development ........................ 22 Figure 3 Codit Integration Cloud ...................................................................................................................... 23 Figure 4 Kwaliteit van projecten ...................................................................................................................... 30 Figure 5 Release Environments ...................................................................................................................... 38 Figure 6 Add Tasks.......................................................................................................................................... 42 Figure 7 Package Management ...................................................................................................................... 43 Figure 8 NuGet Build Steps ............................................................................................................................. 44 Figure 9 Schema Fases................................................................................................................................... 48 Figure 10 Solution Template ........................................................................................................................... 49


57 | 64

STIJN MOREELS



BRONNEN- & LITERATUURLIJST Day, B. (2012, 5 oktober). ALM with TFS 2012 Fundamentals [Video]. Geraadpleegd van https://app.pluralsight.com/library/courses/alm-fundamentals/table-of-contents Codit. (z.j.). Application Lifecycle Management for BizTalk and Azure integration development. Geraadpleegd van http://www.codit.eu/what-we-do/our-services/alm-application-lifecycle-management/ Behat. (z.j.). writing features - gherkin language. Geraadpleegd van http://docs.behat.org/en/v2.5/guides/1.gherkin.html Microsoft. (z.j.). Add workitems to plan and track your project. Geraadpleegd van https://msdn.microsoft.com/library/vs/alm/work/backlogs/add-work-items Microsoft. (z.j.). Agile Tip #1 – Epics and Themes. Geraadpleegd van http://blogs.msdn.com/b/aaronbjork/archive/2010/04/19/msf-agile-5-0-tip-1-epics-and-themes.aspx Microsoft. (z.j.). Kanban basics. Geraadpleegd van https://msdn.microsoft.com/Library/vs/alm/work/kanban/kanban-basics Johnson, P. (z.j.). Testing and Code Coverage. Geraadpleegd van http://pjcj.net/testing_and_code_coverage/paper.html Harry, B. (2015, 29 april). Visual Studio and Team Foundation Server at Build 2015. Geraadpleegd van http://blogs.msdn.com/b/bharry/archive/2015/04/29/visual-studio-and-team-foundation-server-at-build2015.aspx Microsoft. (z.j.). What is Azure IoT Hub? Geraadpleegd van https://azure.microsoft.com/en-us/documentation/articles/iot-hub-what-is-iot-hub/ Microsoft Power BI. (z.j.). Getting started with Power BI Desktop. Geraadpleegd van https://powerbi.microsoft.com/en-us/documentation/powerbi-desktop-getting-started/ Atwood, J. (z.j.). Software Branching and Parallel Universes. Geraadpleegd van http://blog.codinghorror.com/software-branching-and-parallel-universes/ Microsoft. (z.j.). Team Foundation Server 2015 RTM. Geraadpleegd van https://www.visualstudio.com/enus/news/tfs2015-vs.aspx#kanban Microsoft. (z.j.). Automate deployments with Release Management. Geraadpleegd van https://msdn.microsoft.com/en-us/Library/vs/alm/Release/previous-version/release-management-overview Microsoft. (z.j.). Visual Studio Release Management for Azure VMs. Geraadpleegd van https://azure.microsoft.com/en-us/blog/visual-studio-release-manager-for-azure-vms/ Microsoft. (z.j.). Understanding Microsoft Release Management. Geraadpleegd van https://msdn.microsoft.com/Library/vs/alm/Release/getting-started/understand-rm Popov, A. (2014, 18 juli). DevOps Tools by Microsoft. Geraadpleegd van http://blog.dataart.com/devopstools-by-microsoft/ Microsoft. (2016, 27 januari). Package Management. Geraadpleegd van https://marketplace.visualstudio.com/items?itemName=ms.feed


58 | 64

STIJN MOREELS



Microsoft. (z.j.). DevOps and Application Lifecycle Management. Geraadpleegd van https://msdn.microsoft.com/library/fda2bad5 Microsoft. (z.j.). Integrate with service hooks. Geraadpleegd van https://www.visualstudio.com/en-us/getstarted/integrate/integrating-with-service-hooks-vs Microsoft. (z.j.). What to deploy? Artifacts in Microsoft Release Management. Geraadpleegd van https://msdn.microsoft.com/Library/vs/alm/Release/author-release-definition/understanding-artifacts Microsoft. (z.j.). Where to deploy? Environments in Microsoft Release Management. Geraadpleegd van https://msdn.microsoft.com/en-us/Library/vs/alm/Release/author-release-definition/understanding-environments Microsoft. (z.j.). How to deploy? Tasks in Microsoft Release Management. Geraadpleegd van https://msdn.microsoft.com/en-us/Library/vs/alm/Release/author-release-definition/understanding-tasks Microsoft. (z.j.). Power BI - Overview and Learning. Geraadpleegd van https://support.office.com/en-us/article/Power-BI-Overview-and-Learning-02730e00-5c8c-4fe4-9d77-46b955b71467 PractiTest. (z.j.). Application Lifecycle Management (ALM). Geraadpleegd van http://www.practitest.com/application-lifecycle-management/ Wikipedia. (z.j.). Artifact (UML). Geraadpleegd van https://en.wikipedia.org/wiki/Artifact_(UML) Software Engineering Institute. (z.j.). Configuration Management. Geraadpleegd van http://www.sei.cmu.edu/productlines/frame_report/config.man.htm Microsoft. (z.j.). Code Metrics Values. Geraadpleegd van https://msdn.microsoft.com/en-us/library/bb385914.aspx Driessen, V. (2010, 05 januari). A successful Git branching model. Geraadpleegd van http://nvie.com/posts/a-successful-git-branching-model/ Ruehlen, A. (2013, 06 november). Hotfix or Not? Managing a Successful Release Process. Geraadpleegd van https://viget.com/advance/successful-release-management-and-how-to-communicate-about-it


59 | 64

STIJN MOREELS



OVERZICHT VAN DE BIJLAGEN 1

Configuration file

2

PowerShell script


60 | 64

4.3.1.1

Bijlage 1: Configuration file

Onderstaand schema is een voorbeeld van een vereenvoudige configuration file. Deze file wordt standaard in de Solution Template geplaatst en bevat bepaalde vaste naamgevingsregels. <solution>


61 | 64

4.3.1.2

Bijlage 2: PowerShell script

Onderstaande code snippet is een deeltje van het script dat de naamgevingsregels valideert. Door een recursieve oproep kan de configuratie file een eindeloze boomstructuur bevatten en kan dit script het blijven verwerken. Merk op: deze versie is een versie die tijdens de eerste weken werd geschreven, er wordt nog tijd vrijgemaakt om refactoring toe te passen en om een betere functie structuur op te zetten. ## verify folders (list) for a given 'target' (directrory) function Verify-Folders($target, $folders) { # 1. $folders got childs? if($folders.ChildNodes.Count -ge 0) { # 2. Yes? -> find foreach the map with the given target foreach($folder in $folders.ChildNodes) { # skip comments if($folder.GetType() -eq [System.Xml.XmlComment]) { continue } # 2.1 get template from folder $template = Get-Name-Template $folder # 2.2 search for the folder $item = ($target.EnumerateDirectories() | Where { $_.Name -match $template }) if($item -ne $null) { # 2.3 valid folder found Write-Host ($successCodit + $target + "\" + $item + " where correct") # 2.4 verify files in current folder Verify-Files $item $folder # 3. recursive verify for subfolders Verify-Folders $item $folder } else { # 2.3 no valid folder found throw ($errorCodit + "folder not found with template: " + $template + " in folder: " + $target) } } } }


62 | 64

HOE BEHOUD JE DE KWALITEIT VAN PROJECTEN DOOR DE ALM PROCESSEN TE VERBETEREN? PROMOTOR: MH DIETER DE PREESTER

Recommend Documents