Today we have a guest editorial from Kendra Little as Steve is on vacation.

While Redgate Software tooling works well with many version control systems (VCS), when starting a database DevOps initiative it’s often valuable to evaluate your tooling and consider using a new VCS for your project. One of the main arguments for making a change is streamlining workflows for your project with an integration tool such as Azure DevOps Server (formerly TFS) or Azure DevOps Services (VSTS).

At Redgate, many of our recent articles on Database Continuous Integration showcase Azure DevOps because of the benefits of the streamlined workflow that it provides for the SDLC lifecycle. In a single tool you can:

• View a repo of the current database code, complete with branches and history
• Use pull requests (Git) or code reviews (TFVC) to shift code review left in the development process
• Integrate work items into the development process
• Create pipelines for automated builds and deployments for CI/CD, complete with approval gates, when desired

Having these capabilities in a single tool creates “one place to look” for that project, which reduces overhead for documentation and communication about how automation is working, right out of the box. Or right out of the cloud, if that’s how you roll.

For Database DevOps in the Microsoft Data Platform world, the toolkit provided by Azure DevOps is the clear leader in the space currently. Microsoft now recommends Git as the VCS of choice, over TFVC.

While Git is not without its downsides and does introduce more complexity than other VCS options such as Subversion (SVN), it has largely taken the developer world by storm. This image shows a Google Trends comparison of git and svn search terms since 2004. The number 100 represents peak popularity.

Popularity is not the only criterion to use when choosing a VCS. But it is still a consideration in terms of the amount of documentation and online resources that will be available for your development team now and in years to come for emerging features.

In combination with the workflows offered by Azure DevOps Server/Services, the popularity of Git and Microsoft’s demonstrated investment in it-- including suggesting Git as the best/default option for CI/CD workflows-- make a compelling case for teams to consider Git as a VCS system for a fresh database DevOps initiative.

When considering a change like this, however, be careful to choose your battles. Is another VCS or orchestration tool so deeply entrenched in your organization that suggesting a change could risk the failure of your entire initiative? In that case, integrating with the existing tooling may be the only viable approach with your organizational culture, and you might be better off looking for plugins for that tooling to shift code review left or bridge the gaps that you see.

DevOps is about continuous improvement, and sometimes you need to make that improvement one step at a time. Because it’s important to meet people where they are, Redgate will continue to provide extensions and support for lots of different tooling outside of the Azure DevOps family, and we also make custom CI/CD solutions possible with SQL Change Automation PowerShell components.

All that being said, I personally choose Git.