I am working on a data platform project, the product itself is composed of several microservices. Our team is under great pressure of operation and mantainance. Thanks to the DevOps helps us keep the balance of development and deployment.
In this post, I illustrate how we maintain the CI(continuous integration) part, which contains: the branch strategy we adopt, the concept of DevOps, overview of the workflow, the tips.
next post, I will continue to explain the CD part(cotinous deployment)
1. Overview: 3-stage Branching Model
There should be at least two long-live branches:
Dev branch is the front line defensing bugs. This branch
will proceed continuous integration and testing. All the feature, hotfix, customized branches should firstly be merged to
Production(short for prd) branch is used for releasing the stable version of the product. In some scenarios, we need a
Int (abbr. Integration) branch, between
Prd branch. We keep 3 long-live branches: Dev, Release, Prd
- Dev: this branch accepts all the PR from feature branches, and unit tests will be done in this branch.
- Int: this branch accepts release PR
- Prd: this branch accepts stable, UAT PR
2. DevOps Concept
There are three concepts which I think we should keep in mind if we want to be good DevOps player.
Agileness: normal we apply DevOps together with the modern software practice: Scrum. We break down the requirements into smallers features. Instead of giving a breaking change at once after a long period of time, DevOps helps incrementally develop and build the product frequenctly.
Tracibility: we use
JIRAto trace the progress in each sprint. Starting the work by creating a feature branch from the
JIRAticket. After the feature branch has been merged, we can close the ticket.
Automation: by using configuration, scripts, and tooling we enabled to sync, compile, build automatically. The automation of the process eliminates repetitive manual work and human error. It vastly improve the efficiency.
step 1: start the sprint, developers work on feature branches which are created from DEV
step 2: finish the development then merge to the DEV.
step 3: unlike azure environment, on-prem we must merge to INT if we want to test in the runtime environment
step 4: sprint ends around the corner, we finish all the tasks and merge to the DEV.
step 5: create a release branch from dev: for example V0.2.3 (0 means: year; 2 means: PI; 3 means : sprint)
step 6: start to test in INT, found a bug
step 7: create a bugfix branch, merge to DEV first(make sure the main branch has the latest fix), then to release, INT
step 8: the Integration Test ends which stands for the success of the release
step 9: after the PI, we can roll out on PRO
Create a feature branch
git pull before your any actions
git pull git checkout -b new_branch current_branch
delete finished branch locally
git branch -D wanted_to_delete
Protect master branch In case the abuse of master branch, or any dangerous action to the release branch, it is better to restricts the access to master branch. when the feature https://stackoverflow.com/questions/38864405/how-to-restrict-access-to-master-branch-on-git
create PR and discuss with PR reviewrs eariler
merge to dev and automatically trigger the deployment