For the purpose of this article, Bitbucket is chosen as a Git hosting service. In order to prepare the “communication” between Git hosting service and your application, the following steps need to be performed:

Since we have presented a way to review the history of committed changes using Git, Team Foundation Server and Subversion, let’s check how the same can be achieved when working with the Mercurial source control system.

In previous articles, I have already covered the revision history for Git and Team Foundation Server. Similarly, this article covers the revision history of committed changesets using Subversion as the source control system.

Similarly, as described previously in this article, where the revision history is covered for the Git source control system, we’ll present the workflow of reviewing the history of committed SQL database objects using Team Foundation Server (TFS) source control system. In order to use TFS and have SQL database objects being version controlled, Visual Studio is required, as well as TFS server, either installed on a machine or TFS through Team Services, which is actually TFS “in the cloud”.

Introduction

In my previous article, we went over the basics of Mercurial, as well as some arguments why using it is critical for database administrators. Among many reasons, it allows us to easily track history and changes to our scripts, which in turn makes it easier for us to experiment and enhance our toolkit, since we can do so safely without fear of permanently causing damage. In this installment, we are going to go into more depth on the specifics of two feature of Mercurial that, once harnessed, can add significant efficiency to our coding workflows.

Introduction

In my previous article, we went over the reasons why DBAs should use version control, as well as the benefits of Mercurial as a specific choice. We also gave three examples of instances where source control can come in handy (though to be honest they were picked from a much longer list). In this article, I’m going to go a step further and actually walk you through setting up your first repository (locally for now, we’ll go into setting up a remote one later), making your first commit, and making (and viewing) changes to your newly tracked files. Let’s get started!

Introduction

As DBA’s we usually have a lot of utility scripts sitting around that we use in our daily work. Examples might include things like common administrative duties (setting up users for an application for example), installing standardized maintenance routines, or even something as complex as a home grown utility database. Often times these scripts languish on some network share or (worse) our own computers, with previous versions lost for all time when changes are made. For those of us that come from a development background, this approach makes us shiver. Keeping code that is not in some kind of version control system is inexcusable for any level of software professional, and DBA’s should be no exception. Used for quite some time by software developers, version control is a wonderful tool for administrators as well, for reasons we will discuss. But first, I want to talk a little bit about my version control system of choice, Mercurial.

Introduction

Source-code versioning control has always been at the core of Continuous Integration (CI) development practice. In fact tools by JetBrains and Microsoft (amongst, many vendors) have provided development teams an ability to implement some form of CI in their Software Development Lifecycle (SDLC). In recent years, however, the focus of an effective CI strategy has expanded to include mechanisms of keeping track of database files. The possibility of this gradual expansion has largely been driven by two factors:

1. Stability and maturity of source control systems such as TFS and Git
2. Availability of freeware and proprietary tools that make it convenient for data professionals to keep control of their database source code