Skip to content
Snippets Groups Projects
README.md 10.4 KiB
Newer Older
# Integratieplan

## Inhoudsopgave

- [Inleiding](#Integratieplan-Inleiding)

- [1. Branches](#Integratieplan-Branches)

- - [1.1. Branchstructuur](#Integratieplan-Branchstructuur)
- [1.2. Feature](#Integratieplan-Feature)
- [1.3. Commit](#Integratieplan-Commit)
- [1.4. Proof of concept](#Integratieplan-Proofofconcept)

- [2. Review](#Integratieplan-Review)

- [3. Pull request](#Integratieplan-Pullrequest)

- [4. Pipeline](#Integratieplan-Pipeline)

- - [4.1. Algemene toelichting](#Integratieplan-Algemenetoelichting)
- [4.2. Wat als de pipeline faalt?](#Integratieplan-Watalsdepipelinefaalt?)

- [5. Sprint Board](#Integratieplan-SprintBoard)

- [6. Don't use Git and you get Hit](#Integratieplan-Don'tuseGitandyougetHit)

## Inleiding

Het ASD-Project is het belangrijkste project van de opleiding HBO-ICT, waar met een gehele klas aan het platform VeiligVeilen wordt gewerkt. In dit document zal het voorstel van het integratie team staan omtrent de GitLab/BitBucket omgeving en de workflow, integratie & review tijdens het ASD-Project van 22/23.



## 1. Branches

![Branch diagram](/img/BranchDiagram.png)



### 1.1. Branch structuur

Tom Janssen's avatar
Tom Janssen committed
Tijdens het project wordt de 'Main'-branch gebruikt voor het presenteren van het product. Op deze branch staat de meest volledig werkende versie van het product zonder bekende bugs of crashes. Om aan het product te kunnen werken is er een 'Development'-branch. Hier worden alle werkende to-be-released-features gepusht. Dat wil zeggen dat er voor een feature die nog niet af is, ook geen pull request richting de 'Development'-branch wordt aangemaakt. In deze branch staat de laatst werkende WIP-versie (Work In Progress) van het product. Twee dagen voor het einde van iedere fase of deadline worden alle features op de 'Development'-branch naar een 'Release-Candidate'-branch gepulld, in deze branch werken de integratoren verder aan het product om eventuele bugs op te lossen en alle features samen te brengen tot een nieuwe release. Als dit gedaan is zullen de wijzigingen gepulld worden naar de 'network.manual.Main'-branch.

Indien de 'Development'-branch niet meer werkt, wordt de desbetreffende merge teruggedraaid en zal degene die dit heeft veroorzaakt samen met zijn team een werkende versie geven voor de merge.

Op de bovengenoemde branches, 'Main', 'Development' en 'Release-Candidate', wordt niet direct gepusht. Dit gaat altijd via een pull request. In het geval dat de integriteit van de repository is beschadigd kan er een uitzondering gemaakt worden voor de integrators, en alleen de integrators, om de schade te repareren.

Elke ochtend wordt de 'Development'-branch gemerged in de 'Feature'-branch, in deze branch wordt gecontroleerd op werkende versie. Vervolgens wordt de 'Feature'-branch gemerged in de 'Sub-Task'-branch, ook deze branch wordt gecontroleerd op een werkende versie voordat er verder gewerkt wordt.



### 1.2. Feature

Tijdens het werken aan een nieuwe feature wordt er een nieuwe branch aangemaakt vanaf de 'Development'-branch met de volgende naamgeving: **'feature/<featureNummer>-<featureNaam>**'. Om ervoor te zorgen dat meerdere developers aan dezelfde feature kunnen werken, wordt er voor iedere sub-task een branch aangemaakt vanaf de feature branch. Ook hiervoor wordt een standaard naamgeving gebruikt: '**sub-task/<featureNummer>-<sub-taskNaam>**'. Op deze branch kunnen de developers direct zijn wijzigingen pushen voor de feature. Nadat de 'sub-task'-branch gemerged wordt met de 'feature'-branch wordt de 'sub-task'-branch verwijderd.

De naamgeving voor de feature inloggen, zou er als volgt uitzien: '**feature/ASDCBA-007-inloggen**'. Een subtask branch zou er als volgt uitzien: **'sub-task/ASDCBA-007-inlogscherm-ui'**.



### 1.3. Commit

Om de commits van de branches gestructureerd te houden zijn er een aantal regels opgesteld omtrent de commit. De commit messages worden altijd in het Engels geschreven, ook zal de commit message beginnen met een werkwoord en wordt er duidelijk beschreven wat er gedaan is voor de commit. Hierbij wordt een commit message zoals '**Added x to y so z works**' of '**Added x to y so z doesn't happen anymore**' toegestaan, maar '**Added x to y**', '**Fix for problem x**' of '**Small fixes**' niet!



### 1.4. Proof of concept

Om een eventuele proof-of-concept voor een onderzoek te maken kan er een nieuwe '**poc**'-branch aangemaakt worden onder de 'development'-branch. Voor de branch wordt de volgende naamgeving gebruikt: '**poc/<ProofOfConceptNaam>**'. Deze branch wordt hetzelfde behandeld als een 'Sub-task'-branch, maar zal niet worden verwijderd tijdens het integratieproces. De resultaten van de proof-of-concept worden **op afronding** verwerkt/gemerged in een 'Sub-task'-branch.



## 2. Review

![Review diagram](/img/ReviewDiagram.png)



## 3. Pull request

Op het moment dat een sub-task af is en voldoet aan de DoD en de gevraagde functionaliteiten, kan er een pull request aangemaakt worden om de 'Sub-Task'-branch te mergen naar de bijbehorende 'Feature'-branch. Voordat de pull-request wordt gemaakt, dient het teamlid de bijbehorende 'Feature'-branch te fetchen en zo nodig te pullen. Deze 'Feature'-branch wordt vervolgens gecontroleerd en als hij werkt zoals gewenst wordt de 'Feature'-branch in de 'Sub-Task'-branch gepulld. Als de 'Sub-Task'-branch daarna werkt zoals gewenst, kan een pull-request worden aangemaakt.

Nadat de pull request aangemaakt wordt, moet de bijbehorende task op de status 'To Review' worden gezet. In het geval dat de pull request wordt goedgekeurd door minimaal **twee** **personen**, die niet aan de branch gewerkt hebben, en voldoet aan de regels in het hoofdstuk [review](), zal de eigenaar van de pull request deze mergen naar de 'Feature'-branch. Mocht de pull request niet voldoen, wordt de desbetreffende task terug naar de status 'To Do' gezet. Bij het veranderen van de status wordt de eigenaar op de hoogte gesteld van gebreken en eventuele verbeteringen. De gebreken en verbeteringen dienen ook in de pull request zelf genoteerd te worden.

Als de gehele feature af is, en er geen pull request meer open staan van bijbehorende sub-tasks naar de branch, kan er een pull request worden aangemaakt om de 'Feature'-branch te mergen naar de 'Development'-branch. Deze branch moet uiterlijk **twee dagen** voor het einde van de fase of deadline met de **definitieve code** gemerged worden met de 'Development'-branch. In het geval dat er wijzigingen zijn gemaakt in de implementatie van de feature dient de **definitieve documentatie** van de te-mergen-feature **drie dagen** voor het einde van de fase of dezelfde deadline online te staan, dit wordt gedaan om ervoor te zorgen dat het integratieteam zich kan inlezen op de features en het integratieproces soepel kan verlopen. **Twee dagen** voor het einde van de fase of deadline wordt de 'Development'-branch gemerged met de 'Release-Candidate'-branch. Features die niet op de afgesproken deadline op de 'Development'-branch staan worden **niet** meegenomen naar de 'Release-Candidate'-branch en worden pas toegepast in de eerst volgende release. Op het moment dat alle (kleine) bugs opgelost zijn en **alle gewenste functionaliteiten** bevat, wordt de 'Release-Candidate'-branch gemerged naar de 'Main'-branch voor de nieuwste release.



## 4. Pipeline

### 4.1. Algemene toelichting

| **Stage**            | **Job(s)**                                                   | **Toelichting**                                              |
| -------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
| Mirror               | mirror_job                                                   | Deze  job stuurt een mirror van de GitLab repository naar Bitbucket. Dit is vanuit  de HAN vereist. |
| Build                | build_job                                                    | In  de build_job wordt de code gecompileerd en gebouwd.      |
| Test                 | unit_test_job                                                | In  de unit test job worden alle tests die eindigen op “UnitTest” uitgevoerd. Het  is daarom ook belangrijk om de naam test classes van de unit tests te laten  eindigen op “UnitTest”. Anders wordt de test niet meegenomen in deze job. |
| integration_test_job | In  de integration test job worden alle tests die eindigen op “IntegrationTest”  uitgevoerd. Het is daarom ook belangrijk om de naam test classes van de  integration tests te laten eindigen op “IntegrationTest”. Anders wordt de  test niet meegenomen in deze job. |                                                              |
| Quality              | quality_job                                                  | In  deze job wordt de code geanalyseerd door SonarQube.      |



![Pipeline img](/img/PipelineImg.png)



### 4.2. Wat als de pipeline faalt?

Wanneer een van de jobs uit de pipeline faalt, betekent dit dat de gehele pipeline faalt. Als dit gebeurt moet er actie worden ondernomen. Wat er precies moet gebeuren verschilt per gefaalde job.



**De mirror_job is gefaald**

Laat dit zo snel mogelijk weten aan een van de integratoren, zij zullen dit probleem zo snel mogelijk proberen te verhelpen.



**De build_job is gefaald**

Klik op de build_job om de log te openen. Bekijk in de log wat er precies mis is gegaan tijden het builden. Commit nieuwe code die dit probleem verhelpt net zo lang tot de build job weer slaagt.



**De test_job of integration_job faalt**

Klik op de gefaalde job om in de log te kijken welke test er is gefaald. Commit nieuwe code om de job weer te laten slagen.



**De quality_job faalt**

Kijk in sonarqube waarom de quality job is gefaald. Commit nieuwe code om aan de sonarqube standaard te voldoen. De job zou hierna weer moeten slagen.



## 5. Sprint Board

Voor het sprintboard zijn een aantal eisen opgesteld. Bij het aanmaken van een taak op het sprintboard **moeten** pre en postcondities , een concrete beschrijving en een original estimate worden toegevoegd.

Bij bugs **moet** een beschrijving van de stappen om de bug te reproduceren toe worden gevoegd.



## 6. Don't use Git and you get Hit

Als een niet-Integratie teamlid een fout maakt waardoor de integriteit van de Development of Main branch wordt beschadigd dan wordt aangeraden om het zo snel mogelijk op te lossen. In de tijd dat het beschadigd blijft, komt de hoofd integrator namelijk langs met de Git knuppel. Als een integratie teamlid een fout maakt waardoor de integriteit van de Development of Main wordt beschadigd, komt hij met het Git geweer.