Skip to main content

Project: website

Doelstelling​

De beste manier om Git goed in de vingers te krijgen, is er mee aan de slag gaan.

Dat zullen we de komende weken doen aan de hand van een project waar jullie samen aan werken.

Dat project bestaat uit een website die jullie in groep zullen opzetten.

belangrijk

  • Hoewel we de kwaliteit van de website en wijzigingen ook opnemen in de evaluatie, ligt de focus op het correct gebruik van Git.

  • Verder hechten we ook belang aan het gebruik van de extra tools die webgebaseerde Git-repository platformen bieden om software development projecten uit te werken in teams.

Werkwijze​

We maakten voor deze opgave een aantal groepjes. Die verdeling vind je op een tweede tabblad in het planningsdocument.

De repositories (en gitlab group) worden voor jullie voorzien. Eens de teams verdeeld zijn, voegen we jullie toe als maintainer aan deze repository op gitlab.com.

Deze repositories bevatten momenteel nog geen code, dat laten we aan jullie over.

Rolverdeling​

Elke week zullen de rollen gewisseld worden binnen het team. Dat doen we zodat iedereen ervaring kan opdoen met alle taken binnen de vooropgestelde workflow.

Initiële website​

We verwachten niet van studenten in dit vak dat ze in staat zijn om een website te bouwen, en daar ligt ook helemaal de focus niet op. Daarom mag de site aan de hand van vibe coding met AI gemaakt worden. Dat geldt ook voor de aanpassingen achteraf: AI is expliciet toegelaten.

Om te vermijden dat iedereen met een volledig andere oplossing komt, stellen we voor om onderstaande prompt te gebruiken bij het maken van de site. Eventueel kan je wel het onderwerp van de site aanpassen.

Je bent een expert in front-end webontwikkeling. Jouw taak is om de volledige projectstructuur en code te schrijven voor een statische website voor een lokale bakkerij. 

**Technologische Stack:**
- Framework: Vue.js (Vue 3 met Composition API)
- Build tool: Vite
- Navigatie: Vue Router
- Styling: Mag met plain CSS of Tailwind CSS (kies wat de code het meest overzichtelijk houdt)
- Hosting: GitLab Pages (volledig statisch gedeployed)

**Projectvereisten:**
1. **Bestandsstructuur:** Het project moet modulair zijn opgezet in meerdere bestanden (bijv. `index.html`, `src/main.js`, `src/App.vue`, `src/views/...`, `src/components/...`). Geef duidelijk aan welk bestand waar hoort.
2. **Navigatie:** Een simpele navigatiebalk bovenaan die linkt naar 'Home' en 'Contact'.
3. **Pagina 1: Home (src/views/Home.vue)**
   - Een warme, welkomstboodschap voor de bakkerij.
   - Een opvallende sectie genaamd "Aanbieding van de week" (bijv. met een hardcoded aanbieding zoals "10% korting op appeltaart").
4. **Pagina 2: Contact (src/views/Contact.vue)**
   - De contactgegevens (fictief adres, telefoonnummer, e-mail).
   - De openingstijden.
   - Een statisch, niet-functioneel contactformulier (Naam, E-mail, Bericht, Verzendknop) om het visueel compleet te maken.
5. **GitLab Pages Deployment:**
   - Geef de exacte inhoud van een `.gitlab-ci.yml` bestand dat nodig is om dit Vite/Vue project te builden en te deployen naar GitLab Pages. Zorg dat de `public` folder of build folder (vaak `dist`) correct wordt opgepakt als artifact.
   - Geef eventuele aanpassingen in `vite.config.js` of Vue Router die nodig zijn voor de base URL in GitLab Pages.

**Output formaat:**
Geef per bestand de volledige, kopieerbare code. Begin met een overzicht van de mappenstructuur en schrijf daarna de code blokken uit. Zorg voor een nette, moderne en warme uitstraling die past bij een ambachtelijke bakkerij.

Rol van de developer​

De developer staat in voor het implementeren van de gevraagde wijzigingen. Dat gebeurt tussen een nieuwe release en woensdagavond.

In detail houdt dit het volgende in:

  • Een developer zal elke week een of meerdere work items aan zich toewijzen.
  • Als een idee gevonden werd voor een code, dan wordt een work item aangemaakt in de oorspronkelijke repo. Op die manier is duidelijk wie waar aan het werken is. Zo wordt vermeden dat meerdere developers hetzelfde onderwerp aan het bespreken zijn.
  • Een developer is inhoudelijk verantwoordelijk voor zijn code, en ook vormelijk moet het voldoen. Als dat niet zo is, zullen project managers het simpelweg weigeren.
  • Houd na het indienen van je Merge Request (MR) goed in de gaten of er feedback komt van je project managers. Er bestaat immers een kans dat je MR geweigerd wordt of enkele aanpassingen vergt.
    Normaal zal dit via feedback in je MR terug te vinden zijn. Als je notificaties actief zijn, zal je normaal ook een mailtje krijgen.
Belangrijkste punten voor het verwerken van de work items zelf:
  • Lever steeds nette code af.
  • Test de functionaliteit uitgebreid vooraleer je de merge request klaarzet.
  • Voorzie genoeg context in zowel het work item als de merge request.

Rol van de project managers​

