HAN Minor DevOps - Moderne ICT-technieken

Quick links

• Minor informatie/inschrijving Kies op Maat

Figuur 1: Promo video minor DevOps HAN i.s.m. InfoSupport

Course codes:

• MINDEC05 - Minor DevOps - Course DevOps (15 EC) - iSAS
• MINDEP01 - Minor DevOps - Project (15 EC) - iSAS

Inleiding

In deze minor leren ICT-studenten moderne ICT-technieken voor Continuous Delivery volgens een DevOps aanpak. Studenten werken in teamverband aan de ontwikkeling van een geïntegreerd softwareproduct, waarbij zowel de software en de onderliggende software-architectuur, als de infrastructuur (hardware), en de architectuur en configuratie daarvan aan bod komen.

🤝 DevOps en Samenwerking

Studenten leren applicaties te ontwikkelen door middel van een containerized aanpak. Deze aanpak maakt het mogelijk om veel operationele processen te automatiseren, te werken vanuit een gedeelde backlog en op grotere schaal oude silo's te doorbreken. Het doel hiervan is een snellere 'time to market' te realiseren (shift left). DevOps staat hierbij centraal als een manier van samenwerken: DevOps is cooperation.

🎯 Focus op Non-functional Requirements

Naast functionaliteit voor eindgebruikers, wordt er in deze minor ook gekeken naar non-functionele eisen (NFR's), zoals schaalbaarheid, betrouwbaarheid en onderhoudbaarheid. Deze non-functionele eisen worden soms ook wel 'quality attributes' (QA's) genoemd, omdat goede prestaties vaak essentieel zijn voor de eindgebruiker (performance as a feature).

🚀 Opzetten van Deployment Pipelines

Studenten leren een DevOps-proces opzetten en werken met een CI/CD pipeline voor geautomatiseerde deployment naar productie- en andere runtime-omgevingen, gebaseerd op de 'desired state' in versiebeheer (GitOps). Deze efficiënte en frequente updates maken ook een betere focus op beveiliging mogelijk (DevSecOps). Daarnaast verbetert goede logging en monitoring (SlackOps) het zicht op prestaties, het vroegtijdig detecteren van fouten en zelfs het volgen van bedrijfsdoelen. Dit gebeurt door middel van applicatiespecifieke KPI's en tools die helpen bij het monitoren van de naleving van gemaakte afspraken (SLA's - Service Level Agreement).

📈 Ontwikkelen als "T-shaped Professional"

Deze minor biedt zowel verdieping als verbreding. De instroom is beperkt tot ICT-studenten met een achtergrond in Operations (Infrastructuur, Security) of Development (Software-, Web-, of Data Solutions Development). Alle studenten verbreden hun kennis door elkaars vakgebieden te leren begrijpen en interdisciplinair samen te werken. Tegelijkertijd verdiepen ze zich verder in hun eigen specialisatie door te leren werken met moderne technieken zoals containers, cloud providers, microservices en Agile systeemontwikkeling.

