Note: This is part 2 of a Sweetcode blog post series about source code management.
In a previous post, I discussed how software development is fundamentally different today from in the past. I also provided an overview of how source code management practices must evolve to meet the new challenges.
Below, I’ll take the discussion a step further by exploring how source code management tools and workflows have evolved over recent decades.
Traditional Approaches to Source Code Management
Source code management strategies are nothing new to most enterprises. Using basic source code systems like Git or Subversion, enterprises have been centralizing the way they keep track of their app source code for years.
Git, Subversion and the like are useful tools for basic source code management. But they were designed in a different era. They were created in the age of “Waterfall” software development— which meant code was released according to a slow, staccato rhythm. Waterfall is totally at odds with the continuous delivery methods enterprises need to follow today in order to stay ahead of competitors and meet customer expectations.
Nor were these tools designed to meet the needs of enterprises out-of-the-box. They were instead created for developers, by developers. After all, it was programmer extraordinaire Linus Torvalds who built Git, with the goal of helping his community of Linux hackers manage their source code. Subversion, an Apache project, originated for similar reasons.
This is not to knock tools like Git and Subversion. They are great pieces of software. They work well for loosely organized groups of hackers building open source projects.
Git Is Not Enough
On their own, however, traditional source code management tools cannot meet the demands of modern enterprise application deployment. They do not provide the end-to-end visibility and integration that an enterprise needs to deliver software continuously. They lack the ability to provide a single source of truth that everyone on the enterprise IT team can use to streamline the software delivery process.
In the next post in this series, I’ll explain why Git and other traditional source code management tools are not sufficient to meet the demands of enterprises.