Azure DevOps, Visual Studio, GitFlow, and other techniques from the heap

In essence, I am very curious. That is why, whenever I see, read or hear about something that piques my interest, I do not stop until I understand it and if it finally provides me with a benefit, I do my best to include it in my portfolio. This is something that happened to me, a while ago, with DevOps.

My interest in DevOps might seem odd at first. That is to say, that a person focused on Data like me, feels that DevOps can be of much use, it should not be very common. I say this, because I rarely find Data projects that include the use of tools like Visual Studio, Git, Azure DevOps, … instead of the traditional SSMS.

While in this article I am not going to talk about how to use Visual Studio as the main development tool in the data environment, I do want to delve into the use of GitFlow as a branch strategy in development.

But what characterizes GitFlow? It is a branch development strategy that was introduced in 2010 by Vincent Driessen. It uses a central server model called ‘Origin’, which allows each developer to work on a clone of the same, enabling the possibility of using push and pull between them.

The environment is made up of a set of branches with the following names and characteristics.

1. Production uploads are always made from Master.
2. Master must always be stable and ready to deploy.
3. The work is always done on Dev. Putting the focus on the product being releasable and available.
4. The Release branch is used to stabilize development.
5. When we develop a feature, it is done on a Feature branch.
6. Team members can work together on that Feature branch.
7. Feature branches always merge with Dev.
8. Feature branches are always removed after merge with Dev.
9. There is a branch called Hotfix to resolve critical production issues. In addition, this new branch will be merged with Master and Dev as soon as this problem is solved.

After this brief introduction, I will move on to comment on how to implement the use of this strategy in Visual Studio 2019. To do this, the first thing to do is install GitFlow from the Visual Studio 2019 Marketplace.

Once installed, we will only have to verify and map the default branches with their corresponding nomenclatures in our development. In our case, we will change the name of the Development branch, including Dev.

Now we have the possibility of creating both our feature and Release branches and completing our project with the successive commits.

In the example we are going to create the Feature branch with the name 1234-crm-staging. To do this, we just have to click on Team Explorer, GitFlow, Start Feature and name. Once these steps are completed, all you have to do is press Create Feature to complete the task. Simple

If we go to Branches, we will see that a new folder appears with the name of the Feature just created from Dev. Here we have it. Even comment that if you click on the history of the new branch, you will see that it is aligned with Dev, since it has just been created from that branch.

At this time, I make a modification on the branch and make the commit. And succeeded, we have uploaded our code from the 1234-crm-staging branch.

Now I merge from 1234-crm-staging to dev. To do this, I go to GitFlow and select the Feature branch, click on Others and select the check for Rebase on Development branch. That ends my feature and removes it from development by integrating in into dev.

And finished. We have our environment with the Dev and Master branches available to continue working on the rest of the features of our project.

CONCLUSION

The use of Integrated Development Environment such as Visual Studio is not only a matter of application developers, it is also very valid for Data Architecture cases and going beyond, for Data Science even. That is why, from my point of view, it is necessary to deepen the use of Azure DevOps as a system of good practices.

In future articles we will talk about Continuous Integration and Continuous Deployment. As they say that an image is worth more than a thousand words, I leave you this clipping to open your mouth about what the CI of a database would be.