Aller au contenu

Continuous delivery

Continuous Delivery is the ability to get changes of all types—including new features, configuration changes, bug fixes and experiments—into production, or into the hands of users, safely and quickly in a sustainable way.

Continuousdelivery.com

Git strategies

Github Flow

Used at: Github

Source: Github Interactive Guides

So, why don't we use git-flow at GitHub? Well, the main issue is that we deploy all the time. The git-flow process is designed largely around the "release". We don't really have "releases" because we deploy to production every day

Github Flow, outdated guide

  • master branch only, no develop
  • Create topic / feature branches from master. Don't use Gitflow branch naming, use explicit, descriptive names!
  • Deploy the branch to production after the code review but before merging to master

Pros:

  • Immediate feedback and no merge

Cons:

  • Hard to scale (large teams have to implement a deployment queue to deploy multiple branches to production)

Release Flow

Used at: Microsoft

Source: Microsoft Devblogs (2018)

  • master branch only, no develop
  • Create topic / feature branches from master. Don't use Gitflow branch naming, use explicit, descriptive names!
  • Merge every topic or hotfix branch to master
  • When a sprint is finished, create a release branch from master to "freeze" the release

Pros:

  • Adapted to large teams
  • Simplify the Git Flow
  • One sprint = One deployment to production

Cons:

  • Hotfixes are cherrypicked from master to the release branch
  • Not continuous deployment!

Ringed deployments

Source: ALM Rangers Github (2018)

Ringed deployments is going further than simple canary deployments.

In ringed deployments, the feature is first rolled out to Canaries and must be approved by them. Then it's rolled out to Early Adopters - an approval is also required. When the 2 approvals have been collected, the change is rolled out to Production.

  • Allows Continuous Deployment to Production but limits the "blast radius" of a broken change. The users are protected (not the canaries lol).
  • Needs a strong validation checklist for approvals (DoD)
  • Supported natively by Azure Devops (even the combination of Ringed + Feature Flags is supported)