Eclipse/STS IDE showing compilation errors in java code inspite of all dependencies installed
I have a Java project and dependencies are being managed through maven. I have…
July 05, 2018
Its essential to prepare a git branching strategy. This helps greatly in preparing a build management plan and deployment plans. You can also make a plan to test your new features, bug fixes and deploy it.
Generally, we have one Production environment which is being live for end users, and there are one or more environments called Staging, QA, Dev environment. For a clear and smooth management of source code, lets see how we can manage our code so that it does not create chaos.
This article talks about Git, source code management and version history solution.
I assume we are having one production environment and one stage (or QA or dev) environment. Production environment is for builds which is live and users are using it. Other environment where you deploy builds for QA team to test and certify changes that are going to be live on production.
There is one Master branch which is present in git by default. Master branch will reflect always code that is live on production. In simple terms, Master branch code is equal to production. Do not try to commit any code in this branch which is not tested, or is under development.
If you keep on commit your new feature work on Master branch, and if suddenly a bug came which needs urgent fix. How would you bring the state which is live on production. You may end up putting untested code on production along with your bug fix.
This branch is the home for all new development work. If your sub-team is working on a new feature and is developing code for that, this branch will have code for those development features. But note that, this branch too should not have any untested code or incomplete code. This branch will have new development code for a feature that is complete or with minor bug fixes.
Now, the question arises where do we do the development work?
For every new feature you want to work, Fork a new branch from Stage branch. You can name this branch as Feature-XYZ etc. And, you can commit any incomplete or intermediate code there. You can test, do bug fixes complete feature from this branch. These branches usually have a limited life, and are deleted when the work is done.
There might be a situation where there is blocker bug came in production environment and you need to urgently fix it. Fork a new branch from Master branch, and name it something like: HotFix-XYZ or BugFix-ABC. Test it in that branch only, and merge it back to Master only when fully tested. These branches usually have a limited life, and are deleted when the work is done.
When we are certain that our feature is completely developed and is tested by developer, they can create a pull request for this branch. And, merge it in Stage branch, delete that branch. So, stage branch will have all development changes. You can prepare a build from stage branch and deploy in your staging environment where QE will certify this build.
As I said before that Master reflects production. So, when you are ready to deploy all new changes to production, you should create a pull request for stage branch. Merge it to Master. Do not delete stage branch.
When we have tested code from HotFix branch, and is ready to deploy. This branch will merge into Master branch. Note: For every merge from HotFix branch to Master, we need to keep Stage branch in sync with Master.
Every commit in Master is a new Production build or a new release. We should tag master branch for every such release. And, give it a name like 1.0.0, 1.1.1 etc. Tagging helps in identifying what code went live for which version of build. It can help in rollback to a certain point, if required.
Note, we should have our project per repository. And, do not treat a repository like a directory which can have multiple projects.
For these standards, we can have 3 jobs for every repository.
This should prepare builds from master branch, and post builds into some artifactory with Master tag.
This prepare builds from stage branch, and post builds to artifactory with Stage tag.
This job is parameterized to take branch name as parameter. This helps us in creating builds from our feature branch or hotfix branches which are not persistent.
Note: Tags is necessary in Jenkin jobs which helps in posting builds with different name in artifactory.
When you are about to merge code from some branch to a branch, there are three options are given:
This option brings all commit history from source branch to destination branch. If the source branch has 50 commits, then all those 50 commits will come in destination branch. With this option, you will not loose commit history.
This option combine all commits from source branch into one, and combine all those commit into one. With this, we loose commit history from source branch.
Forget about this option for now.
When we commit Feature branch to Stage branch, we can use “Merge and Commit”, as we may use the commit history. But, while merging into Master branch, we can use “Squash and Commit”, as whey would I want to see any dirty commit or incomplete commit in master branch. I would just want to see complete feature commit as one. This serves my purpose.
Note: Above interpretation may change case to case.
In git, you can force some standards or security like:
Example: Only Gorav can merge code into Master branch.
Example: At least 2 reviews are required before merge
Have a look on How to enforce strict policies on git branch
I have a Java project and dependencies are being managed through maven. I have…
Introduction I had to write a CICD system for one of our project. I had to…
So, here we are using input variable String[] args without any validation…
Many times, while administering your drupal website, you must have encountered…
Introduction In the ReactJS project, you are having aa parent component and a…
Introduction This post has the complete code to send email through smtp server…
Introduction In this post we will see following: How to schedule a job on cron…
Introduction There are some cases, where I need another git repository while…
Introduction In this post, we will see how to fetch multiple credentials and…
Introduction I have an automation script, that I want to run on different…
Introduction I had to write a CICD system for one of our project. I had to…
Introduction Java log4j has many ways to initialize and append the desired…