In the previous article, we created a CICD pipeline which pushed code to the development environment whenever any change happens on the master branch. This is not optimal as usually, in any branching strategy, the master branch is associated with the production environment. Note that until now, we have been working on a single branch, which is the master branch.
In this article, we will use branches to isolate our code changes from other code changes. For example, we could be working on branch called “feature-114” in isolation of what is happening with other developers. We could have a branch for development activities, a branch for testing, and a branch for production, usually the master branch.
One famous branching strategy associated with Git is GitFlow. GitFlow usually dictates a branch called develop where all development activities are merged to. The code in this branch is usually released to the development environment. Development activities occurs on short-lived branches called feature branches. Once we want to release to the test environment, we create a branch called release branch. The code in the release branch usually gets deployed to the testing and UAT environments. One we are ready to go to production, we merge the release branch to the master branch, which gets deployed to the production environment. Below is a high level sketch on GitFlow:
For detailed information about GitFlow, please refer to the following article: http://nvie.com/posts/a-successful-git-branching-model/
Let’s go on and create the develop branch. Open the Branches tab in VSTS and click “New Branch” on the top right corner. Fill “develop” as branch name and click “Create branch”
Open the Git CMD, navigate to the iPaaS project and start by typing git status. This should give us the status of the current branch. We should get the following message:
On branch master
Your branch is up-to-date with ‘origin/master’.
nothing to commit, working tree clean
Type git fetch to fetch new changes on the remote repo, you will see a new branch called develop among the branches. Type git checkout develop to switch to the develop branch.
git checkout develop
Switched to a new branch ‘develop’
Branch ‘develop’ set up to track remote branch ‘develop’ from ‘origin’.
Now any change that we do will be done on the develop branch. We’ll configure this branch to deploy to the development environment, and we’ll configure the original “master” branch to deploy to the production environment. Similarly, a release branch will deploy to the test and UAT environments, but I’ll keep that out of the scope of this article. I’ll assume we have a development environment, and a production environment only, for simplicity.
First, let’s configure our build definition to listen to all branches and kickoff a build whenever a change happens on any branch. Edit the build definition in VSTS and go the Triggers tab, include all branches that you have (or might have)
That’s it, save you build definition and it should now listen to any commit on any branch and kickoff a build for that branch.
Now let’s change the release definition.
Open the iPaaSProject Release definition in edit mode. Click the continuous deployment trigger icon on the iPaasProject Build artifact. Include the develop branch so that a release will be created if anything is built from the develop branch also. Note that creating a release does not mean deploying the release. The deployment is set in the environment trigger.
Now we need to set the Development environment to listen on the development branch, meaning to deploy anything from the develop branch on the development environment. Then we need to clone the Development environment, rename it to Production, and set it to listen on the master branch. Finally, we need to set the environment variable for the Production environment to”PRD” (in contrast to DVT for the development environment)
Let’s go. Click on the “Pre-deployment conditions” icon prior to the Development Environment, enable the “Artifacts filter”, add the “iPaaSProject Build” artifact, then include the “develop” branch.
Under the Development environment, click the Clone option, rename the cloned environment to “Production” and do the exact same previous steps to include the master branch only this time. Also, normally, you would want to enable the “Pre-deployment” approvals” option so that automatic deployments to production are disabled and approved by somebody with higher permissions or in the operations team for example. For now, keep this off as this is just a tutorial.
Finally, click the Variables tab, notice that the environment variable is duplicated for each available environment. Edit its value for the Production environment to “PRD” instead of “DVT”. Now once we deploy, all Azure products will be created with “prd” as part of their name, instead of “dvt”. This will be our production environment.
Now go and do any edit to the develop branch, commit, and push to the remote repo and see your build and release created and your development environment fully provisioned. Switch the to master branch, git merge from develop, then push again and see your build and release created and your production environment fully provisioned. A magical end to a fully functional integration solution built end-to-end on Microsoft’s Azure platform. You can also find the ARM templates and PowerShell scripts associated with this series here.
This concludes this iPaaS series. I know it’s a lengthy one that required a lot of concentration to finish from your side, as well as from mine. Hope it was a beneficial one. See you in the next series!