Weekopdrachten
Er zijn in totaal 5 wekelijkse opdrachten:
- GitOps - Werk in tweetallen
- Containerization - De Werkparen Wijzigen
- CD - Flexibele Paren
- RabbitMQ - Flexibele Paren
- Orchestration - Groep van 6 mensen
Werkwijze
Denk aan onderstaande punten bij het maken van de weekopdrachten:
- Vorm telkens duo's of grotere teams en wissel, afhankelijk van de weekopdracht
- Gezamenlijk backlog/issues, samen opstellen/verdelen
- Kleine frequente commits (en commit op de gemaakte issues)
- 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:
- Docent bepaalt de duo-indeling en wijst C# of Java toe.
- Taalvereiste:
- 50% van de paren werkt in Java.
- De andere 50% werkt in C#.
Week 2
- Decentrale Besluitvorming:
- Studenten mogen zelf nieuwe duo's vormen en taal kiezen.
- Als dit goed gaat, mogen ze dit CDMM-punt 'CO-206 Decentrale besluiting afvinken.
- Bij problemen (geen partner vinden, overblijvende studenten) bepaalt docent bij de volgende week opdracht de indeling weer.
Figuur: Decentrale besluitvorming (afbeelding gegenereerd door ChatGPT)
Decentrale besluitvorming komt neer op het principe dat er GEEN dictatuur is, of strikte hiërarchie, met 1 leider die alles beslist (=centrale besluitvorming), en ook GEEN democratie, waarin de meerderheid beslist (stemmen), maar dat voor een beslissing diegene deze beslissing neemt die hierover het meeste weet, of de beste argumenten heeft. Dit klinkt logisch, maar vereist veel onderling vertrouwen, kennis van elkaars vaardigheden en expertises (T-shaped professionals), en een veilige omgeving waarin iedereen zich kwetsbaar durft op te stellen en er geen 'blame' cultuur is.
Dit past bij het CDMM Advanced niveau waar teams de competentie en het vertrouwen hebben om verantwoordelijk te zijn voor wijzigingen tot in productie. Het gaat over het vinden van de meest expert in een bepaald onderwerp, wat ook hoort bij de 'T-shaped professional' (bron: InfoQ - Continuous Delivery Maturity Model).
Merk op dat voor eigen teamindeling over decentraal beslissen gaat op meta niveau of proces niveau, maar dat beslissingskennis ook vaak harde technische kennis is over ICT of het gebruik van DevOps tools, of — even harde — kennis over het domein; the 'inherent complexity' die vaak decentraal aanwezig is. Bijvoorbeeld: de Android developer die beslist over de juiste lifecycle methods voor een activity, de DevOps engineer die de optimale Kubernetes resource limits bepaalt, de database expert die kiest voor de juiste indexing strategy, of de security specialist die de authentication flow ontwerpt. Of domeinkennis: de monteur die weet dat een 'kleine beurt' bij PitStop eigenlijk altijd een oliefilter vervanging betekent, of de receptionist die begrijpt dat een 'APK keuring' niet hetzelfde is als een 'grote beurt' en dus andere tijdsinschattingen en prijzen heeft.
Zie ook DevOps concepten voor meer details over dit CDMM concept.
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 donderdag af zijn, waarbij de docent in de les steekproef doet. 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.
Je hebt dan vrijdag nog om met de feedback aan de gang te gaan. Maar daar is vaak ook al huiswerk voor de les van de maandag. 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
- **Klopt gegeven self assessment cijfer?**: [ ] Ja | [ ] Nee, wij vinden 0|2|4|6..
- **Is het al voldoende (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
- **Klopt gegeven self assessment cijfer?**: [ ] Ja | [ ] Nee, wij vinden 0|2|4|6..
- **Is het al voldoende (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
- **Klopt gegeven self assessment cijfer?**: [ ] Ja | [ ] Nee, wij vinden 0|2|4|6..
- **Is het al voldoende (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
- **Klopt gegeven self assessment cijfer?**: [ ] Ja | [ ] Nee, wij vinden 0|2|4|6..
- **Is het al voldoende (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
- **Klopt gegeven self assessment cijfer?**: [ ] Ja | [ ] Nee, wij vinden 0|2|4|6..
- **Is het al voldoende (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