git - Continuous integration workflow - emergency use cases -
let me first describe simple ci workflow (we use git, jenkins, maven, nexus): project, creates branch master branch, makes changes, verification , code review done. puts request change.
the following automated. changes merged master , queued release. deploy, every item in queue, binary built master branch (using tag or commit id), run test suite, , deploy 1% traffic. within 12 hours, have automatic analysis of performance numbers , business numbers, @ point give 100% traffic. pick next item in queue.
this separation of 1 change per 100% release important because becomes difficult debug wrong if multiple changes in 1 release.
this work fine, until breaks.
- say push feature1 1% traffic, find numbers bad, , in 12 hours takes figure out, feature2 has been merged master. in case, git revert needs done on feature1, if want feature2 go , revert buggy feature1 till fix bugs.
- in above case, feature1 important, , found wrong , know fix. need revert feature2 master, merge feature1 fix master , reset queue.
- if there emergency fix outside of features, , production @ feature0 @ point, feature1 on pilot. want emergency fix on feature0 go 100%. time again need revert feature1 master.
is there workflow, using multiple branches instead of master or adding more automation, avoids git reverts - in cases 2 , 3 developer has finished his/her feature has done nothing wrong.
looks you're doing master. how git-flow-ish model using develop , release branches, plus separate branch each feature , each bugfix?
example of how work kind of scenarios mention:
9am production (100%) on release tag 1. feature finished branch featurea merged develop
10am daily rollout time ... merge develop release, take cut (tag 2) , roll out release tag 2 1%
11am finishes coding feature b , merges featureb develop
12 noon emergency! feature has bug. roll production (1%) tag 1. take branch release tag 2 (remember release branch not contain feature b), called bugfixa, , start working on fixing bug.
4pm bug fix gets signed off - merge bugfixa release, take cut (tag 3) , roll. merge bugfixa develop, , run tests against develop make sure bugfix doesn't clash feature b.
10am next day - rollout time! merge develop release, take tag 4 , push 1% - pushing feature b is
meanwhile somewhere tag 3 (containing feature , patch) passes 12-hour test , moves 100% ...
Comments
Post a Comment