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:
- 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