Continuous Integration(CI) is not a new topic to the Software Developers, yet there are companies picking up the trend. CI will help you to commit and push your code at the convenience of your IDE (Visual Studio 2017 in my case) to Visual Studio Team Services Code Repository and trigger a build. Your build can be defined in the manner you want it to be by adding different tasks such as restoring NuGet Packages, running unit tests etc. You can order your build to copy the build output to a given path. This is much easier when you have a team working on the same project as it avoids last minute integrations.
Visit https://vs2017poster.azurewebsites.net/ for the infographic.
Today I got to know some best practices in using Git, Distributed Version Control System from our onsite team. So I thought of sharing with you all.
Assume that you have a Master branch in Git. Then what they do is create a branch called Development from that master branch. Master branch is the working software in a releasable mode after Quality Assurance Development branch is for the developers.
When there is a new feature to implement or a bug to fix, in their terminology they introduce as an “issue”. The issues are listed in “Jira”, bug tracking system. Then several developers will be assigned to that issue. Those developers will create a new branch from development branch and name it according to the issue number reported in Jira. Lets say the issue number is MWL001, then the branch name will be MWL001. Those developers will pull, commit and push to MWL001 branch. After they completed the issue MWL001 they will merge the MWL001 branch to development branch for testing and quality assurance.
After proper testing and QA the development branch will be merged with master branch for the product release.
This is how they use Git. The procedure is very simple and clean.
In my new project I’m working with Git and BitBucket. Git is a Distributed Version Control System where the most interesting thing I found is I can have a local repository as well as a remote repository. I can easily commit my changes as soon as possible to my local repository and I can push only when I’m done with my code. BitBucket is where we host our code for free.
I have also worked with Mercurial, which is also a DVCS. At initial project stage, we faced lot of issues when we merge the code. But later when we get used to the system we found it much easy to use.
Here are some important links I found in my work. Hope this might help you to get in to the DVCS deep sea.
Introduction to Distributed Version Control System
Distributed Version Control Systems
- Git – http://git-scm.com/
- Mercurial – http://mercurial.selenic.com/
Distributed Version Control Systems Code Hosting
- GitHub – https://github.com/
- BitBucket – https://bitbucket.org/
Converting Subversion to Git with History