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:
- provide a source code referential;
- provide history tracking; and
- provide a certain level of release management by either:
- locking files to prevent updates or
- 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.