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.

Onderzoeksthema'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.

Concreet te documenteren en op te leveren

Geen blog en geen verhalend verslag nodig; je vertelt het verhaal mondeling tijdens de presentatie. Documenteer beknopt en toetsbaar.

• Issue op het team‑projectbord (GitHub Projects of vergelijkbaar)
  • Titel: "Spike: voor <PitStop‑uitbreiding>"
  • Koppel commits/PRs aan dit issue
• Repo‑structuur in jullie PitStop teamrepo
  • Map: /docs/tech-onderzoek-<studentnaam>
  • Minimale prototype‑artefacten: code en/of configuratie (hello world is oké)
  • README.md in deze map met minimaal de volgende kopjes:
    • ## Welk probleem los ik op?
    • ## Wat moet je weten over de technologie?
    • ## Observaties
    • ## Uitdagingen
    • ## Resultaten
    • ## Bronnen (bullets met titel en volledige URL; waar relevant auteur/organisatie)
• Werkwijze
  • Trunk‑based: commit rechtstreeks op main mag voor deze spike
  • Gebruik de hoofdvraag en drie deelvragen als leidraad; beantwoord ze kort in de README
• Acceptatie tijdens presentatie
  • Korte demo van het prototype
  • Heldere, onderbouwde antwoorden op de deelvragen
  • Overzichtelijke bronnenlijst

Voorbeeld screenshots aanpak in GitHub (stappen)

Om het idee van een 'onderzoeksteam' ook handen en voeten te geven, en voor te bereiden op de 2 weken implementatie in de weken na deze onderzoeksweek is het handig nu per persoon een folder /docs/tech-onderzoek-studentnaam op te nemen voor je prototype. Daarin komt je code en/of configuratie.

Aangezien 'documentation as code' een DevOps best practice is (mits publiek developers) kun je markdown gebruiken. Aangezien je bij een Spike onderzoek je onderzoek als issue op de backlog/planbord zet, en je bij DevOps een shared backlog moet hebben, en in GitHub je issues en een projectboard bij je repo kan aanmaken kun je onderstaande stappen zetten. In GitHub issues kun je ook markdown gebruiken.

Voor de laatste stap, het refactoren verplaats je de tekst vanuit issue naar de README.md in je eigen folder. Commit ook je wijzigingen op het persoonlijke issue nr (e.g. zet het #nr in je commit messages).

Herhaalbaarheid en bronvermelding

Voor de herhaalbaarheid en controleerbaarheid van je onderzoek is het verplicht om je geraadpleegde bronnen (officiële documentatie, blogs en tutorials, etc.) te bewaren en op te nemen in je documentatie. Bijvoorbeeld direct in de taak op het projectbord, of in de README.md van je prototype. Noteer per bron minimaal:

• Titel van het stuk (artikel/blog/video/documentatie)
• Volledige URL

Waar relevant kun je ook auteur, datum en versie vermelden. Gebruik consistente notatie.

Toepassen van (HBO) ICT onderzoeksmethoden

Je kunt bovenstaande opdracht volgen. Merk echter op dat je hierbij 'gewoon' werkt volgens de HBO ICT onderzoeksmethoden. Je werkt ook vanuit een onderzoeksvraag. De hoofdvraag voor iedereen in deze week is:

Hoe kan ik mijn gekozen technologie nuttig toepassen in mijn groepsgekozen PitStop‑uitbreiding?

Deze vraag kun (moet) je concreet maken, door zowel de concrete technologie in de vraag te zetten als je PitStop uitbreiding te noemen. Bijvoorbeeld:

"Hoe kan ik de load testing tool K6 nuttig toepassen in onze uitbreiding van PitStop met Voorraadbeheer"

De Spike Guide heeft feitelijk al enkele van de HBO ICT onderzoeksmethoden voor je gekozen. Koppel je aanpak aan passende onderzoeksmethoden (triangulatie) en splits de hoofdvraag op in drie deelvragen:

• Literatuuronderzoek: officiële documentatie, artikelen, tutorials

  • Deelvraag: Welke best practices, beperkingen en randvoorwaarden gelden voor mijn gekozen technologie in de context van onze PitStop‑uitbreiding?
  • Ingrediënten (bron: Literature study):
    • A willingness to read.
    • Search engines (e.g. Google Scholar, your library’s search engines).
    • The ability to select what is really important for your case and to leave the rest unread.
    • Identifying the ‘gatekeepers’ (parties who guarantee the quality of certain information).
    • Knowing when to stop.

• Prototyping: klein, doelgericht proof‑of‑concept

  • Deelvraag: Werkt de technologie in een minimaal, representatief prototype voor onze beoogde use‑case, en wat zijn de technische beperkingen?
  • Ingrediënten (bron: Prototyping):
    • A willingness to tackle the riskiest and difficult parts first.
    • The ability to ‘kill your darlings’ if the feedback or findings are negative.
    • A clear view of what you would like to learn from your prototype.

• Presentatie/Showroom (Pitch): toets je bevindingen bij stakeholders (team/docent)

  • Deelvraag: Kunnen we de waarde en toepasbaarheid van de technologie overtuigend overbrengen en ophalen of de richting klopt?
  • Ingrediënten (bron: Pitch):
    • Enthusiasm.
    • The ability to present your idea briefly and convincingly.
    • Representative experts.
    • A willingness to improve and change.

Gebruik de ingrediënten uit ictresearchmethods.nl om je opzet te verbeteren (kwaliteitscriteria, meetbaarheid, validiteit). Zie een spike niet als aparte methode, maar als onderzoek ingebed in Agile softwareontwikkeling: timeboxed, gekoppeld aan een backlog‑issue en eindigend met gedeelde bevindingen en aanbevelingen.

Toelichting aan de hand van gestelde studentenvragen n.a.v. de opdracht

"Het is dus de bedoeling dat een [...] tool uitkies die ik ook behandel in de presentatie van donderdag? Of is het de bedoeling dat ik alleen een prototype uitwerk die de hoofdvraag beantwoord?"

Antwoord: Beide. Je onderzoekt een CNCF‑technologie én doet iets hands‑on (maakt een prototype). Een prototype bouwen impliceert dat je een tool/stack kiest. Het is niet verplicht om deze week al alles in PitStop te integreren (dat volgt in de laatste twee weken en telt mee in de eindbeoordeling). Een ‘hello world’‑achtig prototype is nu voldoende voor het hands‑on deel, mits je dit koppelt aan je onderzoeksvraag.

"Ik ben een beetje in de war over wat er precies opgeleverd moet worden voor het onderzoek. Het lesmateriaal noemt dat je je bevindingen en resultaten moet noteren, wat de indruk wekt dat het vooral gaat om het lezen van documentatie, het maken van een prototype en daar een korte toelichting bij geven. Maar nu hoor ik dat er ook een onderzoeksmethode bij hoort, waardoor het meer lijkt op een klassiek HAN‑onderzoek, zoals we die gewend zijn."

Antwoord: Het doel is toegepast onderzoek ‘net wat beter’ te doen. Zie softwareontwikkeling als continu toegepast onderzoek: je verkent techniek en domein, werkt eisen uit in code en tests, en onderbouwt keuzes. Deze Spike Guide geeft al een lichte methodische ruggengraat: literatuuronderzoek → prototyping → presenteren. Voeg waar passend principes uit onderzoeksmethoden toe (zoals triangulatie en expliciete kwaliteitscriteria). Een spike is dus geen nieuwe methode, maar een Agile vorm die onderzoek timeboxt en verbindt aan waarde voor het team.