Git Workflows

Best Practices for SPS

Who are we

• The people in your neighborhood
• Mike Bjerkness
• Director of Engineering for Web Applications
• Paul J DeCoursey
• Principal Software Engineer for Web Applications

Git workflows

• What is this and why do I care?
• Git is a distributed collaboration tool
• A git workflow is how software developers use git to collaborate in a productive way
• Merging and deploying of code shouldn't be a job in and of itself
• We need consistency in our usage of git
• Using the same workflow across teams and projects will help
  • on-boarding
  • ops
  • development resources moving between teams
  • communication across teams

Some examples

• centralized workflow -- commit directly to master
• feature branch workflow -- branch off master, do your work, merge to master
• gitflow -- very robust great for versioned scheduled releases
• github flow -- simplier great for continuous deployment

centralized workflow

centralized workflow

• does not scale well with larger teams
• no forks
• code reviews are not built in
• wild, wild west

feature branch workflow

feature branch workflow

• feature branches can get out of date with master
• as teams grow integrations can become unruly
• no forks!

gitflow

[http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/]

gitflow - pros

• supports forks and pull requests
• clear what the current "version" is
• tracking what changes are in each "version" is easy
• seems to fit well into good agile practices
• there is always an active development branch and a passive master branch

gitflow - cons

• there is always an active development branch and a passive master branch
• loosely dependent on the idea that each sprint is marching towards a new "version"
• tightly coulpled to the idea of releases with multiple features

github flow

[['https://guides.github.com/introduction/flow/index.html', 'http://scottchacon.com/2011/08/31/github-flow.html']]

github flow - pros

• simple, one main branch that represents the project
• features are done on branches and can be independently developed and tested
• supports forks and pull request
• tracking what changes are in each feature is easy

github flow - cons

• easy for parallel features to diverge from the base and become a nightmare for merging
• practically perfect in everyway

SPS CodeFlow - Overview

• Essentially github flow, but with some added guidelines
• developers should fork the projects and do all work on their forks
• main project should only have master branch
• pull requests are built and can be deployed to test environments
• master branch commits are tagged with build id
• code that is deployed will be tagged in master of deployment date

SPS CodeFlow - Pull requests

• All code changes need to go through a pull request
• Everyone reviews the code

SPS CodeFlow - Versioning

• YYYYMMDD.HHMMSS[-pull-][-] (utc time)#>
• Major version is the current utc date stamp
• Minor version is the current hour, minute and seconds
• If the build is of a branch then the branch is appendended
• If the build is of a Pull Request, then pull-# is appending along with the branch

SPS CodeFlow - Versioning

--extra-index-url https://repo.fury.io/NqvNFCysuFzM847zBn88/spscommerce/
pyweb-core==20141106.102432
Django==1.6.2
logstash-formatter==0.5.8
redis==2.9.1
passlib==1.6.2
pycrypto==2.6.1
django-cors-headers==0.12
						

Build artifacts

• Build artifacts should be built and submitted to an Ops approved artifact repository, such as Gemfury
• Dependent artifacts should be referenced by the exact build number
• Simple and precise definition of builds
• Configurations
  • Should not be in the build artifact
  • Should be in environment specific artifacts
  • If default configs exist in builds they should default to a broken state

fin

THE END