Werkwijze bij DevOps weekopdrachten

Denk aan onderstaande punten bij het maken van de weekopdrachten

  1. Gezamenlijk backlog/issues in GitLab, samen opstellen/verdelen
  2. Kleine frequente commits (en commit op de gemaakte issues)
  3. Schrijf op het eind als team samen een self assessment van jullie werk a.d.h.v. het CDMM
  4. Lever in via assignen issue aan docent (+een git tag)
  5. Vorm telkens duo's of grotere teams en wissel, afhankelijk van de weekopdracht

Hieronder verdere uitleg per punt.

1. 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 GitLab een planning bord aan met ook achterliggende issues aan in de reposiotory en verdeel de taken onderling (assign) op een logische manier (ieder ongeveer de helft).

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 #, bv. Fixt issue #23 domeinterm nu 'pink' ipv 'piglet'.

2. 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

3. Self assessment

  1. Schrijf SAMEN een korte reflectie en voeg toe in je README of je je aan de best practices hebt gehouden (hierboven genoemd)
  2. Bekijk een aantal relevante punten uit DevOps maturity model (CDMM), Code én naam/korte beschrijving checkpunt, en geef aan of je hier aan voldoet en beoordel op welk niveau je staat in. Waarom niet, en noem verbeterpunten (bv. CO-101, CO-105, CO-205, CO-003, OA-201, OA-202, BD-103, TV-001)
  3. Zijn er nog meer punten relevant? Geef waar nodig toelichting waarom jullie wel voldoen of niet, en welke punten verbetering behoeven en welke nog niet relevant waren
  4. Tag de versie met git als het af is met een 'major versie' 1.0.0 en push alles. Maak een issue getiteld 'Nakijken' aan in GitLab en wijs deze toe aan de docent.

*Tijdens het self assessment heb je wellicht de neiging nog zaken te fixen. Het netjes opdelen van commits schiet er in de praktijk vaak bij in vanwege pragmatische overwegingen. Zoals je als het goed is weet kun je in git achteraf de geschiedenis nog aanpassen. Zeker alleen lokaal; namelijk met interactive rebasing. Zie bv. 'rewriting history op de git site' de sectie 'Splitting a commit' geeft een voorbeeld.

Als je tijd hebt mag dit. Maar belangrijker dan alles goed doen, is kennis hebben hoe het voortaan goed/beter te doen (niveau 'bewust onbekwaam' ip.v. 'onbewust bekwaam'). En dit ook te kunnen formuleren voor jezelf. Dus steek je tijd liever in korte toelichting hoe je dit zou aanpakken, of precies waarom het niet lukt (wat is de reden, wat is de foutmelding die je kreeg? welke stappen heb je gezet?).

Let op: een self assessment betekent NIET een individuele assessment. Het is wel okee (zelfs goed) eerst onafhankelijk van elkaar een assessment te bedenken, maar overleg je mening en voeg daarna de punten uit beiden samen en overleg om tot een teamoordeel te komen.

Schrap daarbij ook onnodig lange, dubbele of achteraf onjuiste of onduidelijke zaken (samenvoegen is namelijk iets anders dan achter elkaar plakken). Dit is ook een vorm van integratie (e.g. bij 'Continuous Integration denk je waarschijnlijk primair aan integreren van code e.g. pull requests, maar ook documentatie hoort hierbij, en een self assessment is ook een vorm van documentatie).

4. Inleveren

Als je klaar bent maak dan een issue aan in/bij je GitLab repo met titel Nakijken en assign deze aan je docent.

De docent beoordeelt je werk in gitlab en of het voldoende is. Zo niet dan maakt de docent een issue aan om te fixen met korte beschrijving. Volgens de Joel test geldt in principe 'fix bugs before you write new code'. Je moet in principe een voldoende hebben voordat je naar volgende opdracht.

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 (2024):

  • MINDEC03
    • TOETS-02 - Beroepsproduct Dev <-- Onderzoeksblog repo + presentatie slides?
    • TOETS-03 - Huiswerkopdrachten Dev <-- Linux Bash script & RabbitMQ groepsrepo
  • MINDEC04
    • TOETS-02 - Beroepsproduct DevOps <-- PitStop uitbreiding BP groepsrepo
    • TOETS-03 - Wekelijkse Huiswerkopdrachten DevOps <-- Verzamelzip weekopdracht 1, 2, 3 en 5

5. 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 en 5

  • Flexibele Paren:
    • Paren kunnen opnieuw wisselen.
    • Terugkeren naar het oorspronkelijke paar is toegestaan.
Last change: 2025-01-13