Drupal: How to block a user by email programatically
Many times, while administering your drupal website, you must have encountered…
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:
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:
For every new feature development, fork a branch from Stage
When the code is ready to deploy, merge it to Master. Dont delete stage branch
Stage branch must be
Master branch must be
Have a look on How to enforce strict policies on git branch
Many times, while administering your drupal website, you must have encountered…
Introduction When I migrated all of my drupal-7 website to drupal-8, I wrote…
This is regarding the timeit implementation in python. The basic requirement…
Its good to write unit tests cases, and this part is mostly forgotten by…
Introduction In your backend and frontend projects, you always need to deal with…
Code that I have is: It was: I changed it to: So, I needed to change button type…
In this post, we will see some of the frequently used concepts/vocabulary in…
System design interview is pretty common these days, specially if you are having…
Introduction You are given an array of integers with size N, and a number K…
Graph Topological Sorting This is a well known problem in graph world…
Problem Statement Given a Binary tree, print out nodes in level order traversal…
Problem Statement Given an array nums of n integers and an integer target, are…