Arbetsprocess Branchstrategi
- US ska kunna implementeras och testas utan beroenden till andra US
- Release ska vara möjlig efter varje US
- Breaking changes ska kunna hållas utanför release tills nästa planerade major-release
- PO ska kunna godkänna US (att acceptanskriterier är uppfyllda) innan test
- Testare ska kunna testa innan release av US
- Möjligt att rätta tidigare releaser
- behovsstyrt av projekten från fall till fall
- Ska stödja pull requests från personer utanför ersättningssystemen
- All utveckling sker på feature-branches.
- Möjliggör oberoende utveckling av US och att det alltid är möjligt att releasa från master.
- Demo och test görs på feature-branchen. Den utvecklare som implementerar en US på feature-branch är ansvarig att synkronisera feature-branchen med master innan demo och test.
- Den utvecklare som implementerar en US är ansvarig att merga feature-branchen till master efter demo och test (eller till branch för innehåll till kommande major-release, se nedan).
Figur 1. Feature-branches används för all utveckling
Möjliggör att alltid göra minor-releaser från master och begränsar antalet branches att uppdatera fram till nästa planerade major-release. Innan planering av US ska det vara utrett om den innebär breaking changes (ej bakåtkompatibla ändringar). Breaking changes integreras och hålls på separat branch för innehåll i kommande major-release. Feature-branches används på vanligt sätt. Demo och test sker på feature-branchen. Den utvecklare som implementerar US med breaking changes på feature-branch är ansvarig att synka branchen med innehåll i nästa major-release mot master samt synka feature-branchen mot branchen med innehåll i nästa major-release. Den utvecklare som implementerar en US är ansvarig att mergea feature-branchen till branchen för innehåll till kommande major-release efter demo och test. När nästa major-release ska göras mergas branchen som innehåller breaking changes till master. Release sker från master.
Figur 2. Branchning för breaking changes som kommer i nästa major-release. branch 'maj_rel' i bilden.
Patch-release är rättning på tidigare release som inte kan vänta till nästa release (”hot fix”). Den utvecklare som implementerar patchen är ansvarig för att vid behov göra motsvarande rättning där behovet finns. Tex. master och branch för innehåll till kommande major-release.
Figur 3. Branchning för patch-release
Vi tar fram förslag, ev följa gitflow för namngivning av ex brancher, next, fixes, featurebranches mm TBD
Figur 4. Översikt publik dokumentation, demo och test.
Siten https://vastra-gotalandsregionen.github.io/komponentkartan-dokumentation/ ska användas för publik dokumentation av komponentkartan (inte samma sak som tidigare komponentkartan ”demo” som kommer avvecklas). Siten behöver inte vara heltäckande avseende att visa komponenternas alla tillämpningar och parametriseringar.
Demo för PO att acceptanskriterier är uppfyllda sker på feature branch. Utvecklaren som implementerar en US väljer själv hur demon görs (på test-sidor enligt nedan eller på tillfällig demosida som kastas efter demon).
Test sker på feature branch lokalt på testares dator.
Det behövs en eller flera testsidor som populeras av komponenterna i de varianter som ska testas. Testsidorna är inte samma sidor som finns på dokumentations-siten https://vastra-gotalandsregionen.github.io/komponentkartan-dokumentation/
Test-sidan (sidorna) underhålls och vidareutvecklas vid behov i samband med US av utvecklaren som implementerar storyn. Test-sidorna kan också byggas ut av testare.
Test-sidornas komplexitet ska hållas på en avvägd nivå för att underhållet av sidorna ska vara av rimlig omfattning.
Test-scope och nödvändiga utvecklingsinsatser som behövs på test-sidorna bestäms tillsammans av utvecklare och testare på refinement av US.
Test-sidorna versionshanteras på samma sätt som alla annan kod i repot på github.
Långsiktiga visionen för test ska vara att ha utbyggda automatiska regressionstester av i första hand ”happy-paths” som kompletteras av manuella exploratory-tester.
Alla major- och minor-releaser sker från master. Patch-releaser sker där behovet finns.
Pull requests ska användas internt vid merge till master/next release.
Utvecklare av en US bestämmer själv om code review behövs.
Efter merge till master ska feature branch tas bort för att undvika döda brancher. Stöd för detta finns i pull request-funktionen.