De project managers houden het overzicht. Zij hebben de eindverantwoordelijkheid om een goeie site op te leveren.

Review van merge requests (donderdag)​

  • Op donderdag gaat deze groep door de lijst van merge requests die de developers maakten en reviewen ze die. Het is de verantwoordelijkheid van de developers dat de merge requests ook kunnen mergen (oa. pipeline checken). Is dat niet zo, dan zijn het de developers die de merge request moeten updaten. (bv indien meerdere MR's binnengekomen zijn zullen er ongetwijfeld conflicten ontstaan waar de developers geen invloed op hebben)
  • Voor elke MR die opgenomen wordt, wordt dit ook via het issuebord in de juiste 'status' gebracht zodat andere developers weten welke issues/MR's in behandeling zijn.
  • Developers krijgen feedback via hun MR (eventueel kan je bepaalde lijnen code van commentaar voorzien). Indien nodig moeten ze hun code nog aanpassen (inhoudelijk, tikfouten, ...)
Belangrijkste punten voor de project manager:
  • Indien er inhoudelijk, vormelijk of bv. in de syntax fouten vastgesteld worden, dan geef je, zoals hierboven vermeld, feedback terug aan de developer via commentaar bij de Merge Request.
  • Volg zeker op of de developer je feedback gezien en opgenomen heeft. Hier hangt immers de rest van de iteratie aan vast en dus het publiceren van een nieuwe versie van je website.
  • Laat ALLE communicatie verlopen via Gitlab.

Mergen naar develop en main (vanaf vrijdag)​

  • Als alles goed gaat zal het eindresultaat van de developers bestaan uit een werkende nieuwe site op de develop-branch. Voor de buitenwereld is die nog niet zichtbaar.
  • Op het issue-bord verander je de status van issues die je behandeld hebt.
  • De project manager hakt op vrijdag de knoop door om al dan niet te mergen naar main.
  • 1 project manager zet die merge klaar, maar minstens 1 andere project manager moet ook toestemming geven vooraleer naar main gemerged wordt. Dat zal uiteraard enkel gebeuren als de testbuilds op staging goeie resultaten geven.
  • De project manager is ook verantwoordelijk voor het dagelijks beheer van de site. Als vb een security patch moet toegepast worden, dan is het ook aan deze rol om dit uit te voeren.
  • De project managers hebben ook de belangrijke taak om via de Protected branches en de Merge request approvals in Gitlab de developers en project managers voor de volgende sprint vast te leggen!!
Belangrijk voor de project manager:
  • De project managers hebben geen ruimte om te experimenteren! De "main"-branch wordt gebruikt om de productie-versie van de website aan het grote publiek ter beschikking te stellen. Er mag dus geen enkel moment zijn waarop deze een versie toont met fouten.
  • Daarvoor dienen de voorafgaande controles door de developers en project managers.
  • Een mogelijke, veilige, manier is lokaal even de merge te testen. Je kan hiervoor lokaal een tijdelijke branch aanmaken die gebaseerd is op de "main"-branch en de "develop"-branch hierin mergen en controleren. Deze tijdelijke branch kan je uiteraard weer verwijderen.

Git-vereisten​

We gebruiken een variante op de Gitlab-workflow. Een schematisch voorbeeldje zie je hier:

gitGraph commit id:"initiële setup" commit id:"project structuur" branch develop checkout develop commit id:"basis configuratie" branch FEAT-feature1 checkout FEAT-feature1 commit id:"nieuwe code (dev1)" commit id:"code afgewerkt (dev1)" checkout develop branch FEAT-feature2 checkout FEAT-feature2 commit id:"nieuwe code (dev2)" commit id:"code afgewerkt (dev2)" checkout develop merge FEAT-feature1 id:"MR#1 gemerged" merge FEAT-feature2 id:"MR#2 gemerged" branch upgrade-component checkout upgrade-component commit id:"security fix" commit id:"component upgrade" checkout develop merge upgrade-component id:"security update" checkout main merge develop id:"sprint release" tag:"v1.0"

Belangrijke punten hierbij:

  • op develop probeer je steeds een werkende versie te hebben. Je kan dit zien als de 'staging' omgeving
  • de main-branch is wat je site-bezoekers zien. Deze mag dus nooit voor experimenten gebruikt worden (zelfs kleine aanpassingen doe je niet rechtstreeks).

Gitlab-vereisten​

Naast een correct gebruik van Git, focussen we ook op een correct gebruik van Gitlab als platform.

Belangrijke punten hierbij:

  • Maak steeds gebruik van work items vooraleer je een branch maakt, en indien mogelijk link je je branches zoveel mogelijk met je issues.
  • Gebruik de verschillende borden in je project. Je moet op elk moment kunnen zien welke issues nog in de backlog zitten, welke momenteel behandeld worden en in welke fase ze zich bevinden. Je zal hiervoor wellicht enkele (extra) labels moeten maken.

Evaluatie​

Er wordt gequoteerd op:

  • Best practices gebruikt voor commit messages
  • Altijd gewerkt met feature branches
  • Kwaliteit van de wijzigingen
  • Halen van deadlines, en het volgen van de bovenstaande werkwijze
  • Aanmaken merge requests
  • Verwerken van de merge requests
  • Gebruik van team collaboration Gitlab-features zoals issues, borden, ...