Visual Studio Team Services comes with many capabilities and features to support your version control needs. One of these features is an unlimited amount of free GIT repositories. The other valuable features are integration of work, build and release out of the box. This is a small how to when you want to start with GIT within VSTS.
The start, setup structure.
Create your VSTS account. While you also can create an unlimited amount of VSTS accounts it advisable to think of how your setup your structure.
You can create all projects in one VSTS account or you can create a VSTS per project. Defining a projects scope is already challenging for many systems.
A good decision maker can be to look at ‘single entities of deployment’, define the parts of the system that can be deployed in isolation. When a system can be deployed in isolation it needs its own GIT repository. Maybe even its own project, or maybe it can be combined in the same project because the system parts have the same cadence and a tighter dependency. For example an API and its Angular Frontend solution.
1. Signup for your account: https://www.visualstudio.com/nl-nl/docs/setup-admin/team-services/sign-up-for-visual-studio-team-services
2. Create a project with GIT as version control system.
3. Add the MD file, this will fill the Git repo with the first file and makes it ready for use.
4. Create a ‘develop’ branch. GitFlow (see: A successful Git branching model) is a good branching strategy to start with. It uses master and develop branches as a basis.
5. Set develop branch as default branch via VSTS settings (upper right corner). Otherwise all pull requests will default to master, which is annoying.
6. Open Visual Studio (or any other favorite IDE), connect and clone to the Git repo. https://www.visualstudio.com/nl-nl/docs/git/gitquickstart
7. In Visual Studio (make sure you have develop checked out) add the Git ignore files. Depending on the project you are planning to make. See this collection of Git ignore files https://github.com/github/gitignore
8. Create the solution you want to make for this project. Within Visual studio make sure you disabled the option ‘make new Git repo.’
9. Stage, Commit and Push your first changes to the develop branch VSTS.
10. Create Build definition for the develop branch. Make it succeed.
11. Configure the Branch policies for the develop branch via settings. Select the just created build. From now on team members only can add changes to the develop branch via a Pull Request.
12. Do the same for master. First merge the develop in to master, commit and push the changes.
13. Also create a build and set the branch policies for the master branch. Now no one is able to make changes to the master branch without a Pull request.
14. Optional, setup a release for the master branch (and develop).
A note on the release in this flow. When you connect the same build as the pull request validation build to the release for continues deployment, the release will start. This is something you don’t want. So there is a need for an additional build, which is triggered after commit, a continuous integration branch. This one can be connected to the release.
And we are all set, ready to do some real work.
The real work exists of making feature branches, code changes, merge the changes and make pull request.
Make feature branch.
Following the GitFlow branching model (see: A successful Git branching model) first a feature branch need to be made.
Within VSTS this can be done from the PBI you’re going to work on.
Name the feature branch (the good thing the PBI is already linked for traceability.) you also can add the task.
Next, do your coding magic. But, first get the feature branch within Visual Studio. (note: often you have to sync before you see the newly created feature branch).
Now you can do your coding magic. Freely commit and branch your feature branch at will, till you and your teammates are done and ready to make a pull request to develop. Don’t forget to publish the branch and, or push the commits.
Make the Pull Request.
Before making the Pull Request you have to validate if the changes in the feature branch don’t interfere with the changes in the develop branch, maybe some teammates made some breaking changes for your story. So first, checkout develop and pull all the changes in.
Now checkout your feature branch and merge develop into it. Solve all merge conflicts.
Now, you are ready for a Pull Request to develop.
VSTS will open with the ‘create Pull request’ screen.
Validation will start and when all good (ping the team for a code review). The Pull request can be completed and the changes merged in to develop.
After the pull request is completed and the code is merged in to the develop branch the CI build is kicked off. When the CI build is done the CD release will continue (see note at start up, after bullet 15).
Ready for a release.
All validation done, all coding done, sprint done, ready for a release. Make a release branch from develop and put it as a Pull request in the master branch.
Sync develop and make a release branch.
There is some time for a few minor last changes (rather don’t do it, than you also have to make a PR to develop) and make a PR to master.
Builds starts, reviews done and complete the release. Same note here on the release and the two builds (PR build and CI build for CD release).