Starting from the top and in the context of this article SCM is the acronym for Source Code Management. The purpose of this article is to give a high-level introduction into the area of SCM and in particular how this can be setup for working on Dynamics 365 implementations.

If you are interested more in Git specifically there probably is no better resource than the free eBook written by Scott Chacon and Ben Straub available on the main Git website. The rest of this post is more of a high-level comparison between Git and DevOps in the Dynamic 365 world.

The tools we can use vary from open source like GIT to commercial products like TFS and even the once very popular visual source safe product. These tools are effectively version control systems for code repositories so that we can track and make changes to files.

Perhaps the two most common version control products we see today for software development are GIT and Team Foundation Version Control (TFVC) aka. TFS. The latter now being referred to as DevOps for the rest of this article. These two are not in direct competition, in fact Microsoft state that GIT should be used for version control not TFVC unless you need the centralised features included within TFVC. GIT is the default repository type in DevOps.

Microsoft has embraced GIT to the point where in 2013 it was introduced within DevOps as a repository type and within Visual Studio 2013 where it was integrated within the IDE. This means we can do our extensions/coding as normal within Visual Studio and use this when we wish to check in code to a GIT repository rather than using perhaps other tool options:

  • TortoiseGit
  • GIT Bash
  • GIT GUI
  • GIT Command Line

Ultimately, that decision typically comes down to the developer preferred tool, as they all will achieve the same end result which is to clone a repo locally from the server, view history, revert code changes, make branches, commit changes, pull requests and everything in between. Though remember with GIT, every developer is in fact its own GIT server instance because it a decentralised approach which means if the master code was ever lost on the server, both the code and change history can be recovered from the developer clone.

The most basic difference between the two is that TFVC is centralised and GIT is distributed. The advantage of distributed is that developers only need access to the centralised repository to sync changes. All other operations like branching, commits, merging can be done locally on the developer machine with no internet connection.

The purists out there will no doubt say that the Command Line and GIT Bash (Unix type shell) are the best option over using GUI tools. The general consensus when learning GIT is to at least start out with the command-line then move to GUI tools later if you wish as that gives a deeper understanding of the process. Ultimately there are some operations that can only be done by command line/Bash especially if you get conflicts or other errors. I’ll leave this decision with you.

DevOps and Git Perfect Combination

By combining DevOps with GIT we get the very best of both worlds:

  • Excellent Version Control System
  • CI/Build Automation
  • Project Management Tool/Sprint Planning
  • Ability to link code changes to a specific story

Whilst we could use DevOps as the code repository and version control system, it is now mostly discouraged as the version control offered by GIT is far better. Of course, unlike previous versions of Visual Studio where you could only use the version control IDE with TFS this has now been opened up which means that Visual Studio can work with other GIT servers such as hosted GitHub or your own dedicated Git Server. DevOps doesn’t even have to be used if you don’t need or want to use it.

CRM Dynamics Setup

Whether on-premise or online all we have to do is setup GIT as the version control repository type within DevOps and then browse to this URL from within Visual Studio as normal. The typical DevOps scenario:

  • Setup a GIT Repository for version control within TFS

For the .NET code and unpacked CRM solution XML files

  • Use DevOps for the sprints, user stories and for the continuous integration (Build definitions) along with being the main interface for browsing code, adding branches to sprint stories etc

Link: Managing multiple CRM solution development pipelines in parallel (change control, merging) and ALM.

If looking for setting up Visual Studio with GitHub or Visual Studio online this is a good article. This article was also a good reference on GIT.

Much more to come on this subject and more detailed articles to be written on change control within the Dynamics 365 space.