git

Workflow

Spingit

for wizards on steroids

Waarom?

1. Behoefte aan eenduidigheid
2. Beide voor en nadelen
3. Moet helpen tijdens de ontwikkeling
   Niet forceren het process aan te passen
4. Verschillende type software
   (mobile, web)

Wat zijn de "uitdagingen" nu?

Waar we het over gaan hebben

1. Situatie nu
2. Voor- nadelen bekeken opties
3. Structureren van branches
4. But how?
5. Uitzonderingen...
6. Pull request

#1 Situatie nu

Release branch

"Wat staat er op dit moment in productie?"

• master
• release
• production
• ... master van 3 weken terug
  ofwel commit: 6a8cd58903

Develop/sprint branch

"Waar zitten alle finished features in voor de volgende release?"

• master
• develop
• development_vo
• staging

Feature branches

"Waar zitten nieuwe features (klaar of niet) in?"

• nieuwe-feature
• feature/nieuwe-feature
• features/nieuwe-feature
• master
• develop

WUT

#2 Voor- nadelen bekeken opties

Gitflow vs Github-flow

1. gitflow Branche structuur
2. gitflow Hotfix flow
3. github-flow Pull Requests/code review
4. gitflow/github-flow Taging
5. gitflow/github-flow master == productie

Now what?

Wat missen beide flows

1. acceptatie omgeving?
2. Mobile apps
   • version bump/tag Android?
   • iOS Ad Hoc taggen/acceptatie omgeving?

#3 Structureren van branches

Start situatie

master
wat er nu in productie staat

staging
wat er nu in de acceptatie omgeving staat

develop
alle afgeronde features voor een volgende release

Features/hotfixes/tags

feature/manage-users-for-backend
een nieuwe feature waar aan gewerkt wordt

hotfix/panic-fix
quick fix die asap live moet

1.0.1
tag naamgeving voor een release

#4 But how?

Flows

1. feature → develop
2. develop → staging → master
3. hotfix

1. feature → develop

1. feature → develop

$ git checkout -b feature/admin-login develop
# work work work, commit commit commit, rebase op develop, FINISHED
$ git push origin feature/admin-login
# create pull request ... ?
          

we komen zo terug op pull requests

2. develop → staging → master

2. develop → staging → master

# develop --> staging
$ git checkout staging
$ git merge --ff develop
$ git push origin staging
# deploy...
          

# staging --> master
$ git checkout -b release/2.1.0 staging
# version bump, changelog aanpassen, commit.
$ git checkout master
$ git merge --no-ff release/2.1.0
$ git push origin master
# deploy...
# create new version tag 2.1.0
$ git tag -a 2.1.0
$ git push origin 2.1.0
          

paniek!

hotfix nodig voor productie!

3. Hotfix flow

3. Hotfix flow

# create hotfix branch from master
$ git checkout -b hotfix/bsod-fix master
# fix, fix, commit, commit
$ git push origin hotfix/bsod-fix
# pull request

# after merge, pull and checkout master
# create new version tag 1.1.1
$ git tag -a 1.1.1
$ git push origin 1.1.1
          

Hotfix ook naar staging, develop mergen!!!

Complete flow

Dus

• features gaan de develop branch in voor een volgende release
• develop kan altijd naar staging omdat hier volledige features in zitten
• bij akkoord kan staging naar de master branch (productie)
• bij een productie release altijd een tag (ook na een hotfix release)

#5 Uitzonderingen

try {} catch(Exception) {}

Acceptatie mobile apps
Android: staging → beta
iOS: staging → adhoc

bekijken of dit werkt...

Meerdere klanten same code base
Bij een release taggen als
<klant>/1.0.1
voorbeeld: <sping>/1.0.1

Remember this?

Code review

Voordelen

• Team is technisch bekend met nieuwe features
• Github PR interface
• Minder duplicate code
• Je leert nieuwe dingen
• "vergeet je niet ..."

Nadelen Nadeel

• Kost wat extra tijd

best practice

+ Merge van een ander

- maar niet van jezelf

PRO TIPS

Geef elkaar de tijd te reviewen

Can we ship it? Can we ship it? Can we ship it?

Spingit: Cheatsheet

Questions?