Subsections of 6. Software Management

Continuous Integration & Deployment

Continuous Integration (CI)

Het softwareontwikkel proces is een continu proces: als een eerste versie van het product klaar is, en wordt overgemaakt aan klanten, volgt het onderhoud en een mogelijke volgende versie. Elke wijziging maakt potentiëel dingen kapot (geminimaliseerd met TDD), of introduceert nieuwe features. Dat betekent dat bij elke wijziging, een computer het hele build proces moet doorlopen om te controleren of er niets stuk is. Dit noemen we het “integreren” van nieuwe code, vandaar de naam.

De CI Server

In de praktijk worden aparte servers verantwoordelijk gesteld om regelmatig de hele codebase te downloaden, alles te compileren, en testen uit te voeren. Als iets niet compileert, of een test faalt, rapporteert dit systeem via diverse kanalen aan de ontwikkelaars. Niemand wilt dit in de achtergrond op zijn eigen machine een tweede build systeem geïnstalleerd hebben, die CPU kracht afsnoept van je eigen PC. De volgende Figuur verduidelijkt de flow (bron):

Dit hele proces verloopt volledig automatisch: niemand drukt op een “build” knop, maar door middel van ingecheckte code wijzigingen (1) start dit systeem. De CI server haalt wijzigingen op (2), build (3) en test (4) om te kunnen rapporteren of dit lukte of niet (5), via verschillende kanalen (6).

De Source Control server, zoals Github.com of een lokale git server, werd reeds besproken in labo ‘versiebeheer’. Er zijn voor Java verschillende populaire CI software systemen:

  • TeamCity van JetBrains, de makers van IntelliJ
  • Bamboo—van Atlassian, de makers van Jira
  • Travis—de eerste CI die naadloos met GitHub integreerde, maar nu betalend is
  • CirlceCi—een populair hosted alternatief voor Travis
  • Jenkins—een ondertussen oudere speler op de CI markt
  • Drone—een nieuwe speler met focus op Docker module integratie
  • Dagger—een CI/CD engine die in containers runt en programmeerbaar in plaats van configureerbaar is

Deze systemen zijn configureerbaar en beschikken over een UI, zoals bijvoorbeeld zichtbaar in de TeamCity screencast. Betalende systemen zoals TeamCity en Bamboo zijn erg uitgebreid, en er zijn ook een aantal gratis alternatieven zoals CircleCI. CircleCI is eenvoudig configureerbaar door middel van een .yml bestand en het gratis plan integreert naadloos met GitHub. Wij gaan echter rechtstreeks via Github Actions werken aangezien dit rechtstreeks via Github kan geconfigureerd worden en op zeer gelijkaardige manier werkt zoals bovenstaande services.

De flow van een CI server

Je Github Actions moeten gedefinieerd worden in de folder .github/workflows in een .yml-bestand. Github helpt je echter om snel veelgebruikte actions op te stellen op basis van je code in de repository.

Via het Actions tabblad worden enkele voorstellen gedaan. Je kan gebruik maken van de Gradle test template. Je .yml-bestand wordt automatisch aangemaakt en zie er uit zoals op onderstaande figuur is weergegeven

example.yml example.yml

Let op: de yml-syntax is zeer gevoelig aan het juiste gebruik van tabs en spaces (gelijkaardig aan python)

1. on

Onder de on sectie ga je definiëren bij welke specifieke acties de onderstaande jobs uitgevoerd moeten worden.

2. Setup Environment

In de jobs sectie kunnen we dan verschillende jobs oplijsten. In het begin van elke job moeten we vermelden op welk besturingssysteem we onze job willen uitvoeren. (Bv. Windows, Mac, Linux).

Je kan jobs ook automatisch op meerdere besturingssystemen laten uitvoeren.

We moeten er natuurlijk ook voor zorgen dat alle applicaties aanwezig zijn om onze code te kunnen compileren en runnen. Daarvoor moeten we de nodige tools installeren in deze virtuele omgeving!