Figuur 3: 'T-shaped DevOps professional' ([plaatje: agilescrumgroup.com](https://agilescrumgroup.nl/t-shaped/))

Lesrooster

Hier het lesoverzicht van de minor. Tijdens de minor volgen wellicht nog wat wijzigingen. Onder de tabel verdere toelichting.

Week 0 - Kick-off week

Donderdag 28 augustus 2025: Kick-off minor met introductie, kennismaking, teamvorming en overzicht van de minor. Zie de kick-off pagina voor het volledige programma.

Onderwijsweek 1 t/m 3

	Onderwijsweek 1 GitOps Week 36 1-7 sep 2025	Onderwijsweek 2 Containerization Week 37 8-14 sep 2025	Onderwijsweek 3 Continuous Delivery Week 38 15-21 sep 2025
Maandag Ochtend	Linux 101	Docker Intro	Domain Driven Design
Maandag Middag	- Course Overview	Docker Compose & Volumes	Domain Driven Design
Dinsdag	Vrij	ORM	Weekopdracht 3
Woensdag	1e weekopdracht thuis	Linux bash script	Micro front-ends
Donderdag	- Opdracht 1 Walkthrough - git workflows (.NET/TDD)	- Opdracht 2 Walkthrough - Container optimization - Debugging	Deeltoets 1

Onderwijsweek 4 t/m 6

	Onderwijsweek 4 Orchestration/DevSecOps Week 39 22-28 sep 2025	Onderwijsweek 5 SlackOps Week 40 29 sep-5 okt 2025	Onderwijsweek 6 BP Spike (sprint 1) Week 41 6-12 okt 2025
Maandag Ochtend	Event Driven Architecture		- Workshop Story Mapping - Teams Backlog - Sprint 1 planning
Maandag Middag	Event Driven Architecture
Dinsdag	K8s 101: Architecture	Alliander Workshop	- Spike Ontwikkelen
Woensdag	RabbitMQ Intro	Monitoring
Donderdag	RabbitMQ + BDD	- Opdracht 5 Walkthrough	Deeltoets 2

Onderwijsweek 7 t/m 9

Wekelijk Organisatie

Contacttijd:

• 1 sessie met gastdocent: Focus op ontwikkelingsconcepten.
• 3 sessies met cursusdocent: Focus op operationele aspecten.

Huiswerk:

• Deadline: voor de Walkthrough van dag 3

Studiejaar 2025/2026 - Kalenderweken

Belangrijke data:

• 28 augustus 2025: Kick-off minor (donderdag 9:00-12:15, Ruitenberglaan 26)
• 5 september 2025: Deadline indienen afstuderen P1 OW-5
• 6-24 oktober 2025: Intekenen onderwijs P2

Programmaoverzicht

Week 1 t/m 5 - Wekelijks een DevOps-gerelateerd onderwerp.

• Activiteiten: Theorie, opdrachten, lessen.

In de eerste vijf weken leer je de basis van DevOps ter voorbereiding op afsluitende opdrachten. Dit gebeurt via het flipped classroom model, waarbij je zelfstandig thuis online bronnen bestudeert, zoals blogs, video's en opgegeven documentatie.

Week 6 t/m 8: Eindopdracht - Beroepsproduct

• Doel: Eindtoets voor de course, met toepassing van de onderzochte technologie in het DevOps-beroepsproduct.
• Activiteit: Ontwikkelen van een DevOps-beroepsproduct in teams van 4-5 personen met vergelijkbaar ambitieniveau.
• Inhoud: Uitbreiding van een softwaresysteem, inclusief configuratie, images, dependencies, CI/CD, database (seed scripts), en documentatie.
• Lesuren: Voor vragen, feedback en korte workshops.

Meer info: Week 6 t/m 8 Beroepsproduct.

Week 9: Eindpresentatie en Beoordeling

• Activiteiten:

  • Eindpresentatie: Groepspresentatie met demo van het beroepsproduct en toelichting op het proces.
  • Individuele sessie: Verantwoording van ieders bijdrage aan het teamproduct.
  • Bezoek opdrachtgever: Oriëntatie op volgende projectfase.

• Beoordeling:

  • Criteria: Kwaliteit, kwantiteit, toepassing van DevOps 'Way of Working' (WoW) en maturity.
  • Basis: Observaties van begeleiders, het werk, backlog en documentatie.
  • Iteratief en incrementeel waar mogelijk, maar met geplande momenten (WaterScrumFall).

Meer info in beoordelingsmodel (iSAS).

Kick-off Minor DevOps 2025/2026

Datum: Donderdag 28 augustus 2025
Tijd: 9:00-12:15
Locatie: Ruitenberglaan 26, lokaal: To Be Determined (TBD)

Voorbereiding: Boekentips voor de zomervakantie

Om je goed voor te bereiden op de minor DevOps, raden we je aan om tijdens de zomervakantie een van de volgende boeken te lezen:

📚 Aanbevolen boeken van Gene Kim

The Phoenix Project (Roman)

• Een roman over DevOps transformatie in een fictief bedrijf
• Leert je DevOps principes door een verhaal
• Perfect voor beginners die DevOps willen begrijpen

The Unicorn Project (Roman)

• Vervolg op The Phoenix Project
• Focus op developer experience en moderne software development
• Geeft inzicht in de uitdagingen van legacy systemen

The DevOps Handbook

• Praktische gids met concrete implementatiestrategieën
• Meer technisch en theoretisch dan de romans
• Voor studenten die dieper in de materie willen duiken

🎯 Waarom deze boeken?

Deze boeken helpen je om:

• DevOps als cultuur te begrijpen (niet alleen tools)
• De uitdagingen van software delivery te herkennen
• De waarde van samenwerking tussen Dev en Ops te zien
• Voorbeelden uit de praktijk te kennen voor discussies

📖 Hoe te lezen?

• Begin met The Phoenix Project als je nog weinig van DevOps weet
• Lees The Unicorn Project als je meer wilt weten over developer experience
• Pak The DevOps Handbook als je praktische implementatiestrategieën zoekt

Concept Programma Kick-off

Wat wordt behandeld?

• Introductie minor: Overzicht van de course fase en project fase
• Kennismaking: Onderlinge kennismaking en eventueel introductie van de klant
• Teamvorming: Vorming van duo's voor de eerste weekopdracht
• Microservices: Overzicht van microservices architectuur (project fase)
• DevOps cultuur: T-shaped professional concept en DevOps als cultuur

Na de kick-off

Let op: Woensdag 3 september (Dag 3 van week 1) werken studenten thuis aan de eerste weekopdracht in de bij de kick-off gevormde duo's.

← Terug naar lesrooster

Rubric Course (blok 1)

Berekening van de Cijfers

1. Theorie Test - 50% van het cijfer
   • 2 deeltoetsen (gemiddelde moet hoger dan 5,5 zijn)
   • Herkansing: 1 grote toets
2. Beroepsproduct - 50% van het cijfer
   • 3 weken code + documentatie
3. Weekopdrachten (huisopdrachten)
   • 5 wekelijkse opdrachten, afvinken (=voldoende/onvoldoend), Voldoende als je oefening hebt gemaakt en feedback van anderen hebt gekregen en verwerkt.

CDMM als Beoordelingsmodel

Als beoordelingsmodel voor de weekopdrachten en het beroepsproduct (BP) dat je maakt — gebruiken we het Continuous Delivery Maturity Model (CDMM) zoals gedefinieerd in een blogpost op de website InfoQ. Deze onderscheid vijf categorieen (rijen) met elk 5 niveaus (kolommen) met een aantal 'checkpunten'.

Hieronder een korte opsomming van de 5 categorieën uit het CDMM, met per categorie een beschrijving van belangrijke aspecten. Maar moet je ook zelf de details achterhalen van de 'checkpoints', zoals onderaan de pagina verder beschreven, toegelicht onder 'DevOps concepten' op deze website, maar ook in het originele 'InfoQ' artikel (Böstrom et al., 2013).

• 🧑‍🤝‍🧑 Culture & Organization: Multidisciplinair samenwerken, conform Agile manifesto, verminderen silo's en gedeelde verantwoordelijkheid conform 'DevOps is not a role', etc. (Agile).
• ⛪ Design & Architecture: Just in time design, continuous documentation, microservice architectuur, High Availability, autonomy over authority, etc. (C4, IaC, clustering)
• 🏗️ Build & Deploy: Gescripte pipelines, continuous integration, continuous deployment, koppeling aan versiebeheer, 'automate all the things' etc. (GitOps)
• 🧪 Test & Verification: Leesbare en liefst uitvoerbare specificaties, geautomatiseerd testen, testpiramide, opstellen en meten bedrijfsmetrics, etc. (TDD, BDD, test pyramid)
• 📈 Information & Reporting Inzicht in issues/backlog, metrics vanuit productie, beeld hard- en softwaregebruik, log aggregatie, visualisatie, 'strengthen feedback loops', etc. (SlackOps)

Bovenstaand de categorieën nog even in het Engels en als toelichting een indicatie van hogere maturity per punt met wat kernpunten. Het Maturity model geeft meer stapsgewijze opbouw in niveaus met bij elk niveau checkpunten om af te vinken. Deze vind je hier CDMM CHEAT SHEET.

Om niet direct te verdwalen in het detail kun je eerst overzicht te krijgen via de toelichting in subsecties hier eronder.

• Sectie A geeft een toelichting van het gebruik CDMM als beoordelingsmodel voor cijferindicatie.
• Sectie B licht de vijf beoordelingscriteria toe die dit model bevat.
• Sectie C beschrijft de samenhang met (en mapping naar) de thema's, opdrachten en lessen van de course fase.
• Sectie D licht de indeling van de teampresentatie momenten toe.
• Sectie E iets over de impliciete aanname dat je geautomatiseerd testen en aan TDD doet.

Voor het eind beroepsproduct van de coursefase krijg je ook een individueel cijfer. Deze is veelal gelijk aan het teamcijfer, maar zoals elders is toegelicht hoe elk teamlid hiervoor de verplichte 'verantwoording van de individuele bijdrage' geeft, via een persoonlijk markdown bestand (waarvoor een template format is), en een mondelinge toelichting hierbij tijdens de Review.

A. Toelichting gebruik CDMM als beoordelingsmodel

Dit model is opgesteld voor ICT organisaties, om de fase van adoptie van DevOps patterns en het toepassen van Continuous Delivery aan te geven. In deze course gebruiken we dit ook voor bepalen van niveau van jullie als DevOps team. Je DevOps team zien we daarbij dus zien als een kleine DevOps organisatie.

Het model kent vijf beoordelingscategorieën met elk vijf beschreven niveaus: base, beginner, intermediate (=gemiddeld), advanced en expert. Voor de becijfering koppelen we grofweg een cijfer aan elk niveau:

• 😴 base niveau cijfer **2**
• 🥱 beginner niveau, een **4**
• 😐 gemiddeld niveau een **6**
• 🙂 gevanceerd niveau een **8**
• 😎 expert niveau een **10**

Het voldoende niveau (dus een 6) is dus intermediate oftewel gemiddeld. Hier ben je voldoende volwassen. Bij lager zit je op onvoldoende, maar dat betekent in dit geval niet dat je aanpak niet adequaat is.

Deze 'Beginner' punten moet je dus wel inrichten, dit zijn traptreden die je moet nemen naar hoger niveau. Op tenminste een aantal punten moet je ook naar gemiddeld of hoger zitten voor een voldoende. Je hebt immers een DevOps minor gevolgd, dus een bedrijf verwacht dan dat je meer DevOps kennis hebt dan de gemiddelde instappende ICT'er. Het staat de beoordelaar vrij om een tussenliggend cijfer te geven op de deelaspecten, dus bijvoorbeeld een 5, 7 of 9 is ook mogelijk (een 1 betekent dat je niks hebt gedaan of ingeleverd).

Bij de beoordeling levert de docenten/beoordelaars wel maatwerk, dus rekening houdend met omstandigheden. Bij beoordeling is het niet allen een kwestie van simpelweg afvinken, maar belangrijkste is dat je ook zelf kunt beoordelen waar je staat, de gebruikte termen goed kunt interpreteren, koppelen aan je eigen en je teams werk. Kortom dat je aantoont dat je een 'bewust bekwame' DevOps professional bent.

Verdere opmerkingen:

• Termen in monocase font (dus met backticks ` in markdown) verwijzen naar specifieke concepten of labels zoals beschreven in het CDMM-model.
• De termen 'beoordelingscriteria' en 'categorieën' gebruiken we in de tekst als synoniemen en verwijzen naar dezelfde onderdelen.

B. De 5 beoordelingscriteria

Onderstaand de vijf beoordelingscriteria waar je in je team laten op 'intermediate' niveau moet scoren. Als indicatie een korte beschrijving en wat voorbeelden. Maar voor beoordeling moet je de hele rubric bekijken en bekijk voor uitleg van alle 'etc.' in onderstaande het originele InfoQ artikel als verdere achtergrond. Merk op dat achter elk criterium uit CDDM tussen haakjes ook een ruw equivalent van de criteria uit de OWE.

1. 🧑‍🤝‍🧑 Cultuur & Organisatie - CO: DevOps is een cultuur (en geen rol). Van basis versiebeheer en ad hoc proces tot projectgebaseerde teams met volledig gedefinieerd DevOps proces. Het team heeft gezamenlijke verantwoordelijkheid en backlog en hanteert een Agile aanpak en ceremonies (bv. Scrum), etc. (DevOps-1 - Continuous Delivery)
2. ⛪ Design & Architectuur - OA: Ontwerp van je software architectuur. Van monoliet naar microservices mapping op infrastructuur (evt. IaC), focus op NFR's voor bv. autoscaling, twelve-factor app principles, etc. (DevOps-3 - Containerization/Orchestration)
3. 🏗️ Build & Deploy - BD: Van wat handmatige stappenplan naar volautomatische build met kwaliteitschecks en een Canary of bluegreen deploy vanuit zelf ingerichte pipeline, dev/prod parity etc. (DevOps-2 GitOps)
4. 🧪 Test & Verificatie - TV: Van wat (goede) unit tests¹ naar volledige testpiramide, load tests en tests van bedrijfswaarde. De mate van TDD, acceptatietests, BDD, security, refactorings, review-proces en -inspanningen etc. (DevOps-4 - DevSecOps)
5. 📈 Informatie & Rapportering - IR: Van standaard hardware monitoring naar realtime applicatiespecifieke metrics en cross applicatie en cluster informatie, A/B tests. Hoe goed monitor je de applicatie, static code analyse, loglevels/-aggregatie, productspecifieke rapportages, etc? (DevOps-4 - SlackOps)

De CDMM CHEAT SHEET is feitelijk overgenomen uit een plaatje bij dit artikel wat een samenvatting van het artikel vormt, in de vorm van afvinkbare 'checkbox punten'. Deze zijn verdeeld over vijf categorieen die elk weer vijf niveaus van 'volwassenheid' hebben.

Wijzigingen t.o.v. originele CDMM

De wijzigingen ten opzicht van het originele CDMM van InfoQ zijn erg beperkt en spreken deels voor zich, maar hier voor de nieuwsgierigen.

• Ten opzichte van het InfoQ artikel is elk item/checkbox vertaald naar het Nederlands.
• Elk checkpunt nu een eigen code (bv. CO-003), die kort de categorie en het niveau aangeeft.

Tot slot zijn de volgende checkpoints in het CDMM toegevoegd:

• CO-206 Trunk based development - In lijn met punt 'CO-201 *minimale branching' is het logisch dat developers in versiebeheer zoveel mogelijk op de trunk werken (bv. main). Zie verder het artikel hierover uit 2018 op InfoQ hierover, 5 jaar na het CDMM artikel :) (InfoQ, 2019)
• Punt DB wijzigingen in VCS is verplaatst vanuit categorie 'Ontwerp & Architectuur' naar 'Build & Deploy' als BD-105 in lijn met de overige hogere checkpoints rondom 'db' zoals 'Automatiseer meeste DB wijzigingen* die ook in deze categorie staan. Deze hangen meer samen met automatiseren van deploys met pipeline en versiebeheer standaarden dan met de applicatie architectuur. Wel kun je argumenteren dat het gebruik van een ORM tool met migrations wel weer deels een (software) design of architectuur keuze is. Wel een ADR waard in ieder geval. Dan zouden BD-303 en BD-402 juist naar de categorie OA moeten, maar i.v.m. consistentie doen we dit niet.
• Punt CO-302 'Strict API based approach or message bus/broker ingevoegd, in verband met missende focus van InfoQ op gebruik Message bus/broker.

Gebruik checkpunten voor self assessments

De checkpunten ga je gebruiken in de weekopdracht en beroepsproduct, maar het is wel de bedoeling naast de code OOK de naam op te nemen in je eigen product documentatie, toelichting bijdrage team en dergelijke. Dus NIET enkel de code, want dan wordt het erg cryptisch (en moet de lezer dit weer opzoeken).

Bijvoorbeeld:

Het gezamenlijk zelf komen tot een besluit tijdens de sprint retrospective — in plaats van naar de PO te kijken voor een besluit — zien wij als voorbeeld van CDMM CO-206 - Decentrale besluitvorming). Dit toont aan dat wij als team al voldoende scoren op criterium Cultuur en Organisatie.

Op een eventuele vraag van de beoordelaar waarom jullie dan nog niet 'handelen op metrics' (C0-203) moeten je dan zelf idealiter een antwoord formuleren (wellicht is "Promotheus doen we pas in week 5" een goede verdediging ;))

C. Mapping van de 'CDMM checkboxes' op de weekthema's/-opdrachten

Tijdens de lesweken in de course fase richt je in opdrachten vooral op stappen Basis en Beginner. Tijdens het DevOps beroepsproduct ontwikkeling (laatste 3 weken) ga je je als het goed is ontwikkelen naar hoger niveau een of manier criteria (maar tenminste vormbehoud).

Hieronder een klein opzetje van de mapping. Merk op dat het merendeel van de checkboxes nog ingedeeld moet worden. Waarbij je sommige in twee of meer categorieen kunt/moet indelen (zoals BD-207 'standaard proces voor alle omgevingen' in containerization en Continuous Deployment en OA-103 in containerization en devSecOps).

• Wk1 - GitOps: CO-003, BD-001 Code in versiebeheer, BD-103 Handmatige tags en versies, BD-201 Auto triggered builds (commit hooks), TV-001 Automatische unit tests, IR-102 Statische code analyse, TV-201 Automatische component test (geisoleerd), ...
• Wk2 - Containerization: OA-103 (3rd party) library management, BD-203 Build once deploy anywhere, BD-204 Automatiseer meeste DB wijzigingen, BD-206 , BD-401
• Wk3 - Continuous Delivery/BDD: CO-001, CO-101, BD-205, BD-206, IR-101, IR-202, TV-301 ...
• Wk4 - Rabbit MQ: CO-105 Testen onderdeel van development, OA-201 Geen of minimale branching, OA-301 Volledige component gebaseerde architectuur, TV-101 Automatische integratietests, TODO OA-302 Strict API based approach or message bus/broker
• Wk5 - Orchestration/DevSecOps: OA-201 Geen of minimale branching, TV-002, TV-303, TV-304, OA-103, ...,

D. Beoordelingsmomenten

De beoordeling van dit beroepsproduct gebeurt op basis van 3 onderdelen. Deze komen langs twee beoordelingsmomenten; een Productdemo en een Code review. Hier een overzicht met ook beoordelingscriteria per onderdeel.

1. Productdemo Het tonen van het product en het updaten en live monitoren ervan tijdens een korte teamdemonstratie voor beoordelaar(s)/opdrachtgever
2. Code review Product en code/config review. Langer overleg met alleen team en beoordelaar(s):
   • toelichting individuele bijdrage
   • vragen van beoordelaars
   • bespreking van jullie self assessment b. Kwaliteit van proces, README en de verdere achterliggende documentatie
   • verloop sprints en Scrum ceremonies
   • doornemen scrumborden, issues, user stories, traceerbaarheid wijzigingen via issues, commit messages, pull requests en review opmerkingen
   • doornemen/toetsen README en begrijpelijkheid documentatie (C4 + UML en overige diagrammen en (verplichte) tekstuele toelichting)

D1. Productdemo Toelichting

De productdemo duurt circa een kwartier en daarna max een kwartier vragen. De presentatie gebeurt voor de beoordelaars. Omdat jullie in principe op basis van een redelijk bekende product hoef je aan introductie hiervan niet veel tijd te bestenden en licht je vooral je eigen uitbreiding hiervan toe, en demo't deploy van product increment en monitoring hiervan.

Voordat de demo is doe je met het hele team een self assessment van het gemaakte DevOps product en gevolgde proces en vult in een self-assessment.md voor alle 5 BC's een cijfer in op basis van niveaubeschrijvingen in de rubric in. Je schrijft hierbij ook een argumentatie voor de invulling, met enkele steekwoorden per BC en ook een of meer paragrafen voor de eindcijfer.

Bij beoordeling geldt dat alle te beoordelen zaken aanwezig zijn in ingeleverde beroepsproduct en ook in je documentatie te vinden zijn. Je werkt dus NIET in Word documenten, maar in tekst en markdownbestanden geintegreerd samen bij de broncode en configuratiebestanden.

Merk op dat de beschrijvingen van de 'lagere niveaus', basis, en beginner niet per se tekortkomingen beschrijven, maar ladders zijn op een trap die je moet nemen richting een voldoende en hopelijk zelfs goed cijfer. Op een aantal criteria zit je gelukkig wel al direct op een 6 door bijvoorbeeld gezamenlijke backlog voor DevOps te gebruiken en een Test en/of Behaviour Driven aanpak te gebruiken.

Als gezegd moet je alle belangrijke zaken, zoals behaalde non functional requirements, of je proces als DevOps team ook zelf kort beschrijven in je documentatie. Je moet ook weten waar je zelf staat. De niveaubeschrijvingen zijn geen kant en klare recepten, dus je moet zelf ook een interpretatie hiervan doen en invulling. Bij twijfel stem zaken - als het goed is vooraf - af met de beoordelende docent(en). Het expert (=extreem) niveau dat bij een 10 en hierbij ga je above en beyond, dus moet je ook zelf aangeven waarom je op het niveau zit.

D2. Code Review Toelichting

Bij een tweede langer assessment met alleen de docenten en je team gaan we ook in op kwaliteit code, match configuratie met infrastructuur model en gewenste NFR's? Als intro hiervoor bespreken jullie de grove rol- en werkverdeling en elk teamlid geeft toelichting van eigen bijdrage in het product (minstens 1 bijdrage waar je trots op bent, en kwaliteit kunt beargumenteren en een stuk werk waar je concrete verbeterpunten kunt noemen).

De kwaliteit van de README beoordelen docenten bijvoorbeeld door terplekke zelf de code te pullen uit versiebeheer en containers of clusters te runnen o.b.v. jullie README. En daarnaast te bekijken of documentatie voldoende aangrijpingspunten biedt voor nieuwe developer in team om het product snel te begrijpen en aan verder te bouwen.

Voor individuele beoordeling geef je verantwoording van je eigen bijdrage in het groepsproduct en bv. aan de hand van je markdown document ook meer details van het toepassen van de onderzochte technologieen uit de spike. Als gezegd hebben deze tools/technologieen hopelijk een positieve uitwerking op je eindproduct gehad. Denk aan verbeterde/makkelijkere monitoring, hogere productiviteit, betere security, betere code kwaliteit, geautomatiseerde pipeline etc.

D3. Eindcijferbepaling en wegingsfactoren

Tot slot nog evenover de weging; om dit EXPLICIET te maken: er is GEEN hard voorgeschreven weging tussen de 5 beoordelingscriteria om tot een eindcijfer te komen. Normaliter zullen alle vijf de criteria even zwaar wegen, en is er vaak een lijn qua product. En geeft een onvoldoende op een aspect reden tot twijfel. Maar het gaat meer om je eigen beoordeling en - vooral - beargumentering hiervan. Daarom moet je ook een self assessment doen; zie onder.

Het kan zijn dat sommige aspecten minder van belang waren in jullie opdracht en op zichzelf onvoldoende waren. Maar het overall toch voldoende was doordat een ander aspect buitengewoon goed is gedaan, of zaken door externe en niet te voorspellen zaken juist erg tegenvielen.

Merk ook op dat het eindproduct zelf geen eigen cijfer krijgt. Dit is bewust (dit is overigens tijdens projectblok anders, waar de opdrachtgever ook een deelcijfer geeft). Geen cijfer voor eindproduct betekent natuurijk NIET dat je geen product increment moet hebben. Dit is verplicht. Maar we willen niet dat je inzet op heel complexe functionaliteit en daarbij de DevOps basics uit het ogen verliest. Of bv. logging of monitoring aan de kant schuift. Maa zonder product (increment) is er geen proces. En beter product en logische 'bedrijfswaarde' geeft meer gelegenheid DevOps skills te tonen en een betere demo en leidt indirect toch tot een hoger cijfer.

Bijvoorbeeld een groter product increment of uitgebreide refactoring in bestaande code of opsplitsen van microservice in 1 container in 2 aparte, geeft ook een langer commit spoor, meer unit tests, een aanleiding voor extra Q&A omgeving, een demo canary deploy voor subfunctionaliteit I, een A/B test van een andere functionaliteit, data migratie van feature X, en (zelf onderzochte) InfraStructure As Code configuratie voor microservice Z. Een groter product increment geeft natuurlijk ook meer aanleiding voor een complexere architectuur. Ga je voor een simpele CRUD microservice, of kies je juist complexe logica die ook een 'domain driven' ontwerp vraagt, met wellicht caching in miroservice en synchronisatie tussen microservives, een event-driven en/of CQRS aanpak met eventual consistentie, inzet van een message broker etc.

E. Speciale noot over (geautomatiseerd) testen

¹ Merk tot slot op dat het instapniveau (dus 2) niveau qua Test en Verificatie direct 'code is onder test', dus geautomatiseerde tests. Terwijl dit in het beroepsveld lang nog niet bij alle bedrijven gebeurt. In de course gaan we in op BDD (ook wel ATDD = Acceptance Test Driven Design of 'Specification by Example' genoemd), waar ISM studenten ook nog een rol bij kunnen spelen in het opstellen. Maar er is in de minor binnen contacturen niet de tijd om TDD 'vanaf de grond' aan te leren. Maar TDD en gerelateerde patterns en principe als Arrange, Act, Assert (AAA) en Red, Green Refactor veronderstellen we wel als bekend bij developers. Zorg dat je hier ook mee geoefend hebt, of alsnog oefent!

Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.

De grondlegger van de term Continuous Integration Martin Fowler hamert in vele van zijn blogs op TDD aanpak en legt in blog met titel 'Is high quality software worth the cost?' aan dat deze vraag op een verkeerde veronderstelling berust, omdat kwaliteitssoftware juist goedkoper is om te onderhouden in plaats van duurder (zie figuur 1).

Figuur 1: High (internal) quality software is goedkoper i.p.v. duurder! Aldus Martin Fowler (2019).

In deze lijn trekken in de DevOps wereld over het algemeen door, bv. Continuous Delivery voorman David Farley (van het gelijknamige 'seminal' boek). Met 'goed' bedoelen we hier:

• behoorlijke test coverage, in ieder geval van complexe code (hoge cyclomatische complexiteit)
• leesbare testcode met cyclomatische complexiteit van 1)
• gericht op gedrag en testen van interface i.p.v. implementatie details
• en zonder 'unit testing anti patterns' (zoals 'Liar', 'Excessive setup', 'The giant' en 'The mockery' zie deze video van David Farley).

Bronnen

• Boström, P & Palmbor., T 6 februari 2013. The Continuous Delivery Maturity Model, geraadpleegd 13-1-2021 op https://www.infoq.com/articles/Continuous-Delivery-Maturity-Model
• Fowler, M. 19 mei 2019, Is high quality software worth the cost. Geraadpleegd 20-10-2021 op https://martinfowler.com/articles/is-quality-worth-cost.html
• InfoQ (2018). Trunk Based Development as a Cornerstone for Continuous Delivery. InfoQ.com. Geraadpleegd 5-9-2024 op https://www.infoq.com/news/2018/04/trunk-based-development/

CDMM Criteria Overview

🧑‍🤝‍🧑 Cultuur & Organisatie (CO)

CO - Basis (2)

• CO-001 Werk geprioriteerd
• CO-002 Gedefinieerd en gedocumenteerd proces
• CO-003 Frequente commits

CO - Beginner (4)

• CO-101 Eén backlog per team
• CO-102 Delen van pijn
• CO-103 Stabiel team per project
• CO-104 Basis Agile methode
• CO-105 Testen onderdeel van development

CO - Gemiddeld (6)

• CO-201 Multidisciplinair team (betrekken DBA, CM)
• CO-202 Component eigenaarschap
• CO-203 Handelen op metrics
• CO-204 Ops & Dev samen
• CO-205 Vast proces voor wijzigingen (DB/CM/Docs/Code/Artefacts)
• CO-206 Decentrale besluitvorming

CO - Gevorderd (8)

• CO-301 Dedicated tools team
• CO-302 Team verantwoordelijk tot productie
• CO-303 Deploy losgekoppeld van release
• CO-345 Continuous improvement (Kaizen)

CO - Expert (10)

• CO-401 Cross-functional team (=CO-201++)
• CO-402 No rollbacks (always roll forward)

⛪ Ontwerp & Architectuur (OA)

OA - Basis (2)

• OA-001 Geconsolideerd platform & technologie

OA - Beginner (4)

• OA-101 Systeem opsplitsen in modules
• OA-102 API-gestuurde aanpak
• OA-103 (3rd party) Library management

OA - Gemiddeld (6)

• OA-201 Geen of minimale branching
• OA-202 Branch by abstraction
• OA-203 Configuratie als Code (CaC)
• OA-204 Feature hiding (feature toggle e.d.)
• OA-205 Modules omzetten naar componenten

OA - Gevorderd (8)

• OA-301 Volledige component gebaseerde architectuur
• OA-301 Strict api-based approach
• OA-303 Graph business metrics uit applicatie

OA - Expert (10)

• OA-401 Infrastructure as Code (IaC)

🏗️ Build & Deploy (BD)

BD - Basis (2)

• BD-001 Code in versiebeheer
• BD-002 Gescripte builds
• BD-003 Basis scheduled builds (CI)
• BD-004 Dedicated build server
• BD-005 Gedocumenteerde handmatige deploy
• BD-006 Enkele deployment scripts bestaan

BD - Beginner (4)

• BD-101 Polling builds
• BD-102 Opslag van build (milestone)
• BD-103 Handmatige tags en versies
• BD-104 Eerste stap naar standaardisatie deploys
• BD-105 DB wijzigingen in VCS

BD - Gemiddeld (6)

• BD-201 Auto-triggered builds (commit hooks)
• BD-202 Geautomatiseerde tags & versies
• BD-203 Build once deploy anywhere
• BD-204 Automatiseer meeste DB wijzigingen
• BD-205 Basis pipeline, prod deploy
• BD-206 Gescripte config wijzigingen
• BD-207 Standaard proces voor alle omgevingen

BD - Gevorderd (8)

• BD-301 Zero downtime deploys
• BD-302 Meerdere build machines
• BD-303 Volledig automatische DB deploys

BD - Expert (10)

• BD-401 Build bakery
• BD-402 Zero touch continuous deployment

🧪 Test & Verificatie (TV)

TV - Basis (2)

• TV-001 Automatische unit tests
• TV-002 Aparte testomgeving

TV - Beginner (4)

• TV-101 Automatische integratietests

TV - Gemiddeld (6)

• TV-201 Automatische component test (geïsoleerd)
• TV-202 Enkele automatische acceptatietests

TV - Gevorderd (8)

• TV-301 Volledige automatische acceptatietests
• TV-302 Automatische performance tests
• TV-303 Automatische security tests
• TV-304 Risico gebaseerde handmatige tests

TV - Expert (10)

• TV-401 Verifieer verwachte bedrijfswaarde

📈 Informatie & Rapporteren (IR)

IR - Basis (2)

• IR-001 Basis procesmetrics
• IR-002 Handmatige rapportages

IR - Beginner (4)

• IR-101 Meet het proces
• IR-102 Statische code analyse
• IR-103 Periodieke automatische kwaliteitsrapportage

IR - Gemiddeld (6)

• IR-201 Gedeeld informatiemodel
• IR-202 Traceerbaarheid ingebouwd in pipeline
• IR-203 Rapportagehistorie is beschikbaar

IR - Gevorderd (8)

• IR-301 Graphing-as-a-service
• IR-302 Dynamic test coverage analysis
• IR-303 Report trend analysis

IR - Expert (10)

• IR-401 Dynamische grafieken en dashboards
• IR-402 Cross-silo analysis

Weekopdrachten

Er zijn in totaal 5 wekelijkse opdrachten:

1. GitOps - Werk in tweetallen
2. Containerization - De Werkparen Wijzigen
3. CD - Flexibele Paren
4. RabbitMQ - Flexibele Paren
5. Orchestration - Groep van 6 mensen

Werkwijze

Denk aan onderstaande punten bij het maken van de weekopdrachten:

1. Vorm telkens duo's of grotere teams en wissel, afhankelijk van de weekopdracht
2. Gezamenlijk backlog/issues, samen opstellen/verdelen
3. Kleine frequente commits (en commit op de gemaakte issues)
4. Lever in via assignen issue aan student die de peer review moet doen (+een git tag)

Hieronder verdere uitleg per punt.

1. Groepsvorming voor wekelijkse Opdrachten

Om het samenwerken te oefenen, heb je voor elke opdracht wisselende teamgrootte en -partners. Als developer heb je wellicht de neiging om alles in je eentje te doen, want dat scheelt een boel overhead. En een klasgenoot vragen/vinden kan best spannend zijn. DevOps gaat echter over samenwerken. Voor het managen hiervan heb je ook de tools maar geldt uiteindelijk:

'Individuals and interactions over processes and tools' - Agile manifesto

Week 1

• Vorming van Paren:
  • Studenten vormen zelfgekozen paren.
  • Taalvereiste:
    • 50% van de paren moet werken in Java.
    • De andere 50% werkt in C#.

Week 2

• Wisselen van Partner:
  • Studenten moeten van partner wisselen.
  • Taalkeuze:
    • Elk paar kan kiezen tussen Java of C# op basis van de behoeften van hun project.

Week 3, 4

• Flexibele Paren:
  • Paren kunnen opnieuw wisselen.
  • Terugkeren naar het oorspronkelijke paar is toegestaan.

Week 6

• Groepen Vormen:
  • Groepen van 6 mensen.

2. Gezamenlijke backlog

Binnen Agile en DevOps is een gezamenlijke backlog ook een best practice ("CO-101 Eén backlog per team"). Maak voor je opdracht in GitHub een planning bord aan met ook achterliggende issues aan in de repository en verdeel de taken onderling (assign) op een logische manier (iedereen moet in gelijke mate bijdragen).

Neem hiervoor samen kort opdracht door en kies korte maar logische issue titels. Gebruik issue nummer(s) ook in je commit messages, zodat je vanuit issues daarna ook door/terug kunt klikken naar gedane commits. Vergeet daarbij niet het gebruik van hekje #.

3. Aanhouden Git versiebeheer (best practice)

Tijdens deze course doen we versiebeheer met git. Je commit je uitwerkingen. Hanteer hierbij git (en devops) best practices, zoals:

• use small commits
• commit often
• write clear and short commit messages
• werk samen (beiden committen!)
• werk op zelfde branch of merge regelmatig

4. Peer review

Als je klaar bent: Tag de versie met git als het af is met een 'major versie' 1.0.0 en push alles. Maak dan een issue aan in/bij je Git repo met titel Nakijken en assign deze aan de student die de peer review moet doen.

Het project moet uiterlijk vrijdag worden ingeleverd, waarbij de docent alleen controleert of het project is ingeleverd en niet de kwaliteit ervan beoordeelt. Elke reviewer evalueert de codebase van een toegewezen peer met behulp van de CDMM Evaluatie Peer Feedback Template (aleen de relevante punten uit DevOps maturity model) en beoordeelt of het project voldoet aan een minimum niveau 6 per categorie, met een onderbouwing.

De ingevulde feedback moet uiterlijk maandag als een pull request worden ingediend in de repository van de peer, waarbij de template wordt toegevoegd aan de onderkant van het README-bestand. De eigenaar van de code is verantwoordelijk voor het bekijken en accepteren van de pull request, wat dient als erkenning van de ontvangen feedback.

# Peer Feedback Template: CDMM Evaluatie

**Naam beoordelaar:**  
**Naam student (peer):**  
**Gecodebaseerd project:**  
**Datum van beoordeling:**

---

## 🧑‍🤝‍🧑 Cultuur & Organisatie

- **Minimaal niveau 6?**: [ ] Ja | [ ] Nee
- **Toelichting**:  
  *(Leg uit of de peer minimaal niveau `6` in deze categorie heeft bereikt en verwijs naar specifieke aspecten in de codebase of het project die dit ondersteunen of juist niet.)*

- **Ik kan de volgende punten niet beoordelen omdat...**  
  *(Noem de punten die je niet kunt beoordelen en leg uit waarom, bijvoorbeeld vanwege ontbrekende documentatie, onvoldoende toegang tot relevante informatie, of onduidelijke implementatie.)*

---

## ⛪ Ontwerp & Architectuur

- **Minimaal niveau 6?**: [ ] Ja | [ ] Nee
- **Toelichting**:  
  *(Geef een onderbouwing op basis van de ontwerp- en architectuurelementen die je hebt waargenomen in het project.)*

- **Ik kan de volgende punten niet beoordelen omdat...**  
  *(Noem de punten die je niet kunt beoordelen en leg uit waarom.)*

---

## 🏗️ Build & Deploy

- **Minimaal niveau 6?**: [ ] Ja | [ ] Nee
- **Toelichting**:  
  *(Bespreek de build- en deploymentpraktijken en of deze voldoen aan minimaal niveau `6`.)*

- **Ik kan de volgende punten niet beoordelen omdat...**  
  *(Noem de punten die je niet kunt beoordelen en leg uit waarom.)*

---

## 🧪 Test & Verificatie

- **Minimaal niveau 6?**: [ ] Ja | [ ] Nee
- **Toelichting**:  
  *(Beoordeel de test- en verificatieprocessen en onderbouw je conclusie.)*

- **Ik kan de volgende punten niet beoordelen omdat...**  
  *(Noem de punten die je niet kunt beoordelen en leg uit waarom.)*

---

## 📈 Informatie & Rapporteren

- **Minimaal niveau 6?**: [ ] Ja | [ ] Nee
- **Toelichting**:  
  *(Evalueer de informatie- en rapportagemechanismen en leg uit waarom je tot deze beslissing bent gekomen.)*

- **Ik kan de volgende punten niet beoordelen omdat...**  
  *(Noem de punten die je niet kunt beoordelen en leg uit waarom.)*

5. Inleveren

NB Aan het eind van van de course upload je een .zip met al je opdrachten naar iSAS voor het archief (namelijk voor evt. accreditatie checks bij AIM). Dit inleveren is een eis om totaalbeoordeling/-cijfer te krijgen (want na cijfer toekenning door docent gaat je inlevermogelijkheid automatisch dicht).

Wat moet ik waar uploaden in iSAS?

Hier het totaal overzicht van wat waar in te leveren in iSAS:

• TOETS-02 - Beroepsproduct DevOps <-- PitStop uitbreiding BP groepsrepo
• TOETS-03 - Wekelijkse Huiswerkopdrachten <-- Verzamelzip weekopdracht 1, 2, 3, 4 en 5

Projectrooster

Hieronder het rooster voor het project. Meer details in het .pdf rooster op Slack. Toelichting hieronder. Als je inconsistentie tussen dit rooster en de .pdf opmerkt, meld dit dan bij de docent!

Overzicht Project Blok 2

Projectduur: 9 weken, opdracht voor een echte klant

• Begeleiding en beoordeling door InfoSupport, eindbeoordeling door HAN.

Na de courses start het project in blok 2. Het doel van de courses is om voldoende basis te leggen voor dit project. Je werkt voor een echte opdrachtgever en levert zo snel mogelijk op naar een productieomgeving volgens DevOps-principes. Daarna blijf je doorontwikkelen, inclusief non-functional requirements en quality attributes.

De volledige eisen, competenties en beoordelingscriteria staan in de OWE. Voor een introductie: opdrachtbeschrijving. Meer details over het project volgen in week 9 van de course, waar je ook kennismaakt met de opdrachtgever. Zie eisen eindproject in blok 2 voor aanvullende informatie.

Projectindeling

1. Requirementsfase (Sprint 1)

• Focus: Opstellen van requirements zoals StoryMaps en andere specificaties.

2. Ontwikkelingsfases (Sprints 2 t/m 8)

• Sprint 2-4:
  • Regelmatige feedback en voortgangscontrole.
  • Halverwege (week 5): Tussentijdse beoordeling.
• Sprint 5-8:
  • Doorontwikkeling en itereren op basis van feedback en nieuwe inzichten.

3. Eindfase (Sprint 9)

• Einddemo en beoordeling:
  • Presentatie van eindresultaten.
  • Evaluatie en afronding van het project.

Belangrijke Details

• Projectduur: 40 uur per week
• PreGame: 2 dagen voor User Storymapping en oriëntatie op ontwikkelomgeving.
• Scrum ceremonies: Teams verzorgen zelf alle ceremonies zoals Daily Standups, Sprint Planning, Retrospectives, etc.
• Begeleiding:
  • Korte statusupdates op vrijdag door HAN-begeleiders.
  • Communicatie via e-mail, Slack of korte Teams-calls.
• Sprint Reviews: Met Product Owner op vrijdag in week 2, 4, 7, 9.
  • Tussendoor: Vragenuur DevOps op maandag in alle weken.
  • Bereid vragen goed voor en kom met concrete voorstellen of alternatieven.

Technische Reviews & Evaluaties

• Tech Review (om de week): Focus op DevOps-principes zoals:
  • OTAP-omgevingen, CI/CD, monitoring, codekwaliteit, test coverage, etc.
• Beoordeling:
  • Week 5 en 9: Beoordeling door HAN-docenten op basis van observaties, werk en feedback van PO en InfoSupport-begeleiders.
  • Maandag voor beoordeling: groepssessie voor individuele verantwoording.

Werkdagen & Locatie

• Maandag, woensdag, donderdag: Zelfstandig werken aan DevOps-taken, thuis of op de HAN.
• Locatie-ontwikkeling: Dagen op locatie voor Dev- en Ops-taken; ceremonies duren meestal maximaal een half uur.
• Eindpresentatie (week 9): Alle groepen presenteren voor de opdrachtgever en elkaar.

Eisen aan eindproject van DevOps minor

De opdrachtomschrijving voor het project in blok 2 volgt tijdens dat blok zelf. De requirements moet je 'agile' afstemmen met de klant/opdrachtgever.

De totale beoordeling bestaat uit een oordeel over jullie DevOps teamproduct en een oordeel over je individuele bijdrage op basis van je eigen verantwoording. De beoordeling over het teamproduct staat hieronder beschreven. De individuele beoordeling is volgens hetzelde model als die voor de Course BP.

Beoordeling groepscijfer

Hieronder de eisen en beoordelingscriteria voor het teamproduct. Onderstaand de 6 eisen met korte samenvatting, maar verdere secties geven de details hiervan:

• een ingevuld self assessment
  • CDMM checkpoints met toelichtingen + cijfer indicatie 5 hoofdcategorieën
• a. Omgang Technologie
  • techstack, devops tools, monitoring/metrics
• b. Jullie 'Way of Working'
  • Scrum, Storymap, etc.
• c. Build en Deployment
  • ontwikkelstraat, Azure DevOps, etc.
• d. Documentatie
  • C4, continuous documentation, ADR's, etc.
• e. Soft Skills
  • effectief Agile werken, communiceren en presenteren aan technische+niet technische stakeholders

De checkpoints gelden hierbij als vereisten en dus knock-outs voor het teamcijfer. De beoordelingsniveaus zijn beperkt tot onderstaande 5; dit ter beoordeling aan de begeleiders en opdrachtgever. Als één punt onvoldoende is, is het gehele eindcijfer een onvoldoende (e.g. het zijn knock-outs). Als er Twijfel is kun je het compenseren met Goed of Uitmuntend op andere beoordelingscriteria, om totaal boven de minimale 5.5 te komen om het project succesvol af te sluiten.

• O=knOck-out, 2.0, niet gedaan
• T=Tsja (Twijfelachtig), 4.0, twijfel of serieuze tekortkomingen
• V=Pass (Voldoende), 6.0, punt voldaan
• G=Goed , 8.0, met veel kwaliteit of kwantiteit en afgestemd met begeleiders/opdrachtgever
• U=Uitmuntend 10.0, je ging 'above and beyond' de vereisten

Self assessment

Bij je oplevering (tussentijds en eind) hoort ook een zelf als team samen opgesteld self assessment met het CDMM model (net als bij het beroepsproduct aan het einde van de course). Houdt vanaf het begin hiermee ook al in de gaten of je voldoende variatie in werkzaamheden hebt en op je 'DevOps volwassenheid'. Het CDMM is hierbij niet alleen het beoordelingsmodel, er zijn ook concretere eisen opgesteld onder de volgende vijf beoordelingscriteria A tot en met E hieronder.

A. Technologie

• ⛪ Design & Architecture
• 📈 Information & Reporting

1. Je werkt met de technologiestack zoals de klant die gebruikt (of hebt een goede onderbouwing waarom je daar van afgeweken bent)
2. De applicatie is opgedeeld in (Docker) containers en draait in een Kubernetes (cluster)
3. Je hebt monitoring ingericht die de beschikbaarheid van de (onderdelen van de) applicatie inzichtelijk maakt

B. Way of Working

• 🧑‍🤝‍🧑 Culture & Organization

1. Je hebt nauw contact met opdrachtgever/Product Owner (meer malen per week)
2. Je werkt volgens Scrum met een- of tweeweekse sprints, Scrum ceremonies en wekelijks contactmomenten
   • Elke week een Review met demo
     • met werkende software, uiterlijk week 2 à 3
     • met monitoring, uiterlijk week 3 of 4
   • Opleveren: Een overzicht van verbeterpunten uit de retrospectives (minimaal 1, liever meer, zinvolle procesverbetering per week en het resultaat van de verbetering)
3. In week 1 oriënteer je je op het project en legt je werkwijze als team vast (binnen gegeven kaders project)
   • Een Definition of Ready
   • Opleveren: Definition of Ready
4. Je week 1 maak je ook een User Story Map
   • User story map en overige zaken
   • Verdeeld in zinvolle slices die je gebruikt in de communicatie met de opdrachtgever en bijhoudt gedurende het project.
   • High level user stories met prioritering en waar mogelijk onderliggende acceptatiecriteria, persona's e.d.
   • Initiele backlog
   • Opleveren: Gevulde backlog, User story map, elke week een foto of afbeelding van de bijgewerkte map
5. Je past code reviews toe
   • Je hebt een systeem van pull requests ingericht met reviewopmerkingen in Azure DevOps (of ander gekozen Code management systeem)
   • Bij persoonlijke beoordelingen (na 4 en 8 weken) tenminste 1 review laten zien van jouw over andermans code.

C. Build en Deployment

• 🏗️ Build & Deploy

1. Je hebt na sprint 1 een 'productie omgeving' en werkt deze daarna bij
2. Je hebt na sprint 2 à 3 werkende software in productie staan en bouwt daar vervolgens op voort
3. Je denkt na over meerdere omgevingen, dus naast productie bv. een develop, QA of staging omgeving
4. Je levert vanaf sprint 5 à 6 aantoonbaar vaker op dan enkel einde sprint, middels automatische uitrol
5. Je hebt automatische tests in een build pipeline

D. Documentatie

• ⛪ Design & Architecture

1. Je hebt je product gedocumenteerd met:
   • Een goede README voor developers (volgens Microsoft richtlijnen)
   • C4-diagram: minstens een Context en Container diagram, inlcusief toelichting op elk, als documentatie van je Software Architectuur
   • Architectuurbeslissingen in de vorm van ADR’s
   • Specificaties in de vorm van given-when-then’s (Gherkin)
2. Je hebt zelf een beeld van je DevOps volwassenheid via een self assessment van het CDDM
   • met een realistisch deelcijfer/niveau op elk van de 5 categorieën
   • en per cijfer/categorie ook eigen toelichting* over hoe je 'checkpunten' hebt gehaald en waar dit zichtbaar is in eigen werk (of (net) niet hebt behaald (wellicht met goede reden),
3. Opleveren: Een overzicht van de (runtime) omgevingen, hoe ze zijn ingericht, en beheerd worden (incl. de koppeling met versiebeheer).

E. Soft skills

• 🧑‍🤝‍🧑 Culture & Organization

1. Je werkt prettig samen met de opdrachtgever en geeft een professionele indruk
2. Je werkt goed samen als team en creëert een goede werksfeer
3. Je valt de opdrachtgever niet lastig met technische details, maar kunt issues en werkzaamheden vertalen naar bedrijfstermen
4. Je schermt als team de opdrachtgever af van kleine afwijkingen van de planning
5. Maar bij grote(re) tegenslagen communiceer je tijdig, zodat opdrachtgever kan meedenken over alternatieve richtingen
6. Bij extra tijd en evt. opraken van werk denk je pro actief mee met business over mogelijk waardevolle features

Toelichting

Merk op dat dat bovenstaande punten grofweg knock-outs zijn van het minimale verwachte werk, de te gebruiken werkwijze en de op te leveren zaken (deliverables). Voor het komen tot een concreet cijfer kijken begeleiders naar de hoeveelheid en de kwaliteit van met team gemaakte product, en ook omgang en goed hanteren van Agile proces en samenwerken als team. Bedenk hierbij dat het gemaakte product een DevOps product is, dus focus niet alleen op code en functionaliteit, maar toon DevOps volwassenheid. Andersom, focus je niet alleen op pipelines, build bakeries etc. maar maak ook een product wan zonder nieuwe features en requirements heb je geen DevOps nodig.

Hoe ga ik naar ruim voldoende, goed, zeer goed of uitmuntend?

Voor het aantonen van hogere 'Devops volwassenheid' (en dus eindcijfer boven een 6) kun je — net als in de coursefase — het CDMM er weer bij pakken en jezelf hiermee assessen. Hou het niet bij alleen afvinken, maar argumenteer per checkpunt onder de verschillende niveaus van de beoordelingscriteria waarom je het wel of niet of deels hebt. Om je beschrijving enigszins kort te houden helpt het wel om ook te linken naar concreet werk in je code management systeem. Dus een goede linktekst op te nemen vergelijkbaar met hoe je dit in individuele fact sheet doet.

Zeker bij de hogere punten XX-30X en XX-40X moet je behalve zeggen DAT je het doet ook uitleggen/beargumenteren HOE je hier dan aan voldoet. Voor het afvinken van deze criteria moet je ook 'bewust bekwaam' zijn en dit aantonen. Anders kan een beoordelaar aanvoeren dat het een 'toevalstreffer is'. Ook is het zelden voldoende om te zeggen 'Dit checkpunt hebben we omdat we Tool X gebruiken'. Bijvoorbeeld 'Cross Silo analysis voldoen we aan omdat we Prometheus en Grafana gebruiken'. Geef of beschrijf in plaats daarvan een concreet scenario van een 'cross silo analysis'. Lees ook de toelichting bij verschillende checkpoints in de 'lijst van devops concepten'.

Een goede redenering en argumentatie is dus ook nodig voor een goed cijfer. Je kunt ook een checkpunt afvinken, maar aangeven dat je er deels nog niet aan voldoet, maar wel een oplossingsrichting geven. Dus maai liever het gras voor de voeten weg van mogelijke kritiek of vragen)

Figuur 1: Het Continuous Delivery Maturity Model van infoq.com

Merk overigens op dat het CDMM van InfoQ is, iets anders is dan InfoSupport. Als je zelf een ander moderner, simpeler, passender of anderszins beter maturity model weten of vinden dan het CDMM uit de coursefase, dan kun je deze in overleg met de begeleiders ook gebruiken voor dit self assessment! Plumlogix model is wat simpel en enkel 'cretologie' zonder onderscheid tussen niveaus, dus dit moet je allemaal zelf definiëren en beargumenteren. Het Nederlandse NISI heeft bijvoorbeeld ook een recenter maturity model, CD3M genaamd, maar de term 'continuous intelligence' hierin is nogal vaag. Het CDMM van InfoQ (feb 2013) is nog van (net) voor de tijd dat veel huidige DevOps tools ontstonden (bijvoorbeeld Docker (1.0 in maart 2013 uit dotCloud) of Kubernetes (2014, open-source versie onder de naam 'Borg') bestonden of gemeengoed waren). Zelfs microservices werden net iets later pas hot. Maar het CDMM bevatte conceptueel al wel heel veel zaken zoals een 'Build bakery' (dit idee zit in de base images uit Docker) en 'microservices' zijn de 'componenten' uit OA205: 'Modules omzetten naar componenten' (e.g. van modulaire monolith naar microservices, waar OA-101 'Systeem opsplitsen in modules' nog te zien is als de stap is van een niet-modulaire monoliet naar een wel-modulaire).

Figuur 2: Een alternatief DevOps Maturity Model van plumlogix.com

Beoordeling Individuele bijdrage

• Datum: 11 okt 2021
• Auteur: Bart van der Wal

1. Inleiding: Verantwoording eigen bijdragen

Naast je beoordeling als team voor het samen gemaakte product krijg je ook een individueel cijfer op basis van jou bijdrage aan dit product. Dit gebeurt zowel tijdens beroepsproduct en voor je product uit blok 2.

Je hoeft tijdens het project geen uitgebreid verslag te schrijven, en sowieso geen Word documenten, zoals in sommige andere projecten. Maar wel moet elk groepslid wel een eigen markdown bestand toevoegen en bijhouden (direct) in de docs folder van het team repository/project. Hieronder het template. Dit template bevat de volgende 9 kopjes. Bij elk kopje kort vermeld de competenties uit de OWE of 'devops maturity' aspecten die hier in ieder geval bij horen:

1. Code/platform bijdrage

   • DevOps-1 Continuous Delivery
   • CDMM: Design & Architecture
   • CDMM: Test & Verification

2. Bijdrage app configuratie/containers/Kubernetes

   • DevOps-2 Orchestration
   • DevOps-4 Containerization
   • CDMM: Design & Architecture

3. Bijdrage versiebeheer, CI/CD pipeline en/of monitoring

   • DevOps-3 GitOps
   • DevOps-5 SlackOps
   • CDMM: Information & Reporting
   • CDMM: Test & Verification
   • CDMM: Build & Deploy

4. Onderzoek

   • DevOps-6 Onderzoek

5. Bijdrage code review/kwaliteit anderen en security

   • DevOps-4 DevSecOps
   • CDMM: Culture&Organization
   • CDMM: Test & Verification

6. Bijdrage documentatie

   • CDMM: Design & Architecture
   • DevOps-6 Onderzoek

7. Bijdrage Agile werken, groepsproces, communicatie opdrachtgever en soft skills

   • DevOps-7 Attitude*
   • CDDM: Culture & Organization

8. Leerervaringen

   • DevOps-7 Attitude
   • CDDM: Culture & Organization

9. Conclusie & feedback

   • DevOps-7 Attitude

Dit document dient als bewijslast richting beoordelaars op meer afstand, maar ook voor je eigen overzicht en ter referentie tijdens de groepssessie voor beoordeling van de individuele bijdrages.

Om een basisvulling te vereisen maar ook al te grote omvang van het document te beperken ivm beoordeelbaarheid, vermeldt het template wat minimum- en maximumaantallen. Dit bestand houdt je bij tijdens het hele project.

Hieronder in sectie 2 wat eisen en richtlijnen over het 'invullen' van het template. In sectie 3 volgt het template zelf, om te copy-pasten naar je eigen repo. In sectie 4, 5 en 6 daarna nog wat achtergrondinformatie bij de individuele beoordeling, de individuele delta die dit geeft op het groepscijfer respectievelijk de algemene beoordelingscriteria die hierbij relevant zijn.

2. Eisen en richtlijnen Individuele verantwoording

Hieronder de richtlijnen in 4 subsecties, maar deze lijst is al de TL; DR:

1. Zorg dat template teksten zo snel mogelijk weg zijn uit de templates, uiterlijk bij (en enige ;) tussentijdse beoordeling.
2. Zorg dat verantwoording ook tussentijds al leesbaar en compleet is (tussentijds eventueel TODO's voor jezelf)
3. Gebruik vrije tekst en bullets
4. Gebruik (semantische) linkteksten GEEN kale URL's.

2.1 Beoordelaar kijkt niet als er nog template teksten aanwezig zijn

Verwijder voor het inleveren alle template teksten! Zodat alleen de kopjes (en opgesomde competenties) overblijven!

De template teksten staat in de markdown als hulp. Maar aanwezigheid van deze (standaard) template teksten op het moment van beoordelen ziet de beoordelaar als een teken dat je nog niet klaar bent ermee bent. Dit heeft als gevolg dat hij/zij dus niet kan beoordelen. Niet (kunnen) beoordelen betekent een onvoldoende!

Vervang bijvoorbeeld <mijn-naam> door Eliezer Yudkowsky. NB: Dus NIET <Eliezer Yudkowsky >; de angle brackets (< en >) zijn om templateteksten aan te geven, dus bij invullen moet je deze WEGhalen.

2.2 Ook leesbaar en compleet bij tussentijdse beoordeling

Bij tussentijdse toetsing heb je al een volledige en leesbare versie, met minstens de minimale aantallen. Richting de eindbeoordeling werk je deze verder bij, en schrapt evt. punten als je anders over het maximum aantal gaat en je inmiddels grotere/belangrijker zaken hebt. Of als je punten kunt samenvoegen onder 1 noemer (N.B. Punten zijn evt. terug te vinden via versie historie).

Dus je vult ook al een voorlopige eindoordeel in. En bijvoorbeeld hebt ook al de helft van de tips en tops.

Mocht je er tussentijds achterkomen dat onder een kopje nog te weinig of zelfs GEEN werk en/of links kunt geven, neem voor je zelf dan wat TODO's op, met een richting, zodat je in de 2e helft kunt zorgen dat je wel voldoende varieteit en breedte in je werk hebt.

2.3 Gebruik vrije tekst én bullets

TL; DR Dus: gebruik een combinatie van beschrijvende teksten en korte bullet lijsten met links naar werk in het met team gebruikte 'code management systeem' waarmee beoordelaar je werk kan verifieren.

De bedoeling van deze verantwoording is dat het korte tekstuele beschrijving is. Voor structuur gebruik je hierbij ook bullets. Maar je gebruikt NIET alleen maar bullets, of alleen maar paragrafen. Je gebruikt een combinatie. Typisch is een paragraaf dan een inleiding bij een bullet lijst, zoals Qua Kubernetes configuratie deed ik het volgende. Of een toelichting bij iets interessantes. Schrijf ook een korte inleiding.

2.4 Gebruik linkteksten

• Maak van links shortlinks, dus met goede linktekst en niet de hele originele URL’s (die nemen anders groot deel van je documentatie in beslag, dat is ongewenst)
• Maak deze links ook naar bv. code diffs of pull requests i.p.v. direct naar volledige bestanden/folders in versiebeheer met integrale stukken code die van iedereen in het team kunnen (en horen!) te zijn.
• Plaats ook opmerkingen in pull requests (review opmerkingen) en github issues ().

Het agile principe van face-to-face contact is ook belangrijk, maar stem niet alles alleen maar mondeling af zorg voor de traceerbaarheid en beoordeelbaarheid door externen. Zo heeft groepsgenoot ook iets om op terug te vallen na mondeling afstemmen (of deze notuleert zelf mondling overleg in issue).

Als je dit onverhoopt tijdens het project te weinig gedaan hebt, kun je alsnog dit documenteren. In je markdown zelf maakt deze wellicht te groot, maar dan kan het in een taak/issue waar je in markdown naar linkt, of in de wiki o.i.d. (hier hebben jullie hopelijk ook team standaard voor, en anders kun je die wellicht met terugwerkende kracht opstellen, in kader van overdracht naar anderen, nu jullie dit project gaan verlaten).

Dus vervuil je markdown niet met hele lange URL links, maar kort deze in, of - beter nog - maak een linktekst die echt semantisch is, en ook thuishoort in een lopende tekst. In de tabel hieronder drie voorbeelden.

Mwegh...	Okee.	Top!

3. Markdown template individuele bijdrage

# Eigen bijdrage <mijn-naam>

Als deliverable voor de individuele bijdrage in het beroepsproduct maak een eigen markdown bestand `<mijn-voornaam>.md` in je repo aan met tekst inclusief linkjes naar code en documentaties bestanden, pull requests, commit diffs. Maak hierin de volgende kopjes met een invulling.

Je schrapt verder deze tekst en vervangt alle andere template zaken, zodat alleen de kopjes over blijven. **NB: Aanwezigheid van template teksten na inleveren ziet de beoordelaar als een teken dat je documentatie nog niet af is, en hij/zij deze dus niet kan of hoeft te beoordelen**.

Je begin hier onder het hoofdkopje met een samenvatting van je bijdrage zoals je die hieronder uitwerkt. Best aan het einde schrijven. Zorg voor een soft landing van de beoordelaar, maar dat deze ook direct een beeld krijgt. Je hoeft geen heel verslag te schrijven. De kopjes kunnen dan wat korter met wat bullet lijst met links voor 2 tot 4 zaken en 1 of 2 inleidende zinnen erboven. Een iets uitgebreidere eind conclusie schrijf je onder het laatste kopje.

## 1. Code/platform bijdrage

Competenties: *DevOps-1 Continuous Delivery*

Beschrijf hier kort je bijdrage vanuit je rol, developer (Dev) of infrastructure specialist (Ops). Als Developer beschrijf en geef je links van minimaal 2 en maximaal 4 grootste bijdrages qua code functionaliteiten of non-functionele requirements. Idealiter werk je TDD (dus ook commit van tests en bijbehorende code tegelijk), maar je kunt ook linken naar geschreven automatische tests (unit tests, acceptance tests (BDD), integratie tests, end to end tests, performance/load tests, etc.). Als Opser geef je je minimaal 2 maximaal 4 belangrijkste bijdragen aan het opzetten van het Kubernetes platform, achterliggende netwerk infrastructuur of configuration management (MT) buiten Kubernetes (en punt 2).

## 2. Bijdrage app configuratie/containers/kubernetes

Competenties: *DevOps-2 Orchestration, Containerization*

Beschrijf en geef hier links naar je minimaal 2 en maximaal 4 grootste bijdragen qua configuratie, of bijdrage qua 12factor app of container Dockerfiles en/of .yml bestanden of vergelijkbare config (rondom containerization en orchestration).

## 3. Bijdrage versiebeheer, CI/CD pipeline en/of monitoring

Competenties: *DevOps-1 - Continuous Delivery*, *DevOps-3 GitOps*, *DevOps-5 - SlackOps*

Beschrijf hier en geef links naar je bijdragen aan het opzetten en verder automatiseren van delivery pipeline, GitOps toepassing en/of het opzetten van monitoring, toevoegen van metrics en custom metrics en rapportages.

NB Het gebruik van *versiebeheer* ((e.g. git)) hoort bij je standaardtaken en deze hoef je onder dit punt NIET te beschrijven, het gaat hier vooral om documenteren van processtandaarden, zoals toepassen van een pull model.

## 4. Onderzoek

Competenties: *Nieuwsgierige houding*

Beschrijf hier voor het Course BP kort je onderzochte technologie met een link naar je blog post, of het toepassen ervan gelukt is en hoe, of waarom niet. Beschrijf evt. kort extra leerervaringen met andere technologieen of verdieping sinds het blog.

Tijdens het grote project beschrijf je hier onderzoek naar het domein en nieuwe onderzochte/gebruikte DevOps technologieën. Wellicht heb je nogmaals de voor blog onderzochte technologie kunnen toepassen in een andere context. Verder heb je nu een complex domein waar je in moet verdiepen en uitvragen bij de opdrachtgever. Link bijvoorbeeld naar repo's met POC's of, domein modellen of beschrijf andere onderwerpen en link naar gebruikte bronnen.

Als de tijdens course onderzochte technologie wel toepasbaar is kun je dit uiteraard onder dit punt noemen. Of wellicht was door een teamgenoot onderzochte technologie relevant, waar jij je nu verder in verdiept hebt en mee gewerkt hebt, dus hier kunt beschrijven. Tot slot kun je hier ook juist een korte uitleg geef over WAAROM jouw eerder onderzochte technologie dan precies niet relevant of inpasbaar was. Dit is voor een naieve buitenstaander niet altijd meteen duidelijk, maar kan ook heel interessant zijn. Bijvoorbeeld dat [gebruik van Ansible in combi met Kubernetes](https://www.ansible.com/blog/how-useful-is-ansible-in-a-cloud-native-kubernetes-environment) niet handig blijkt. Ook als je geen uitgebreid onderzoek hebt gedaan of ADR hebt waar je naar kunt linken, dan kun je onder dit kopje wel alsnog kort conceptuele kennis duidelijk maken.

## 5. Bijdrage code review/kwaliteit anderen en security

Competenties: *DevOps-7 - Attitude*, *DevOps-4 DevSecOps*

Beschrijf hier en geef links naar de minimaal 2 en maximaal 4 grootste *review acties* die je gedaan hebt, bijvoorbeeld pull requests incl. opmerkingen. Het interessantst zijn natuurlijk gevallen waar code niet optimaal was. Zorg dat je minstens een aantal reviews hebt waar in gitlab voor een externe de kwestie ook duidelijk is, in plaats van dat je dit altijd mondeling binnen het team oplost.

## 6. Bijdrage documentatie

Competenties: *DevOps-6 Onderzoek*

Zet hier een links naar en geef beschrijving van je C4 diagram of diagrammen, README of andere markdown bestanden, ADR's of andere documentatie. Bij andere markdown bestanden of doumentatie kun je denken aan eigen proces documentatie, zoals code standaarden, commit- of branchingconventies. Tot slot ook user stories en acceptatiecriteria (hopelijk verwerkt in gitlab issues en vertaalt naar `.feature` files) en evt. noemen en verwijzen naar handmatige test scripts/documenten.

## 7. Bijdrage Agile werken, groepsproces, communicatie opdrachtgever en soft skills

Competenties: *DevOps-1 - Continuous Delivery*, *Agile*

Beschrijf hier minimaal 2 en maximaal 4 situaties van je inbreng en rol tijdens Scrum ceremonies. Beschrijf ook feedback of interventies tijdens Scrum meetings, zoals sprint planning of retrospective die je aan groespgenoten hebt gegeven.

Beschrijf tijdens het project onder dit kopje ook evt. verdere activiteiten rondom communicatie met de opdrachtgever of domein experts, of andere meer 'professional skills' of 'soft skilss' achtige zaken.

## 8. Leerervaringen

Competenties: *DevOps-7 - Attitude*

Geef tot slot hier voor jezelf minimaal 2 en maximaal **4 tops** en 2 dito (2 tot 4) **tips** á la professional skills die je kunt meenemen in toekomstig project, afstuderen of wellicht zelfs verdere loopbaan (de 'Transfer' uit STARRT). Beschrijf ook de voor jezelf er het meest uitspringende hulp of feedback van groepsgenoten die je (tot dusver) hebt gehad tijdens het project.

## 9. Conclusie & feedback

Competenties: *DevOps-7 - Attitude*

Schrijf een conclusie van al bovenstaande punten. En beschrijf dan ook wat algemener hoe je terugkijkt op het project. Geef wat constructieve feedback, tips aan docenten/beoordelaars e.d. En beschrijf wat je aan devops kennis, vaardigheden of andere zaken meeneemt naar je afstudeeropdracht of verdere loopbaan.

4. Werkwijze beoordeling individuele bijdrage

Voor je individuele bijdrage in het project krijg je ook een beoordeling.

4.1 Input voor beoordeling

Basis hiervoor is de input van je teambegeleider(s), en evt. observaties van de klant/opdrachtgever tijdens Scrum ceremonies of daarbuiten of andere door beoordelaars belangrijk gevonden punten. De inbreng tijdens Productdemo of de Review sessie kan ook doorslag geven als je ervoor nog te weinig zichtbaar was. Uiteraard weegt ook mee het correct en voor externen ook leesbaar en begrijpelijk invullen van bovenstaand template met je verantwoording van je individuele bijdrage.

4.2 Groepssessie individuele beoordeling

De uiteindelijke individuele beoordeling gebeurt n.a.v. een groepssessie. Dit klinkt wellicht tegenstrijdig, want je focust in de verantwoording op eingen werk, maar we gaan er vanuit dat je toelichting bekend is bij teamgenoten en geen verantwoording. Omdat samenwerking met groepsgenoten en bv. het reviewen van elkaars werk, of anderszins samenwerken centraal staat bij DevOps. Tijdens de sessie geef je ingevulde tekst toelicht. Deze meeting duurt een half uur tot een uur afhankelijk van je groepsgrootte. Je hebt hierbij ongeveer 5 minuten voor je eigen werk. Deze sessie plan je in met je begeleiders/beoordelaars. De begeleider vraagt tijdens deze sessie bijvoorbeeld het volgende:

• Waar ben je het meest trots op van je bijdragen aan het teamproduct?
• Waar heb je nog het minst laten zien?
• Vervolgens lopen we samen snel door je factsheet heen

Aan het eind van de sessie geeft de beoordeleer aan wat je delta op het groepscijfer is.

Als teamlid mag je opmerkingen/input geven, maar we proberen discussies te bewaren voor andere contactmomenten.

4.3 Gebruik links

Naast de tekst zelf is natuurlijk de kwaliteit van het daarin gelinkte bronmateriaal (zorg dat de links zelf ook werken, en bv. wijzen naar een diff of review van eigen werk, i.p.v. naar werk van anderen). Zorg ook dat het presentabel is door GEEN kale lange URL's te geven, maar de URL's zelf waar mogelijk in te korten maar ook netjes achter een link te stoppen met korte maar duidelijke linktekst in een duidelijke en actief geschreven zin (of herschrijf).

5. Delta op teamcijfers

Je eindcijfer is het groepscijfer en nog individuele 'delta' hierop. Deze delta is in principe 0, dus dat betekent dat je eindcijfer hetzelfde is als het groepcijfer. Maar als beoordelaars aanleiding hebben kunnen deze een delta geven die varieert van -1 tot +2 op het teamcijfer. Ook geldt dat als je als teamlid geheel niet of duidelijk te weinig hebt bijgedragen, of je bijdrage niet voldoende kunt verantwoorden, dan is je eindcijfer een onvoldoende, ongeacht het teamcijfer. Dit laatste betekent dus dat je het project een volgende editie over moet doen. Hetzelfde geldt uiteraard als na toepassen van een delta je eindcijfer onder de 5,5 zit.

• 2 Project niet afgerond
• 4.5 Project gedaan maar onvoldoende bijgedragen (geen vormbehoud courses) en/of deze bijdrage niet voldoende verantwoord
• -1 Op aantal punten tekort geschoten, maar wel significante bijdrage
• -0,5 Op één of enkele punten tekortgeschoten op verwachte input of toegezegde bijdrage
• +0 Project goed meegewerkt, gezorgd voor significante bijdrage en kwaliteit en vormbehoud van course
• +0,5 Erkenning van belangrijke bijdrage op een aspect van het teamproduct of -proces
• +1 Belangrijke extra invloed qua kwantiteit of kwaliteit van teamproduct binnen het team op één of enkele punten
• +2 Op een aantal punten een essentiële positieve extra invloed qua kwaliteit, kwantiteit van werk

Om bovenstaande wat concreter te maken hieronder enkele (fictieve) beschrijvingen van projectsituaties en de hieruit voortkomende beoordeling.

5.1 Voorbeeld 1

Een team heeft als teamcijfer een 7 gehaald met een weinig opvallend project met wel een enthousaste en duidelijk einddemo. Eigenlijk al het gevraagde zat erin, zij het minimaal. Teamlid A heeft een belangrijke invloed gehad bij de realisatie van de database, en is 'above and beyond' gegaan en krijgt een 7+1=8. Teamlid B heeft steady gecodeerd, maar heeft geen enkele verslaglegging gedaan en kan achteraf ook onvoldoende terugvinden in aangemaakte issues of commit opmerkingen om dit nog te fixen voor de inlever deadline. Een 4.

5.2 Voorbeeld 2

Een team heeft een 6 gekregen. In dit team is Teamlid X in week 2 helaas uitgevallen (een 1). Het security aspect missen zij geheel, want heeft verder niemand opgepakt ondanks dat dit teamverantwoordelijkheid is. Wel is er een nieuw microservice en wijzigingen in back-end en front-end met noSQL storage. Teamlid Y heeft een bestaand issue nooit gefixt, hoewel dit wel met hem is afgesproken omdat dit bij zijn expertise hoorde. Achterliggende reden was dat zijn technologie toch niet in bleek te passen in het beroepsproduct en hierdoor was hij gedemotiveerd.

De team beslissing bij sprint 2 om dit te laten vallen en te documenteren als ADR was hij het eigenlijk niet mee eens. Maar dat durfde hij toen niet te zeggen. Omdat hij achter de schermen bleef 'doormodderen' kwam hij een week onvoldoende aan zijn issues toe. Gelukkig kon hij hier wel op reflecteren en heeft op de front-end in de week erna nog goed bijgedragen: (6-0.5 = 5.5).

Teamlid Z heeft alle issues van X opgelost, en ook de hele front-end opgezet, en hierbij ook een BDD aanpak gerealiseerd waardoor vanuit de front-end de hele applicatie geacceptatest kan worden: 6+2 = 8.

6. Beoordelingscriteria

Bij de beoordeling is uitgangspunt dus een ingevulde individuele bijdrage en uiteraard ook alles wat erachter zit qua product/configuratue en documentatie in gitlab/versiebeheer. De beoordelaars hebben verder ook indrukken beoordelaars tijdens SCRUM sessies en dergelijke. Tijdens het project hoef je niet alles te doen wat in de course behandeld is, maar je hebt hier wel gebruik van gemaakt en toont vormbehoud op de competenties uit de course fase (zoals ook vermeld in individuele bijdrage):

• DevOps-1 Continuous Delivery
• DevOps-2 GitOps
• DevOps-3 Containerization
• DevOps-4 DevSecOps
• DevOps-5 SlackOps
• DevOps-6 Onderzoek
• DevOps-7 Attitude

Verder kunnen beoordelaars ook algemene teamcompetenties meenemen zoals:

• Focus op kwaliteit en kwantiteit van het werk
• Pragmatisch houding (KISS) en rol pakken
• Teamgenoten helpen
• Kritische houding, focus op testen, security en reliability
• Aanspreekbaar zijn en verantwoordelijkheid nemen
• Nieuwsgierige en onderzoekende houding

Week 1 - GitOps

GitOps Definitie

GitOps is reconciling a desired state in Git with a runtime environment
Everett Toews 10-2-2020, deloitte.com

Week 1 Opdracht

Je krijgt de 1e opdracht via GitHub Classrooms. Je kiest/vindt hierbij zelf een partner en bouwt samen een klein software project. Het is meer "Hello world" dan echte functionaliteit, omdat de focus NIET op code ligt, maar op DevOps technieken.

Het project bevat unit tests, en de tutorial laat dit je test first opzetten (TDD). Dit is de moderne standaard. Hierbij heeft je programma eigenlijk nog geen echt entrypoint. Want de tutorial geeft aan een classlib aan te maken in .NET. Laat dit voor nu zo, dit ga je volgende week refactoren/uitbreiden naar wel een entry point (main) en ook een .NET web api project, zoals de docent als het goed bespreekt (anders naar vragen!). En nog later kun je de webapplicatie continuous deployment of delivery toepassen.

Neem het project aan het begin samen door, verdeel taken en schrijf op het eind een self assessment op basis van CDMM en een reflectie zoals de werkwijze bij weekopdrachten vraagt.

Het is aan te raden enkele eigen unit tests toe te voegen, en evt. te experimenteren met 'parameterized tests'. In ieder geval geen code vol met unit testing anti patterns (zie video David Farley) i.v.m. met .

Plenair einde les

Lees het overzichtsartikel over gitops op gitops.tech. Schrijf interessant/onbekende termen op. Bekijk hierna ook naar lessen overzicht van deze minor.

• Wat betekent de term reconcilliation?
• Geef drie voorbeelden van toepassen van reconcilliation in een software project denk aan
  • a) een feature release
  • b) dependency management/update en
  • c) infrastructure as code
• Wat is het verschil tussen declaratief en imperatief?
  • (kun je koppelen aan term 'reconcilliation')
• Wat is het idee van pull-based vs push-based GitOps?
  • Is 1 van de 2 beter?
  • (Welke gebruikt InfoSupport?)
• Welke onderdelen moeten we in de komende weken nog bekijken?
• Welke onderdelen gaan we NIET behandelen (maar zijn wel kandidaat voor eigen onderzoek voor week 5)
• Wat is een run time environment? Geef 3 voorbeelden
• Hoe verloopt een applicatie wijziging binnen GitOps en wat is het verschil met andere (oudere) aanpakken?

Leerdoelen

• Je kent Git, kunt het gebruiken op command line en GUI en weet wat je hierin opslaat en wat niet
• Je kent de rol van branches in Git en erbuiten en enkele alternatieven voor feature branching die beter matchen met Continuous Integration
• Je kent twee Git workflows om in een team software producten te bouwen
• Je kunt een Git hook maken, en kent de mogelijkheden en beperkingen ervan
• Je kunt commits doen in (Git) versiebeheer en kent de git basics zoals 4 area's, branches, .gitignore en omgang met Git's 'gedistribueerde karakter'
• Je kunt markdown gebruiken en een UML diagram in tekst opstellen
• Je kunt de definitie van GitOps en kunt de term uitleggen en hebt een onderbouwd oordeel of het een buzzword is of meer dan dat
• Je kunt de termen reconcilliation en runtime environment uit de GitOps definitie uitleggen en van elk 3 voorbeelden geven
• Je kent het verschil tussen code en software en de relatie met 'source control'
• Je kent verschil tussen git en git platforms als GitHub of GitLab en kunt ermee werken

Lesoverzicht

• Les 1 - Linux 1/2
• Les 2 - Introductie GitOps
• Les 3 - Getting Git
• Les 4 - Git Workflows + Weekopdracht bespreken & peer feedback (CDMM, aanwezigheid, reflectie)

Les 1 - Intro Minor

DevOps is een cultuur van samenwerking tussen software developers en infrastructuur beheerders (=operations) en eventueel nog andere specialisten

Het doel van DevOps is om eindgebruikers waardevolle software te leveren en snel en succesvol in te kunnen spelen op veranderingen in het domein van deze software.

Voorbereiding

Geen voorbereiding, omdat dit introductie les is. Wel voor volgende lessen!

Lesprogramma

Ochtend

• Aanwijzingen Registratie
  • Vergeet niet om de volgende les bij te wonen, want het is belangrijk om duo's te vormen voor de opdracht die aan het einde van week 1 moet worden ingeleverd. We organiseren deze groepen tijdens de tweede les, dus je aanwezigheid is essentieel.
• Samen kijken naar de video-introductie voor de minor.
• .pdf slides/presentatie van de minor.
• InfoSupport Project Periode 2 presentatie.

PAUZE - 15 min.

• Eenvoudige spellen in de klas, in groepen werken en elkaars namen leren.

PAUZE - 15 min.

• Lesoverzicht - Samen controleren
  • Introductie van de wekelijkse opdracht en hoe deze is georganiseerd.
• Hoe cijfers worden berekend voor Dev en DevOps

EIND - Mentimeter

Middag

• 'T-shaped professional'
  • Mentimeter
• Microservices in 9 Stappen
  • STAP 1 - Geen Monolith maar Microservices Architecture
    • Keywords:
      • Modulaire Monolith
      • Strangle Monolithic Application
      • BFF: Backend For Frontend
    • STAP 2 - Message Bus
    • STAP 3 - Containerization Microservices
    • STAP 4 - Naar Kubernetes met pods, services, ingress, etc.
    • STAP 5 - Kubernetes Orchestration
    • STAP 6 - Pipeline Code Bouwen
    • STAP 7 - Image Registry
    • STAP 8 - GitOps → Reconciliation
    • STAP 9 - Monitoring (analytics, SlackOps)

Leerdoelen

• Je hebt een idee van DevOps cultuur, wat een T-shaped professional is en de relatie ertussen
• Je hebt al een idee van wat een MicroService Architecture (MSA) is waar we naar toe werken in deze minor en de onderdelen hiervan
• Je kent het verschil tussen MSA en een monoliet en kent het idee van het 'Strangler' pattern

Quiz

Test je kennis over T-shaped professionals met deze multiple choice quiz:

Les 2 - Getting Git

Bron: https://xkcd.com/1597/

Voorbereiding

Reminder: De voorbereiding is niet optioneel. Zonder voorbereiding wordt het lastig om mee te doen met de les en dat is een verspilling van zowel je eigen tijd, tijd van je mede studenten en tijd van de docent. Niet aardig.

1. Lees de opdrachtbeschrijving van deze week.
2. Accepteer 1e weekopdracht via de GitHub Classroom link die docent je geeft.
3. Zorg dat je de laatste (LTS) versie van Git lokaal geinstalleerd hebt.
4. Review Git
   1. Uitgangspunt is al enige ervaring met Git uit eerdere projecten, zowel theorie als prakijk. Als Git nieuw is, of heel lang geleden kun je deze korte 15 minuten git intro op YouTube van een zekere Colt Steele kijken.
   2. Maak de online oefeningen van module 1 (introduction sequence) van Learn git branching
5. Lees [dit artikel van Priyam Singh (2020) over de 'four area's'
6. Haal uit de officiele 'git reset' documentatie het verschil tussen hard, soft en mixed git reset.
7. Beantwoord de volgende vragen (hier komen wij in de les op terug)
   • Schrijf uit je hoofd op wat de 'four area's' van Git zijn.
   • Hoe past de remote repository bij deze four area's?
   • Hoe commit je het verwijderen van een file?
   • Hoe commit je het veranderen van een bestandsnaam?
   • Kun je een Git commit message later nog aanpassen via de command line? (Zo ja, hoe? Als niet, waarom niet?)
   • Wanneer heb je langere 'commit trail'? Bij gebruik van merge of van rebase?
   • Wat is de standaard 'mode' van git reset (mixed)?
   • Wat zou een toepassing kunnen zijn van git reset soft?

Bron: www.theserverside.com

Lesprogramma

Figuur 1: GitOps in a nutshell (Bron: vocal.media)

• GitOps Betekenis
  • Reconciliation
• Wekelijkse Opdracht
  • Discussie over het vormen van groepen
  • Introductie tot cursus rubric CDMM — Nodig voor Wekelijkse Opdracht reflectie
  • Introductie deze week Opdracht

PAUZE — 15 min.

• Doornemen huiswerk vragen
• Maak de online oefeningen van module 2 en 3 van Learn git branching (4 en 5 optioneel)
  • Ramping up
  • Moving work around

• Bespreken "advanced" termen
  • De staging area (en hoe git reset nou precies werkt)
  • Het netjes maken van commit messages en hergroeperen van commits
  • De stash
  • Cherry picking
  • remotes
  • Changes rebasen i.p.v. mergen

Vooruitblik

Volgende DevOps les over Git workflows, alternatieven voor git branches en GitOps. Bekijk het huiswerk ook!

Leerdoelen

• Je kunt uitleggen wat GitOps is, de rol die Git hierin speelt en de betekenis van woorden 'runtime', 'reconcilliation' en 'desired state' hierbij
• Je kent de basis Git commando's, als add, commit, push, pull, stash en concepten als Git's four area's
• Je kent ook enkele geavanceerdere Git commando's en werkwijzen zoals git reset, git cherry-pick, rebasing en het manipuleren van de historie met amend en revert
• Je kunt uitleggen hoe Git branching 'goedkoop' heeft gemaakt

Bronnen

• Singh, P. (January 17, 2020) Git - The Four Areas devsecopsgirl.in Geraadpleegd november 2024 op https://www.devsecopsgirl.in/devsecops/Git%20-%20four%20areas
• Git (z.d.) git-reset Documentation. git-scm.com. Geraadpleegd december 2024 op https://git-scm.com/docs/git-reset
• McKenzie, C. (23-8-2024) Git reset hard vs. soft: What's the difference? theserverside.com Geraadpleegd december 2024 op https://www.theserverside.com/blog/Coffee-Talk-Java-News-Stories-and-Opinions/Git-reset-hard-vs-soft-Whats-the-difference

Les 3 - Linux 1/2

Geen voorbereiding

Lesintroductie

We zijn verheugd om Rene Grijsbach als gastspreker te hebben, die de sessie zal leiden. Het beste nieuws? Er is geen voorbereiding nodig van jouw kant—gewoon meedoen en genieten van de leerervaring.

Om de presentatie te volgen, kun je de .pdf van de slides downloaden via de volgende link: NDG Linux Unhatched.pdf.

Lesnotities

Voor deze Linux les ga je aan de slag met de Cisco 'Linux unhatched' course. Deze is online beschikbaar op netacad.com, maar in 2024/2025 minor zal workshop docent een eigen variant 'on premise - private cloud' draaien.

The DevOps way is ook 'embracing the command line', zoals je bv. op de DevOps roadmap op roadmap.sh kunt zien (zie figuur 1). We volgen deze roadmap zeker NIET geheel in deze minor, maar wel paar hoofdpunten.

Deze roadmap geeft aan dat je als je een programmeertaal kent — zoals voor alle developers geldt — dat dan Operating System (OS) kennis en specifiek Linux kennis de volgende stap is. Dus ook kennis van het gebruik van de command line ('learn to live in the terminal') en bash scripting (wk 2). En daarna door met Git en versiebeheer (onderdeel van GitOps). Opvallend is dat 'creator of Linux' Linus Torvalds (Wikimedia, 2023) ook de auteur was van Git. Dus zijn naam moet je als DevOps professional zeker kennen!

In deze les is er ook al introductie van de Linux opdracht die je in week 2 af moet hebben. Tevens demonstreert de docent hoe je een VPS kunt gebruiken/krijgen in de private cloud. Alsmede de VPN client ['Tunnelblick](https://tunnelblick.net/) die je moet installeren op je laptop/pc om vandaar bij deze omgeving te komen (i.v.m. security). Deze VPS gebruik je ook de weekopdracht 3 van de DevOps course.

Op deze omgeving is wel beperkte support, dus als hiermee problemen zijn, vallen we terug op VPS'en aan te vragen bij HAN/AIM ICT ([martin.jacobs@han.nl](mailto:martin.jacobs@han.nl martin.jacobs@han.nl)) (documenteer en meldt wel de error).

Iets over de Linux kernel, verschillende distributies en de link met Docker

Figuur 1: DevOps roadmap (deels, rode pijlen toegevoegd; (roadmap.sh, 2023))

Figuur 2: Enkele Linux distributies (roadmap.sh, 2023))

Belangrijke achtergrondinformatie voor een Linux les is ook wel te weten dat 'Linux' eigenlijk niet bestaat. Bij Linux denken we vooral aan de Linux shell die je als eindgebruiker gebruikt, de command line. Maar feitelijk is de shell de 'user interface' van de Linux software zelf: het operating system. En dat 'operating system' is weer een abstractie van de hardware die in je computer zit, e.g. CPU, geheugen, harddisk en netwerk. Deze vormen samen de 'infrastructuur' van je laptop/desktop of wat dan ook (Linux draait op heel veel devices, ook PDA's, TomTom's en ook Android wat op veel mobiele telefoons draait is Linux-based).

Figuur 2 toont een boom met hierin enkele Linux distributies. Of eigenlijk is het een omgekeerde boom ;) (tree, een relevante/veelgebruikte datastructuur in de ICT). De basis van de boom is de Linux Kernel. Dit is de gedeelde functionaliteit die alle Linux distributies delen. Maar iemand die 'Linux draait' gebruikt altijd een specifieke distributie. Dit diagram gemaakt met behulp van ChatGPT, en geeft naast naam van een distributie . Dus garantie tot de deur, maar hier is de originele 'prompt' en bron.

De '2005' Alpine is in ieder geval wel gecheckt. Dit is opvallend genoeg een aantal jaar voor het ontstaan van Docker (geboorte bij dotCloud 2010, Docker launch in 2013). Deze Alpine distributie is vooral bekend uit de Docker wereld, maar 'predate' deze dus blijkbaar wel:

“The idea was that the system was installed in memory during boot from a read-only media and that you could remove the boot media once it was booted,” explained Natanael Copa, the creator of Alpine Linux, in an interview." - TheNewstack.io

Opdracht

• Maak een Cisco account, neem de stof door en oefen. Maak tot slot de oefenvragen. Bekijk de onderwerpen waar je evt. fouten had nog een keer beter. Maak vragen totdat je denkt dat je stof beheerst. Schrijf probleempunten op voor navragen bij de docent.

Opmerkingen

Gebruik hier de online command line die Cisco je biedt. Voor een wat 'echtere' ervaring en als je op Windows werkt is het ook handig om lokaal Linux te kunnen draaien (we gaan even uit van veelgebruikte Linux distributie Ubuntu (zelf weer afgeleid van Debian)).

Twee opties:

• Installeer Docker Desktop
  • Start daarmee (bv. Ubuntu) Linux via docker run -it ubuntu:latest (je kunt deze — na experimenteren — afsluiten met commando exit)
• Door het gebruik en installatie/activeren van WSL 2.
  • Dit is een heel stappenplan, maar huidige Docker Desktop versies werken hier ook goed mee samen, dus wel aan te raden

Opmerking: In DevOps lessen van week 2 ga je verder werken met Docker.

Quiz

Test je kennis over Linux met deze multiple choice quiz.

Hieronder een deel van de README.md van de tool featmap op GitHub, die terug komt in één van de vragen.

Building from source and running with docker-compose

Clone the repository

git clone https://github.com/amborle/featmap.git

Navigate to the repository.

cd featmap

Let's copy the configuration files

cp config/.env .
cp config/conf.json .

Now let's build it.

docker-compose build
Startup the services, the app should now be available on the port you defined in you configuration files (default 5000).

docker-compose up -d

Leerdoelen

• Je kent de basis Linux command line commandos uit de Cisco unhatched cursus/vragenset
• Je weet wat de Linux kernel en Linux 'distro's' zijn en kunt er enkele noemen
• Je kent de naam van de originele ontwikkelaar van Linux en weet wat voor een 'git' hij is ;)

Les 4 - Git workflows

Voorbereiding

Reminder: De voorbereiding is niet optioneel. Zonder voorbereiding wordt het lastig om mee te doen met de les en dat is een verspilling van zowel je eigen tijd, tijd van je mede studenten en tijd van de docent. Niet aardig.

Neem de 2 artikelen en diagrammen door:

1. Over GitHub flow
2. Over git flow.
3. Vragen over verschillen en eigen keuze:

• 3.1: Beschrijf eerst beide methoden in eigen woorden. Geef daarna een lijstje met verschillen tussen beiden.
• 3.2: Welk van deze methode ken jij al (een beetje)?
• 3.3: Voor welk van de twee zou je kiezen?
• 3.4: Welke van de twee methoden 1. Git flow of 2. GitHub flow zou jij kiezen in project A respectevelijk B:
  • Project A: Een command line tool die door medewerker van een 'WebShop' gebruikt wordt om een JSON bestellijst van die dag om te zetten naar 2 aparte lijsten voor order picken door medewerkers in hun 2 magazijnen 'Vloerbedekking en Laminaat' en 'Gordijnen en vitrages'
  • Project B: Een online video website met Agile ontwikkelmethode, waarin product owner onderkent dat deze de wensen van eindgebruikers niet geheel kent, en jullie experimenteren om nieuwe functionaliteit door eindgebruikers thuis te laten Beta testen?

Lesprogramma

• Doornemen lesvragen.
• Vraag: Waar heb jij 'branch by abstraction toegepast' in weekopdracht 1? (komen we verderop op terug)
• Samen doornemen van highlights uit video van David Farley over Continuous Integration vs Feature Branch Workflow dik kwartier (als genoeg tijd dan integraal samen kijken)
  • Schrijf tijdens het kijken highlights op en minstens 2 vragen.
  • Opdelen in duo's. Beantwoord elkaars vragen. Bespreek erna plenair (met docent) zaken waar je ook samen niet uitkwam.
• Kijken 'werkwijze bij weekopdrachten'
• Doornemen gemaakte weekopdrachten via enkele steekproefen, onderlinge feedback
  • Bespreken vragen/knelpunten/onduidelijkheden
  • Doornemen reflecties/self assessments
  • Bespreken CO-304 uit het CDMM - Deploy losgekoppeld van release
• Kijken naar "OA-202 - Branch by abstraction" en andere alternatieven voor Git branches (zie kopje hieronder)
• Toepassen Branch by abstraction op code om PrimeService/Priemtester werkend te krijgen voor alle getallen
• Als eerder klaar en opdracht 1 al veel af, doornemen en uitdelen opdracht week 2
• Vooruitblik volgende week en huiswerk les 2-1

Alternatieven voor git branches

Introductie term Branch by abstraction en andere alternatieven voor feature branching die beter bij Continuous Integration passen zoals feature toggles, of een dark release. Git heeft branching 'goedkoop' gemaakt t.o.v. andere versiebeheersystemen, maar branchen moet je zo kortdurend en minimaal mogelijk doen binnen DevOps. Geen 'long lived branches'.

Figuur 1: De branch uit branch by abstraction is GEEN 'Git branch', maar een conceptuele branch (bron: Fowler, 2014)

Er is ook zoiets als een 'Dark release' zoals Dave Farley het noemt (op 11:50 min in het filmpje). Martin Fowler defininieert deze term overigens net anders definieren en noemt wat Farley een 'Dark Launch' zelf meer een Keystone Interface (2020). Hij en anderen gebruiken 'Dark Release' als een synoniem voor een 'Canary Release' :S (split.io, z.d.). Een Canary release is een release die wel voo gebruikers beschikbaar is, maar voor slechts een deel daarvan, bijvoorbeeld Beta testers. Daar kijken we in week 4 verder naar, want bv. de Ingress uit KuberneteS maakt Canary releases makkelijker. Maar in dit vak hanteren we de terminologie van

Figuur 2: Keystone interface dankt zijn naam aan het concept 'keystone' een sluitsteen die een boog afmaakt.

Leerdoelen

1. Je weet dat veelvuldig en - vooral - langdurig gebruik van meerdere Git branches NIET past bij een aanpak volgens Continuous Integration en waarom
2. Je kunt drie alternatieven voor Git branches noemen en elke hiervan uitleggen
3. Je weet waarom je (Git) branching toepast en op welke manier dit wel acceptabel is
4. Je weet manieren 'to decouple release from deploy' (conform CDMM 'gevorderd' niveau)
5. Je weet wat 'trunk based development' is (Gemmail, 2018)

Bronnen

Dit zijn in deze les aangehaalde gebruikte bronnen.

• GitHub flow* Geraadpleegd september 2024 op https://guides.github.com/introduction/flow/
• Farley, D. ()
• Hendriks, V. (5-1-2010) update on 5-3-2020 A successful Git branching model. Geraadpleegd september 2024 op https://nvie.com/posts/a-successful-git-branching-model/
• Fowler, M. (7-1-2014). Branch by abstraction. Geraadpleegd 7 december 2023 op https://martinfowler.com/bliki/BranchByAbstraction.html
• Fowler, M. (29 April 2020). Keystone Interface. Geraadpleegd 7 december 2023 op https://martinfowler.com/bliki/KeystoneInterface.html
• Gemmail, R. (Apr 22, 2018) Trunk Based Development as a Cornerstone for Continuous Delivery Geraadpleegd op 5 september 2024 op https://www.infoq.com/news/2018/04/trunk-based-development/
• split.io (z.d.) Dark Launch Geraadpleegd op 5 september 2024 op https://www.split.io/glossary/dark-launch/

Week 2 - Containerization

Lesoverzicht

• Les 1 - Docker 101
• Les 2 - ORM en ADR
• Les 3 - Linux Bash (VPN/VPS)
• Les 4 - Weekopdracht bespreken & peer feedback (CDMM, aanwezigheid, reflectie)

Containerization Definition

Containerization is packaging software with the OS and other dependencies required to run the code to create a container that runs consistently on any infrastructure. IBM

Docker kwam in 2013 en maakte enkele krachtige maar obscure features uit Linux simpeler om te gebruiken. Met hun containers geven ze operations mensen de 'best of both worlds' van

• a) virtuele machines (isolatie en beheer via software) en
• b) de performance van OS processen direct op hardware ('metal).

Ze geven developers de mogelijkheid hun applicatie te containerizen met het OS en ook de hele tussenliggende stack van software (middleware zoals applicatie servers, webservers, message busen, en database servers en data caches e.d.). Zo werd het verschil tussen development omgeving en productie kleiner zodat je het 'works on my machine' probleem kan aanpakken.

*Figuur 1: Docker - Oplossing voor het 'works on my machine' probleem?

Week 2 Opdrachten

Opdracht 1: Linux Bash Script

In Les 3 maak je een Linux bash script volgens de user stories in de opdracht repo. Zet het script in een eigen private repo op GitHub en maak een issue aan voor de docent om na te kijken.

Opdracht 2: Docker Containerization

De Docker opdracht staat op (private) GitHub AIM organization. Je doet een laatste Git opdracht/puzzel en containerized daarna je vorige week gemaakte applicatie in een Docker container. Deze test je lokaal en zet dan zelf docker op externe VPS en runt hierop de container. Werk weer samen in een (nieuw) duo via git en GitHub en let naast opdracht ook weer op algemene werkwijze zoals taakverdeling vooraf en eindigen met (gezamenlijke) self assessment in je README met betrekken relevante CDMM checkpunten en een reflectie zoals de [werkwijze bij weekopdrachten]vraagt.

In deze opdracht komt ook refactoring terug, en heb je nog een kans 'branch by abstraction' toe te passen/te identificeren. Het voorbeeld met vertaling van pipeline diagram van vorige opdracht is voor sommige zo klein/triviaal dat ze het daar nog missen.

Wellicht helpt (code) op onderstaande foto nog bij 1e stappen opdracht:

Toelichting: Wellicht heb je een docent wel eens horen zeggen dat als je kunt programmeren het daarna niet uitmaakt of je nou een webapplicatie, of desktop applicatie of console applicatie of mobiele app of webservice maakt. Dat is wat kort door de bocht; maar zit wel kern van waarheid in. In .NET kun je al zulke applicaties maken, en je gaat de simpele code uit je classlib nu beschikbaar stellen voor zowel web project als een console project.

Hiervoor moet je naast op code niveau met import ... statements (dit is using in .NET) nu ook op project niveau instellen voor de projecten in je solution. .NET heeft module systeem (net als Java vanaf v 9). Dus kijk even terug naar dotnet cli commando's die je bij de 1e opdracht wellicht domweg hebt nagespeeld.

Leerdoelen deze week

Check met onderstaande leerdoelen of je de behandelde stof begrepen hebt en toetsvragen kunt beantwoorden.

• Je kent de 'Docker architectuur' (met concepten als images, containers, de docker engine en buildkit)
• Je kunt lokaal een container runnen
• Je kunt een eigen container maken
• Je kent de term ephemeral en het nut, en de 'oplossing' voor data persistentie in containers
• Je snapt het nut van een ORM en welke drie zaken je moet veranderen bij gewenste wijziging data schema
• Je snapt hoe Docker containers en images 'immutable' zijn en kunt termen als 'union file system' en 'copy on write' uitleggen
• Je begrijpt het begrip multi-stage container
• Je kunt een container optimaliseren en kent het concept van container layers
• Je kunt een container registry gebruiken en snapt het begrip
• Je kunt docker compose gebruiken en kent de relatie tussen Docker en docker compose
• Je kunt Docker installeren op een Linux VPS en deze gebruiken via een Docker context

Les 1 - Docker 101

Gastdocent: Jaap Papavoine

Een nieuwe technologie toe-eigenen hoort bij je werk. Je hebt ondertussen in de opleiding veel technologieën leren kennen, meestal met begeleiding van lesmateriaal en een docent. Tijdens je afstuderen en in je werk hierna zal je ongetwijfeld veel nieuwe technologieën gaan gebruiken die we je niet geleerd hebben, en op dat moment is er geen materiaal of docent beschikbaar. Om hier alvast mee te oefenen maken we in de lessen over Docker zo veel mogelijk gebruik van online bronnen.

Voorbereiding

Reminder: De voorbereiding is niet optioneel. Zonder voorbereiding wordt het lastig om mee te doen met de les en dat is een verspilling van zowel je eigen tijd, tijd van je mede studenten en tijd van de docent. Niet aardig.

Installeer Docker Desktop - Zorg dat je het commando 'docker container run hello-world' kunt uitvoeren.

In het Docker desktop learning center (in de UI van Docker Desktop) zitten een aantal walkthroughs. Doorloop de volgende walkthroughs:

- What is a container?
- How do I run a container?

De rest mag je gerust ook maken als je geïnspireerd bent!

Lees alvast 'Part 1: Overview' van de Get started guide op https://docs.docker.com/get-started/. We gaan in de les verder met deze getting started guide, en je kunt al zover door werken als je kunt.

Lees het eerste hoofdstuk (van 'Minor Devops: Lets do...' tot 'Fasering, project etc..') van het DevOps course materiaal (nog eens?) door, maar ga specifiek op zoek naar raakvlakken met containers. Welke requirements / uitdagingen / concepten / technieken genoemd in de DevOps minor hebben iets te maken met software containers? Maak een lijstje van alle raakvlakken die je hebt gevonden en neem dit lijstje mee naar de les.

Tijdens het maken van de voorbereiding kom je waarschijnlijk dingen tegen die je niet precies begrijpt. Logisch, je bent tenslotte een nieuwe technologie aan het leren. Schrijf de vragen die je hebt en de concepten die je niet kent op!

Loop je vast tijdens het voorbereiden, schrijf dan de volgende dingen op:

• Bij welke stap loop je vast?
• Wat heb je geprobeerd?
• Hebben je collega's hetzelfde probleem?
• Waar denk je zelf dat het misgaat?
• Heeft stackoverflow een oplossing voor je probleem?

Misschien is er tijd om voor de les je probleem te bekijken met de docent en/of medestudenten.

Lesprogramma / Lesmateriaal

Bestudeer de theorie die zowel in de lesdia's als in de Docker Workshop wordt gepresenteerd. Lees voor de Docker Workshop de README-bestanden zorgvuldig door, voltooi de oefeningen en experimenteer verder op eigen houtje.

• Lesdia's: Docker_In_A_Nutshell.pdf
• Docker Workshop

Les 2 - ORM (EF core)

In de workshop zijn kort 'volumes' behandeld in Docker, die nodig zijn voor persistent opslag. Althans als je data langer moet bestaan dat de container, wat op productie het geval is, als je een database gebruikt.

Neem de Docker documentatie []`Volumes'(https://docs.docker.com/engine/storage/volumes/) (negeer de oude constructie 'mounts' e.d. dit is alleen voor oudere containers die dit gebruikten).

Lees het artikel DevOps for databases van Christian Melendez. Als oefening kun je evt. de Contonso voorbeeld code downloaden, de dotnet ef tools installeren zoals het artikel aangeeft en de besproken oefening meedoen.

“Database refactorings […] involve three different changes that have to be done together

• Changing the database schema
• Migrating the data in the database
• Changing the database access code”

Quote 1: Bron: Martin Fowler, 2016, geraadpleegd 21-2-2022 op https://www.martinfowler.com/articles/evodb.html

Van de 3 wijzigingen uit quote 1 mist in simpele applicaties vaak het echte migreren van bestaande data. Dit vereist ook vaak het nadenken over hoe deze data te migreren en het handmatig schrijven/uitbreiden van de migratie code (de Up() en Down() methode in EF core.

Figuur 2: ORM oefening. Het in de les besproken mogelijke klassendiagram voor de database in weekopdracht.

ERM model

Dit ERD diagram geeft het gewenste datamodel van een CDMM Checkpoint.

Op deze manier is het mogelijk voor een student om zelf een self assessment te doen door het CDMM in te vullen voor een bepaalde beroepsproduct en -project.

User stories

• Als docent wil ik dat studenten een self assessment aan de hand van het Continuous Delivery Maturity Model (CDMM) kunnen maken en deze beargumenteren, zodat zij kunnen zien waar zij staan qua DevOps volwassenheid, en zich in DevOps best practices moeten verdiepen
• Als student wil ik makkelijk een CDMM beoordeling kunnen invullen en hierbij achtergrond informatie krijgen over de verschillende CDMM checkpoints zodat ik informatie over bijbehorende en een punt minder snel verkeerd interpreteer
• Als student wil ik iteratief een assessment willen invullen op verschillende data, zodat ik vooruitgang zie.
• Als student wil ik een ingevuld CDMM assessment kunnen exporteren, zodat ik deze , bv. als PDF kan inleveren als bewijslast voor school en als markdown/documentation as code op kan nemen als documentatie in mijn huiswerkopdrachten of beroepsproduct (DevOps BP)

Web applicatie server

In de weekopdracht van deze week moet je de vorige week gemaakte applicatie uitbreiden naar een WEB API en ook hosten met een webapplicatieserver. Een veelgebruikte is nginx (spreek uit: 'Engine X'). Hiervoor maak je ook kennis met ADR's: Architecture Decision Records.

"What are alternatives to nginx when you want a webapplication server for a .NET application that you also want to containerize?"

Dit is goede video om in de les samen te kijken ter relativering/van ORM's:

• Gormin, Christin (2011) Hibernate should be to programmers what cake mixes are to bakers: beneath their dignity. Vimeo. Ook nu even gecheckt op https://vimeo.com/28885655

Ook 'Continuous Delivery' Dave Farley haalt de video van Gormin aan in zijn boek 'Modern Software Engineering (tip!). Martin Fowler's artikel 'ORM hate' is een meer genuanceerde kijk op deze kwestie. Dat je geen SQL kennis zou hoeven te te hebben bij gebruik ORM is een drogreden, vanwege de ca. 10% gevallen die overblijft (en idd soms slechte performance). Hoewel de hoeveelheid SQL achtige annotaties in Gormin's wel wat hooggekozen is. Maar voor de resterende 10% moet je namelijk inzicht hebben in performance gevolgen. Voor SQL Server bv. van impact van bepaalde join volgorde en handmatige optimalisaties via keys toevoegen of verwijderen met hierachter technische concepten als 'table scan' vs 'index scan', etc. (zie bv. Anvesh 2023). En daarbij vergeleken is SQL syntax a walk in the park. Maar het 'single point of truth' of 'single point of definition' dat een goed ORM framework met ook 'migrations' mogelijkheden je kan geven. Al kom je als student niet snel in aanraking met een situatie waarbij je productie data hebt, die ook gemigreerd moet naast DB schema en applicatiecode, zoals Fowler in zijn artikel/blog 'Evolutionary database design' de big 3 aangeeft.

Leerdoelen

Check met onderstaande leerdoelen of je de behandelde stof begrepen hebt en toetsvragen kunt beantwoorden.

• Je kent de relatie van BDD met TDD, DDD en Agile/DevOps
  • met o.a. relevante begrippen als Ubiquitous Language, test-first, red-green-refactor, AAA pattern, given-when-then en collaborative development
• Je kent de BDD three amigo's, en de 3 stappen van het iteratieve BDD proces
• Je kent 2 andere namen van BDD, en kunt deze uitleggen
• Je kent de term 'self testing code' en het onderscheid tussen .feature files, glue code en applicatie code en de talen/standaarden die hier achterin zitten
• Je kunt de verhouding uitleggen tussen BDD test scenario's, test cases en suites met user stories en acceptatiecriteria uit Scrum
• Je kent de test pyramide, het belang van de verschillende soorten testen hierin en de link met BDD
• Je kunt op basis van een tutorial een project met werkende en relevante BDD tests opstellen m.b.v. Cucumber of Specflow

Bronnen

• Anvesh (1-8-2023). Table Scan vs Index Scan vs Index Seek. medium.com Geraadpleegd 18-4-2024 op https://medium.com/silenttech/table-scan-vs-index-scan-vs-index-seek-f5cbb4e93478
• https://martinfowler.com/bliki/OrmHate.html
• https://martinfowler.com/articles/evodb.html

Les 3 - Linux 2/2

Lesintroductie

We willen Rene Grijsbach opnieuw hartelijk bedanken voor het verzorgen van deze sessie. We zijn blij dat hij weer met ons is om zijn kennis te delen.

Voor deze nieuwe les kun je de .pdf van de presentatie en uitwerkingen van de lesopdrachten hier: Presentatie SSH & BASH (inclusief voorbeeld uitwerkingen)

Lesnotities

Zorg dat je de Cisco 'Linux Unhatched' course van vorige week af hebt en alle testvragen voldoende kunt beantwoorden.

Week Opdracht

• Schrijf een Linux bash script volgens de user stories (=spec) in deze opdracht repo op github
• Zet het bash script in een eigen prive repo op GitHub
• Maak een issue aan in GitHub voor de docent om hem na te kijken en assign dit issue aan de docent
• Je mag je eigen bronnen gebruiken om te leren scripten. Er zijn bijvoorbeeld de 3 volgende opties:
  • een PluralSight course over Bash scripting binnen PluralSight's free library
  • een module over bash scripting binnen de gratis Cisco course 'NDG Linux Essentials'
  • of een YouTube video hierover

Figuur 1: Only legends will get this? :P Bron: TwisterByte23@Reddit, 2023

"I'm not sure what the matt-daemon project does yet, but I'm pretty excited about the name." - Justin Searls (2012)

Week 3 - Continuous Delivery

Lesoverzicht

• Les 1 - InfoSupport Workshop DDD & Microservices (hele dag!)
• Les 2 - C4 & Continuous Documentation
• Les 3 - Micro-frontends
• Les 4 - DevOps vs Continuous Delivery + Deeltoets 1 (1 uur) + Weekopdracht bespreken & peer feedback (2 uur)

Deze week is het thema Continuous Delivery. We gaan even terug naar het begin: de business waarde en cultuur achter DevOps. Want Continuous Delivery maak je mogelijk door een 'DevOps aanpak' te hanteren.

"Continuous Delivery is the ability to get changes of all types—including new features, configuration changes, bug fixes and experiments—into production, or into the hands of users, safely and quickly in a sustainable way."" Jez Humble, continuousdelivery.com

Lees deze week de reader DevOps H10: 'Code Management' (NB: vragen in theorietoets!)

Week Opdracht week 3

Deze week gaan we de in vorige opdrachten opgezette applicatie geautomatiseerd builden, testen en opleveren door het opzetten van een pipeline zoals je al in de 1e opdracht al tekenden.

Minimaal build je een container, maar optioneel kun je deze ook live zetten en evt. nog extra lint stappen toevoegen. Blijf ook op security letten. Tevens beantwoord je een theorievraag rondom 12factor app methodology. De docent licht dit kort toe tijdens een les, maar dit is verder zelfstudie.

Nuttige bronnen:

• GitLab: Mastering continuous software development
• Installeren Jenkins lokaal in Docker container
• GitHub Actions
• Mr 'Continuous Delivery' Jez Humble over 'WaterScrumFall en hoe DevOps in verlengde van Agile ligt
• Martin Fowler: ObservedRequirement
• 12factor app principles for SAAS applications ('web applications')
• Wikipedia: Software rot of Software erosion zoals Heroku het noemde en 12factor introduceerde

Les 3-1 - Workshops Microservices & DDD

Link naar sheets (private repo; met de slides en oefeningen).

InfoSupport: Microservices & DDD - Strategic Patterns

Er is geen verplichte voorbereiding voor de workshop in les 1.

Lesprogramma / Lesmateriaal

OCHTEND

• Microservices - Zie Microservices.pdf
• Oefening Microservices van UserStories hier downloaden microservices-oefening.docx
• Domain Driven Design inleiding - Zie H02 - DDD Strategic Patterns.pdf

MIDDAG

• Oefening Domain Driven Design hier downloaden Exercises in Domain-Driven Design.docx.

Leerdoelen

Check met onderstaande leerdoelen of je de behandelde stof begrepen hebt en toetsvragen kunt beantwoorden.

• Je kent de betekenis van de volgende termen in relatie tot Microservices: Cohesion/Coupling, Polyglot Microservices, Scalability
• Je kent de betekenis van de volgende Microservices-principes: Culture of automation, Modelled around business domain (DDD), Highly observable, Isolate failure (Design for Failure), Decentralize all things (freedom for the devops Teams)

C4 & Continuous Documentation

Deze les gaat over een van de 'Continuous Everything' zaken, namelijk Continuous Documentation. We kijken naar het C4 model van Simon Brown: Documentation for developers by developers! Daarna wat highlights van werk van HAN docent-onderzoeker Theo Theunissen rondom documentation in Continuous Software Development. Daarna naar Architecture Decision Records.

Maar eerst doen we een korte recap en aanvulling op InfoSupport's workshop over Domain Driven Design.

1. DDD + Microservices recap

Korte terugblik workshops over DDD respectievelijk microservices.

Samen bespreken DDD's strategic vs. tactical patterns, en korte recap van de 3 hoofd strategic patterns:. Na de bespreking snap je deze termen hopelijk en kun je dit uitleggen. Anders geeft de website infiniot deze korte definitie, en moet je een bron vinden die het uitgebreider uitleggen:

• *Ubiquitous Language – Een taal gestructureerd rond het domeinmodel en gebruikt door alle teamleden om alle activiteiten van het team met de software te verbinden.
• Bounded Context – Een beschrijving van de grens waarbinnen een bepaald model wordt gedefinieerd.
• Context mapping - Hoef je in deze cursus hoef je deze niet te kennen.

Deze laatste hangt wel vrij direct samenahngt met de andere twee, zoals een student al aangaf. En in de PitStop casus uit eindopdracht course fase zit een mooi voorbeeld van een Context Map waar je mee te maken krijgt.

Figuur 1: Ubiquitous betekenis (bron: Google translate)

Wellicht ken je al 'onion' of 'Ports and Adapters' architectuur. Hierbinnen zitten ook DDD tactical patterns als 'Repository' en 'Services' (met onderscheid tussen Application Services (technische glue) en Domain Services (business logica).

Figuur 2: DDD Tactical patterns: Onion architecture with 'lower level' DDD pattern (bron: Jordan Jordanov, J., Petrov P, 2023)

We zoomen in op de andere DDD tactical patterns:

Figuur 3: DDD Tactical patterns: Aggregate met Aggregate root en Entity vs Value object (bron: .NET Microservices Architecture for Containerized .NET Applications Figure 7-9. p. 203

Dit zijn meer 'implementatie in OO' gerichte patterns: Entity, Value Object en Aggregate. Een Aggregate geeft een idee van de minimale 'grootte' van een microservices definieren/beschrijven, Zoals je bv. leest in een online artikel van Microsoft Learn of Dave Taubler op Medium (edit 2024: helaas inmiddels achter paywal/abonnement):

"As a general principle, a microservice should be no smaller than an aggregate, and no larger than a bounded context. First, we’ll review the tactical patterns.” - Microsoft Learn (z.d.)

"... we [..] designed our microservices around Aggregates" - Dave Taubler (2020)

2. Continuous Documentation

Relevante vragen:

• Wat houdt 'Continuous Documentation' in?
• Wat is de relatie met 'Continuous Delivery' (en andere uit 'Continuous Everything'?)
• Kun je een praktijk voorbeeld van Continuous Documentation geven?
• Welke manieren van documenteren van Software ken je? (deliverables, methodes)
• Open vraag: Welke documentatie gebruik je binnen 'Ops werk'?

De 3 fasen van software documentatie volgens Theunissen (2021) (klik via 'Publicaties' onder https://theotheunissen.nl.

Lesopdracht: Maak een opsomming van veel vormen van documentatie die je als ICT'er in je opleiding/werkervaring bent tegengekomen. Verdeel deze daarna onder over de 3 fases;

1. Upfront: Acquiring knowledge
2. Development: Building knowledge
3. Delivery: Transferring knowledge

Zijn er ook types die in meerdere fases horen?

3. Het C4 model

De sheets van deze workshop.

Figuur 1: © Simon Brown, c4model.com

4. ADR's

Software Architectuur is het deel van de (software) design dat moeilijk te veranderen is. Je ontwerp leg je op verschillende niveaus vast met C4 en UML diagrammen en goede toelichtingen hierbij. Om verdere 'onderweg gemaakte' keuzes vast te leggen gebruiken we in deze minor Architecture Decision Records (ADR). ADR's zijn een heel belangrijk iets voor Software Architecten, maar ook Software Developers zoals beargumenteert in dit IEEE explore blog (2022)):

"ADRs’ greatest strength is their low barrier to entry. Since anyone on the team can write an ADR, everyone who wants can fill the role of software architect." - Michael Keeling (2022)

Hoe je deze keuzes vastlegt (documenteert) is weer een keuze op zich. Maar sowieso is het idee 'lichtgewicht' en direct bij de code in een tekst format, typisch markdown. Want de doelgroep is toch: mede developers/architects, kortom ICT'ers (en niet domein/business stakeholders, daar zijn andere docmenten voor). Hierbij is het handig een template te gebruiken. Om de keuze stress op dit niveau wat te beperken, en zo te kunnen focussen op concretere en relevantere keuzes in techniek en domein modelleren beperken we in deze minor de opties hiervoor tot twee:

1. Wellicht wel de best optie is een heel korte en krachtige variant van ADR's genaamd y-statements (DocSoc, 2020). Dit is feitelijk een enkele zin, maar hierin zit ook al een stuk 'alternatives':

2. Of je gebruikt het template van Nygard, één van de grondleggers, volgens een artikel van Michael Keeling (2022). Omdat een ‘decision’ (=beslissing) ook opties impliceert (anders kies je nergens tussen) nemen we hierin ook alternatieven op. In het template van Nygard zit geen apart kopje, maar zouden alternatieven dan onder kopje 'Decisions' moeten. Of je plaatst ze al direct in de Context' (zoals Nygard zelf deed in het artikel waarin hij ADR's introduceerde (Nygard, 2011). Maar in het kader van het 'single responsibility' principe voeg je ten opzichte van Nygard's template een extra kopje toe: `Alternatieven'. IN het kader van ['The pyramid principle'] (Minto, 2002) plaats je deze sectie ACHTER de 'Decision'

Binnen DevOps mag je echter afwijken van rigide standaarden, als er een goede reden is, het gaat immers om "Individuals and interactions over processes and tools" (Agile Manifesto, Fowler et al., 2001). DevOps over ligt immers in het verlengde van Agile (embrace change).

Dit is een heel stuk korter dan de volledige ADR in Nygard (Henderson, 2023) met kopjes:

• Status: What is the status, such as proposed, accepted, rejected, deprecated, superseded, etc.?
• Context: What is the issue that we're seeing that is motivating this decision or change?
• Decision: What is the change that we're proposing and/or doing?
• Consequences: What becomes easier or more difficult to do because of this change?

Zie voor een voorbeeld voor de PriemChecker casus de docs/ADR folder in de (PriemChecker repo) voorbeeld van standaard straks in het project.

"In the context of storing large prime candidates in our SQL database using Entity Framework Core, facing the need to accurately store numbers larger than the built-in SQL data types can handle, we decided for using a Value Converter to convert BigInteger to a string format for storage, and against using decimal or bigint storage formats, to achieve compatibility with extremely large numbers while maintaining database flexibility, accepting that this introduces performance overhead from conversion and adds complexity in the application logic."

Hieronder nog iets over de folderstructuur in dit project.

Folder structuur en toepassen Pyramid principle in documentatie

Qua folder structuur zet je de ADR's in folder /docs/adr en zet in zowel docs/ als docs/adr ook een README.md als 'landingspagina. De README.md onder adr geeft deze inleiding/leeswijzer en linkt naar alle ADR’s. Dit is ook de DoD (Definition of Done) voor ADR’s, namelijk het Nygard template format dat jullie hanteren (Henderson, z.d.) of Y-statements (Olzzio, 2023)

Ook kun je verbanden leggen tussen verschillende ADR's. Als je bv. in het begin van je project kiest voor dataopslag met SQL Server, en dit vastlegt in een ADR, en gaande het project, bv. vanwege geheugengebruik issues van SQL switcht naar meer light weight database als PostgreSQL kun je deze aan elkaar koppelen. Of juist naar MongoDB vanwege partitioning eisen, of wat dan ook. Ook heb je keuze om hierbij twee technologie specifieke ADR's te maken (e.g. ADR-SqlServer.md en ADR-PostgreSQL.md) of een enkele ADR, met een meer functionele/semantische naam Data-Persistence.md die je aanpast. In de paragraaf hieronder een voorbeeld van een te gebruiken tekst. Zoals hier aangeven gebruik het 'standaard format van Nygard, maar vul deze aan met 'Alternatives'. Of - als je het graag zo kort mogelijk houdt - kijk eens naar 'y-statements' van Olzzio (2023).

Quiz

Test je kennis over continuous documentation en C4 met deze korte multiple choice quiz.

Leerdoelen

Check met onderstaande leerdoelen of je de behandelde stof begrepen hebt en toetsvragen kunt beantwoorden.

• Je kunt uitleggen wat Continuous Documentation is en hoe het zich verhoudt tot Continuous Delivery.
• Je kent praktijkvoorbeelden van Continuous Documentation en kunt verschillende manieren van documenteren van software beschrijven.
• Je kunt het C4 model uitleggen en beschrijven hoe het helpt bij het documenteren van softwarearchitectuur binnen DevOps teams.
• Je kent twee manieren van architectuur beslissingen vastleggen met ADR's die je in het DevOps project gaat gebruiken
• Je kent de belangrijkste strategic DDD patterns zoals Ubiquitous Language, Bounded Context, en Context Mapping, en kunt het onderscheid uitleggen tussen strategic en tactical patterns.
• Je kunt voorbeelden geven van tactical DDD patterns zoals Entity, Value Object, en Aggregate, en weet dat aggregates een indicatie geven van minimale grootte van microservices.

Bronnen

Hier (nogmaals) de bronnen gebruikt op deze pagina in APA format.

• Brown, S. (z.d.). C4 model. Geraadpleegd op 23 september 2024 op https://c4model.com/
• Doc Soc (7-5-2020) Y-Statements - A light template for architectural decision capturing. Medium.com. Geraadpleegd september 2024 op https://medium.com/olzzio/y-statements-10eb07b5a177
• Google. (z.d.). Ubiquitous language betekenis via Google Translate. Geraadpleegd op 23 september 2024 op https://translate.google.com/?hl=nl&sl=en&tl=nl&text=ubiquitous&op=translate
• Jordanov, J., & Petrov, P. (2023). Domain Driven Design Approaches in Cloud Native Service Architecture. Geraadpleegd op 23 september 2024 op https://www.researchgate.net/publication/375982003_Domain_Driven_Design_Approaches_in_Cloud_Native_Service_Architecture/
• Keeling, M, (20 June 2022). Love Unrequited: The Story of Architecture, Agile, and How Architecture Decision Records Brought Them Together IEEE. Geraadpleegd dec 2023 op https://ieeexplore.ieee.org/document/9801811
• Microsoft. (z.d.). Implementing Value Objects with DDD. Geraadpleegd op 23 september 2024 op https://learn.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/implement-value-objects
• Theunissen, T. (2021). Csimq: Continuous Software Development Documentation Artifacts. Geraadpleegd op 23 september 2024 op https://theotheunissen.nl/wp-content/uploads/2022/09/csimq.pdf
• Parker Henderson, J. Decision record template by Michael Nygard. Github.com geraadpleegd september 2024 op https://github.com/joelparkerhenderson/architecture-decision-record/blob/main/locales/en/templates/decision-record-template-by-michael-nygard/index.md
• Using tactical DDD to design microservices Microsoft Learn. Geraadpleegd september 2024 op https://learn.microsoft.com/en-us/azure/architecture/microservices/model/tactical-ddd
• de la Torre, C (2023) .NET Microservices Architecture for Containerized .NET Applications v7.0. Microsoft Coorporation. Geraadpleegd september 2023 op https://github.com/dotnet-architecture/eBooks/blob/main/current/microservices/NET-Microservices-Architecture-for-Containerized-NET-Applications.pdf
• Minto, B. (2002) The pyramid principle : logic in writing and thinking 3rd edition, Financial Times Prentice Hall

Workshop Micro Frontends

Voorbereiding

• Lees uit het artikel Micro-Frontends op martinfowler.com (Jackson, 2019) de hoofdstukken:

  • Benefits
  • The Example
  • Integration Approaches

• Verzin 2 toetsvragen over het onderwerp van Micro-Frontends

  • Zet je 2 vragen in de thread hierover op het MS Teams Team van je klas/de minor
  • (Als deze er nog niet is, vraag je docent dan, of start deze thread zelf)
  • Formuleer bij voorkeur een multiple choice vraag met 4 antwoord opties waarvan 1 goed is (en 2 anderen plausibel zin)
  • Verzin een unieke vraag (e.g. hoe sneller je er een post, hoe makkelijker)
  • De beste vragen kunnen daadwerkelijk in de toets komen

Figuur 1: De microfront-end architectuur volgt vaak component structuur op het scherm/ontwerp (Jackson, 2019)

Lesprogramma

• Bespreken toetsvragen
• Mentimeter
• In teams uit elkaar
• Build your own MF met create-mf-app
• Plenair samenkomen: benefits & integration approaches

Figuur: Microservices everywhere (bron: Aditya,m 2022))

In teams uit elkaar

• 5 teams. Elk team krijgt één 'integration approach' om te gebruiken en een 'benefit' toegewezen om kort uit te leggen.

  1. Onderzoek hoe deze integration approach in zijn werk gaat.
  2. Onderzoek voor- en nadelen.
  3. Maak of vindt een kleine demo van approach
  4. Vat de toegewezen 'mf benefit' samen
  5. Presenteer je resultaten aan de rest van de klas
  6. Einddiscussie: Zou je MF's gebruiken in project, of niet. Wat is het alternatief? Als MF moet; welke integration approach zou jij het eerst kiezen voor front-end in het project?

Integratie methoden:

• Server-side template composition
• Build-time integration
• iframes
• JavaScript
• Web Components

Voordelen:

• Incremental upgrades
• Simple, decoupled codebases
• Independent deployment
• Autonomous teams
• De 5e: Bonus, niet echt voordeel, maar leg de 'Two Pizza rule of Amazon uit' + hoe dit pizza plaatje aansluit bij onderwerp microfront-ends?

Create-mf-app

Ga nu in tweetallen aan de hand van het artikel van logrocket (Patel, 2024) zelf aan de slag met het maken van een MF-app.

• Maak een simpele applicatie waarin 2 micro-frontends met elkaar moeten communiceren of in ieder geval van de resultaten van een actie gebruik moeten maken. Bijvoorbeeld:
  • Zoekbalk, Artikellijst
  • Boodschappenmand, Productenoverzicht
• Spreek met je teamgenoot af hoe je tussen de 2 micro-frontends gaat communiceren. Denk na over opties als:
  • pub-sub
  • externe service
  • browser internals
  • store/state-manager die beiden applicaties toegang tot hebben (e.g. redux, mobx, vuex, rxjs)

Quiz

Test je kennis over micro front-ends met deze multiple choice quiz:

Leerdoelen

Check met onderstaande leerdoelen of je de behandelde stof begrepen hebt en toetsvragen kunt beantwoorden.

• Je kunt gegeven een opdracht aangeven of een microfrontend een goede keuze is.
• Je kent het concept module federation, en kent twee andere manieren om micro-frontends met elkaar te integreren
• Je weet wat een micro-frontend is wat enkele voordelen ('benefits') hiervan zijn en kent de relatie met microservices.

Continuous Delivery vs DevOps

Huiswerk

1. Bekijk het interview met Gene Kim over 'zijn' 3 ways of DevOps
2. Bekijk het animatiefilmpje van Rackspace over 'What is DevOps'
3. Beantwoord voor jezelf onderstaande vragen over deze bronnen (zet deze in een markdown bestand `<les-cd-antwoorden-mijn-naam.md> in je weekopdracht)
4. Lees deze week de reader DevOps H10: 'Code Management' ((Sommerville, 2018) students only acces in GitHub; NB: vragen in theorietoets!)

1 Vragen bij Reader DevOps

• Wat zijn de 3 hoofdpunten belangrijkste principes* van DevOps uit Sommerville's hoofdstuk over `DevOps and Code Management'? (p. 307)
• Hoe verhouden deze 3 punten zich tot de punten uit de twee filmpjes over DevOps van Gene Kim en RackSpace? Schrijf wat je opvalt, wat verschilt en overeenkomt.

2. Vragen bij interview Gene Kim

Beantwoord de volgende vragen:

1. Wat bedoelt Kim precies met zijn 'peeing puppy' analogie? Schrijf een korte paragraaf hierover.
2. Hoe moeten jullie straks tijdens het tweeweekse project dat de DevOps course afsluit om gaan met deze 'peeing puppy'? (E.g. wanneer moet deze 'zindelijk' zijn?)
3. Kun je beter beschrijvende namen vinden verzinnen voor de three ways dan Kim's cryptische 'First way', 'Second way' en 'Third way'? Geef deze! #namingThings

3. Vragen bij animatie filmpje DevOps

Beantwoord onderstaande vragen bij het filmpje. Dit is een check of je gekeken hebt, maar ook voor activering van je voorkennis en duidelijk krijgen verschil in voorkennis en mening tussen jou en collega studenten.

NB: Het is niet erg als je voorkennis niet hebt, beantwoord wel sowieso de vragen die het filmpje zelf geeft en de mening vragen. Je hoeft niet te gaan googlen o.i.d voor de overige, tenzij een vraag dit expliciet vermeldt.

1. Welke 2 typische deploy omgevingen ('environments') worden genoemd in het filmpje? Welke hoort bij Anna en welke bij Dave?
2. Ken jij nog meer omgevingen dan deze twee? Hoe noem je deze als ICT'er? Welke hiervan zal of moet elke ICT organisatie in ieder geval hebben?
3. Vergelijk deze extra 'tussenliggende' omgevingen met de 2 van vraag 1. Stel dat de software een typische 3-tier webapplicatie is, e.g. website met wat business logica en een database voor persistentie. Welk van deze onderdelen verschilt van de andere? Hoe. En waarom? Geeft dit nog security risico's.
4. Welke 3 problemen veroorzaakt de delay die Dave ervaart? Geef voor elk probleem aan of dit een probleem is voor Dave, Anna en/of het hele bedrijf.
5. Wat levert Dave eigenlijk precies op aan Anna? Is dit code of software? Wat is eigenlijk het verschil hier tussen?
6. Uit welke 2 componenten bestaat DevOps volgens het filmpje? (Niet 'Dev' en 'Ops'; kijk het filmpje!)
7. Welke van deze twee denk je dat belangrijker is? Waarmee moet je beginnen? Welke van de twee is het makkelijkst te adopteren?
8. Welk van deze twee besteden we de meeste tijd aan in de minor denk je? (En welke zouden we het meeste tijd aan moeten besteden vind je?)
9. Welke 3e item/onderdeel blijft impliciet? Kun je nog een 3e onderdeel verzinnen bij DevOps?
10. Met welke 3 soorten taken zorgt DevOps voor betere samenwerking en productiviteit?
11. Een van deze 3 taken (taaksoorten) heeft met workflows te maken. Wat bedoelt de verteller met workflows?
12. Iets verderop geeft het filmpje nog een lijstje van 3. Nu zijn het alle 3 'automatiseer' taken. Welk item is hier verschillend met het vorige lijstje van 3?
13. Stel je houdt met DevOps bijvoorbeeld een grote e-shop in de lucht (zoals je zelf zult doen in het beroepsproduct aan het eind van deze course). Dan kun je de zogenoemde 'conversie ratio' bepalen (conversion rate). Leg uit wat dit is, zoek eventueel op.
14. Wat heeft 'conversie' ratio met je antwoord op vraag 12 te maken?
15. Welk soort code schrijf je in de DevOps role meer dan in een Dev rol?

Les overzicht

• Bespreken stelling
• Behandelen huiswerkvragen
• Bespreken problemen bij weekopdracht 3
• Pauze
• 12Factor app principles (of 15 factor..): Duo ~~presentaties`` pitches (belangrijk voor de toets)
• Video 'The Difference Between DevOps and Continuous Delivery' (13 min) kijken en nabespreken (Farley, 2021)
• Checken leerdoelen

Als er onvoldoende tijd is voor video dan thuis zelf kijken en nu korte samenvatting door docent).

Les inhoud

Stelling:

"Requirements are the things that you should discover before starting to build your product." - Bron...?

12factor app principles

Opsplitsen in duo's en verdelen 12Factor principles.

Elk duo leest beide leden de introductie op de 12factor.net website. Het beantwoorden van onderstaande vragen onderling bespreken helpt je bij het geven van een presentie.

• Waarvoor zijn de 12factor principles? Gebruik in je antwoord de term 'software erosion' en leg uit wat dit is
• Wat is het verschil tussen SaaS, PaaS en IaaS, en welke is relevant voor 12factor principle en waarom?
• Geef een voorbeeld op waarin het principe van toepassing was uit je eigen ervaring als ontwikkelaar of operations werkzaamheden, of verzin er eentje, evt. met hulp van google of ChatGPT.

Leerdoelen Continuous Delivery

Check met onderstaande leerdoelen of je de behandelde stof begrepen hebt en toetsvragen kunt beantwoorden.

• Je kunt iets vertellen over 'Continuous Delivery' en de relatie met DevOps
• Je kent het belang van DevOps cultuur en mindset
• Je kent de 'three ways' van DevOps
• Je kent het Agile manifesto en enkele principes ervan en kunt uitleggen hoe DevOps in het verlengde daarvan ligt
• Je kunt verschillende stadia en vormen noemen hoe DevOps in een bedrijf is doorgevoerd
• Je kent de centrale rol van de CI/CD pipeline binnen DevOps en de aansluiting op versiebeheer
• Je snapt het principe van refactoren en de term technical debt
• Je kunt een (scripted) pipeline inrichten in GitHub Actions (of evt, andere gewenste doel pipeline technologie zoals Jenkins 2, Jenkins X of Gitlab.com)
• Je kent de 12factor app methodology en kunt toetsen of je software conform een bepaalde factor is

Bronnen

• Farley, D., Continuous Delivery (24-3-2021) The Difference Between DevOps and Continuous Delivery youtube.com Geraadpleegd november 2024 op https://www.youtube.com/watch?v=-sErBqZgKGs
• Fowler, M. (16-9-2008) Observed Requirement martinfowler.com Geraadpleegd november 2024 op https://martinfowler.com/bliki/ObservedRequirement.html
• Kim, G. Hiller, P (6-6-2020) DevOps Gene Kim Defines the 3 Ways of The Phoenix Project Jack Caine op youtube.com, geraadpleegd oktober 2024
• Rackspace Technology (12-12-2013) What is DevOps? - In Simple English YouTube.com, Geraadpleegd oktober 2024 op https://www.youtube.com/watch?v=_I94-tJlovg
• Sommerville, I. (2018) Engineering Software Products H10 Code management
• Wiggins, A. (2017) The Twelve-Factor App. 12factor.net. Geraadpleegd november 2024 op https://12factor.net

Toetsen 1 & nabespreking

In deze les krijg je de eerste 2 toetsen. Hierna volgt een klassikale nabespreking. Individuele toetsinzage is op een later moment. Ook kijken we vooruit naar weekopdracht 3 en vind je vast een partner voor de opdracht (andere dan opdracht 2, terugwisselen mag, of nog keer afwisseling :).

• 9:00 Lokaal open, intro en regels
• 9:30 TheorieToets Dev
• 10:00 Pauze
• 10:15 Theorietoets DevOps
• 10:45 Pauze & Docent nakijken
• 11:30 Ruimte voor vragen en centrale nabespreking
• ..... Verdeling weekopdracht 3, vragen opdracht 2

Oefendeeltoetsen 1

Hier linkjes naar de oefentoetsen om beter beeld te krijgen van de echte toets op deze dag.

• Oefendeeltoets Dev 1
  • Linux vragen uit gedane Cisco course van week 1 en 2 (zelfstudie)
• Oefendeeltoets DevOps 1
  • Stof uit DevOps lessen week 1 en week 2:
    • Algemene vragen DevOps: Culture, t-shaped professional, CDMM, Microservices architecture
    • GitOps: Git commands & Git workflows, CI vs feature branch
    • Containerization: Docker, containers, images, volumes, ORM/Evolutionary Database Design

Nabespreking/vooruitblik week 3

• Reminder InfoSupport etentje 25 sept (aanmelden Slack!)
• Toets bespreken
• Maken duo's voor de week opdracht 3
• Verdeling 'platform' voor opdracht Continuous Delivery over duo's (GitHub Action/GitLab CI)
• Verdelen onderdeel 'stellingen 12factor' theorie-/deelopdracht (evt. bespreken in les)

Week 4 - Orchestration

Lesoverzicht

• Les 1 (hele dag!) - Workshops Microservices & DDD
• Les 2 RabbitMQ
• Les 3 - Weekopdracht 3 + BDD
• Les 4 - Weekopdracht bespreken & peer feedback (CDMM, aanwezigheid, reflectie)

NB: De Kubernetes 101 les en praktische deel hierachter is in 2024 naar week 5 verplaatst.

"The portability and reproducibility of a containerized process [...] lets us move and scale containerized applications across clouds and datacenters.

We need tooling [...] to help automate maintenance, replacement and rollout of updates of the containers during their lifecycle!"

Docker docs - september 2021

Week 4 Opdracht

De week 4 opdracht in 2024/2025 is de opdracht rondom RabbitMQ. Toepassen van Kubernetes theorie in praktijk zit in week opdracht 5, samen met monitoring/prometheus.

Verder wordt de weekopdracht opengezet, moet iedereen weer een duo partner hebben (en bij oneven aantal één drietal).

Over de gevormde teams verdelen we de 3 te gebruiken techniek om van de in vorige opdracht gebruikte Docker compose naar Kubernetes te gaan:

• Docker Stack vervallen
• Kompose
• Skaffold

Leerdoelen

Check met onderstaande leerdoelen of je de behandelde stof begrepen hebt en toetsvragen kunt beantwoorden.

• DevOps-3 Je kunt werken met containers, gangbare software architecuren vertalen naar een container architectuur en de principes van container orchestration toepassen (Containerization)

• DevOps-2-3 Kan applicatie onderdelen 'containerizen' en onderling laten communiceren

• DevOps 2-4 Kent de rol van netwerken bij containers, en principes van een load balancer, firewall en proxy en relavante protocollen/standaarden

• MDO-DevOps-3 - Containerization/Orchestration "Je kunt werken met containers, gangbare software architecuren vertalen naar een container architectuur en de principes van container orchestration toepassen (containerization)"

• En de DDD en microservices leerdoelen n.a.v. Workshop InfoSupport. "Kent de basisprincipes van Domain Driven Design en kan deze toepassen en toetsen in DevOps code, configuratie en documentatie"

Workshop Event Driven Architectures (EDA)

Link naar sheets (Dag2Les.pptx) (private repo; met de slides en oefeningen)

Lesvoorbereiding

Als je stap 3 van het bestand “Exercises in Domain Driven Design” niet hebt voltooid, doe dan het volgende:

• Voltooi het domeinmodel voor de bounded contexts die essentieel zijn voor de gameplay.
• Zet de klassen van het domeinmodel om in code met je voorkeursprogrammeertaal. Focus op het maken van klassen en hun attributen, niet op het implementeren van spelregels.

Lesprogramma / Lesmateriaal

• Web Scale Architecture - Zie web-scale-patterns.pdf
• Chess Game DDD - Zie Git Repo

Leerdoelen

• Moet de student vier vormen van event-driven architecturen (Event Notification, Event-carried State Transfer, Event Sourcing, en CQRS) kunnen uitleggen en de verschillen ertussen benoemen. Daarnaast moet de student in staat zijn om de voor- en nadelen van elke vorm te onthouden en uitleggen.
• Aan het einde van de les moet de student het CAP-theorem kunnen uitleggen en de drie pijlers (Consistency, Availability en Partition Tolerance) beschrijven. De student moet kunnen toelichten waarom een gedistribueerd systeem maximaal twee van deze eigenschappen kan waarborgen.
• Aan het einde van de les moet de student het principe Design for Failure kunnen uitleggen, inclusief het belang van foutdomeinen (Bulkhead pattern). De student moet de 8 fallacies of distributed computing in algemene termen kunnen benoemen en begrijpen hoe deze valkuilen kunnen worden vermeden. Daarnaast moet de student het belang van het Circuit-breaker pattern voor snel falen in gedistribueerde systemen kunnen uitleggen.

Workshop RabbitMQ + BDD

De RabbitMQ workshop wordt aangeboden via GitHub Classrooms. Je krijgt automatisch toegang tot de workshop repository wanneer de assignment wordt geopend.

Les 1: RabbitMQ Fundamentals

Wat is RabbitMQ?

RabbitMQ is een open-source message broker die het Advanced Message Queuing Protocol (AMQP) implementeert. Het fungeert als een tussenpersoon voor berichten tussen verschillende services in een gedistribueerd systeem.

Waarom Message Queuing?

In traditionele monolithische applicaties communiceren componenten direct met elkaar via functie-aanroepen. In microservices architecturen is dit anders:

• Loose coupling: Services hoeven niet direct van elkaar af te weten
• Asynchrone verwerking: Services kunnen onafhankelijk van elkaar werken
• Betrouwbaarheid: Berichten worden opgeslagen en kunnen opnieuw worden verwerkt
• Schaalbaarheid: Services kunnen onafhankelijk worden geschaald

AMQP Componenten

RabbitMQ gebruikt het AMQP-protocol met de volgende kerncomponenten:

• Producer: Service die berichten verstuurt
• Exchange: Router die berichten ontvangt en doorstuurt naar queues
• Queue: Buffer waar berichten worden opgeslagen
• Consumer: Service die berichten verwerkt
• Binding: Regel die bepaalt welke berichten naar welke queue gaan

Exchange Types

RabbitMQ ondersteunt verschillende soorten exchanges:

1. Direct Exchange: Routeert op basis van exacte routing key match
2. Topic Exchange: Routeert op basis van wildcard patterns
3. Fanout Exchange: Stuurt berichten naar alle gebonden queues
4. Headers Exchange: Routeert op basis van message headers

Real-world Analogie

RabbitMQ werkt als een postkantoor:

• Producer = Afzender die een brief post
• Exchange = Postkantoor dat brieven sorteert
• Queue = Postvak waar brieven wachten
• Consumer = Ontvanger die brieven ophaalt
• Routing Key = Postcode die bepaalt waar de brief heen gaat

Les 2: BDD en Cross-Service Testing

BDD: Behaviour Driven Development

BDD (Behaviour Driven Development) is een softwareontwikkelingsproces dat voortbouwt op TDD (Test Driven Development). BDD combineert de algemene technieken en principes van TDD met ideeën uit domain-driven design en object-oriented analysis and design om softwareontwikkeling te voorzien van gemeenschappelijke tools en een gedeelde proces voor samenwerking tussen softwareontwikkelaars en domeinexperts.

BDD Principes

• Gemeenschappelijke taal: Gebruik van een gedeelde taal die zowel technische als niet-technische stakeholders begrijpen
• Gherkin syntax: Given-When-Then structuur voor het beschrijven van gedrag
• Living documentation: Tests die als levende documentatie dienen
• Collaboration: Samenwerking tussen developers, testers en business stakeholders

Voorbeelden van BDD scenarios

Feature: User Registration
  As a new user
  I want to register for an account
  So that I can access the system

  Scenario: Successful registration
    Given I am on the registration page
    When I fill in valid registration details
    And I submit the form
    Then I should be registered successfully
    And I should receive a confirmation email

BDD definitie en relatie met andere *DD's

We beginnen met de definitie van BDD op Wikipedia (2023):

"In software engineering, behavior-driven development (BDD) is a software development process that goes well with Agile software development process that encourages collaboration among developers, quality assurance experts, and customer representatives in a software project. It encourages teams to use conversation and concrete examples to formalize a shared understanding of how the application should behave.

[...] Behavior-driven development combines:

• the general techniques and principles of TDD
• with ideas from domain-driven design (DDD)
• and object-oriented analysis and design

to provide software development and management teams with shared tools and a shared process to collaborate on software development."

BDD's relatie met andere *DD's: Ook test driven en testen 'inherente complexiteit'

Een belangrijk basisbegrip is 'self testing code'. Het is altijd goed het origine artikel van Martin Fowler hierover te lezen. Zijn onderstaande plaatje vat dit kort samen met beeld van code 'met een knop' die zichzelf kan testen. Maar dit kan een onervaren ICT'er onterecht het beeld geven dat je code kunt maken die op een of andere magische wijze zichzelf test (met een tool ofzo). En dat is natuurlijk niet het geval.

Een iets uitgebreidere samenvatting van 'self testing code' is dat je deze 'knop' realiseert door in een code naast de applicatiecode ook test code op te nemen. Deze test code roept de applicatiecode aan, en controleert dat deze de verwachte output krijgt. Hierbij is ook het doel dat er een hoge 'code coverage' haalt, typisch een line coverage van 80% in onze opleiding. Maar de afspraak hierover verschilt per bedrijf, en is ook afhankelijk van de complexiteit van de codebase (die - bij DDD aanpak - als het goed is vooral afhangt van de complexiteit van het onderliggende domein...). De vereiste code coverage hangt ook af of de codebase een monoliet is, of een microservices architectuur (MSA) heeft. Bij die laatste krijgen integratie testen meer belang en unit tests wat minder, en is code coverage minder van belang (want bij integratie tests is het geautomatiseerd bepalen van code coverage onmogelijk, of in ieder geval ingewikkelder/nog niet standaard).

Hoe dan ook, de interne werking is dus:

digraph G { rankdir=LR; // This sets the direction from left to right subgraph cluster_SelfTesting { label = "Self-Testing System"; A [label="Test code"]; B [label="Application code"]; A -> B; } }

Figuur 2: Intern onderscheid tussen test code (grote O 1) en (vangt de 'inherente' complexiteit conform DDD)

Net als TDD gaat BDD een stap verder dan enkel 'self testing code', want BDD is ook 'test driven'. Door eerst de test code te schrijven, denk je meteen vanuit 'client' kant aan welke interface je methode moet hebben, hoe je deze aanroept, en wat deze teruggeeft. Deze 'HOE roep ik het aan?' zit meer aan de WAT kant: "WAT is de interface", omdat de echte 'hoe' kant is: 'Hoe implementeer ik de code zodat deze daadwerkelijk het verwachte resultaat' teruggeeft. TDD grondlegger Kent Beck (van het Agile Manifesto) noemt dit in zijn article 'Canon-TDD' (2022) de 'Interface/Implementation Split':

"The first misunderstanding is that folks seem to lump all design together. There are two flavors:

1. How a particular piece of behavior is invoked.
2. How the system implements that behavior."

BDD -> Geen unit maar integratie tests!

Laten we in de nieuwe 'AI age' waar we in lijken te zitten, sinds de (hype rondom) de introductie van ChatGPT

Me: Wat voor soort testen doe je bij behaviour driven development (BDD)? Kun je deze kort samenvatten in Jip en Janneke taal!?

ChatGPT: Bij Behavior-Driven Development (BDD) worden verschillende soorten testen gebruikt om softwaregedrag te specificeren en te valideren:

• Acceptatietesten: Test of de software doet wat de baas wil.
• Scenario's: Verhalen schrijven over hoe de software moet werken.
• Unit-tests: Kleine stukjes code testen om te zien of ze goed werken.
• Integratietests: Controleren of alle stukjes samenwerken zonder problemen.
• Automatisering: Tests laten de computer uitvoeren om tijd te besparen.
• Regression Testing: Kijken of nieuwe veranderingen geen oude fouten veroorzaken.

Figuur 3: De test pyramide (Bron: headspin.io - Open commons licentie)

ChatGPT geeft een mooi overzicht van verschillende soorten tests, die je als developer moet kennen. Maar om unit tests op te nemen in dit overzicht van voor BDD relevante testen is wel een fout van ChatGPT (terzijde: AI modellen/systemen laten zich helaas NIET goed unit testen vanwege hun non-deterministische gedrag). Dus daarom is dit doorgestreept. Want BDD richt zich dus op juist op integratietests of zelfs end-to-end tests (integratie tests over alle lagen/units/functionaliteit heen). Lees bv. op de Cucumber Blog website (z.d.), dat je Cucumber gebruikt voor integratie en end-to-end tests, en NIET voor unit tests:

"BDD should also be used to verify the wanted behaviour using integration tests.

[...] These unit tests will not be validated by a stakeholder as they are written in code, and most stakeholders don't read code. If they did we wouldn't need tools like Cucumber."

De regressie tests die ChatGPT vermeld zijn GEEN wezenlijk verschillende tests van de andere tests die hij eerder noemt. Want je gebruikt je unit-tests en integratie-tests ook als 'regressie tests' om eventuele regressie fouten op te sporen en/of uit te sluiten. Regressiefouten zijn fouten uit stukjes code die 'omvallen' als je later wijzigingen aanbrengt in andere delen van de code waarvan je denkt dat die ongerelateerd zijn, maar die toch aan elkaar gekoppeld blijken (te weinig 'loos coupling').

Je moet de kracht en bedoeling van de verschillende tests kennen:

• Het voordeel van een unit test boven een acceptatietest is dat deze duidelijker aanwijst waar de fout vandaan komt (namelijk 1 specifieke unit).
• Het nadeel van units apart is dat deze soms geen fouten aantonen gaan, maar dat er alsnog integratie errors tussen de units buiten beeld blijft, die een acceptatie test wel aanwijst.
• Het voordeel van een integratie test is dat deze die fout wel laat zien
• Net nadeel van een integratie test is dat deze een fout niet aanweijzen
• En een nadeel is dat deze langzamer zijn, om dat bv. echt de database gebruikt word. Bij een unit test moet je externe dependencies/systemen als database altijd mocken

The Three Amigo's

Figuur 1: The three amigo's en het BDD proces met 3 stappen+1(van Pluralsight)

"The 'Three Amigos' is a meeting that takes user stories and turns them into clean, thorough Gherkin scenarios. It involves three voices (at least):

• The product owner
• The tester
• The developer

https://johnfergusonsmart.com/wp-content/uploads/2017/11/iStock-147318638-1024x683.jpg

Figuur 2: The three amigo's, niet per se 3, niet per se Spaans, maar wel per se >=3, divers en onderling vriendschappelijke omgang :)

BDD: 'Executable specifications' en synonieme acro's voor BDD

Gherkin is the most commonly used plain-text language for writing executable specifications in Given-When-Then-And-But steps. These scenarios are commonly saved as .feature files.

Feature: Users should be able to book appointments.

Scenario: A user wants to book an appointment.

Given a user has booked an appointment

When the booking status is timed out

Then the appointment will be not confirmed

Bron: 'What are executable specifications?' - Cucumber.io blog, 7-2-2019

... "BDD aims to express requirements unambiguously, not simply create tests. The result may be viewed as an expression of requirements or a test, but the result is the same. Acceptance tests record the decisions made in the conversation between the team and the Product Owner so that the team understands the intended behavior.

There are three alternative labels to this detailing process:

• Behavior Driven Design (BDD)
• Acceptance Test–Driven Development (ATDD)
• Specification by Example (SBE)

Bron & ©: Scaled Agile, Inc.

Cross-Service Testing en de "Testing Pyramid of Hell"

In microservices architecturen verandert de traditionele test pyramid drastisch. Waar je vroeger veel unit tests en weinig integratie tests had, is dit in een microservices omgeving niet meer effectief.

Figuur 4: The Testing Pyramid of Hell (Bron: TechBeacon)

In microservices architecturen krijg je de "Testing Pyramid of Hell":

• Veel integratie tests: Omdat services via APIs of message queues communiceren
• Contract tests: Om te zorgen dat services compatibel blijven
• End-to-end tests: Om complete workflows te testen
• Minder unit tests: Omdat individuele services vaak eenvoudiger zijn

BDD voor Cross-Service Testing met RabbitMQ

BDD is ideaal voor het testen van service-to-service communicatie via RabbitMQ:

Feature: Order Processing Across Services

Scenario: Order flows through multiple services via RabbitMQ
  Given a customer places an order
  And the order service is running
  And the inventory service is listening to the "orders" queue
  And the payment service is listening to the "payments" queue

  When the order service publishes an order message to RabbitMQ
  And the order service publishes a payment request to RabbitMQ

  Then the inventory service should receive the order message
  And the payment service should receive the payment request
  And the customer should receive an order confirmation

Huiswerk/opdracht

a. Bestudeer de theorie over Behaviour Driven Development zodat je theorie achter de BDD leerdoelen van deze week haalt. De keuze is afhankelijk van of je Java of .NET hebt gekozen in je weekopdracht:

1. Bestudeer het materiaal van de 'Cucumber' (Java)
2. Of SpecFlow (.NET) ReqNRoll (.NET) frameworks.

Edit 2024: De praktijk opdracht van BDD is in 2024 optioneel vanwege problemen overgang SpecFlow naar ReqNRoll en dat de 'Dare2Date' casus pas in week 4 volgt. De theorie van BDD moet je uiteraard wel kennen. Je zult de theorie dan in het Beroepsproduct van week 6&7 en het grote project moeten toepassen.

b. Opdrachten (maak tot en met opdracht 4, de rest in de les):

1. Pak uit de Opdracht voor de DevWorkshop de EuroCard service, maak hier (eigen keuze) een Java of .NET project voor aan, voeg BDD dependencies en tools toe (zie PluralSight) en voeg volgens BDD stijl Cucumber of Specflow tests toe en realiseer zo test-first de methoden.
2. Installeer hiervoor IntelliJ als je deze nog niet hebt/had (jaar gratis Ultimate editie voor HAN/AIM studenten) of Microsoft Visual Studio
3. Schrijf Gherkin code (given, when, then) voor 4 testgevallen credit cards nummers: 1, 2, 1023 en 208724
4. Schrijf glue code ('Step definitions')
5. Refactor de 4 tests naar één enkele Gherkin 'datatable'
6. Schrijf evt. ook dezelfde tests in TDD stijl (JUnit/XUnit).
7. Moet er nog een validatie en aparte melding bij voor credit card nummers met ongeldig format? (eigenlijk zouden ze zo moeten zijn: 6703 4444 4444 4449 (bron) en zou je ook een 'issuer check` kunnen doen).
8. Waarom wel, of waarom niet? En zo ja, hoe documenteer je dit? (want het staat niet in huidige spec)

Lesvragen

Behandelen opgekomen studentenvragen n.a.v. huiswerk of behandelde theorie. Als er geen vragen zijn, dan staan we even stil bij deze vragen:

1. Kun je in algemeen zowel TDD als BDD doen in een project, of moet je kiezen?
2. Welke CDMM checkpunten zijn relevant voor BDD?
3. Voor Java is er Cucumber, voor .NET is erSpecFlow of ReqNRoll, maar welke taal gebruik je wel in beide voor BDD?
4. Wat is een testsuite? Heeft een applicatie één testsuite?
5. Het Gherkin voorbeeld op de pagina toont één feature met één scenario. Is dit typisch, of horen bij één feature vaak meer scenario's, of bij één scenario meerdere features?
6. Waarom is de traditionele test pyramid niet meer geschikt voor microservices?
7. Hoe kun je BDD gebruiken om cross-service communicatie via RabbitMQ te testen?

Quiz

Test je '101 kennis' over RabbitMQ met deze korte multiple choice quiz:

Leerdoelen

RabbitMQ Leerdoelen

• Je kunt uitleggen wat een message broker is en de rol beschrijven van RabbitMQ in verbeteren van 'loose coupling' van systemen.
• Je kunt het verschil beschrijven tussen verschillende messaging patterns, zoals work queues, publish-subscribe, routing en topics en gegeven een situatie/toepassing aangeven welke het geschiktst is.
• Je kunt de componenten van het AMQP-protocol beschrijven, zoals exchanges, queues, bindings en routing keys, en uitleggen hoe ze samenwerken in RabbitMQ.
• Je kunt uitleggen hoe RabbitMQ berichten routeert op basis van binding keys en routing keys.
• Je kunt van de verschillende types exchanges in RabbitMQ in ieder geval fanout uitleggen en bijbehorende use-cases benoemen.
• Je kunt een real-world analogie geven voor de werking van RabbitMQ, bijvoorbeeld door het te vergelijken met het sorteer- en bezorgproces van een pakketbezorgdienst.

BDD Leerdoelen

• Je kunt uitleggen wat BDD is en hoe het verschilt van traditionele test-driven development
• Je kunt Gherkin syntax gebruiken om user stories te beschrijven
• Je kunt BDD scenarios schrijven in Given-When-Then format
• Je begrijpt hoe BDD bijdraagt aan betere communicatie tussen stakeholders
• Je kent de relatie van BDD met TDD, DDD en Agile/DevOps
• Je kent de BDD three amigo's, en de 3 stappen van het iteratieve BDD proces
• Je kunt de verhouding uitleggen tussen BDD test scenario's, test cases en suites met user stories en acceptatiecriteria uit Scrum
• Je kent de test pyramide, het belang van de verschillende soorten testen hierin en de link met BDD
• Je begrijpt waarom de traditionele test pyramid niet meer geschikt is voor microservices architecturen
• Je kunt BDD gebruiken om cross-service communicatie via message queues te testen

Bronnen

• Beck, K. (1-12-2023) Canon TDD - Software Design: Tidy First? Substack.com. Geraadpleegd september 2024 op https://tidyfirst.substack.com/p/canon-tdd
• Fowler, M. (1 mei 2014) Self Testing Code martinfowler.com Geraadpleegd september 2024 op https://martinfowler.com/bliki/SelfTestingCode.html
• Cucumber.io (z.d.) What are executable specifications? Geraadpleegd september 2024 op https://cucumber.io/blog/hiptest/what-are-executable-specifications/
• TechBeacon (z.d.) Integration tests don't cut it for microservices. Here's what does Geraadpleegd september 2024 op https://techbeacon.com/app-dev-testing/integration-tests-dont-cut-it-microservices-heres-what-does

Les 3-2 BDD

Huiswerk/opdracht

a. Bestudeer de theorie over Behaviour Driven Development zodat je theorie achter de BDD leerdoelen van deze week haalt. De keuze is afhankelijk van of je Java of .NET hebt gekozen in je weekopdracht:

1. Bestudeer het materiaal van de 'Cucumber' (Java)
2. Of SpecFlow (.NET) ReqNRoll (.NET) frameworks.

Edit 2024: De praktijk opdracht van BDD is in 2024 optioneel vanwege problemen overgang SpecFlow naar ReqNRoll en dat de 'Dare2Date' casus pas in week 4 volgt. De theorie van BDD moet je uiteraard wel kennen. Je zult de theorie dan in het Beroepsproduct van week 6&7 en het grote project moeten toepassen.

b. Opdrachten (maak tot en met opdracht 4, de rest in de les):

1. Pak uit de Opdracht voor de DevWorkshop de EuroCard service, maak hier (eigen keuze) een Java of .NET project voor aan, voeg BDD dependencies en tools toe (zie PluralSight) en voeg volgens BDD stijl Cucumber of Specflow tests toe en realiseer zo test-first de methoden.
2. Installeer hiervoor IntelliJ als je deze nog niet hebt/had (jaar gratis Ultimate editie voor HAN/AIM studenten) of Microsoft Visual Studio
3. Schrijf Gherkin code (given, when, then) voor 4 testgevallen credit cards nummers: 1, 2, 1023 en 208724
4. Schrijf glue code ('Step definitions')
5. Refactor de 4 tests naar één enkele Gherkin 'datatable'
6. Schrijf evt. ook dezelfde tests in TDD stijl (JUnit/XUnit).
7. Moet er nog een validatie en aparte melding bij voor credit card nummers met ongeldig format? (eigenlijk zouden ze zo moeten zijn: 6703 4444 4444 4449 (bron) en zou je ook een 'issuer check` kunnen doen).
8. Waarom wel, of waarom niet? En zo ja, hoe documenteer je dit? (want het staat niet in huidige spec)

Lesprogramma / Lesmateriaal

• Doornemen leerdoelen high level
• Behandelen theorie
• Beantwoorden vragen n.a.v. huiswerk en lesvragen
• Zelf verder aan de slag met BDD (optioneel in 2024)

Les inhoud / BDD Theorie

Hier wat korte theorie over BDD uit verschillende bronnen, namelijk over de relatie met TDD en DDD uit de Wikipedia definitie, iets over de Three Amigo's (wie) en het 3-staps proces +1 (hoe). Tot slot iets over verschillende namen BDD, ATDD en SBE en quotes van Martin Fowler en Dave Farley.

BDD definitie en relatie met andere *DD's

We beginnen met de definitie van BDD op Wikipedia (2023):

"In software engineering, behavior-driven development (BDD) is a software development process that goes well with Agile software development process that encourages collaboration among developers, quality assurance experts, and customer representatives in a software project. It encourages teams to use conversation and concrete examples to formalize a shared understanding of how the application should behave.

[...] Behavior-driven development combines:

• the general techniques and principles of TDD
• with ideas from domain-driven design (DDD)
• and object-oriented analysis and design

to provide software development and management teams with shared tools and a shared process to collaborate on software development."

BDD's relatie met andere *DD's: Ook test driven en testen 'inherente complexiteit'

Een belangrijk basisbegrip is 'self testing code'. Het is altijd goed het origine artikel van Martin Fowler hierover te lezen. Zijn onderstaande plaatje vat dit kort samen met beeld van code 'met een knop' die zichzelf kan testen. Maar dit kan een onervaren ICT'er onterecht het beeld geven dat je code kunt maken die op een of andere magische wijze zichzelf test (met een tool ofzo). En dat is natuurlijk niet het geval.

Een iets uitgebreidere samenvatting van 'self testing code' is dat je deze 'knop' realiseert door in een code naast de applicatiecode ook test code op te nemen. Deze test code roept de applicatiecode aan, en controleert dat deze de verwachte output krijgt. Hierbij is ook het doel dat er een hoge 'code coverage' haalt, typisch een line coverage van 80% in onze opleiding. Maar de afspraak hierover verschilt per bedrijf, en is ook afhankelijk van de complexiteit van de codebase (die - bij DDD aanpak - als het goed is vooral afhangt van de complexiteit van het onderliggende domein...). De vereiste code coverage hangt ook af of de codebase een monoliet is, of een microservices architectuur (MSA) heeft. Bij die laatste krijgen integratie testen meer belang en unit tests wat minder, en is code coverage minder van belang (want bij integratie tests is het geautomatiseerd bepalen van code coverage onmogelijk, of in ieder geval ingewikkelder/nog niet standaard).

Hoe dan ook, de interne werking is dus:

digraph G { rankdir=LR; // This sets the direction from left to right subgraph cluster_SelfTesting { label = "Self-Testing System"; A [label="Test code"]; B [label="Application code"]; A -> B; } }

Figuur 2: Intern onderscheid tussen test code (grote O 1) en (vangt de 'inherente' complexiteit conform DDD)

Net als TDD gaat BDD een stap verder dan enkel 'self testing code', want BDD is ook 'test driven'. Door eerst de test code te schrijven, denk je meteen vanuit 'client' kant aan welke interface je methode moet hebben, hoe je deze aanroept, en wat deze teruggeeft. Deze 'HOE roep ik het aan?' zit meer aan de WAT kant: "WAT is de interface", omdat de echte 'hoe' kant is: 'Hoe implementeer ik de code zodat deze daadwerkelijk het verwachte resultaat' teruggeeft. TDD grondlegger Kent Beck (van het Agile Manifesto) noemt dit in zijn article 'Canon-TDD' (2022) de 'Interface/Implementation Split':

"The first misunderstanding is that folks seem to lump all design together. There are two flavors:

1. How a particular piece of behavior is invoked.
2. How the system implements that behavior."

BDD -> Geen unit maar integratie tests!

Laten we in de nieuwe 'AI age' waar we in lijken te zitten, sinds de (hype rondom) de introductie van ChatGPT

Me: Wat voor soort testen doe je bij behaviour driven development (BDD)? Kun je deze kort samenvatten in Jip en Janneke taal!?

ChatGPT: Bij Behavior-Driven Development (BDD) worden verschillende soorten testen gebruikt om softwaregedrag te specificeren en te valideren:

• Acceptatietesten: Test of de software doet wat de baas wil.
• Scenario's: Verhalen schrijven over hoe de software moet werken.
• Unit-tests: Kleine stukjes code testen om te zien of ze goed werken.
• Integratietests: Controleren of alle stukjes samenwerken zonder problemen.
• Automatisering: Tests laten de computer uitvoeren om tijd te besparen.
• Regression Testing: Kijken of nieuwe veranderingen geen oude fouten veroorzaken.

Figuur 3: De test pyramide (Bron: headspin.io - Open commons licentie)

ChatGPT geeft een mooi overzicht van verschillende soorten tests, die je als developer moet kennen. Maar om unit tests op te nemen in dit overzicht van voor BDD relevante testen is wel een fout van ChatGPT (terzijde: AI modellen/systemen laten zich helaas NIET goed unit testen vanwege hun non-deterministische gedrag). Dus daarom is dit doorgestreept. Want BDD richt zich dus op juist op integratietests of zelfs end-to-end tests (integratie tests over alle lagen/units/functionaliteit heen). Lees bv. op de Cucumber Blog website (z.d.), dat je Cucumber gebruikt voor integratie en end-to-end tests, en NIET voor unit tests:

"BDD should also be used to verify the wanted behaviour using integration tests.

[...] These unit tests will not be validated by a stakeholder as they are written in code, and most stakeholders don't read code. If they did we wouldn't need tools like Cucumber."

De regressie tests die ChatGPT vermeld zijn GEEN wezenlijk verschillende tests van de andere tests die hij eerder noemt. Want je gebruikt je unit-tests en integratie-tests ook als 'regressie tests' om eventuele regressie fouten op te sporen en/of uit te sluiten. Regressiefouten zijn fouten uit stukjes code die 'omvallen' als je later wijzigingen aanbrengt in andere delen van de code waarvan je denkt dat die ongerelateerd zijn, maar die toch aan elkaar gekoppeld blijken (te weinig 'loos coupling').

Je moet de kracht en bedoeling van de verschillende tests kennen:

• Het voordeel van een unit test boven een acceptatietest is dat deze duidelijker aanwijst waar de fout vandaan komt (namelijk 1 specifieke unit).
• Het nadeel van units apart is dat deze soms geen fouten aantonen gaan, maar dat er alsnog integratie errors tussen de units buiten beeld blijft, die een acceptatie test wel aanwijst.
• Het voordeel van een integratie test is dat deze die fout wel laat zien
• Net nadeel van een integratie test is dat deze een fout niet aanweijzen
• En een nadeel is dat deze langzamer zijn, om dat bv. echt de database gebruikt word. Bij een unit test moet je externe dependencies/systemen als database altijd mocken

The Three Amigo's

Figuur 1: The three amigo's en het BDD proces met 3 stappen+1(van Pluralsight)

"The 'Three Amigos' is a meeting that takes user stories and turns them into clean, thorough Gherkin scenarios. It involves three voices (at least):

• The product owner
• The tester
• The developer

https://johnfergusonsmart.com/wp-content/uploads/2017/11/iStock-147318638-1024x683.jpg

Figuur 2: The three amigo's, niet per se 3, niet per se Spaans, maar wel per se >=3, divers en onderling vriendschappelijke omgang :)

BDD: 'Executable specifications' en synonieme acro's voor BDD

Gherkin is the most commonly used plain-text language for writing executable specifications in Given-When-Then-And-But steps. These scenarios are commonly saved as .feature files.

Feature: Users should be able to book appointments.

Scenario: A user wants to book an appointment.

Given a user has booked an appointment

When the booking status is timed out

Then the appointment will be not confirmed

Bron: 'What are executable specifications?' - Cucumber.io blog, 7-2-2019

... "BDD aims to express requirements unambiguously, not simply create tests. The result may be viewed as an expression of requirements or a test, but the result is the same. Acceptance tests record the decisions made in the conversation between the team and the Product Owner so that the team understands the intended behavior.

There are three alternative labels to this detailing process:

• Behavior Driven Design (BDD)
• Acceptance Test–Driven Development (ATDD)
• Specification by Example (SBE)

Bron & ©: Scaled Agile, Inc.

Lesvragen

Behandelen opgekomen studentenvragen n.a.v. huiswerk of behandelde theorie. Als er geen vragen zijn, dan staan we even stil bij deze vragen:

1. Kun je in algemeen zowel TDD als BDD doen in een project, of moet je kiezen?
2. Welke CDMM checkpunten zijn relevant voor BDD?
3. Voor Java is er Cucumber, voor .NET is erSpecFlow of ReqNRoll, maar welke taal gebruik je wel in beide voor BDD?
4. Wat is een test suit? Heeft een applicatie een testsuite?
5. Het Gherkin voorbeeld op de pagina toont één feature met één scenario. Is dit typisch, of horen bij één feature vaak meer scenario's, of bij één scenario meerdere features?

Quiz

Check je kennis over BDD met onderstaande korte multiple choice toets.

Leerdoelen

Check met onderstaande leerdoelen of je de behandelde stof begrepen hebt en toetsvragen kunt beantwoorden.

• Je kent de relatie van BDD met TDD, DDD en Agile/DevOps
  • met o.a. relevante begrippen als Ubiquitous Language, test-first, red-green-refactor, AAA pattern, given-when-then en collaborative development
• Je kent de BDD three amigo's, en de 3 stappen van het iteratieve BDD proces
• Je kent 2 andere namen van BDD, en kunt deze uitleggen
• Je kent de term 'self testing code' en het onderscheid tussen .feature files, glue code en applicatie code en de talen/standaarden die hier achterin zitten
• Je kunt de verhouding uitleggen tussen BDD test scenario's, test cases en suites met user stories en acceptatiecriteria uit Scrum
• Je kent de test pyramide, het belang van de verschillende soorten testen hierin en de link met BDD
• Je kunt op basis van een tutorial een project met werkende en relevante BDD tests opstellen m.b.v. Cucumber of Specflow (ReqNRoll)

Bronnen

• Beck, K. (1-12-2023) Canon TDD - Software Design: Tidy First? Substack.com. Geraadpleegd september 2024 op https://tidyfirst.substack.com/p/canon-tdd
• Fowler, M. (1 mei 2014) Self Testing Code martinfowler.com Geraadpleegd september 2024 op https://martinfowler.com/bliki/SelfTestingCode.html

Kubernetes 101

NB In 2024 gaat deze les NIET door, en zit onderstaand huiswerk bij workshop Alliander van de maandag erop en de daarin niet behandelde theorie uit deze les behandelen we in de Kubernetes 102 les de dinsdag erop.

Deze les kijken we naar de 'Kubernetes architectuur', en alle componenten van Kubernetes. Formeel Kubernetes 'resources' genoemd, zoals Cluster, Node etc. De les begint echter met een recap van de vorige les en uitstapje over semantic versioning. En hieronder eerst het voorbereidende huiswerk.

Huiswerk

Doe het volgende huiswerk. Dit zijn 2 stukken documentatie over 'orchestration' van Docker en 2 korte opdrachten die hierop doorgaan:

1. Lees de Docker: Orchestration, get started... documentatie en zet lokaal Kubernetes aan in Docker Desktop volgens de instructie (je hoeft NIET Docker Stack aan te zetten, dat is deprecated)
2. Bekijk de 1e 12 minuten van deze presentatie van Edwin van Wijk (medewerker InfoSupport).
   • Als je liever leest dan video's kijkt neem de onderdelen van de 'overview' van de Kubernetes docs op kubernetes.io door,
   • Vanaf 2:11 begint het stuk over Kubernetes, na een intro over Docker, maar vanaf het begin kijken is wellicht wel zo relaxed
   • Zorg dat je ieder geval de concepten Pods, Deployments en Services duidelijk hebt. Als de video hiervoor te kort/high level is; lees dan de kubernetes docs, of er is ook deze wat uitgebreidere versie om ook intro te krijgen in Pitstop en vergelijking K8S en Docker compose (vanaf ca. 6:00 tot ergens 30 a 40 minuten. Je kunt sowieso stoppen als Edwin Service Mesh gaat behandelen (dat zou mooi onderzoeksonderwerp zijn voor week erna, als je dit interessant vindt).
   • De Kube proxy zorgt dat een pod via network bereikt kan worden en Kubernetes higher level concepten als een NodePort kan realiseren.

A. Neem Figuur 1 voor jezelf op papier over, en breidt deze tekening met met concepten Cluster, Nodes en Pods uit met de overige Kubernetes resource types. Voeg hierin ook de ReplicaSet toe en lees hiervoor de volgende bron over ReplicaSets op website bmc.com.

- Merk op dat in deze overview de *Kubelet* voorkomt i.p.v. een pod. Een Kubelet is te zien als 'de Ops kant' van een Pod. Een Kubelet is een daemon programma dat draait op een server en van de server een K8S node maakt. Meestal gaat deze deel uitmaken van de *data plane* zodat de K8S *control plane* node(s) hier een Pod kan gaan draaien. Vanuit de 'Dev' kant heb je liever de pod als abstractie, dan kun je dit 'extra [niveau van indirectie](https://en.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering)' negeren. Maar zeker een mogelijk onderzoek in week 6 om onder de moterkap te kijken naar schalingsmogelijkheden van pods of de Ops side van Nodes:
  - Horizontal Pod Autoscaling *HPA)
  - Hoe de kubelet een PodSpec te sturen.
  - Hoe een Kubelet meer dan één pod beheren, zogenaamde 'side car pods'

Figuur 1: Diagram van een Kubernetes cluster.

B. Kijk naar Figuur 2 en klik er zo nodig op voor een grotere versie.

• Maak een schema/lijstje met opdeling van de Kubernetes commands's in de 'imperatieve' en 'declaratieve' commando's.
• En doe kort onderzoek naar de achtergrond hiernaar. Stel bv. ChatGPT een vraag hierover, en valideer wat je terug krijgt kort door te googlen naar andere bronnen.
• Bijvoorbeeld een relevante stackoverflow post.

Figuur 2: Kubernetes: imperatieve vs declaratieve commando's in Kubernetes

Kubernetes Architecture

Figuur 3 geeft weer een beeld van de K8S resources in de K8S architectuur.

Figuur 3: Kubernetes Resources

Dit zijn er best veel, dus staan we er even bij stil. Gelukkig waren de lessen over Docker (van vorige week) wel een springplank voor veel concepten. Probeer voor je zelf alle objecten op te halen en op te schrijven. Highlight hieronder de tekst om antwoord zichtbaar te maken.

• Cluster?
• Node
• Service
• Deployment
• ReplicaSet
• Pod
• Container?
• Bonus 1: Data plane vs control plane
• Bonus 2: K8S Client, K8S API?, ...
• Bonus 3: Taints vs tolerations

...

Figuur 3: (Een deel van) ChatGPT 4's poging tot een overzicht als Mermaid klassediagram.

Quiz

Test je '101 kennis' over Kubernetes met deze korte multiple choice quiz:

Leerdoelen

• Je kunt uitleggen wat Kubernetes is en dat je het gebruikt voor containerorchestratie.
• Je kent het onderscheid in Kubernetes tussen control plane en data plane.
• Je kunt het verschil uitleggen tussen de node types binnen Kubernetes (master en worker nodes) en hun rol binnen de cluster.
• Je kent Kubernetes resources zoals Pods, ReplicaSets en Deployments en kunt beschrijven hoe deze met elkaar verbonden zijn en welke functie ze vervullen.
• Je herkent de voordelen van declaratieve versus imperatieve Kubernetes commando's en kunt uitleggen hoe je deze toepast in verschillende scenario's.

Week 5 - SlackOps (monitoring)

Lesoverzicht

• Les 1 - Alliander Workshop: K8s & GitOps
• Les 2 - Kubernetes 102
• Les 3 - Prometheus
• Les 4 - Semantic Versioning + Weekopdracht bespreken & peer feedback (CDMM, aanwezigheid, reflectie)

Zelfstudie: Chaos Engineering (zie Prometheus en Chaos Engineering)

Les 5-1 Alliander workshop: K8S & GitOps

Alliander gastles.

Les 5-2 Prometheus/PromQL en Chaos engineering/Load testing

Kijk verder naar les over Prometheus en chaos engineering.

Les 5-3 Todo

Todo.

Leerdoelen

Check met onderstaande leerdoelen of je de behandelde stof begrepen hebt en toetsvragen kunt beantwoorden.

• MDO-DevOps-5 - Slackops "Je kunt goede logging en monitoring realiseren in verschillende omgevingen en zorgen voor applicatiespecifieke rapportages"
• Ops-2-1 Je kent de principes van chaos engineering en de toegevoegde waarde hiervan

Workshop Alliander - DevOps bij Alliander: ArgoCD & GHA & Pax

Het bedrijf Alliander uit (o.a.) Arnhem komt in onze minor een workshop geven over 'DevOps bij Alliander'!

Huiswerk

De informatie uit deze workshop overlapt deels met de Kubernetes 101 les. Maak het huiswerk/de voorbereiding daarvan.

Alliander: netwerkbeheer

Dit zijn de slides van de presentatie van Alliander:

• DevOps bij Alliander (2024)

Alliander doet netbeheer, maar is effectief ook een ICT-bedrijf met 100-en ICT'ers in dienst. Slimme ICT is een belangrijk onderdeel van hun bedrijfsvoering en absoluut noodzakelijk in het kader van de energietransitie, wat in de huidige maatschappij erg belangrijk is.

Alliander: ICT

Kortgezegd gebruikt Alliander ook het onderdeel GitOps uit DevOps en hierbij van tools als Kubernetes, GitHub Actions en ArgoCD.

• ArgoCD is een tool voor GitOps volgens een 'pull based model' (voor Continuous Deployment)

Figuur 1: GitOps

Quiz

Test je kennis na deze workshop van Alliander met deze korte multuple choice quiz.

Leerdoelen

Het doel van de workshop is dat je een goed beeld hebt van hoe Alliander bij hun praktijk DevOps in de praktijk invult. Dus welke standaard tools en best practices Alliander gebruikt.

• Je kunt uitleggen hoe Kubernetes en Helm worden gebruikt voor het beheren en deployen van applicaties binnen Alliander.
• Je kunt beschrijven wat GitOps inhoudt en uitleggen hoe het wordt gebruikt om infrastructuur te beheren met Git als single source of truth.
• Je kunt de werking van een GitOps Operator zoals ArgoCD uitleggen en begrijpen hoe deze wordt gebruikt voor continuous delivery.
• Je begrijpt hoe het CI/CD proces bij Alliander is ingericht met GitHub Actions en ArgoCD en kunt het belang hiervan toelichten.
• Je kunt uitleggen hoe AWS Elastic Container Registry (ECR) wordt gebruikt om container images op te slaan en beheren zoals voor software updates of container retentie.

Kubernetes 102

NB In 2024 behandelen we in deze les ook nog niet eerder behandelde onderwerpen uit de Kubernetes-101 les

Deze les geeft Kubernetes verdieping en dient om aan de slag te kunnen met je eigen Kubernetes Rancher cluster onder aimsites.nl en hierop een kleine microservice applicatie te kunnen runnen (PitStop).

Huiswerk/voorbereiding

Dit is het huiswerk voorafgaand aan de les:

1. Neem als recap van de vorige les het artikel Kubernetes 101 door
2. En ook de korte blog post 'Difference between a load balancer and an ingress'
3. Neem high level de 3opties door voor migratie uit Docker compose in artikel van Milind Chavan (2021)
4. Lees de documentatie over Kompose op de Kubernetes docs.
5. Beantwoord onderstaande 8 huiswerkvragen. Zoek o.b.v. dingen die hierin onduidelijk zijn zelf relevante stukken uit de volgende bronnen (eigen keuze/leerwegonafhankelijk)
   • de Kubernetes documentatie (kubernetes.io) over meer gedetailleerde werking van Deployments, Replicasets, Ingress en Services.
   • Of meldt je aan voor de gratis (fremium) Linux Foundation course over Kubernetes en neem hoofdstuk '8. Kubernetes building blocks en '10 Services' door.

Huiswerkvragen

1. Noem 3 opties om te upgraden vanaf docker compose naar Kubernetes
2. Noem een voordeel van elk van deze 3 opties
3. Kun je op productie ook Docker en Docker compose gebruiken? Noem minstens 1 reden waarom je dit zou willen, en 2 waarom niet.
4. Wat betekent "Pods are used as the unit of replication in Kubernetes."
5. Wat betekent 'round robin'? Google het zo nodig (staat niet in de bronnen) leg het uit
6. Wat is DNS en hoe gebruikt Kubernetes dit?
7. Op welke (wel/andere) behandelde 'resource' lijkt een Kubernetes DaemonSet?
8. Zelfde vraag voor de (verouderde) K8S resource ReplicationController: a. met welke resource(s) hangt deze samen? b. waarom is de ReplicationController gedeprecate? vind in bron, of vraag bijvoorbeeld aan ChatGPT en evalueer diens antwoord en zorg dat je het zelf snapt/kan reproduceren

Les

Kubernetes (K8S) is een te groot onderwerp om geheel in één week te kunnen behandelen. Hier zou je ook een hele minor mee kunnen vullen.

De bedoeling is dat je basis K8s Architectuur en K8S componenten en concepten kent en hier mee om kunt gaan. Zodat je m.b.v. kubectl en extra benodigde vaardigheden tijdens opdracht en project relatief snel kunt uitzoeken met behulp van deze 'kapstok van kennis' die je al hebt.

In deze les kijken we naar:

• Terugblik Kubernetes architectuur (vragen vorige lessen)
• Het YML format en de relatie met JSON
• K8S advanced onderwerpen 'Ingress'
• K8S advanced onderwerp 'etcd' (en de relatie met High Availability clusters)
• Optioneel: het begrip 'Quality of Service' in algemeen, en specifiek in K8S in verband met mogelijk onderzoek.
• Workshop ArgoICT over Kubernetes (en K8S 'workloads')

1. Lesopdracht/-uitstapje: JSON vs YAML

Bekijk de website https://www.json2yaml.com/ en experimenteer hiermee. Zorg dat je duidelijk krijgt de link tussen JSON en YAML.

2. Lesvragen .yml

1. Is YAML ook JSON?

2. Hoe ziet een JSON array eruit bij omzetten naar YAML?

3. Hoe ziet een JSON object eruit? Wat is het verschil en overeenkomst met een array?

4. Maak een YAML bestand met een lijst van namen van jezelf en 3 studenten die om je heen zitten. Zet erna in het bestand ook de informatie over jezelf qua:

   • 'lievelingskleur'
   • 'favoriete film'
   • 'hobby'

5. Vraag ook een van de 3 klasgenoten deze 3 'properties' en vul in

6. Ken je nog meer talen/formats die onderling zo'n zogenoemde 'superset' zijn van een andere taal/format? Schrijf op welke. Wat is het voordeel?

3. Nog 2 K8S onderwerpen: Ingress en etcd

Interessant én relevant stuk theorie is de werking van etcd, het gedistribueerde opslagsysteem waar K8S de eigen config opslaat. En wat ook een beeld geeft van kwesties rondom 'database sharding' en ook 'clustering' en 'voting. Bekijk deze korte intro:

We bekijken samen de video Kubernetes Ingress in 5 mins - Sai Vennam, IBM (5:40 minuten)

• What is etcd? - Whitney Lee, IBM (6 minuten)

Lesvragen Ingress en etcd

• Wat hebben K8S Ingress en etcd met elkaar te maken? (if any)
• Wat is het verschil tussen een Ingress en een Service?
• Bedenk zelf een toetsvraag over Ingress en zet in Teams
• Wat is een HA cluster in K8S?
• Wat heeft het aantal met het Raft voting systeem te maken?
• Wat is een 'etcd. member' en zit deze in control plane of data plane?

Optioneel: Quality of service in K8S

Een opstapje naar 'advanced Kubernetes' is wel het concept 'Quality of Service' (QoS) en implementatie en werking hiervan in Kubernetes.

Dit zou een mooi onderzoek zijn voor wie deze meer 'Ops side of things' wil verkennen.

Workshop "K8S op Rancher - Kubernetes een beetje praktisch" - Argo ICT

Het bedrijf Argo ICT uit Arnhem, met oud HAN student Murat Castermans geeft een hands-on uitleg bij het gebruik van een Rancher cluster voor de laatste opdrachten in de course fase.

Argo ICT moet je niet te verwarren met de vaak in het blok 2 gebruikt project te gebruiken tool Argo CD :). Argo ICT regelt de complexere ICT benodigheden voor HAN ICT en AIM, maar hebben ook andere klanten.

Samenvatting presentatie

Hier de link naar de presentatie (Google Slides)

Enkele quotes/samenvatting

Kubernetes is 'meer dan alleen maar schaalbaar' "Je hebt iemand die continue over je schouders meekijkt".

• Aantal issues tackled K8S zelf, heeft bv. probes voor detecteren van memory leaks, zodat je 's nachts niet wakker wordt gebeld.
• Je hoeft geen rekening houden met allerlei zaken aan de achterkant, zoals het configureren van Nginx, of OS specifieke zaken.
• Je hebt minder last van vendor lock-in. Zolang het maar 'Certified Kubernetes' is.

Soorten workloads in K8S

Quote uit de Kubernetes docs over 'workloads'

"A workload is an application running on Kubernetes. [...] Kubernetes provides several built-in workload resources:

(Uit de sheets van Murat):

• Deployment - Alles stateless, maakt niet uit welke node en of er storage is, makkelijk schalen, bv. een JavaScript front-end in een Nginx container
• StatefulSet - Wel storage, geisoleerd van andere storage, bv. voor database server
• Daemonset - K8S zorgt dat deze 'service' elke Node zorgt , bijvoorbeeld voor logging services (zoals FlentD)

Verdere highlights

K8S kent 3 soorten probes: Startup, Readiness (traffic) en Liveness (kill)

Gebruik voor testen op je eigen K8S cluster op aimsites een port forward, i.p.v. een NodePort setting (zoals je op localhost wel doet).

RWO = 'Read Write Once', wordt niet getoetst, wel interessant voor onderzoek evt. (access modes van K8S PersistentVolumeClaim)

Quiz

Test je kennis met deze korte multiple choice quiz.

Leerdoelen

Check met onderstaande leerdoelen of je de behandelde stof begrepen hebt en toetsvragen kunt beantwoorden.

• Je kunt uitleggen wat de rol van Pods is als replicatie-eenheid in Kubernetes.
• Je begrijpt hoe Kubernetes Ingress werkt en hoe het verschilt van een Service.
• Je kunt uitleggen hoe een HA cluster werkt in Kubernetes en waarom minstens drie master nodes vereist zijn voor etcd consensus.
• Je kent de voordelen van migreren van Docker Compose naar Kubernetes en weet hoe tools zoals Kompose en Skaffold hierbij helpen.
• Je kunt de functie van een DaemonSet in Kubernetes uitleggen
• Je kent het voorbeeld van de ReplicationController uit de K8S die is gedeprecate en vervangen door ReplicaSet als voorbeeld van verbeteringen en verandering in Kubernetes historie
• Je kunt het verschil tussen JSON en YAML uitleggen aan de hand van hun relatie en voorbeelden en kan uitleggen waarom men .yml vaker voor K8S config gebruikt

Prometheus & Chaos engineering

NB Deze les vervalt in 2025. Chaos engineering komt in week 6 terug als onderzoeks thema in de spike/onderzoek sprint van het 3-weeks eindproject. Prometheus of andere monitoring/observability wordt ook verder onderzocht in week 6 samen met security onderwerp en advanced Kubernetes onderwerp/techniek uit het CNCF landschap.

Vandaag 2 aparte onderwerpen: monitoring en statistieken via Prometheus en Grafana. En een 'build for failure' aatitude via Chaos engineering in K8S met de tool Chaos mesh.

Huiswerk/voorbereiding Chaos Engineering

• Zorg dat je begrijpt wat Chaos Engineering is én hoe je dit bereikt (Chaos Monkey, bv. link met 'design for failure' uit Event Driven workshop)
• Lees over Chaos Mesh
• Als het goed is ken je al het concept 'shift left', neem deze blog door over het concept 'shift right'
• Optioneel: Doe de 3 stappen van de Quickstart van open source Load test tool K6
• Krijg zelf overzicht van de Prometheus architectuur (zie figuur 1) door de website van Prometheus zelf door te nemen: prometheus.io.

Chaos Mesh

Figuur 1: Chaos Mesh

Figuur 2: Shift left vs shift right

Huiswerkvragen

• Schrijf voor jezelf op wat 'shift left' betekent. Beantwoord in ieder geval:
  • waarom term 'left'?
  • wat shift je?
  • betrek ook het plaatje van software development continuum (of DevOps infinity loop)
• Zelfde voor 'shift right': Wat betekent shift right?
  • Betekent 'shift right' dat je test in productie?
  • Wat heeft shift right' met SlackOps te maken?
  • Kun je een load test ook op een test omgeving doen? Wat is er dan nodig?

Uitstapje: The founder

Figuur 3: 'Founder trailer'

Lesvraag: Wat heeft deze video met DevOps te maken? Link ook aan het concept 'shift right'.

Chaos Engineering in PitStop

Figuur 3: Video: Stukje Chaos engineering in PitStop; demo van Edwin van Wijk

• Welke tools gebruikt Edwin van Wijk om Chaos Engineering principe toe te passen (het YouTube filmpje start bij stuk over 'Chaos Engineering' op 41 en een halve minuut. Misschien ). Bij welke van de 5 weekthema's uit de minor hoort elke?

• Welk onderzoeksmethode hoort bij een load test? (if any)

  • In welke onderzoeksruimte zit deze methode?
  • Wat is het verschil tussen een load test en een performance test? (if any)
  • Vindt een alternatieve tool voor K6, schrijf kort verschil in features tussen de twee (nadeel en voordeel t.o.v. elkaar)

Prometheus

Week opdracht 5 bevat het maken van custom metrics in je applicatie en het verzamelen (scrapen) hiervan met Prometheus.

Figuur 1: Prometheus architectuur (bron: prometheus.io)

In deze laatste onderwijsweek testen we meer je eigen attitude.

Attitude

• je bent nieuwsgierig, en vindt zelf geschikte bronnen (je hebt deze minor zelf gekozen, en gaat volgende week ook onderzoek doen)
• je werkt zelfstandig (je gaat na de minor afstuderen)
• kunt *samenwerken ('DevOps is cooperation').
• je bent pragmatisch (je pakt een nuttige rol in de groepsopdracht, bepaalt een einddoel en houdt deze in de gaten)

Vanuit deze attitude zorg je dat een aantal dingen kent (kennis op doet) en kunt (vaardigheden aanleren en oefenen).

Kennen:

• de Prometheus architectuur
• Belangrijke termen: metrics, metrics server, promql, visualizer, service discovery, time series en scraping.
• Ook weet je hoe samenwerking Prometheus is met Grafana of andere broodnodige visualisatie tools als de ELK stack (omdat Prometheus NIET zelf visualisatie doet; zie figuur 2.)

Kunnen:

In de weekopdracht moet je

• enkele algemene metrics tonen
• maar ook applicatiespecifieke metrics.

Figuur 2: Prometheus uitgebreide architectuur (inclusief visualisatie tool als Grafana; bron: DevOpsSchool.com)

Bronnen

TODO: netjes volgens APA.

• Basis architectuur https://prometheus.io
• Uitgebreide architectuur... Geraadpleegd op 3-11-2023 op https://www.devopsschool.com/blog/what-is-prometheus-and-how-it-works/

Semantic Versioning

Figuur 1: Semantic versioning (bron: Surjit Bains, CC BY-SA 4)

NB Dit is in 2024 in week 4 geplaatst als zelf studie om voldoende tijd te hebben voor kubernetes in week 5. Kubernetes zit op het moment van schrijven op versie 1.28.x. K8s gebruikt semver: semantic versioning

"Kubernetes versions are expressed as x.y.z, where x is the major version, y is the minor version, and z is the patch version, following Semantic Versioning terminology. - kubernetes.io

Opdrachten/zelfstudie

1. Lees over Semantic Versioning op semver.org zodat je het begrijpt
2. Welke onderdelen je wel of niet leest, mag je zelf bepalen, maar zorg dat je bij plaatje in Figuur 1 een verhaal kan vertellen over wanneer je welke van de 3 delen van een semver versie moet ophogen
3. En beantwoord ook waarom de term 'semantisch' in de naam semver zit
4. Denk eens na op welke zaken in een DevOps project je allemaal versies kunt geven.

Tijdens het project is semver ook een goede keuze. Je hebt echter de vrijheid om een eigen versienummer systeem te gebruiken. Zolang je dit documenteert/ernaar verwijst. Én er ook een goed idee achterzit. Dus bijvoorbeeld niet een 'anti naming pattern' zoals WendtVer die voor kenners wel vermakelijk is om te lezen.

"Let WendtVer provide you with a “fun” way to release and upgrade packages without having to think, saving you time and thinking."

Je mag er zelf over nadenken of alleen een git commit hash gebruiken als versienummer een goed idee is... :).

Als je een toepassing wilt kijken van semver die in een groot project ook erg handig is kun je eens kijken naar `conventional commits':

"[Conventional commits] dovetails with SemVer, by describing the features, fixes, and breaking changes made in commit messages." - https://www.conventionalcommits.org/en/v1.0.0/

TL; DR

De DDD term 'ubiquitous language' is van belang voor het checkpunt 'IR-201 Gedeeld informatiemodel' uit het CDMM. Dit staat uitgelegd onder de categorie 'Information and reporting'. Zie voor uitleg hiervan de beschrijving op pagina over 'DevOps concepten'. Zoals daar uitgelegd gaat het in CDMM checkpoint 'shared information model' vooral over informatiemodel van het software ontwikkel proces. In plaats van het domeinproces in het domein van je software zelf over gaat.

De term 'domein' is ook een verwarrende term, aangezien soms ook ICT zelf, en dus 'software ontwikkelen' een domein is. Namelijk het domein waar je les in krijgt op het HBO ICT. Het kunnen analyseren van andere domeinen waarbinnen je automatiseert is een van de competenties nodig om goed te kunnen werken in het ICT domein. Binnen dit ICT domein is een belangrijk concept dat van 'semantic versioning': semver. Dit geeft algemene richtlijnen over de betekenis van versienummers van software. Binnen een specifiek domein kun je vervolgens met semver je concrete software ook concrete semver versies toewijzen, waarbij je dan in kaart brengt welke features of bugfixes een bepaalde versie bevat. In termen van de concrete functionaliteit die een applicatie heeft. Maar ook de software tools die je zelf als developer gebruikt, en eindgebruikers geen weet van (hoeven te) hebben kan semver versies hebben.

Quiz

Leerdoelen

• Je kunt uitleggen wat semantic versioning inhoudt en waarom het nuttig is in softwareontwikkeling.
• Je kunt het verschil uitleggen tussen de drie onderdelen van semantic versioning en aangeven welk onderdeel je verhoogt in specifieke situaties.
• Je kunt uitleggen hoe je semantic versioning toepast om compatibiliteit te waarborgen tussen verschillende versies van een project.

DevOps Beroepsproduct

Afsluiter van de course fase is een opdracht om in teamverband een DevOps BeroepsProduct (BP) te realiseren, te deployen en in de lucht te houden en monitoren.

Het is goed om je al een keer op deze eindopdracht en beoordelingscriteria te orienteren aan het begin van de course, zodat je hier gericht naar toe kunt werken. Tijdens de course fase refereert de docent waarschijnlijk ook regelmatig aan de eindopdracht, ivm het CDMM beoordelingsmodel. En in de laatste weekopdracht(en) neem je hierop ook al een voorschotje.

---

Figuur: Ontdek het DevOps 'Secret Ingredient' tijdens de course eindopdracht!

NB Tijdens de course eindopdracht leer je — eindelijk — de secret ingredient van DevOps kennen! (zie figuur; spoiler warning: filmpje NIET aanklikken!)

De DevOps minor is voltijd. Jullie worden geacht om 40 uur per week aan beroepsproduct te ontwikkelen. Dus op maandag bespreken we bovenstaand overzicht en eventuele uitwijkingen hierop. Communcatie verloopt ook via het aangemaakt Slack kanaal en/of Teams (Slack in 2024)/.

Lestijden DevOps-project

Vraag student

"Ik ben een beetje verward door het rooster van ISAS i.c.m het rooster op minordevops.nl. Wat zijn nu precies de lestijden voor het DevOps project volgende week? Ik wil ook netjes verlof boeken met m'n werk."

Reminder: KiesOpmaat geeft/gaf ook aan:

Rooster Er wordt vanuit gegaan dat studenten van maandag t/m vrijdag beschikbaar zijn, dus bijbaantjes of andere vakken van maandag t/m vrijdag (9.00-17.45 uur) volgen is geen optie.

Er is in de laatste drie weken geen centrale stof meer, en ook geen theorietoetsen. We gaan de geleerde theorie toepassen, en waar nodig nog aanvullen of gaten dichten. Je werkt zelfstandig met je team werken aan de eind opdracht. Hiermee oefenen we ook de vorm vam het eindproject in blok 2. Op de lesmomenten is de docent in het geroosterde lokaal, tenzij anders afgestemd. Begin van de week zijn sprint planning en eind van de week reviews. In week 2 kan begin van de week nog een retrospective met je docent zijn, of je doet dit als team zelfstandig (continuous improvement).

In week 9 is (naast theorie toets herkansing) mogelijk ook nog een bedrijfsbezoek en/of een workshop bij InfoSupport workshop. Details volgen in de lessen.

Week 6: Spike/Onderzoek Sprint

Zie de Spike Guide voor uitleg over de onderzoeksweek, de te onderzoeken thema's en de presentatie op donderdag. Je maakt ook alvast een User Story map van je functionaliteit en ook je spikes en non-functionals hierin.

Week 7: Implementatie & Development

In week 7 ga je de bevindingen uit je spike-onderzoek implementeren in je MSA DevOps applicatie. Je werkt aan:

• Basis functionaliteit van je product increment (selectie user storie)
• Toepassen van onderzochte technologieën in je applicatie
• Architectuur aanpassingen volgens je spike-bevindingen
• Documentatie via C4 diagrammen en ADR's

Aan het einde van week 7 moet je applicatie werkend zijn op een productie-omgeving.

Week 8: Product Increment & Presentatie

Week 8 staat in het teken van het afronden van je product increment en de voorbereiding van de eindpresentatie:

• Product increment realiseren met de 6 vereiste eisen (uitrol, architectuur, monitoring, security, schaling, fouttolerantie)
• Staging omgeving opzetten naast productie
• Testing en validatie van alle functionaliteit
• Voorbereiding eindpresentatie en demo
• Documentatie afronden (README, ADR's, C4 diagrammen)

Op donderdag van week 8 presenteer je je beroepsproduct aan de klas en docenten.

Opdrachtbeschrijving beroepsproduct DevOps

Afsluiter van de course fase is een opdracht om een DevOps beroepsproduct te maken als team met — uiteraard — gelijkwaardige bijdrage van elk teamlid. Hieronder de opdracht voor het team en elk groepslid.

A. Team:

1. Deploy een applicatie (systeem) die bestaat uit meerdere containers (microservices) naar minstens één live omgeving
2. Pas de onderzochte DevOps technologieën uit Spike onderzoeken toe in de applicatie en/of deployment
3. Voer hierop een product increment door met toepassing van de in thema weken opgedane kennis en vaardigheden

B. Elk groepslid:

1. Voer een technisch Spike onderzoek uit naar een DevOps-technologie naar keuze
2. Werk effectief samen in een team met goede onderlinge communicatie
3. Vind een eigen rol en specialisatie
4. Lever een bijdrage volgens een Agile aanpak

Alle punten die hierboven beschreven zijn, zijn knock-outcriteria.

Dit betekent een gedeelde verantwoordelijkheid en verantwoordelijkheidsgevoel. Dit beroepsproduct is zo een voorbereiding op de grote opdracht van tijdens de project fase van de minor. Daarom werk je aan een product met een moderne microservices architectuur (complexe architectuur, zie bv. Figuur 1).

Figuur 1: Voorbeeld van een microservice architectuur — waar komt jouw uitbreiding?

Al met al moet je best veel dingen voor elkaar krijgen in drie weken. Verdeel het werk over alle teamleden en zoek naar 'twee vliegen in een klap slaan'. Kijk wat je met het toepassen van je technologieen al hebt afgedekt. Hou tot slot de gemaakte functionaliteit en architecturele aanpassing klein zoals in toelichting hieronder ook vermeldt.

Enkele opmerkingen van student na afloop van dit BP project staan onderaan. Wellicht goed om door te nemen voor een meer 'studenten perspectief'. En ook om niet aan dezelfde steen/stenen te stoten...

De knockouts zorgen voor een bepaalde minimale hoeveelheid werk die je als team moet verzetten, oftewel kwantiteit. Wellicht kun je dit i.p.v. kwanteit overigens nog beter varieteit noemen. Want in plaats van je tijd alleen steken in bv. veel functionaliteit, kun je na 1e functionaliteit beter focussen ook security analyse te doen en pipeline in te richten. Deze variateit/kwantiteit is nodig om dus een 6 te halen. Op HBO niveau geldt echter NIET 'het werkt, dus het is goed genoeg'. Eerst maak je een werkende situatie, maar daarna review en refactor je verder tot het ook onderhoudbaar, uitbreidbaar etc is. Kortom, zorg voor kwaliteit.

Voor het bepalen van de kwaliteit van het product en gebruikte proces (en dus voor een cijfer hoger dan een 6) gebruik je de CDMM beoordelingscriteria zoals elders beschreven. Naast het afvinken leg je ook uit waarom je aan de punten voldoet. E.g. toon aan dat je bewust bewkaam bent als team.

A1. Applicatie live zetten (en houden)

Dit betekent dat je

• a. De applicatie werkend krijgt op een productie omgeving (week 1 van ontwikkeling).
• b. Maar ook een (externe) staging omgeving (cq. test, QA, etc.) (week 2 van ontwikkeling)

Omdat je maar één K8s cluster hebt kun je hiervoor een Kubernetes namespace gebruiken (Lewis 2015). Bonus is als je de staging omgeving tijdelijk maakt, door deze test omgeving weer snel te kunnen stoppen en afbreken. Zodat er bv. minder load balancer kosten zijn.

A2. Toepassen technologieën

• a. Je past de onderzochte DevOps technologieën in het product.
• b. Documenteert het gebruik in README, ADR's.
• c. En/of automatiseert in shell scripts zodat ook iemand die technologie niet kent met het product kan werken.

Als technologieen alternatieven zijn, doe je PoC's en past evt. beide toe, of je kiest o.b.v. bronnen en documenteert keuze met Architecture Decision Records. Evt. clashes, problemen met technologie had je waar mogelijk voorzien tijdens onderzoek, maar documenteer je anders kort met verwijzing naar evt. openstaande issue van gebruikte technologie en/of vind work-around.

Architectuur Documentatie

Je software architectuur documenteer je in dit project typisch via C4 diagrammen en ADR's. Maar vergeet bij de C4 diagrammen de begeleidende toelichting niet. En bij de ADR's ook een inleiding.

Kijk voor opties voor ADR's nog eens terug in de les over Continuous Documentation

Er zijn geen uitgebreide verslagen nodig.

A3. Product Increment

In het product increment (figuur 2) besteed je als team — naast realisatie van nieuwe functionaliteit — ook aandacht aan het opstellen van non-functionele eisen en het hieraan voldoen via de aangeleerde DevOps aanpak. In het product increment realiseer je de volgende zes eisen:

• a. Makkelijke uitrol van je product increment, via 'niet standaard' Deployment
  • bijvoorbeeld Canary, Blue Green Deployment of gebruik van een externe tool als Helm of Ansible
• b. Aanpassing van architectuur van de applicatie, inclusief documentatie!
• c. Monitoring van hardware gebruik
  • om problemen te voorkomen en efficiency en kostenbesparing mogelijk te maken en evt. custom metric en rapportages
• d. Security aspecten, bv scan op container en/of dependency niveau
  • update van dependencies en uitrollen ervan zonder regressiefouten of voor gebruikers merkbare glitches of functionele veranderingen
• e. Automatische schaling, bv. bij meer of minder (gesimuleerde) gebruikers
• f. Fouttolerantie, design for failure en/of High Availability
  • uitvallende hardware of services erop heeft geen merkbare gevolgen (evt. Chaos engineering toepassen)

Figuur 2: Output van een Sprint is een Product increment (Bron: kiwop.com, 2020)

Toelichting/tips bij de opdracht

Het is zaak de functionele uitbreiding relatief simpel te houden. Het kan ook een prototype functionaliteit zijn, die nog verder uitgewerkt moet, mits de roadmap wel duidelijk is en evt. bugs op een 'known issues' lijst staan en workaround hebben. De uitbreiding moet dus wel enigszins realistisch zijn, en ook deels zichtbaar via UI of webservices. Ook heb je uiteraard tests geschreven voor het geautomatiseerd testen van je product increment.

De toepassing van de onderzochte technologie moet efficient zijn en pragmatisch. Ofwel: de technologie moet je helpen bij bovenstaande doelen en niet loshangen en alleen tijd gekost hebben. Denk aan het gebruik van een geautomatiseerd monitoring dashboard, toepassen van een service mesh met built in security features, of gebruik een ops tool/technieken als IaC.

Bewaar al te grote ambitie qua functionaliteit voor het project in blok 2. De kern van de opdracht is het tonen van een DevOps aanpak. Dus het is niet onoverkomelijk ook als in je functionaliteit mogelijk nog wat UI gebreken zitten, of integratiebugs. Hiermee kun je bv. ook demo'en dat dat je een rollback kunt doen...

Denk bij een architecturwijziging aan:

• één of meer nieuwe microservices toevoegen. Deze communiceren onderling of met bestaande microservices.
• Het opsplitsen van bestaande microservice in twee onderdelen met eigen verantwoordelijkheid.
• Het aanpassen van .NET microservice naar (API compatible) Java, NodeJS of microservice met een andere programmeertaal (Polyglot 'X').
• Onder Polyglot X hoort overigens naast een andere programmeertaal ook het gebruik van een andere stack, bv. Java TomEE vs Java Spring, of een aanpassing in een andere laag, bv. persistentie dus switchen van MSSQL naar MySql, PostgreSQL, een NoSQL oplossing zoals ElasticSearch of caching technologie rondom database en/of applicatie zoals Redis of RabbitMQ of Service Bus persistent of een in memory database.
• Het doorvoeren van meer Event Driven architectuur zoals aanpassen naar CQRS patroon.
• Het uitbreiden of uitsplitsen van front-end laag naar aparte microservice, een self hosted CDN aanpak of cookieless subdomain of zelfs micro frontend achtige aanpak.
• Of nog iets anders... :)

Er is bij deze opdracht GEEN externe opdrachtgever en tevens gebruik je hierbij een bestaande applicatie, zodat je zelf weinig functionaliteit/features hoeft te verzinnen. Start met een applicatie die al in containers kan draaien, zodat je deze niet van scratch hoeft op te bouwen.

In dit opzicht lijkt het op een zogenaamd brown field project, in de zin dat je NIET vanaf scratch begint, maar je moet verdiepen in een bestaande software architectuur en een deel van de details van de code en configuratie. Het gekozen project is echter wel een green field qua gebruikte technologieën en aanpak. Dus het bevat unit tests en heeft in principe een microservices architectuur. Aangeraden project is InfoSupport's Pitstop. Een alternatief is Microsoft's 'e-shop on containers' project.

Je uitbreiding moet wel uniek zijn binnen je klas. De technologieen die je hierin toepast zijn ook uniek, maar dat is bij onderzoeksopdracht als het goed is al geregeld.

Voorbeelden van functionele uitbreidingen

Kijk bij de les/workshop User Story mapping voor enkele casussen (casi?) voor een functionele uitbreiding van PitStop (met elk ook weer subonderdelen). Met een plaatje erbij van Dall-e voor een sfeer impressie. Geef wel je eigen draai aan een functionaliteit. Of verzin zelf een functionaliteit (en je eigen plaatje met Dall-e).

Studentenfeedback na afloop van de BP opdracht

Hier wat feedback/reflectie van studenten na afloop van het project, om een beeld te krijgen vanuit hun perspectief.

"De opdracht was aardig abstract en vaag in het begin. Na het stellen van vragen aan de docent was er meer duidelijkheid en tijdens de werkdagen kwamen we er zelf ook meer achter wat we moesten doen. Er was weinig tijd om alles goed te doen en hierdoor hebben we concessies moeten maken op bepaalde vlakken. Verder is werken aan een (redelijke) grote applicatie die jezelf niet hebt geschreven lastig en tijdrovend maar wel leerzaam voor later in het bedrijfsleven." - Student X

---

"Ik ben zeer tevreden met de voortgang van dit project. In het begin was het nog een beetje puzzelen wat precies de verwachtingen & eisen waren. Zodra dit bekend was bij ons waren wij al snel uit over wat we willen doen met dit project. Namelijk het toevoegen van mechanics. Al snel had ieder zijn specialiteit gevonden, in mijn geval was dat de front-end. ..." - Student Y

---

"In het begin was de opdracht heel onduidelijk. Ik begreep toen ook niet wat er nou precies moest gebeuren. Wat later kwam ik erachter dat wij gewoon heel vrij waren, zolang wij maar bepaalde doelen haalden. Op zich was dit wel een keer een fijne manier van werken, maar vind het persoonlijk prettiger werken wanneer er meer duidelijkheid is. Ook was de Pitstop applicatie aardig groot voor deze twee weken. Wij zijn in het begin heel veel tijd verloren aan het uitzoeken hoe Pitstop in elkaar zit." - Student Z

---

Bronnen

• Lewis, I. (28 Augustus 2015) Using Kubernetes Namespaces to Manage Environments, geraadpleegd 21-10-2021 op https://kubernetes.io/blog/2015/08/using-kubernetes-namespaces-to-manage/
• Long, D. Hongxin (31 juli 2023) Creating Quality Online Content in the Era of AI Geraadpleegd 5-10-2023 op https://www.deanlong.io/blog/creating-helpful-reliable-people-first-ai-content
• Kiwop (12 April 2020). Agile methodologies in web development kiwop.com. Geraadpleegd 19-12-2024 op https://www.kiwop.com/en/blog/agile-methodologies-in-web-development

Spike Guide: Onderzoek Sprint Week 6

In de eerste week van het 3-weeks eindproject (week 6) doen alle teams een spike/onderzoek sprint waarin ze één van de volgende 4 thema's onderzoeken. Deze handleiding legt uit wat je onderzoekt en hoe je dat systematisch aanpakt.

Onderzoeks Thema's (per groep van 4-5 studenten)

1. Chaos Engineering & Resilience Testing

   • Onderzoek chaos engineering principes en tools
   • Test resilience van je MSA applicatie
   • Implementeer chaos testing in je pipeline

2. Monitoring & Observability

   • Onderzoek monitoring tools en best practices
   • Implementeer logging, metrics en tracing
   • Zet monitoring op voor je MSA applicatie

3. Security in DevOps (DevSecOps)

   • Onderzoek security scanning en best practices
   • Implementeer security checks in je pipeline
   • Zorg voor secure deployment van je applicatie

4. Kubernetes & Container Orchestration

   • Onderzoek advanced Kubernetes features
   • Implementeer proper container orchestration
   • Optimaliseer je deployment strategie

Elk team presenteert hun bevindingen aan het einde van week 6 en integreert de geleerde kennis in hun MSA DevOps applicatie voor de resterende 2 weken.

Donderdag week 6

Op donderdag vindt de presentatie en review van de spikes plaats. Hier wordt ook de aanwezigheid en actieve deelname van studenten afgevinkt.

---

Handleiding voor het Uitvoeren van een Technische Spike

Een technische spike is een korte, gerichte inspanning om een nieuwe technologie of aanpak te verkennen en te valideren. Voor je DevOps-project gebruik je een spike om een nieuwe DevOps-technologie te onderzoeken en een prototype te maken, terwijl je je bevindingen direct documenteert in de gerelateerde taak op het projectbord.

1. Definieer het Doel

Begin met een duidelijk doel dat het doel van de spike definieert.

• Belangrijke Vragen om te Beantwoorden:

  • Welk probleem los je op?
  • Wat moet je weten over de technologie?

• Voorbeeld Doel:
  "Onderzoek en maak een prototype van Kubernetes voor containerorkestratie. Specifiek:

  • Zet een Kubernetes-cluster op met behulp van Minikube. Zorg ervoor dat het cluster operationeel is en meerdere pods kan beheren.
  • Implementeer een voorbeeldapplicatie, zoals een Nginx-webserver, die reageert op HTTP-verzoeken. Configureer load balancing en schaal de applicatie horizontaal naar minimaal 3 pods.
  • Integreer monitoring met behulp van Prometheus voor metrics en Grafana voor het visualiseren van CPU-gebruik, geheugengebruik en netwerkverkeer."

2. Plan de Spike

Stel grenzen en een tijdsbestek vast voor de spike. Houd het kort en gefocust (4-6 of 8 uur).

• Resultaten:

  • Een werkend prototype dat de technologie demonstreert.
  • Gedocumenteerde bevindingen en aanbevelingen in de gerelateerde taak op het projectbord.

• Scope:
  Definieer wat binnen de scope en buiten de scope van het prototype valt.

3. Voer Onderzoek uit en Maak een Prototype

Onderzoek de technologie en maak een eenvoudig prototype om het gebruik ervan te demonstreren.

a. Verzamel Informatie

• Bekijk officiële documentatie, blogs en tutorials.

b. Bouw een Prototype

• Zet een kleine, geïsoleerde omgeving op.
• Ontwikkel een minimale werkende oplossing om belangrijke functies te testen.
  • Voorbeeld: "Implementeer een eenvoudige applicatie met Kubernetes en test schaalbaarheid."

c. Documenteer Bevindingen

• Noteer observaties, uitdagingen en resultaten direct in de taak op het projectbord.

4. Analyseer en Vat Samen

Consolideer je bevindingen na het maken van het prototype.

• Vat Belangrijke Punten Samen:

  • Voordelen en nadelen van de technologie.
  • Geschiktheid voor je project.

• Geef Aanbevelingen:

  • Moet het team de technologie adopteren? Waarom wel of niet?
  • Geef indien nodig de volgende stappen aan.

5. Presenteer je Bevindingen

Zorg ervoor dat je bevindingen en prototype duidelijk zijn gedocumenteerd in de gerelateerde taak op het projectbord.

• Voeg toe:
  • Doel van de spike.
  • Belangrijkste bevindingen en inzichten.
  • Screenshots of codefragmenten van je prototype.
  • Eindaanbeveling.

Workshop User Story Mapping

Deze workshop leer je eindopdracht kennen, maar leert ook de User Story Mapping (USM) techniek kennen. Je past deze toe voor de opdracht komende twee weken. Deze techniek gebruik je ook in het eindproject om (meer) structuur aan te brengen

Figuur 1: De oorspronkelijke analogie van van Jeff Patton de grondlegger van USM (Patton, 2008)

Voorbereiding

1. Lees het verhaal over User Story Mapping en kijk de video van 6 minuten van Atalassian op de website van de Open Practice Library ().
2. Kies een van onderstaande mogelijke 'Functionele uitbreidingen van PitStop' op, of verzin of genereer er zelf
3. Verzin voor deze casus zes (6) user stories in de standaard vorm Als <gebruikersrol> wil ik <functionaliteit> zodat ik <businesswaarde>. Hierbij:

• a. Minstens drie verschillende gebruikers(rollen) of persona's.
• b. Zoek op wat een persona is in Agile (bijvoorbeeld op Wikipedia of interaction-design.org).
• c. Zorg dat je user stories uniek zijn, anders dan die van je klasgenoten.
• d. Post je 6 user stories in Slack (eindopdracht-kanaal).
• e. Na het posten van unieke user stories kun je een casus claimen voor je groep. Overleg met je team; bij discussie beslist de docent.

NB: Het is geen gegeven dat je zelf ingediende/bedachte user stories ook mag implementeren, dit gaat in overleg met team, en hier houdt de docent veto recht.

Lesinhoud

• Maak een aantekeningen/tekening (concept map)
• The 8 Fallacies
• Intro User Story Map
• Lesopdracht: Maak met je team een user Story map van je eigen casus/user stories

Een 'Concept map' van 'User Story Map'

Opdracht studenten: Maak n.a.v. lesinhoud vandaag een concept map van User Story Mapping

Relevante termen voor deze concept map zijn o.a.:

• Value slices, prioritering
• User story map, backbone
• User stories, acceptatiecriteria en backlog/code management tool

Einde les maakt de docent een foto hiervan.

User Story Map

Figuur 2: User Story map, leeg template van miro.com

Doel van de les is een goed beeld te hebben wat een User Story Map is en waar dit voor dient, en hoe je er een kunt maken voor een concrete business case (of functionele uitbreiding). Als Figuur 2 een plaatje van een USM stond hoef je zelf geen beeld meer te maken. Dit is een leeg template van op Miro, een mooie tool.

De richtlijnen op Open Practice Library geven aan minstens 3 sprints te maken. Ook de term 'MVP' in het template is belangrijk. Dit is een soort abstract 'sprintdoel'. Maar in true 'DDD practice' moet je hier in je eigen template een concrete invulling voor maken in de 'Ubiquitous language' die je deelt/gaat delen met business experts. In plaats van hen uit te leggen wat een 'MVP' is. Want dat moeten zij uiteindelijk zelf beoordelen: wat is 'viable' in hun business? Wat levert waarde op? Wel kun je eens nadenken over varianten op MVP als 'Minimally Marketable Product' (MMP) en 'Minimal Loveable Product' (MLP).

Lesvraag: Is er een vaste volgorde in het maken van MVP, MMP en MLP? Minimally Viable Product, Marketable Product en Lovable Product!?

Intro over 'Fallacies' in algemeen

Ter overpeinzing/bespreking:

“The trouble with the world is not that we know so little. It’s that we know so much, that just ain’t so.” - Mark Twain (or is it.. ;)

• Toetsvraag fallacies of distributed computing bespreken/bekijken
  • Dit was een tricky vraag. Waarom is het nuttig te denken in termen van 'fallacies'?
• Terzijde: Toetsvraag over Autonomy over authority bekijken
  • Wat betekent hierin het (Engelse) woord over?
  • Is authority hier op meta niveau, over development team, of basisniveau, de microservice zelf? Snap je het onderscheid?

The 8 Fallacies of User stories

Hier zijn 3 fallacies. Verzin met de klas er nog 5. Bekijk de lijst die de docent toont.

Invest principes

Een beetje het tegenovergestelde van deze zelf bedacht 8 fallacies is het INVEST principe van Bill Wake (Wikipedia, 2024). Deze geldt voor PBI's, maar User stories is daar een vorm van. Deze moet je hanteren in het project bij het maken van sprint planningen, of bij het nadenken van value slices in je User Story Map. Hieronder de korte definitie van Wikipedia, maar het artikel van Philip Rogers op logrocket.com is wat toegankelijker met plaatjes en meer toelichting (2018).

"..the characteristics of a good quality Product Backlog Item (commonly written in user story format, but not required to be) or PBI for short. Such PBIs may be used in a Scrum backlog, Kanban board or XP project."

Letter	Meaning	Description
I	Independent	The PBI should be self-contained.
N	Negotiable	PBIs are not explicit contracts and should leave space for discussion.
V	Valuable	A PBI must deliver value to the stakeholders.
E	Estimable	You must always be able to estimate the size of a PBI.
S	Small	PBIs should not be so big as to become impossible to plan/task/prioritize within a level of accuracy.
T	Testable	The PBI or its related description must provide the necessary information to make test development possible.

Agile: GEEN WaterScrumFall

Agile wordt wel eens foutief aangegrepen als excuus om 'gewoon aan de slag te gaan' zonder verder te plannen of na te denken. Het is belangrijk om aan de slag te gaan en niet verstrikt te raken in 'analysis paralysis'. Maar met een beetje nadenken vantevoren kun je vaak veel verspilde tijd later voorkomen. En nadenken over een Road map voor je product samen met opdrachtgever en andere stakeholders. Dit kan in de vorm van een User Story Map. Hiermee zet je ook wat 'sprint goals' uit voor de 1e paar Sprints. Dit Requirements Engineering' stukje kun je ook iteratief aanpakken, in plaats van waterfall. Zodat je niet in de val trapt van 'WaterScrumFall' zoals Jez Humble het noemt:

"After witnessing a handful of Agile transformations, oftentimes the system of Waterfall isn’t entirely replaced by Agile, merely paved over. The DevOps group might have embraced it, but the rest of the business is still operating in a “Non-Agile”, project-that-starts-and-ends, style." - Steven Prutzman (2023)

Figuur 2: Simon Brown predikt 'Just enough upfront design' (YouTube/Brown, 2022)

Naast Humble's WaterScrumfall concept benadrukt ook C4 creator ook Simon Brown's praatje 'The lost Art of Software Architecture' hoe enige INVESTering zich kan uitbetalen in tijdsbesparing later. Dit is zeker een kijktip! Je software architectuur uitdenken met het C4 model is hier een vorm van. Maar aan de domein-/functionele kant is User Story Mapping hier een goede vorm voor.'

Quiz

Test je kennis met deze korte multiple choice quiz.

Leerdoelen

Check met onderstaande leerdoelen of je de stof beheerst en User Story mapping en gerelateerde kennis in de vingers hebt.

• Je kunt uitleggen wat User Story Mapping (USM) is en waarom het belangrijk is voor projectplanning.
• Je kunt beschrijven hoe USM helpt bij het prioriteren van user stories in DevOps projecten.
• Je kunt het INVEST-principe uitleggen en toepassen op het maken van sterke user stories.
• Je begrijpt wat fallacies zijn (algemene misvattingen) en kunt misvattingen in user stories herkennen als ze worden gegeven.
• Je kunt het verschil uitleggen tussen user stories en andere Product Backlog Items (PBI’s), zoals taken, bugs en epics.
• Je kunt een backbone en value slices beschrijven in een User Story Map.

Casussen Uitbreiding Pitstop

Kies een van onderstaande casussen of maak er zelf een.

Casus 1. Klant 'in the loop'

Notificatie systeem naar gebruikers dat reparatie gestart is, of reparatie klaar, of evt. input tussentijds nodig is Image(goedkeuren reparatie a.d.h.v. kosten) (huidige notificatie systeem in het systeem is alleen naar klanten dat een onderhoudsbeurt nodig is).

Doel is vooral de response tijd van klanten te verkleinen, wachttijden verkleinen voor efficiënter gebruik van garage werkplaatsen.

Casus 2. Leenauto’s: geluk bij een ongeluk

Klanten kunnen tijdens reparatie ook een leenauto krijgen. Hiertoe moeten zij digitaal kunnen aangeven dát ze dit willen, zo ja met wat soort auto, en iets kunnen vinden over voorwaarden, inleverdatum etc.

Hierbij werkt PitStop samen met een Leasemaatschappij, en richten zich op klanten die wel eens een ‘leuke/andere’ auto willen uitproberen als ‘geluk bij een ongeluk’ als ze een (al dan niet geplande) reparatie hebben.

Casus 3. Doe het zelf avonden

Module voor inplannen en aanmelden voor informatieavonden, waarbij klanten in de garage kunnen mee sleutelen onder leiding van reparateur. Dit doet PitStop vooral voor klantenbinding. De workshops richt zich vooral op wat klanten met wat oudere auto’s, wat een aantal reparateurs leuk vindt, en ook onder klanten animo voor is. En ook vanwege moeilijk te krijgen personeel, en dat de garage in de avonduren nu toch ongebruikt is.

Casus 4. Andere eigen functionaliteit

Figuur 3: Wie is creatiever; mens of machine? Bron: Dean Long (2023)

Studentengroepen kunnen ook zelf een functionaliteit plannen, mits passend bij Pitstop, en niet te groot en niet te klein. Wees zelf creatief. Of gebruik desgewenst ChatGPT als 'assistive technology' of 'creative technology' om een suggestie. Kader deze wel met de nodige informatie. Geef hem de beschrijving huidige functonaliteit zoals Edwin van Wijk die opgeeft in documentatie in zijn github repo. Geef hem daarna de drie voorbeeld casussen/functionaleiten als eh.... voorbeeld. Maar itereer (prompt) ook wel door op wat ChatGPT je geeft krijgt. Onderstaand is een - vrij uitgebreide - start prompt die deze zaken bevat:

"Genereer een context- en opdrachtbeschrijving voor een nieuwe PitStop uitbreiding Zie de opdrachtbeschrijving en 3 voorbeelden op de minordevops.nl site. Concreet:

1. Raadpleeg de bestaande functionaliteit van Microservice applicatie PitStop over 'Garage Maintenance' op https://github.com/EdwinVW/pitstop/wiki/Application%20functionality. Vertaal dit naar het Nederlands voor de introductie (onderdeel C hieronder)
2. Raadpleeg dan de sectie "Voorbeelden van functionele uitbreidingen" op </week-7-8-beroepsproduct/opdracht-beschrijving.html#voorbeelden-van-functionele-uitbreidingen>
3. De 4e optie beschrijft daar al het 'zelf verzinnen' eventueel met hulp van ChatGPT. Voor de gewenste functionele uitbreiding van PitStop genereer je 7 zaken:

• a. een coole project naam a la "Leenauto's" of "Klant in the loop", maar dan voor een nieuwe/andere functionele uitbreiding
• b. En ook een creatieve ondertitel, hierbij zoals "Geluk bij een Ongeluk"
• c. Een Nederlandse vertaling en parafrasering van de standaard functionaliteit van PitsStop via de eerder gegeven URL op github.com/EdwinVW als context beschrijving en introductie in een h2 kopje 'Context'.
• d. Een korte opdrachtbeschrijving waarin je minstens 2 gebruikersgroepen noemt en ook wat details qua 'working objects' als 'lijstjes', 'notificaties', 'overzicht', 'start ticker' of 'go/no beslissing' en functionaliteit en domeintermen uit PitStop zoals 'reparatie', 'doorlooptijd' en nieuwe termen uit de uitbreiding (dit zijn voorbeelden, gebruik deze NIET letterlijk, tenzij ze voor de door jou bedacht uitbreiding ook toevalllig relevant zijn)
• e. Genereer ook direct een afbeelding bij de opdracht, in lijn met de andere 3 (tekening rondom het thema, met liefst hierop een of meer personen in beweging (een beetje 'in actie').
• f. Geef tot slot een disclaimer dat dit een fictieve casus is, en dat genoemde API's en partijen niet per se echt zijn.
• g. Geef de bronnen, de 2 URL's op github.com en minordevops.nl van hierboven

Geef dan aan dat je graag door itereert op wat je hebt gemaakt. "Want één prompt is geen prompt..."

Maak van al bovenstaande een duidelijke zakelijke tekst, dus GEEN marketing tekst. Schrijf actief. Wees spaarzaam met bivoegelijke naamwoorden. Bewaar marketing voor het plaatje ;). Schrijf de hele tekst in b2 niveau Nederlands en in active vorm (dus NIET lijdend e.g. met 'word/worden' of 'is/zijn' + voltooid deelwoord). Laat ook de a, b, c t/m g indeling weg uit je gegenereerde input. Dit is hierboven enkel voor het structureren van de prompt zelf. Graag 1 kopjes 1 met de Titel en dan dubbele punt en erachter de subtitel. Dan eronder direct het gegenereerde plaatje (afbeelding), liefst rechts uitgelijnd."

ChatPUG: PitStop Uitbreiding Generator

Er is per oktober 2024 ook een kant en klare 'custom GPT', een zogenaamde 'GPTs' beschikbaar. Deze bevat een uitgebreide variant van bovenstaande prompt. Hier de link naar chatgpt.com:

ChatPUG

Dit is een service aan jou, maar geeft geen garantie op dat de output goed is (e.g. 'garantie tot de deur', oftewel de plek waar jij begint met gebruiken is al GEEN ENKELE garantie meer). Dat is ter eigen beoordeling. Je kunt dit ook gebruiken 'zolang de voorraad strekt' (want Open AI kan deze feature ook betaald maken e.d.)).

Figuur 4: ChatPUG: PitStop Uitbreiding Generator

NB Een Generative AI is dus NIET betrouwbaar. En je zou het een 'slappe afspiegeling' van een echte opdrachtgever kunnen noemen. Maar het is wel een opdrachtgever met - waarschijnlijk - meer kennis dan welke 'echte' opdrachtgever ter wereld dan ook. En ook is een Genearative AI gebruiken als 'opdrachtgever' beter dan als developer zelf je eigen opdrachtgever zijn. Omdat je dan opdracht en/of requirements snel bij stelt op basis van wat makkelijk te implementeren is. Of zelf leuk lijkt.. Een bekend gezegde is "You are NOT your user". Dit gaat over UX/UI, maar is ook iets breder toepasselijk.

"User-Centred Design is surprisingly difficult. One of the biggest issues, certainly for those with no HCI or usability experience, is a lack of appreciation of how users think and work.Their assumption is that users will approach and solve problems in the same way as the designers and developers of an interactive solution." - ixDF, 2016

Maar nogmaals wel is AI en zeker LLM's (Large Language Models) structureel unexplainable en onbetrouwbaar. Daarom hieronder een belangrijke disclaimer en waarschuwing bij gebruik.

Disclaimer/waarschuwing

In essentie is het gebruik van ChatPUG niet wezenlijk anders dan bovenstaande 'handmatige' prompt gebruiken. Je hoeft nu alleen maar 'Go' in te typen o.i.d. Maar omdat de Prompt nu netjes verpakt is in een (GPTs) doosje, vergeet je wellicht dat ChatGPT fouten maakt. En dat de maker eran mogelijk ook fouten of onvolkomenheden in de prompt achter de GPTs heeft achtergelaten. Dus we raden aan om verder werken hierop en de GPTs zelf bekijken en aanpassen. En vooral zelf alle output te controleren, door te prompten en handmatig verder te werken met wat je van ChatGPT krijgt. Want als engineer kun je de gebruikte tool niet de schuld geven; je bent zelf verantwoordelijk voor je werk.

Sowieso moet je NOOIT persoonlijke gegevens of IP (Intellectual property) gevoelige gegevens in ChatGPT of andere online tools/AI's invoeren!

Ook moet je GEEN gevoelige gegevens in ChatGPT stoppen. Sowieso geen persoonsgegevens als namen of locatiegegevens. Maar onder gevoelig gegevens hoort bijvoorbeeld ook de opdracht(beschrijving) die je van de echte opdrachtgever in blok 2 van de minor DevOps krijgt.

Voor die opdracht teken je mogelijk ook een NDA (Non Disclosure Agreement). Maar ben je zonder dat ook in algemene zin een 'professionele houding' verplicht en voorzichtigheid met gevoelige gegevens. Dus vraag altijd eerst toestemming voor gebruik van AI van een opdrachtgever. Een leg deze daarbij goed uit wat je wilt doen, wat de meerwaarde kan zijn, maar ook welke alternatieven. En wat de risico's zijn. Het zelf in controle blijven, en Generative AI de (minder gevoelige) details laten verbeteren is ook vaak een betere aanpak:

"You start to rely on AI to generate content that you realistically should be ashamed to be letting a robot generate for you" (Panagis, 2024).

Hoogstens kun je als tegenmaatregel je prompt eerst zwaar anonimiseren. Of een custom AI model gebruiken in plaats van een van de tech giants. Want bij tech giants en ook in het algemeen moet je altijd bedenken dat:

"If you're not paying for the product, you ARE the product." - Andrew Lewis (Shaikh 2018)

Bronnen

• Brown, S. (13 okt 2022) The lost art of software design by Simon Brown. YouTube. Geraadpleegd 14-102-2024 op https://www.youtube.com/watch?v=36OTe7LNd6M
• Interaction Design Foundation - IxDF. (2016, February 28). Empathic Design: Is Empathy the UX Holy Grail?. IxDF. Geraadpleegd 14-10-2024 op https://www.interaction-design.org/literature/article/empathic-design-is-empathy-the-ux-holy-grail
• Prutzman, S. (Nov 10, 2023) Is your business stuck in a Water-Scrum-FALL model? medium.com.Geraadpleegd 13-20-2024 op https://medium.com/@sprutzman/is-your-business-stuck-in-the-water-scrum-fall-model-28e3c99eca6c
• Rogers, P. (Sep 10, 2024) Writing meaningful user stories with the INVEST principle Logrocket.com. Geraadpleegd 11-20-2024 op https://blog.logrocket.com/product-management/writing-meaningful-user-stories-invest-principle/
• Takane M., De Beasi, R. (April 20, 2017) User Story Mapping & Value Slicing - Create lightweight release plans by slicing value out of collections of features Open Practice Library. Geraadpleegd op 11-10-2024 via https://openpracticelibrary.com/practice/user-story-mapping
• Panagis, A. (Aug 8, 2024) Is AI A Good Starting Point? Generative AI – The Easy Way Out scalemath.com. Geraadpleegd op 11-10-2024 via https://scalemath.com/blog/generative-ai/
• Patton, J. (8 okt 2008) The New User Story Backlog is a Map jpattonassociates.com. Geraadpleegd 11-10-2024 op https://jpattonassociates.com/the-new-backlog/
• Shaikh, F. (Nov 23, 2018) If you're not paying for the product, you are the product! LinkedIn. Geraadpleegd op 11-10-2024 via https://www.linkedin.com/pulse/youre-paying-product-you-faiz-shaikh/
• Wikipedia auteurs (17 sept 2024) INVEST (mnemonic) Wikipedia Geraadpleegd op 11-10-2024 via https://en.wikipedia.org/w/index.php?title=INVEST_(mnemonic)&oldid=1246204419

FAQ Eindopdracht

Onderzochte technologie toepassen in beroepsproduct

Vraag: Ik kan mijn beoogde onderzochte technologie toch niet toepassen. Kan ik nu alsnog een voldoende halen voor het project?

Antwoord 1

Dit kan gebeuren. Want als je vantevoren al 100% wist dat de gekozen technologie ging werken dan was je gekozen technologie wellicht niet spannend genoeg...

Of je alsnog een voldoende haalt is afhankelijk van je motivering hierbij. Als je moet kort vooronderzoek de problemen al had kunnen voorzien, dan had je de technolgoie niet moeten onderzoeken. Het idee van praktisch onderzoek is wel dat je de resultaten gebruikt om om het toe te passen. Onderzoek alleen voor theorie doen we niet in dit project/vak (elders heeft dit zeker en plaats...)

Idealiter merk je aan het eind van het onderzoek al dat het onderzochte wellicht toch niet past. Soms stuit je op een bug of moeilijk te voorzien integratie probleem. Gebruik alsnog je geschreven blog post als referentie, mogelijk voor een in de toekomst. Of als genoemd/overwogen alternatief voor een wel gebruikte technologie of aanpak (denk aan decision forces diagram). Als er een bug is, geef dan een referentie naar documentatie waar dit staat. Of een issue in open source repo. Mocht deze er niet zijn, dan maak je deze natuurlijk zelf even aan, om de community al wat verder te helpen.

Als de enige reden dat je het niet toegepast is dat je hier geen tijd voor had is dit in principe niet geldig. Je moet dan althans in je documentatie nog een beschrijving geven hoe het wel toegepast kan worden. Bij wel voldoende tijd. Geef een oplossingsrichting.

Unieke technologie

Vraag: Ik wil dezelfde technologie onderzoeken als mijn teamgenoot

Antwoord 2

Dat mag niet :|. Het is de bedoeling je eigen specialisatie te hebben en niet het geehl met zijn tween te doen. Uiteraard mag je elkaar wel helpen en verder samenwerken. Als het een grote tool of framework is waar je beiden één aspect of feature van wilt onderzoekn mag dit wel. Stem dan onderling gezamenlijke zaken af en zorg dat je ook een eigen aspect. Licht deze situatie ook kort toe in de inleiding van je blogpost en verwijs naar elkaars blog posts, met een quote of parafrase waaruit de lezer een idee heeft wat het is en wat de verschillen zijn.

Deeltoetsen 2

Oefendeeltoets Dev 2/2

Edit minor 2024/'25: De oefenquizzes op specifieke pagina's zijn meer bijgewerkt en hebben minder oververtegenwoordiging van Kubernetes vragen dan onderstaande pdf's (hoewel deel van K8S vragen nog wel relevant zijn):

• Oefendeeltoets 1 (5 minuten)
• Oefendeeltoets 2

De toetsen gaan over alle stof in week 3 t/m 5 in de course.

Hieronder voor 2024 een korte samenvatting. Maar het is handiger om zelf een samenvatting te maken tijdens het doornemen/herhalen van de stof uit online materiaal, gelinkte bronnen en slides, etc.

Neem ook de leerdoelen van de weekthema's en lessen door en controleer dat je hierover de kennis ('kent') of vaardigheid ('kan') hebt, door een verhaaltje te vertellen.

Toetsstof 2024

• Micro Frontends
• C4 & Continuous Documentation
• RabbitMQ
• Continuous Delivery (incl. 12factor, IAAS vs PAAS vs DevOps three ways e.d.)
• Domain Driven Design (DDD) + Webscale + Microservices (MSA)
• Behaviour Driven Design (BDD)
• Event Driven Architectures (EDA)
• SemVer
• Orchestration/Kubernetes (etcd)
• CDMM (niet uit hoofd, maar CDMM categorieen en checkpoints hieronder wel herkennen en kunnen uitleggen/toepassen)
• SlackOps (Chaos engineering)

Week 9 - Presentaties, herkansingen, transfer naar project blok 2

• Les 1 - Eindpresentaties
• Vrijdag: Minor DevOps Workshop Maarten van Golen MCPS
• Herkansing theorietoetsen (meer info)

De volledige formele eisen, competenties en beoordeling staan in de de OWE.

De beoordeling van het beroepsproduct is in de vorm van een teampresentatie van het gebouwde product, en live deployment. Tot slot geef je hier ook de als team eerder vastgestelde self assessment op basis van het Continuous Delivery Maturity Model (CDMM). Met ook verbeterpunten en/of richtingen van evt. known issues.

Op een andere dag een meer inhoudelijke review meeting ook met het hele team, maar dan met van alle teamleden toelichting van eigen bijdrage in product en kwaliteit hiervan. Hierbij laat je ook documentatie zien zoals C4 diagrammen, Architecture Decision Records en een goeie README. Maar de mondelinge toelichting vinden we minstens zo belangrijk als 'comprehensive documentation'. Dit is vergelijkbaar met de beoordelingvorm in het grote project in blok 2. Je code moet zoveel mogelijk voor zichzelf spreken (the code IS the design). Maar gekozen technologieen moet argumentatie voor zijn (DRY vs YAGNI e.d.).

Na de presentaties is deze week ook de herkansingsmogelijkheid van theorietoetsen. En eind van de week kennismaking met de opdrachtgever.

Week 9 - Herkansings(totaal)toetsen

Als je voor één of meer deeltoetsen een onvoldoende had en je cijfer wilt ophalen, of zelfs als je al voldende had, maar je cijfer gewoon wilt ophalen, heb je op deze dag een totaaltoets voor zowel de course Dev als de course DevOps. Je moet je wel vantevoren aanmelden via iSASOsiris. Het lokaal navragen bij de docent (of evt. in iSAS).

• Oefendeeltoets DevOps 2

NB November 2023: De grote set Kubernetes oefenvragen uit Kahoots zijn ook in deze oefentoets gezet, i.v.m. lagere toegankelijkheid van Kahoots.

Vrijdag 3 november 2023 11:30-13:00 (lokaal: C1.06)

• 11:30 Lokaal open, intro en regels
• 11:35 TheorieToets Dev: Linux, C4, RabbitMQ
• 12:05 Einde/Pauze
• 12:15 Theorietoets DevOps: GitOps t/m SlackOps en DDD t/m EDA...
• 12:45 Einde/Evt. kort nabespreken desgewenst
• 13:00 Einde

DevOps (voltijd)

"Let's do some major DevOps!"

In deze multidisciplinaire minor staat de moderne techniek DevOps centraal. In een DevOps-team werken developers en beheerders samen om nieuwe features van een applicatie te ontwikkelen, en tegelijkertijd de bestaande features draaiende te houden.

Hierbij is er veel aandacht voor het garanderen van een hoge beschikbaarheid van een applicatie. We gaan kijken naar loosely coupled micro services, event-carried state transfer, Docker, Kubernetes, RabbitMQ, unit testen, acceptatie testen, build- en release-pipelines, logging, monitoring, site reliability engineering, kort-cyclisch development en natuurlijk de samenwerking tussen Dev en Ops.

De minor bestaat uit twee gedeelten: een gedeelte met theorie en een kleinschalig project waarin zowel je theoretische als praktische kennis wordt voorbereid op het tweede deel: het uitvoeren van een grootschalige project voor een echte klant waarbij je je expertise optimaal kunt benutten. Beide delen worden verzorgd door de HAN en Info Support samen, waarbij de HAN vooral in het eerste en Info Support vooral in het tweede deal de lead zal nemen in de begeleiding.

Afhankelijk van het profiel dat je volgt, wordt aandacht besteed aan de volgende onderwerpen:

• Devops
• Test driven development
• Deployment-tooling (CD/CI-tools, containers, container orchestration)
• Management en beheer (configuration management, monitoring, logging, cloud providers)
• (Domain driven) design en design patterns
• OO-programmeren
• REST
• ORM
• Web- en applicatieservers
• Versiebeheersystemen (zoals Git)
• Operating systems
• Netwerken, security en protocollen
• Proxies, load balancers, firewalls

Leerdoelen

Na het volgen van deze minor beschik je over de theoretische en de praktische kennis om een DevOps ontwkkelproject in te richten en uit te voeren in een professionele organisatie.

Aanvullende informatie

Voor meer informatie:

info@han.nl | T (024) 35 30 500 van 09.00 tot 16.30 bereikbaar | www.han.nl

Contactpersoon minor

Bart van der Wal E-mail: bart.vanderwal@han.nl

Inschrijven? Goed om te weten!

Bij populaire minoren vindt 3 tot 4 weken na het open gaan van de inschrijvingen een loting plaats áls er op dat moment meer inschrijvingen zijn dan beschikbare plaatsen. Bij de minoren waar nog plaats is, geldt daarna tot aan de sluiting van de inschrijfperiode: zodra een minor vol is, wordt deze gesloten, vol = vol.

Daarnaast geldt dat als het aantal aanmeldingen na drie weken ruim onder de norm ligt; deze minor mogelijk wordt teruggetrokken. Dus heb je interesse, meld je direct aan.

Schrijf je op tijd in!

Let op: Voor HAN studenten geldt dat zij zich, in geval van uitloten of geen doorgang van de eerste keuze NA de periode van besluitvorming (deze duurt ca. 3 weken), kunnen herinschrijven. Dit kan alleen op de dan nog beschikbare minoren die plaatsen vrij hebben.

Ook dan geldt: zodra een minor vol is, wordt deze gesloten, vol = vol.

Een goed overzicht van de HAN minoren kun je vinden in de minoren app! De app is bereikbaar via: http://www.minoren-han.nl/

Toetsing

Er zijn 2 deeltoetsen voor de DevOps course. Verder zijn er wekelijkse verplichte opdrachten.

Tot slot is er een DevOps beroepsproduct waar je met een team 2 weken aan werkt en tot slot presenteert voor beoordelaars en ook individuele bijdrage aan toelicht tijdens een review sessie.

De toetsing is de standaard projecttoetsing met een tussentijds groepsbeoordeling en individuele beoordeling en hetzelfde op het eind. De beoordelingscriterie en eisen tijdens het project volgen begin van het project.

Zie details overweging en beoordeling in de officiële OWE beschrijving.

Rooster

Er wordt vanuit gegaan dat studenten van maandag t/m vrijdag beschikbaar zijn, dus bijbaantjes of andere vakken van maandag t/m vrijdag (9.00-17.45 uur) volgen is geen optie.

De roostering zal plaatsvinden zoals bij AIM gebruikelijk: in de coursefase (MINDEC05) 4 tot 6 maal per week een dagdeel les (verder zelfstudie) en in de projectfase (MINDEP01) 40 uur per week projectwerk.

Werkvormen

• Werkcolleges
• Projectopdracht

Deze tekst staat ook op kiesopmaat.nl (dd, 1 feb 2021)

DevOps tools (tech in deze minor (logo attributie)

^{Presented by:}

Courses - Blok 1 bij AIM

• git
• Markdown
• Docker
• OpenNebula
• Kubernetes
• GiHub
• Java
• Cucumber
• RabbitMQ
• ELK
• npm
• Ansible
• DevOps schema
• DotNet core

Project - Blok 2 bij InfoSupport

• Argo
• Azure
• Azure DevOps
• React
• Java 11
• Docker
• Kubernetes
• Argo
• Micronaut (todo logo)

Logo's

DevOps lijst van concepten

Onderstaande tabel bevat een lijst van woorden, of — beter — concepten (want een concept bestaat soms uit meerdere woorden). De tabel bestaat nu vooral uit een toelichting op de checkpunten uit het CDDM beoordelingsmodel. Voor het beantwoorden van vaker terugkomende vragen zoals:

Wat wordt er bedoelt met het punt BD-203 - Build Once deploy anywhere?

Hoe dan ook, van deze termen moet je de betekenis kennen als je de minor hebt gevolgd. Alleen de uitleg in de tabel lezen is niet altijd voldoende voor goed begrip. Je moet ook de context uit de les erover kennen. Maar het kan wel een begin zijn, of manier om snel iets terug te zoeken.

Toelichting

In de DevOps minor leer je DevOps tools en DevOps concepten. Nu zijn tools meestal tijdelijk, zeker in een snel ontwikkelend vakgebied als DevOps. Maar (basis) concepten hebben een veel langere houdbaarheid, goede concepten zelfs oneindig...

Figuur 1 toont ludiek wat termen uit het wild, waar je ook veel buzzwords tegenkomt. Als DevOps professional moet je onderscheid kunnen maken tussen waardevolle concepten, en buzzwords.

In ieder geval is het doel wel dat deze termen ook aansluiten bij de beroepspraktijk en bestaande DevOps terminologie. De meeste woorden zijn dan ook Engels.

Hoewel de meeste feitelijk ook Nederlands zijn, of feitelijk deel uit maken van de internationale DevOps taal of jargon. Idealiter, als een concept een goede 'semantische' naam heeft, is ook voor ICT'ers de Van Dale soms een aardig begin. En zou je de originele betekenis/oorspring niet altijd terug moeten zoeken ('Death of the author' principe). Maar in de praktijk is vaak enkel de termn maar is dit niet toereikend heb je meer bronnen nodig om deze` goed te begrijpen (zie het voorbeeld uit figuur 3).

Figuur 2: Discussie thread op Twitter X over 'deployment' vs. 'release' (bron: Steve "ardalis" Smith 9-11-2023 op X)

Het plaatje in Figuur 2 toont een (vrij) recente discussie rondom checkpoints CO-302 uit het CDMM.

Concept/begrip	Uitleg
DevOps	Cultuur van samenwerken
Green field vs. brown field	Nieuwbouw project vs bestaand project en/of nieuwe/nieuwste technologie vs legacy technologie.
TODO	...
OA-001 Geconsolideerd platform & en technologie	Dit betekent dat je als organisatie een keuze hebt gemaakt qua technologie, meestal met erbij horende training, ervaring van huidige medewerkers. Bijvoorbeeld Java, of dotNet. Of Wordpress voor simpele corporate sites maar SiteCore voor complexere sites, en of multi-tenant opdrachten. Dit hoort bij lagere niveaus, omdat je bij microservices aanpak juist 'Polyglot X' kunt doen, zoals InfoSupport dat noemt, om programmeertaal of stack te laten varieren per microservice. Maar aanname is hierbij wel vaak weer een basis technologie als Kubernetes of Docker Swarm o.i.d die deze polyglot X mogelijk maken. Kortom: deze krijg je eigenlijk gratis bij gebruik PitStop, mits je gebruikte technologie maar documenteert.
BD-006 Enkele deployment scripts bestaan	Dit zijn wat handmatige deploy scripts die als basis kunnen dienen voor automatisering op de hogere levels (e.g. 'automate all the things').
BD-101 Polling builds	Ik ga uit dat dit polling model is waarbij in plaats van dat je 'git distribution' (bv. GitHub met GitHub Actions) recht geeft te pushen naar de (runtime) omgeving via opslaan credentials o.i.d., er een tool is op een andere plek die periodiek checkt (bv. elke minuut) of er in je Git repo of ander versiebeheer een nieuwere versie staat en zo ja dan die code pakt, build en containerized en evt. test. Merk op dat het testen van de build onlosmakelijk verbonden is met Continuous Integration in de definitie van Martin Fowler’s hiervan: "Each of these integrations is verified by an automated build (including test) to detect integration errors as quickly as possible."
BD-203 Build Once Deploy Anywhere	Dit 'BODE' principe houdt in dat je één keer een artefact bouwt, zoals een .jar, .war, of een Docker-image, en ditzelfde artefact gebruikt voor alle omgevingen: van test en staging tot productie.Je koppelt een specifieke commit aan het artefact en automatiseert tagging en versiebeheer, zodat je elke build uniek kunt traceren. Je beheert configuraties buiten het artefact via omgevingsvariabelen, in lijn met het 12 Factor App-principe. Door configuraties niet hard mee te bouwen, voorkom je de noodzaak om omgevingsspecifieke artefacten te maken, zoals spotitube-prod.war of spotitube-staging.war. Met één geteste en goedgekeurde build kun je direct deployen naar productie, zonder opnieuw te bouwen. Je standaardiseert het deploymentproces over alle omgevingen. Dit proces omvat ook geautomatiseerde database-migraties en gescripte runtimeconfiguratie-aanpassingen. Door deze aanpak creëer je een uniforme delivery pipeline die alle stappen omvat: van source control tot productie. Dit minimaliseert fouten, verhoogt de betrouwbaarheid en versnelt het deploymentproces. Met tools zoals ArgoCD en andere CI/CD-oplossingen automatiseer je het combineren van configuraties met de artefacten en rol je deze efficiënt uit naar meerdere omgevingen.
BD-204 Automatiseer meeste DB wijzigingen	Dit punt kun je bv. afvinken met het gebruik van de in de course fase (kort) behandelde Entity Framework (EF) Code first aanpak. Deze ondersteunt (automatische) data migraties (o.b.v. een 'single source of truth', namelijk de code). Maar alleen het gebruik van EF is voor dit punt echter niet voldoende. Je moet dan ook minstens één voorbeeld hebben van een daadwerkelijke en 'niet triviale' data migratie. Vaak hebben teams een standaard migratie voor het opzetten van de initiële database. E.g. een migratie van 'niets' naar iets. Of deze is evt. opgesplitst in een 'create' stuk en een 'insert' migratie, maar ook dat is nog triviaal (e.g. simpel). 'Niet triviaal' wil zeggen dat je de databasestructuur verandert door bijvoorbeeld een tekstveld om te zetten naar een foreign key naar een stamtabel (vaak hoort hier wijziging in de UI bij van een vrij tekstveld naar een dropdown, en/of back-end veld omzetten naar Enum i.p.v. String o.i.d.). Bij deze structuur wijziging moet je ook bestaande data migreren in je Up() én Down() methode. Of alles goed gaat moet je dan vervolgens testen, en typisch is handmatig schrijven van wat migratie code nodig. Voor afvinken moet je zo'n (voorbeeld van) een migratie ook kort toelichten in je CDMM of elders. Helemaal interessant maak je het als je een serie van wijzigingen hebt die je apart lokaal test, maar vervolgens op een test omgeving gecombineerde doorvoert (migreert) en test, liefst ook tegen kopie van productie, of gelijkwaardige set om te voorkomen dat je dit als eerste op productie doet en hierbij pas eventuele integratie problemen optreden. Let wel, dat dit is in een kleine project wel lastig te verwezenlijken. Dit vraagt ook een goede toepassing binnen het domein en afstemmen met de opdrachtgever. Als er voor de opdrachtgever geen winst in de nieuwe datastructuur zit, is de effort moeilijke te verkopen. Voor dit punt helpt het wel om heel vroegtijdig live gaan (in week 1 of 2) met een simpele datastructuur en ook bijbehorende test dataset. En hierop ook de opdrachtgever of andere testers laten werken om productie achtige gegevens in te voeren. Op deze test data kun je daarna je (niet triviale) migratie kunt doorvoeren.
BD-206 Gescripte config wijzigingen	Als je config wijzigigingen gescript hebt, kun je dit script testen op een test omgeving, en checken dat config wijzigingen doen wat je wilt, voordat je het op productie ook doet. Voorkomt fouten en zorgt voor herhaalbaarheud. Versnelt ook het proces, omdat je niet handmatig stap voor stap de config wijzigingen uit moet voeren, of op productie foutgevoelig met een editor config aanpast.
IR-402 Cross Silo analysis	Dit punt uit Information & Reporting is geavanceerd en vereist de nodige domeinkennis en overzicht van de organisatie. Dit punt is gelieerd aan Conway’s Law over de link tussen de structuur van de applicaties/microservices en de structuur van de organisatie die de applicaties gebruiken/laten bouwen. Basis eis is dat je meerdere microservices draait die Kan je systeem ook metrieken rapporteren waardoor je verbanden tussen verschillende organisatie onderdelen (silo's) kunt zien? Dat je organisatieonderdelen onderling kunt vergelijken op bepaalde aspecten? Zulke informatie geeft voor een bedrijf vaak optimalisatie mogelijkheden. Zoals InfoQ aangeeft: "Moving to expert level in this category typically includes improving the real time information service to provide dynamic self-service useful information and customized dashboards. As a result of this you can also start cross referencing and correlating reports and metrics across different organizational boundaries,. This information lets you broaden the perspective for continuous improvement and more easy verify expected business results from changes."
CO-201 Multidiscl. team (betrekken DBA, CM)	In plaats van een aparte developer team en operations team (die CM=Configuration Management) doen. En wellicht ook aparte DB admin of admins, plaats je iedereen in het team, zodat mensen vroegtijdig(er) overleggen (shift left), en wijzigingen niet tijdens deploy aan het eind vastlopen, omdat een probleem bovenkomt die iemand van andere discipline had kunnen zien aankomen. Denk bijvoorbeeld ook aan security mensen (e.g. van DevOps naar een DevSecOps team).
CO-202 Component eigenaarschap	Hoewel het hele team verantwoordelijk is voor alles, is het wel goed om een of enkele mensen eigenaar te maken van een component. Denk bij een component bijvoorbeeld aan een microservice. Dit sluit ook aan bij de 'Pizza rule' uit DevOps (NetFlix): het team verantwoordelijk voor 1 microservice moet (bij onderhoud) aan 1 pizza genoeg hebben. Dus 2 of 3 mensen?
CO-203 Handelen op metrics	Studenten vraag: > "[...] Hoe zouden wij dit moeten uitvoeren in dit project? We hebben niet echt gebruikers waarop we kunnen reageren." Antwoord: Als er geen echte gebruikers zijn, moet je deze faken. Sowieso is het een best practice om een test dataset aan te leggen in een database of andere data storage. Ook om je requirements duidelijk te krijgen, en gekozen abstracties te testen. Dit onder de noemer “Sometimes three good examples are more helpful to understand the requirements than a bad abstraction.”' - Peter Hruschka (domainstorytelling.com, 2023).
CO-206 Decentrale besluitvorming	Agile is naast cross-functional en collaberatief ook niet hiërarchisch (Wrike, z.d.). Er is dus NIET één baas, voorzitter of product owner die alles beslist. De product owner is weliswaar verantwoordelijk voor houden van overzicht van het product en WAT erin komt. Maar HOE je dit realiseert besluiten de teamleden samen, en voor decentrale besluitvorming betekent dit dat een beslissing idealiter bij de persoon die de meeste relevante kennis heeft, qua domein en/of technisch (zie ook <a href="CO-202>CO-202 Component eigenaarschap). Een probleem kan ook om 3:00 's nachts optreden, en idealiter kan er op dat moment ook een beslissing genomen worden om het op te lossen, zonder 'de baas' uit bed te bellen om een beslissing te nemen over wel/niet release van een fix en evt. release. Wel houdt CO-206 in dat je ook samen een proces opzet, waarbij je met hele team later bv. een post mortem over zo'n issue houdt, en meer structurele fix inplant, na een nachtelijke work-around/bugfix, en bv. ook je (DevOps) proces optimaliseert om kans op een soortgelijke fout later te verkleinen. Terzijde: er is ook een interessante link tussen 'decentral decision making' en het concept 'epicrocacy' zoals beschreven door Jason Brannon in zijn 'scherpe' boek 'Against democracy' (2017, voor de duidelijkheid: geen ICT boek :P).
CO-301 Dedicated Tools team	Er is een apart team in het bedrijf dedicated gericht op DevOps tools inrichten, beheren en onderzoeken. Sinds circa 2022 kwam dit principe ook onder de noemer Platform Engineering naar voren (State of DevOps, 2023). Dit houdt in dat er één apart team verantwoordelijk is voor het 'platform' waarop de IT draait. Dit lijkt op een soort interne 'Platform as a Service (PAAS)', maar sommigen spreken liever van 'Platform as a Product' (taloflow.ai, 2024, teamtopologies.com, 2021). Of pessimistisch (of realistisch?) gezegd: Het team van 'DevOps tools experts' is zo druk met hun werkzaamheden, dat ze geen tijd meer hebben voor ontwikkelwerkzaamheden in regulier teams. NB: Merk op dat het woord 'apart' een beetje indruist tegen de 'DevOps cultuur' van 'break down silo's. En een 'specialistisch' team gaat ook tegen het multi-disciplinaire karakter van DevOps teams, waarbij ook juist een Polyglot X aanpak mogelijk is. Dus dat elke deelapplicatie/microservice een andere techniek heeft (the right tool for the right job). Ook bij polyglot X is echter het (container) platform meestel wel geconsolideeerd (dat wil zeggen er zijn regels over, zodat alle teams in het bedrijf dezelfde taal en frameworks gebruiken). Dit is bijvoorbeeld Kubernetes en de de DevOps aanpak geeft veel nieuwe andere tools en technologie die aansluiten bij DevOps zoals Git, Kubernetes, Ansible, Argo. Iedereen kent de basis, maar een expertise team op dit gebied levert voor grotere bedrijven wel winst op.
CO-302 - Deployment loskoppelen van release	Hoewel ICT'ers de termen 'release' en 'deployment' vaak als synoniemen gebruiken, geeft dit CDMM checkpoint aan dat een volwassen DevOps deze 2 van elkaar los kan koppelen. Een release is een set samenhangende wijzigingen, een product increment in Scrum termen. Het 'increment' samen met het product samen leidt tot een potentially shippable product. Een nieuwe versie van je applicatie. Het 'potentially' stelt eisen aan dat de nieuwe features (voldoende) bugvrij zijn, en samenhangend. Maar het laat dus vrij of je de nieuwe versie ('release') daadwerkelijk beschikbaar stelt voor naar eindgebruikers ('productie'). Dit is dan een 'business beslissing'. Het loskoppelen heeft twee varianten. Je kan er de nieuwe release alleen deployen op een (accceptatie test omgeving, en dan beslissen er op door te itereren door nieuwe inzichten die je krijgt. Je kunt ook via bv. een 'dark release' of 'feature toggle' de onderliggende code van de functionaliteit wel degelijk opleveren, maar deze nog niet activeren (feature toggle) of bereikbaar maken (dark release). Het 'loskoppelen' gaat erom dat je dit makkelijk in kunt stellen, zodat de twee concepten 'release' en 'deployment' duidelijk van elkaar gescheiden zijn. Zie figuur 1.
OA-001 Geconsolideerd platform & technologie	Een bedrijf kiest voor een enkele technologie, of combi van bij elkaar passende technologieen (e.g. stack) voor alle applicaties. Bv. Windows (platform) en GEEN macOS. Of programmeertaal/ontwikkelomgeving .NET. Dus een medewerker kan dan niet bij een nieuwe opdracht opeens Java kiezen, ook al is er wellicht een library in Java die al 50% van de requirements vervult, die er (nog) niet voor .NET is. En een developer kan ook niet een Elixir project kiezen voor opdracht waar dit past (maar hoge concurrency eisen bv. proberen te voldoen via gebruik RabbitMQ). Of "Geen MySQL, want "we hebben een SQL Server licentie, en 3 DB admins met MS DP-300 certificaat. Dit is erg pragmatisch en komt dus veel voor, want geeft standaardisatie, maar is tegelijkertijd wel de tegenhangen van de Polyglot X aanpak die DevOps in principe mogelijk maakt (merk op dat Polyglot X zeker niet verplicht is bij DevOps).
CO-402 No rollbacks (always roll forward)	Dit checkpunt vereist wat zelfstudie, want dit punt vraagt wat verdieping en kun je over discussieren. Lees bijvoorbeeld kritische beschouwing van Jim Bird over roll forward en andere DevOps best practices of misconcepties (Bird, 2011). Dit punt moet je discussieren en toelichten als je dit punt wilt afvinken in je CDMM, met liefst beschrijving van eigen concrete situatie in je software ontwikkeltraject waar je een roll forward deed, of juist automatische rollback kon doen, en hoe dan.
OA-102 API-gestuurde aanpak	De microservices praten met elkaar met (geconsolideerde) interface, bv, RESTful API's of service bus (of RabbitM!). Dit maakt PolyGlot X aanpak mogelijk, niet alle applicaties hoeven bv., meer in Java (voorloper aanpak voor innovatie is andere taal op zelfde Virtual Machine zoals JVM (met Java, Kotlin, Scala)) of .NET met C#, F# of VB.NET voor CLR.
OA-203 Configuration as Code (CaC)	De (software) configuratie van een applicatie staat OOK in versiebeheer, zodat je het verloop hiervan over de tijd kunt zien en terugvinden (ivm auditing ook: wie heeft op 28 oktober deze setting aangepast?). Evt. kan configuratie hierbij in aparte repository staan dan code in verband met security, waar andere mensen (dan developer) verantwoordelijk voor zijn (denk aan connection strings die anders toegang tot productie db zouden geven (niet confogm AVG/GDPR)). Denk bij configuratie aan welk OS, welke software/middleware, maar ook zaken als welke software instellingen zoals IP adressen van machines). Verder kun je naast configuratie van applicatie zelf, ook denken aan configuratie van bijvoorbeeld een deployment pipeline die je applicatie build uit de code en oplevert naar een (runtime) omgeving. CaC vraagt dus de 'scripted pipelines' van Jenkins 2.0, de oude 'via UI' manier in Jenkins 1.0 geldt niet als CaC (maar wellicht kun je via UI ingestelde settings wel exporteren en dan inchecken in VCS en daarna hiermee verder werken). Hier is verder veel online over te vinden.
OA-205 Modules omzetten naar componenten	De monoliet is al wel modulair opgezet, de bestaande modules hang je in eigen microservice, bv. met eigen Docker container, zodat je ze los van elkaar kunt gaan opleveren. Heeft als potentieel probleem wel 'testing pyramid of hell'
OA-301 Volledige component gebaseerde architectuur	Next level van OA-205, met het 'strangle pattern' is een evt. oude monoliet (volgens 'monolithFirst' aanpak van Fowler) volledig omgezet in microserves
OA-302 Strict API based approach or message bus/broker	TODO: Beschrijven i.v.m. missende focus op gebruike message bus/broker en/of event driven aanpak in originele InfoQ artikel.
OA-303 Graph business metrics uit applicatie	Naast de standaard metrieken die bv. Grafana kan geven van cpu, geheugen en bandbreedte gebruik heb je ook custom metrics gemaakt, die ook voor de business waarde hebben. En die frequent geupdate zijn, zodat business hierop ook kan sturen, en experimenten kan doen qua business logica in de markt en zien hoe deze uitpakken (bv. A/B testen).
BD-104 1e stap naar standaardisatie deploys	Meerdere teams gebruiken zelfde stappenplan voor deploy (bv. geconsolideerde keuze is SQL Server, en men switcht van .bak bestanden naar nieuwe BacPac) en/of gebruikt Azure Cloud voor alle producten.
BD-206 Gescripte config wijzigingen	De bij BD-203 genoemde config (bv. systeemvariablen) test je ook op een test omgeving VOORdat je op productie test door een script te maken die je kunt uitvoeren. Sluit aan bij 12factor principe van one off Admin processes. Onder config wijzigingen kun je overigens naast omgevingsvariabelen ook andere config denken, zoals update van dependency bij security issue, maar bv, zelfs aanpassingen aan het database schema zien (SQL DDL scripts). In een ORM gebruik je hiervoor bv 'db migration scripts/code.
BD-401 Build bakery	Dit is een heel breed onderwerp, wat teruggaat naar de begintijd van Virtualisatie, met Amazon Machine images, maar wat feitelijk volwaasen is gemaakt door container registries en runtimes a la, waarbij je bv. een door veel applicatie hergebruikte base image hebt, met aparte config voor de specialisatie ervan (e.g. Dockerfile met CMD apk install tool-x). Vink dit punt NIET zomaar af als je Docker gebruikt, maar verdiep je in bron en argumenteer zelf waarom je hieraan voldoet.
BD-402 Zero touch continuous deployment	Geen handmatige inmenging meer nodig voor een deploy, een commit leidt automatisch tot nieuwe versie op productie, idealiter met gradual release maar dat valt hier niet bij, via de pipeline (mits linting, unit tests, automatische integratie tests etc. ). Merk op dat in projecten waar nog handmatige tests zijn dit niet altijd gewenst is, maar idealiter gebeurde dit plaats op test omgeving, en kun je via BODE principe (BD-203) risicoloos ermee naar productie via commit op main.
TV-201 Automatische component test (geisoleerd)	Geautomatiseerde integratie en/of UI test van een microservice, waarbij gebruikte dependent microservice gemockt zijn
IR-101 Meet het proces	InfoQ heeft bij het 'measure the process' stuk het voorbeeld van een aantal metrieken rondom het software ontwikkelproces zoals cycle-time of delivery time. Het proces meetbaar maken betekent dat je weet hoe lang een release duurt, dus het runnen van de pipeline. Of dat je weet hoeveel bugs er open staan op een component. En wat de gemiddelde fix tijd van een bug is. Of hoeveel bugfixes er in een release zitten. Het uberhaupt in kaart brengen is het begin van ook weten waar bottlenecks of probleemgebieden zijn in je software landschap. Waar zitten de moeilijke onderhoudbare 'big ball of mud' monolieten. Of welke modules leveren vaak bugs op. En voor de release van welke service moet je altijd een paar developers klaar hebben. Meet het proces gaat echter alleen over het inzichtelijk hebben van zulke informatie, en nog niet over het verbeteren op basis hiervan.
IR-201 Gedeeld informatie model	Dit punt is op twee manieren op te vatten. De eerste, zoals binnen InfoQ's artikel vooral bedoelt gaat het over het informatie model van het software ontwikkelingsproces zelf. Zoals je ook metrieken voor bepaakt onder IR-101. Dit informatiemodel gaat over releases, indienen van bepaalde requirements, deze formuleren als requirements en hier bijvoorbeeld unit tests of acceptatie tests voor opstellen. Ook het indelen van de software in modules of componenten (=typisch microservices), en dan de namen van deze microservices of modules. Dit is dus op meta niveau ten opzichte van het 'domeinproces' waarover de ontwikkelde applicatie gaat, en waarop ook een informatiemodel van toepassingen is. Dit gaat dan om entiteiten en hun eigenschappen zoals zichtbaar in het domeinmodel. Om aan te kunnen geven hoe het release proces verloopt, welke feature net is gereleased, of voor een komende release gepland is, of hier nog issues voor open staan, of om terug te zoeken op welke omgeving het staat, of wie dit daar gedeployed heeft, moet iedereen (of in ieder geval de juist mensen) dit terug kunnen halen uit bijvoorbeeld een code mangement systeem, een log van gedraaide pipelines, of overzicht van containers en hun versies in een container registry. Voor dit punt kun je ook denken aan het informatiemodel van de applicatie en van het domein en diens subdomeinen zelf. Denk hierbij aan DDD's ubiquitous language. Dit is een door iedereen gedeelde lijst van woorden, e.g. een 'alomvertegenwoordige taal' in een organisatie. Deze gebruiken dus zowel business mensen tijdens het werk, als developers in hun broncode (class names, foldernamen, variabele namen, methodenamen etc.). Dit houdt in dat de hele organisatie bedoelt hetzelfde met een bepaalde term. Of als één term meerdere dingen betekent in verschillende contexten, zoals bijvoorbeeld verschillende afdelingen van het bedrijf, dan zijn deze (bounded) contexts duidelijk en bekend, en is voor elke context een definitie van de term. In een microservice architectuur heeft idealiter elke microservice eigen opslag (autonomy over authority) en synchroniseer je geen informatie direct via de database (maar heb je validation layer (DDD))
IR-202 Traceerbaarheid ingebouwd in pipeline	Traceren of 'tracing' gaat over het achterhalen van fouten/bugs in software. In een DevOps omgeving denk je dan eerder aan fouten in productie (of staging), i.p.v. nog lokaal (development) waar je deze fouten kunt debuggen in je IDE. Het gaat hierbij ook vaker om integratie bugs.
IR-301 Graphing-as-a-service	Er is een aparte service die op aanvraag en redelijk gestandaardiseerd grafieken kan aanleveren. In plaats van dat elke applicatie dit intern zelf doet, en elk op eigen wijze.
IR-303 Report trend analysis	Gelieerde aan IR-402, maar in plaats van Cross Silo kan in ieder geval binnen een Silo/service/organisatie onderdeel grafieken of gegevens worden opgevraagd, maar dan wel over een bepaalde tijd, om verloop te kunnen analyseren (trend).
IR-401 Dynamische grafieken en dashboards	Spreekt hopelijk voor zich? Realtime of i.i.g. 'near realtime' data uit productie op dashboard scherm ook bereikbaar voor business mensen. Bv. het aantal openstaande issues op schermen in team work garden, maar wellicht ook direct inzichtelijk maken als/dat server geheugen volloopt, of tonen van aantal mensen momenteel in check-out scherm van webwinkel (of vergelijkbare 'custom metric' in ander/eigen domein).
OA-401 Infrastructure as Code (IaC)	Deze term is te vergelijken met Configuration as Code (CaC OA-203), alleen in plaats van de software configuratie beschrijf je nu de hardware configuratie als code. Oftewel: op welke infrastructuur gaat je software precies draaien. Dus welke CPU, hoeveel geheugen, hoeveel harde schijfruimte, maar bv. ook of bandbreedte. Voor echt hardcore IAC hoort hier ook het type hardware nog bij, zoals heb je Intel processor nodig, of AMD of een Apple M1 o.id., is je harddisk een (snelle) SSD (solid state disk) of ouderwetse magenetische schijf. Typisch gezien doe je dit bij Cloud providers, die dit soort hardware ook kunnen leveren. De precieze opties die je hebt hangen dan ook af van de Cloud provider die je gebruikt. Verschillende cloud providers hebben ook verschillende naampjes voor de machines. Er zijn ook wel speciale IaC tools/talen om meer generiek een config in te schrijven, zoals Cloudformation voor AWS (Amazon Web Services) of Azure Resource Manager (ARM, niet te verwarren met de (RISC) processor met hetzelfde acronym). Deze geven dus een soort abstractielaag om niet alle details te hoeven kennen, en minder afhankelijk te zijn van wijzigingen in hardware die er zijn. En er is zelfs cloud agnostische Terraform (hoewel de machine namen in deze config taal vaak alsnog cloud specifiek zijn). Vergeet ook niet dat je voor IaC ook tools moet hebben die deze config moeten kunnen uitvoeren (anders is het slechts een 'spec', geen code). Dit punt zit dus erg aan de OPS kant, en kun je NIET zomaar afvinken, maar moet je je echt verdiepen in IAC. Als developer wil je je vaak je software juist enigszins onafhankelijk maken van onderliggende hardware details, maar uit handen laten nemen door in te stappen op een 'X As a Service model'. Als er speciale eisen zijn, zoals gebruik GPU's i.p.v. CPU's voor bv, grafische toepassingen, of machine learning kan dit echter niet altijd meer, of als je heel grootschalig gaat werken kun je je kosten besparen als je dit zelf doet. Een goede aanzet voor dit punt, om het 'half af te vinken' kan wel zijn dat je in Kubernetes horizontal podscaling instelt ën je containers draait met zogenaamde Quality of Service instellingen hebben, dus echt vermelden van hardware karakteristieken zoals minimale CPU snelheid en harddisk ruimte.

CDMM Q&A

Q: Kunnen wij het punt CO-305 - Continuous improvement al behalen door retrospectives uit te voeren over ons individuele handelen en onze processen? A: Niet helemaal, je moet naast probleem analyse (retro), ook verbeterpunten concreet formuleren (denk Transfer uit STARRT methode) en ook doorvoeren in opvolgende sprints (of kunnen uitleggen waarom een voorgenomen improvement in de praktijk er toch niet van kwam) Q: Wat bedoelen jullie met het punt BD-207 - Standaard proces voor alle omgevingen? A: Dit gaat vooral over het deploy proces. Als antwoord een schets van een situatie waarin een team een verschillend proces per omgeving hanteert. Zonder standaardisatie verloopt het deploymentproces verschillend per omgeving:

- Op de developmentomgeving gebruiken teamleden handmatig commando’s om de app te deployen.
- Voor staging upload je bestanden via FTP.
- Production vereist speciale scripts die uniek zijn voor de live-omgeving.

 Deze verschillen leiden tot fouten, zoals configuratiemissers, vergeten updates, of inconsistente versies tussen omgevingen.

Q: Voor BD-302 - Meerdere build machines: mag mijn teamgenoot die runnen op zijn VPS? A: Ja

Q: TV-302 - Performance test? Wat moeten wij performance testen? En hoe uitgebreid? A: Performance kritieke onderdelen. Early optimisation is the root of all evil. Zei eens iemand. Maar er kwam nog wat achteraan. En performance is ook een feature, die veel geld of andere waarde (minder verspilde tijd) kan opleveren in sommige domeinen. Dus zo uitgebreid als nodig is om probleem in kaart te krijgen, maar mits het past in jullie tijdsbesteding. Stem af met opdrachtgever. Je moet echter ook wat onderzoek doen in het project, je bent met een heel team. Dus je kunt best goede tools en/of aanpakken onderzoeken. Bv. een profiler in je IDE. Of een load test tool als K6 voor webapps.

Nog over faken data: fake it till you make it

In kader van het 'shift right' is het goed om al tijdens ontwikkelen vooruit te kijken naar relevante metrics die je kunt verzamelen en waarop de business kan handelen. Dit is wel eens beschreven als een soort 13e factor als uitbreiding op de 12factor app principles. Namelijk als 'Telemetry' (namelijk in het boek van Kevin Hoffman (2016))

I like to think of pushing applications to the cloud as launching a scientific instrument into space. [...] If your creation is thousands of miles away, and you can’t physically touch it or bang it with a hammer to coerce it into behaving, what kind of telemetry would you want?

Bronnen

• Hoffman, K. 1st edition, april 2016. Beyond the twelve factor app - Exploring the DNA of Highly Scalable, Resilient Cloud Applications. Oreilly, Pivotal. Geraadpleegd op 23-10-2023 op https://www.cdta.org/sites/default/files/awards/beyond_the_12-factor_app_pivotal.pdf
• Hofer S. & Schwentner H. domainstorytelling.com (2023) Domain Storytelling: Quick-Start Guide - Feeling lost? Workplace Solutions Geraadpleegd 23 oktober 2023 op https://domainstorytelling.org/quick-start-guide#feeling-lost
• Bird, J (2011) Rolling forward and other deployment myths. DZone. Geraadpleegd laatst op https://dzone.com/articles/rolling-forward-and-other
• Smith, Steve "ardalis" (9-11-2023). Deployment vs Release. X Geraadpleegd 13 nov 2023 op https://x.com/ardalis/status/1722728350437757320
• Brannon, J. Against democracy Boekbeschrijving geraadpleegd 23 oktober 2023 op https://www.bol.com/nl/nl/p/against-democracy/9200000075205551/

Minor chartering

Door: Bart van der Wal, zomer 2021

Het toepassen van The Agile Inception Deck (AID) op de Minor DevOps zelf.

NB Een workshop van InfoSupport behandelt AID ook en in het project in blok 2 ga je dit ook gebruiken.

1. Describe why we are here

To do some major DevOps!

De DevOps beweging bestaat nu zo'n 10 jaar, en je ziet adoptie in groot deel van ICT bedrijfsleven, maar bij AIM (en voor zover mij bekend andere HBO ICT's) was er nog geen dedicated vak hierover, maar sijpelde het slechts hier en daar het onderwijs binnen via gebruik tools en om sneller aan de slag te kunnen.

2. Create an Elevator Pitch

"Let's do some major DevOps!" :)

In deze minor leer je moderne DevOps technieken en concepten om te kunnen innoveren en waarde toe te voegen in bedrijven. DevOps ligt in het verlengde van de Agile beweging, en geeft zeer veel tools, en best practices om als klein bedrijf een applicatie op schaal te draaien en om als groot bedrijf je complexe bedrijfsprocessen te modelleren, en te voorkomen dat tijd verloren gaat aan ICT complexiteit (accidental complexity) zodat je de gewonnen tijd kunt steken in het (via ICT) verbeteren van je bedrijfsvoering (inherente complexiteit).

3. Design a Product Box

Met het voltooien van een minor DevOps tijdens je studie ben je meer waard voor bedrijven en kun je sneller aan de slag in het ICT werkgebied. Interessante werkgevers hebben een hele categorie vacatures zals 'DevOps Engineer' en 'Site Reliability Engineer' (SRE), waarvoor je in aanmerking komt.

4. Create a NOT List

In scope	Out of scope
Git	Cloud provider specific services/tools
Docker	Programming basics (voorkennis)
Kubernetes	Infrastructure as Code (Terraform e.d.)
Prometheus/Grafana	Service mesh (eigen onderzoek)
Linux	Basic computer skills (voorkennis)
DevOps principles	Business part/LEAN etc.
CNCF & DevSecOps basics	Ansible, Puppet, Chef, eBPF

Extra: Ideeen Ops workshops 2022

• Package manager
• Running unit tests (writing Cucumber specs?)
• Managing DevOps
• CM: Ansible/CM

5. Meet Your Neighbors

Core team is jij, mede studenten, docenten AIM, docenten InfoSupport.

Buren/dependencies:

• aimsites.nl
• StackOverflow
• InfoSupport medewerkers
• Stackoverflow
• Academic license cloud services/trials

6. Show the Solution

Zie DevOps Tech.

7. Ask What Keeps Us Up at Night

• Is het te makkelijk?
• Is het te moeilijk?
• Operationele problemen

8. Size It Up

• 9 weken courses
• 9 weken project

9. Be Clear on What’s Going to Give

What's going to give? Nou in deze volgorde (tussen haakjes korte toelichting)

• 1. scope (minimale diepgang per onderwerp)
• 2. quality (6 niveau ligt vast)
• 3. time (vast, 9 weken)
• 4. money (n.v.t. behalve 'tijd is geld')

10. Show What It’s Going to Take

• Minimaal 20 studenten (max. 30)
• Een PluralSight account voor elke student
• Een voldoende krachtige laptop om lokaal
• VS Code, IntelliJ
• Nieuwsgierigheid, pragmatische insteek en een kritische blik
• Flexibiliteit en uren (40 uur per week, geen bijbanen)
• Goede en tijdige onderlinge communicatie
• Tijdige feedback en input