git

Workflow

Spingit

for wizards on steroids

Waarom?

Wat zijn de "uitdagingen" nu?

Waar we het over gaan hebben

#1 Situatie nu

Release branch

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

Develop/sprint branch

• master
• develop
• development_vo
• staging

Feature branches

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

WUT

#2 Voor- nadelen bekeken opties

Gitflow vs Github-flow

Now what?

Wat missen beide flows

• 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

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

Meerdere klanten same code base Bij een release taggen als<klant>/1.0.1voorbeeld: <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?