Great content delivered right to your mailbox

Thank you! Check your inbox for our monthly recap!

Experienced coders working in teams have long been using version control systems to keep track of the history of changes in the code base of applications. And historically, it has always been a centralized system, since it was the state of the art in a pre-git era. This fulfilled the requirements of the time:

  1. provide a source code referential;
  2. provide history tracking; and
  3. provide a certain level of release management by either:
    1. locking files to prevent updates or
    2. allowing code base branching

For a few years now, our department had been using TFS as both its source control system (TFVC or team foundation version control) and its agile management (read: work items, sprints and backlogs). This gave us the advantage of having a single point of reference for source code management and agile project management. Since we had only worked with centralized systems before (e.g., Apache Subversion), this was considered a significant leap forward in features, not to mention the tight integration with Microsoft’s development environment, e.g., Visual Studio.

Nevertheless, our department faced significant issues with TFS, which every team has faced at one time or another:

  • the bottleneck associated with pending work in general (“WIP getting accessor X done” or the “Fixed feature Y after running test in environment Z” code change message. Does this sound familiar?).
  • And in particular, the code reviews (“Changes following code review”).

Not only are code reviews mandatory for SOC-2 compliance, but simply put, this is just a common software development process practice along with a UAT (User Acceptance Test) that is common to the agile world.

Let’s assume the team members are not using the dreadful practice of locking the files they are working on (sometimes for days, and DUH! he is on vacation for the next week). The bottleneck is still present unless development or release branches are enforced to enable other members to publish their work or release a version of the application. This becomes critical for a department using an agile methodology to get the work done and continuous delivery to release it. From the start of the integration of continuous integration and delivery, TFVC has not delivered in terms of branching, tagging and team collaboration (oh, yeah, right, shelvesets). Meanwhile, git had been on the market for seven years and was still enjoying a tremendous amount of hype.

With new developers joining our team with diverse experience in using git and migrating from TFVC to git a choice needed to be made. The department decided on git and nobody misses TFVC.

→ Read Part 2: How We Moved from MS Team Foundation Server to git


Written by Guy Lépine Employee @ Sherweb

Guy Lépine has a degree in Computer Engineering from the Royal Military College of Canada in Kingston, Ont. He has worked as a computer engineer in the private sector and has also held jobs as a software developer in various application domains. Guy has a diploma in Project Management from the Université de Québec à Montréal and in Electrical Engineering Specializing in Computer Security from the Université de Sherbrooke. Guy has participated in several software development projects using the Agile methodology.