3. Build Code

Nu kunnen we simpelweg gebruik maken van de Gradle tasks.

4. Package Code & Upload Artifact

Zodra één stap mis gaat (zoals een falende test), worden volgende stappen niet uitgevoerd. Als alles goed gaat is de output van het builden de binary die we het artifact noemen, die de huidige buildstamp draagt (meestal een datumcode).

Alle gebuilde artifacts kunnen daarna worden geupload naar een repository server, zoals de Central Maven Repository, of onze eigen artifact server, waar een historiek wordt bijgehouden. (Dit gaan we niet doen in deze cursus)

5. Publish Results

In de README.md van je repository kan je een Github Badge plaatsen die de status van je action snel weergeeft.

Github badge Github badge

Je kan dit toevoegen via onderstaande code:

![example workflow](https://github.com/USERNAME/REPONAME/actions/workflows/YMLFILENAME.yml/badge.svg)
Tip

Bij de opdrachten zal je repository onder de organisatie KULeuven-Diepenbeek staan, en niet onder je eigen username.

2. Continuous Deployment (CD)

Automatisch code compileren, testen, en packagen, is slechts één stap in het continuous development proces. De volgende stap is deze package ook automatisch deployen, of installeren. Op deze manier staat er altijd de laatste versie op een interne development website, kunnen installaties automatisch worden uitgevoerd op bepaalde tijdstippen, …

Populaire CD systemen:

  • Octopus Deploy
  • Codeship
  • Modules van moderne CI systemen zoals hier boven vermeld, bijvoorbeeld Dagger/Drone Deployment
  • Eigen scripts gebaseerd op CI systemen
  • Cloud deployment systemen (Amazon AWS, Heroku, Google Apps, …)

Automatisch packagen en installeren van programma’s stopt hier niet. Een niveau hoger is het automatisch packagen en installeren van hele omgevingen: het virtualiseren van een server. Infrastructuur automatisatie is een vak apart, en wordt vaak uitgevoerd met behulp van tools als Puppet, Docker, Terraform, Ansible of Chef. Dit valt buiten de scope van deze cursus.

2.1. De flow van deployment en releases beheren

Nieuwe features in productie plaatsen brengt altijd een risico met zich mee. Het zou kunnen dat bepaalde nieuwe features bugs veroorzaken in de gekende oude features, of dat het (slecht getest) systeem helemaal niet werkt zoals men verwachtte. Om dat zo veel mogelijk te vermijden wordt er een release plan opgesteld waarin men aan ‘smart routing’ doet.

Stel, onze bibliotheek-website is toe aan vernieuwing. We wensen een nieuw scherm te ontwerpen om efficiënter te zoeken. We zijn echter niet zeker wat de gebruikers gaan vinden van deze nieuwe manier van werken, en beslissen daarom om slechts een aantal gebruikers bloot te stellen aan deze radicale verandering. Dat kan op twee manieren:

  1. Blue/green releasing: Een ‘harde switch’ in het systeem bepaalt welke personen (bijvoorbeeld op regio of IP) naar versie van het zoekscherm worden begeleid.
  2. Canary releasing: Een load balancer verdeelt het netwerkverkeer over verschillende servers, waarvan op één server de nieuwe versie is geïnstalleerd. In het begin gaat 90% van de bezoekers nog steeds naar de oude versie. Dit kan gradueel worden verhoogd, totdat de oude server wordt uitgeschakeld.

Onderstaand schema verduidelijkt dit idee (bron).

De juiste logging en monitoring tools zorgen ervoor dat we een idee krijgen over het gebruik van het nieuwe scherm (groen, versie B). Gaat alles zoals verwacht, dan wordt de switch weggehaald in geval (1), of wordt de loadbalancer ge-herconfigureerd zodat het hele verkeer naar de nieuwe site gaat in geval (2). Ook deze aanpassingen zijn volledig geautomatiseerd. Na verloop van tijd valt de oude versie (blauw, versie A) volledig weg, en kunnen we ons concentreren op de volgende uitbreidingen.

Het groene vlak, de ‘Ambassador/API gateway’, kan aanzien worden als:

  • Een fysiek aparte machine, zoals een loadbalancer.
  • Een publieke API, die de juiste redirects verzorgt.
  • Een switch in de code, die binnen dezelfde toepassing naar scherm 1 of 2 verwijst.

Versie A en B hoeven dus niet noodzakelijk aparte versies van applicaties te zijn: dit kan binnen dezelfde applicatie, softwarematig dus, worden ingebouwd.

Oefeningen (enkel ter oefening, de verplichte opdracht rond CI vind je bij de andere opdrachten)

Volgende videos kunnen je helpen bij het oplossen van de oefeningen en de uiteindelijke opdracht:

Oefening 1

Ontwerp een ‘calculator’ applicatie die 2 getallen kan optellen, aftrekken, het product en het quotient (zonder rest) kan berekenen. (gebruik Gradle)

  1. Schrijf een aantal testen voor deze applicatie.
  2. Maak een github repository aan en gebruik Github Actions om je applicatie automatisch te laten testen bij een push naar de main branch.

Oefening 2

Gebruik een andere workflow.yml om je repo uit opgave 1 te beveiligen tegen pull-requests. Zorg ervoor dat eerst je testen moeten slagen en je applicatie gebuild kan worden voordat je een pull request kan toelaten. (Test dit ook uit met een medestudent).

Kijk in Github bij de settings van je repo -> branches -> require status checks

Let op: je repo moet hiervoor public zijn. Je kan zoeken op status checks via de job names in je .yml action files

Software Management Skills

De chaos van het Werk

De technische kant van het ontwikkelproces is slechts één kant van de medaille. De keerzijde bestaat uit het werk beheren en beheersen, zonder ten prooi te vallen aan de grillen van de klant of de chaos van de organisatie ervan.

Stel, een gemeente vraagt om een nieuwe website te ontwikkelen voor de lokale bibliotheek. Er wordt een vergadering ingepland met stafhouders om samen met jou te beslissen wat de vereisten zijn. Ze dachten aan een mooie visuele website (1) waar men ook on-line kan verlengen (2) en het profiel raadplegen (3). De website moet uiteraard de gebruiker laten weten of een boek is uitgeleend of niet (4), en nieuwe aanwisten verdienen een aparte pagina (5). Men wil kunnen inloggen met de eID (6), én met een speciale bibkaart (7). Een bezoek aan de bib zelf levert je nog meer eisen op: het personeel wilt immers de nadruk leggen op andere zaken dan de stafhouders.

Hoe ga je te werk om dit te beheren en tot een succesvol einde te brengen? Er is een raamwerk nodig om:

  1. Werk overzichtelijk in kaart te brengen
  2. Werk in te schatten en op te delen in beheersbare deeltaken
  3. Werk eenvoudig te kunnen verdelen
  4. Werk zichtbaar te maken: wie met wat bezig is, wanneer het klaar is, …
  5. De klant in elke stap van het proces zo nauw mogelijk te betrekken

A. Werk managen: Scrum

De alsmaar populair wordende term ‘scrum’ komt vanuit de Amerikaanse sport rugby, waar men letterlijk de koppen bij elkaar steekt om nog een laatste peptalk uit te delen voordat de chaos van de wedstrijd zelf losbarst (Bron):

Het principe van deze coördinatie is gemuteerd naar de softwareontwikkeling, waar het Scrum framework een oplossing kan bieden voor ons beheer probleem, waarvan alle 5 bovenstaande punten van het probleem op een structurele manier worden aangepakt.

Een Werk ‘raamwerk’

Een agile software development methodologie is een methodologie om snel te kunnen ingrijpen op veranderingen. Klanten zijn van nature erg wispelturig en weten vaak zelf niet goed wat ze willen. Daarom is een ontwikkelmethode die sneller van richting kan veranderen tegenwoordig veel waardevoller dan een log systeem waarbij veel analysewerk op voorhand wordt verricht, om daarna alles te ontwikkelen. Een voorbeeld van zo’n klassiek log systeem is het waterval model. Een voorbeeld van zo’n modern agile systeem is scrum.

De volgende Figuur representeert het Scrum principe in de technische wereld:

Het Scrum principe verdeelt de ontwikkeltijd in een aantal iteraties, waarbij een iteratie een vooropgestelde tijd is, meestal 14 of 30 dagen, die een vaste kadans bepaalt waarin teams software ontwikkelen. Elke iteratie gebeurt er hetzelfde: bepalen wat te doen binnen die iteratie, de ontwikkeling ervan, en het vrijgeven van een nieuwe versie van het al dan niet volledig afgewerkt product.

De introductie van itererende blokken waar taken van de backlog worden genomen en verwerkt, biedt de mogelijkheid tot veranderen. Tussen elke iteratie in kan er worden bijgestuurd door functionaliteit op de (product) backlog te verwijderen, toe te voegen, of te wijzigen.

1. De Backlog

De backlog is een grote lijst van zaken die moeten worden ontwikkeld voordat de klanten tevreden zijn (een ‘story’’). Men begint met één grote product backlog waar op een hoog niveau alle eisen in zijn beschreven. Voor elke sprint van x dagen (30 in de Figuur), beslist het team welke items van deze backlog naar de sprint backlog worden verplaatst: dit zijn de zaken die het team denkt te kunnen verwerken in één sprint.

Een product backlog bevat stories die nog niet goed geanalyseerd en beschreven zijn, waarvan moeilijk te zeggen valt hoeveel werk dit effectief kost. Wanneer dit in een iteratie terecht komt, wordt dit nauwer bekeken door het team. De betere beschrijving leidt tot een accurate inschatting, en mogelijks zelfs meerdere backlog items.

Het volgende filmpje verduidelijkt de rol van de backlog in het team:

2. Taken

Een sprint backlog item wordt typisch door ontwikkelaars nog verder opgesplitst in kleinere taken om het werk beter te kunnen verdelen. Bijvoorbeeld, de mogelijkheid tot inloggen met eID kan bestaan uit (1) authenticatiestappen en het inlezen van een kaart, en (2) het UI gedeelte waar de gebruiker mee interageert. Misschien beschikt al één teamlid over authenticatie kennis, maar nog niemand weet hoe de UI aan te pakken. In dat geval is taak (1) sneller gedaan dan taak (2).

Als alle taken zijn opgesplitst, worden er inschattingen gemaakt van elke taak, ten opzichte van een referentie taak. Inschattingen zijn relatieve getallen in Fibonacci nummers: 1, 2, 3, 5, 8, … Hoe moeilijker of groter de taak, hoe vaker teams verkeerde inschattingen maken, en hoe meer impact dit heeft op de planning, vandaar de snel groeiende nummers. De referentie taak heeft een vast nummer in de rij, zoals bijvoorbeeld 2. Merk op dat dit nummer dus niets te maken heeft met een concreet aantal (uren, dagen) werk.

Stel dat een simpel loginscherm reeds werd ontwikkeld. Men schat dan de moeilijkhei van het authenticeren van eID in ten opzichte van het werk aan het loginscherm: zou dat veel minder werk kosten, of meer? Minder werk: 1. Meer werk: veel moeilijker of een beetje? Veel: 5 of meer. Een beetje: 3.

3. Een iteratie

Elke iteratie bestaande uit bijvoorbeeld 30 dagen kan een team een bepaald aantal ingeschatte punten verwerken, zoals 30. Men kiest een aantal taken waarvan de som van de inschatting niet dit maximum overschrijdt, en men begint aan de iteratie.

Elke dag is er ’s morgens een scrum stand-up: een korte, rechtstaande vergadering, waarin iedereen vertelt:

  1. Wat hij of zij gisteren gedaan heeft
  2. Wat hij of zij vandaag gaat doen
  3. Met welke problemen hij of zij kampt

Op die manier is onmiddellijk iedereen op de hoogte. Dit noemt men ook wel een scrum meeting, geïnspireerd op de Rugby scrum. Als men merkt dat collega’s problemen hebben kan er dan beslist worden om taken weg te laten, toe te voegen, enzovoort.

Werk visualiseren

Een van de belangrijkste redenen om voor een agile methodologie te kiezen als Scrum, is de mogelijkheid tot het visualiseren van werk. Een team van 6 mensen kan daardoor ten allen tijden in één oogopslag zien aan welke taken wordt gewerkt, welke taken/stories in de iteratie zijn opgenomen, en waar het schoentje knelt (bron):

Elke story wordt een ‘swimlane’ toegewezen: een horizontale band, die wordt opgedeeld in een aantal kolommen. Wanneer alle taken van één story van links naar rechts zijn verhuisd, weet het team dat die bepaalde functionaliteit (de story) klaar is voor de eindgebruikers. De taken kunnen worden gecategoriseerd met behulp van kleurcodes (technische opzet, database werk, UI werk, scherm x, y, …) De kolommen zelf variëren van team tot team. Een voorbeeld:

  • (Task) Todo
  • Doing (in progress in bovenstaande Figuur)
  • To Review/To Test/Done

Een taak die van Doing naar Done wordt verschoven is daarom niet volledig afgewerkt. Het kan zijn dat de ontwikkeling af is, maar dit nog moet worden nagekeken door een technische collega (to review), of worden getest door de customer proxy (to test), of worden uitgerold naar een interne test- of acceptatieomgeving (to deploy).

In het volgende filmpje komen verschillende implementaties van persoonlijke scrumborden aan bod, om je een idee te geven van de aanpasbaarheid van zulke borden:

Hier wordt het woord kanban gebruikt om aan te geven dat werk wordt gevisualiseerd - maar niet noodzakelijk een deel is van agile softwareontwikkeling of van scrum. Zoals je kan zien is het dus ook een effectieve manier om voor jezelf TODO/DOING/DONE items (school taken, hobby’s, …) op te hangen en dus visueel te maken.

B. Teams managen: Rolverdelingen

Werk verdelen en managen is niet het enige sterkte punt van Scrum. Een efficiënt team opbouwen dat in staat is om verschillende rollen op te nemen is nog een van die punten. Om bovenstaande stories en taken als onderdeel daarvan zo goed mogelijk te kunnen afwerken, dient het werk verdeeld te worden. Hieronder volgt een kort overzicht van de vaakst voorkomende rollen.

De Product Owner

Een Scrum team is sterk klant-georiënteerd, waarbij stories hoofdzakelijk het gevolv zijn van de vraag van de klant. Ook welke stories in welke iteratie worden opgenomen is het gevolg van de wil van de klant. In de praktijk heeft de klant, een ander bedrijf dus, nauwelijks tijd om het ontwikkelproces op de voet op te volgen.

Daarom dat de product owner (PO) die belangrijke taak van de klant overneemt. Een Product Owner is een domein expert van het ontwikkelbedrijf die het overzicht bewaart: hij of zij weet welke stories nog moeten volgen, kan wijzigingen laten doorvoeren, en kent het product vanbinnen en vanbuiten. De PO overlegt vaak met de klant zelf en vertegenwoordigt de belangen van de klant bij het ontwikkelbedrijf.

De Customer Proxy

Stories zijn niet meer dan kleine briefjes waar in een paar zinnen staat beschreven welke grote blokken functionaliteit de klant verwacht. Voordat dit kan worden opgesplitst in deeltaken dient er een grondige analyse uitgevoerd te worden. Dit gebeurt door de customer proxy, vaak ook gewoon analist genoemd.

De customer proxy is, zoals het woord zegt, een vervanger voor de klant, die expert is in bepaalde deeldomeinen. De Product Owner bewaart het overzicht op een hoog niveau, van het héle product, en de Customer Proxy is expert in bepaalde deeldomeinen. Ontwikkelaars en proxies discussiëren en beslissen vaak samen de werking van bepaalde delen van het product, waarbij de proxy de belangen van de klant hierin verdedigt. Er zijn typisch meerdere proxies aanwezig in één team, terwijl er maar één product owner is.

De Ontwikkelaar

Stories worden opgesplitst in taken door de proxy en ontwikkelaar, die de functionele en technische gebundelde kennis gebruiken om problemen op te delen in kleinere, en makkelijker verwerkbare, deelproblemen. De ontwikkelaar is verantwoordelijk voor de implementatie van taken, en kan daardoor taken van todo naar doing en done verhuizen op het scrumbord.

De Team leider

Ontwikkelen en analyseren loopt nooit van een leien dakje. Een leider zorgt er voor dat het team zo weinig mogelijk last heeft van eender welke vorm van afleiding. Dat betekent zowel te veel druk van de klant als mogelijke administratieve taken die het bedrijf eist van elke werknemer. Een goede team leider is een onzichtbare die er voor zorgt dat iedereen zijn werk kan doen.

Een tweede taak van de team leider is het opvolgen van vooruitgang van de sprint. Het zou kunnen dat ingeschatte stories meer werk kosten dan initiëel gepland, of dat er een gaatje is om extra werk op te nemen. Dit wordt gevisualiseerd door middel van een ‘burndown chart’, een grafiek die het aantal nog te behandelen taken afbeeldt op de resterende tijd in dagen of uren (bron):

Pieken boven de groene ideaallijn betekent onverwacht extra werk die niet werd ingepland, waarbij de team leider mogelijk moet ingrijpen. Dalingen onder de groene lijn betekent vlot werk met mogelijkheid tot iets extra buiten de sprint. De team leider overlegt vaak met de Product Owner om de verwachtingen zo goed mogelijk bij de ideaallijn gealigneerd te krijgen.

Trends in burndown charts evalueren is een belangrijke vaardigheid voor elk lid van het team. Iedereen kan in één oogopslag onmiddellijk zien of het team meer werk heeft gedaan dan initieel ingepland, nog op schema ligt, of erg achter hinkt. Pieken en dalingen in de grafiek zijn duidelijke tekenen van onder- of overschattingen van de story’s. In bovenstaande grafiek krijgt het team bijvoorbeeld na dag 4 (X-as) een zware dobber te verwerken dat meer tijd kost dan eerst gedacht, die pas na dag 9 wordt opgelost. Tussen dag 11 en 15 verloopt alles op cruise snelheid - het gaat zelfs lichtjes beter dan verwacht. De grafiek ‘remaining effort’ is de belangrijkste (bron).

Het effect is erg uitgesproken op de tweede grafiek. Op dag 3 valt het team volledig stil (de oorzaak is natuurlijk niet af te lezen, dit kan zowel liggen aan technische problemen als aan bijvoorbeeld ziekte van een aantal programmeurs), wat de scherpe piek verklaart. De rest van de iteratie zwoegt het team om het verloren werk in te halen, wat pas na dag 10 uiteindelijk bijna lukt.

Deze informatie is erg belangrijk omdat het kan worden gebruikt om toekomstige sprints in te plannen. Grafieken worden ge-extrapoleerd om een betere inschatting te kunnen maken van het toekomstige werk. Een consistent goed presterend team - de remaining effort lijn ligt onder de remaining time - kan in de toekomst bijvoorbeeld meer werk aan binnen dezelfde iteratie. Het is dan aan de team leider om dit naargelang in te plannen.

Lees meer over de burndown chart via de extra bronnen.

Opdrachten

Dit deel bevat geen opdrachten maar kennis ervan zal afgetoetst worden tijdens het schriftelijk examen. Bijvoorbeeld wat betekent SCRUM en wat is Agile Development.