-
Notifications
You must be signed in to change notification settings - Fork 2
Release & development flow
Our applications are usually built for three different environments:
- Test
- Staging
- Production
Branch: develop
Builds on push to develop
Intended for developers and internal Q/A
Branch: release/*
Intended for customer distribution / external Q/A.
Builds must be manually triggered
Branch: master
Intended for production / public release
Builds on push to master
The git-flow-avh model is used: Using git-flow to automate your git branching workflow
Most important take aways from git flow:
- There are only two long living branches: develop and master
- There can be only one release/* branch which contains the next release (this process is called 'preparing a release')
- When a release (the content of the release/* branch) is actually being released it is merged to BOTH master ander back to develop, after which the release/* is deleted (this is managed by the git flow commands)
- Fixing a production release (called a hotfix in git flow) is done via a hotfix branch, which is merged back to BOTH master and develop
- Versioning of the app is managed in package.json using standard semver convention
- Odd minor version is used for development (test) (0.1.x, 0.3.x, etc)
- Even minor version is used for releases (staging / production) (0.2.x, 0.4.x, etc)
- Bumping version should always be done using npm version minor / patch
New development is done on the develop branch. Direct commits in the develop branch must be limited as much as possible, all new features should be implemented in feature branches according to the git-flow model after which they are merged back into develop.
Preparing a release basically create a new branch release/{name / version of the release} using git flow
The name of the release branch is {major}.{minor} for the next release. So for example, if develop is on 0.1.2 the next release version would be 0.2.0, so the name of the release branch is 0.2
-
git flow release start {name / version}- in above example 0.2 - after starting / preparing a release you switch to the new release branch that is just branched from develop (in above example 0.1.x)
-
npm version minor- in above example this causes a version bump from 0.1.x to 0.2 -
git flow release publish- to push the newly created release branch to github -
git checkout develop- go back to develop for version bumping -
git merge release/{name / version}- to get the version bump back into develop, in above example develop is on 0.2.0 after this command -
npm version minor- to get develop on the next odd minor version, in above example this results in 0.3.0 -
git push && git push --tags- publish changes on develop branch to github
After this, trigger a build manually in Bitrise
Any needed bugfix on release/* can be done directly on the branch. When all fixes on this release/* are committed and pushed:
Until this is handled in the build plan: version patch the release:
-
npm version patch- in above example this results in 0.2.1
And trigger a build in Bitrise.
So it will be clear to the testers there is a new version of the app with the bugfix. Since release/* is build on push make sure the bump is done before pushing.
Releasing a prepared release to production is done using standard git flow tooling. Remember, this triggers a merge to BOTH master and develop. Depending on the commits on release/* this might result in conflicts on develop, please take extra care when resolving that the version of develop is maintained and not overwritten with the version of release/*
git flow release finishgit push && git push --tags
As per git flow hotfixing is done in a branch from master:
git flow hotfix start
After implementing the bugfix in the hotfix branch, version bump patch the hotfix and finish it:
-
npm version patch- in above example this would result in 0.2.1 (or 0.2.2 depending on the example) git flow hotfix finish
After the push to master a build is triggered.