Why the Recipe Reveal Team Opted for a Version Control System

Majorly, every software has a huge amount of code files and code in it to combine all of them and build a useful software that can solve some real world problems. And in the early days of tech evolution, we didn’t have any Version Control System, which led to issues like no collaboration, not being able to track which developer changed which part of the code, and more, which we will be discussing in this article with a simple analogy to get the glimpse of the importance of the Version Control Systems like Git, Mercurial, Fossil, Darcs and others.

Taking the analogy of the product Recipe Reveal as an example, which has a decent amount of frontend and backend code in it, it provides all the Indian Recipes in a single place with a tool to track your health goals and other features. The developers faced a problem in the initial stage of building this product, which was the collaboration for different features like recipe filters component in all recipes page, personalised AI chatbot component, time-based recipe suggestion component in the hero section, and a lot of others, and tracking which team member has implemented which part of the product.

Initially, they used the traditional Pendrive System, where the tech lead created the first version of the product, which included just a landing page listing the top recipe of the platform, featured recipes, about Recipe Reveal, and a few other sections. He launched the product on PeerList and shared it with his network. People loved it and demanded more features. But with the rising demand for features, the tech lead realized he couldn't implement all of them himself and decided to get help from some junior developers to ship those features. He created a zip file of the current codebase and shared it with his two junior developers on a pendrive. The first developer's task was to build the recipes page, where users could search for specific recipes from their database with premium filters, and the second developer's task was to add the AI-based personalized chatbot. Finally, the tech lead was implementing the Auth system, where users could sign up for the platform and access the features built by the team.

Now, as soon as the tech lead got the implemented feature on the pendrive, he realized that he had made a blunder. The pendrives looked identical, and he couldn't recognize which one contained the code he was looking for; that was fine, as he could see after inserting it into the computer. But the main problem was integrating the code provided by the developer into the code he had, because there was still a lot of work to do, and there was no point in taking help from others if he had to integrate the code himself, wasting his time. Interestingly, he was also unable to track which developer had made what changes after a certain iteration on the codebase. All three of them had their own version of the product: the tech lead had the first version with some features, the first developer had a codebase with some features, and the other developer also had his own version of the code with other features. And in the future, if the new version had a bug and it still got into production, there was no way to backtrack to the previous working version of the code and revert to it.

It was a total mess; the main problem was:

1. Code Tracking

2. Collaboration

So, what is the solution?

The tech lead comes up with the Idea to build a simple tool that they can install on a pendrive, which will track the code changes and who made the change in them, track the time, and store the different versions of the code in the same pendrive. The reason for building this tool is to solve the code tracking and debugging problem.

Now, whenever someone changes even a single line or character, the tool tracks who made the changes at what time, and what the changes are. And more importantly, they were able to revert to the working version of the code in case they pushed the breaking changes to production, patched the breaking changes, and again pushed the working code into production.

This tool solves the one major problem, which is Code Tracking. Now there is still one problem: multiple developers can’t work on the same code in parallel, and also there is confusion about which version of the code is the final one and can be pushed to production. Like the 1st developer added the filters in the recipes pages, the 2nd developer added the chat interface, and the tech lead added the authentication flow, still there are 3 different versions of the code. We still can’t finalize which version of the code should be in production, and we still need to merge all the code into a single source code manually; that may cause other issues in production.

This problem was addressed by creating a central server that stores all the different versions of the code using the same tool installed in the pendrive, but with additional features like maintaining a single source of truth on which developers can rely. Like, now the tech lead has completely moved all the code from the pendrive to the central server, which also has the main version of the code, which will be in production, and other versions as well. So that other developers can work independently, and after the final changes, it can be merged into the main version very easily.

In the market, there are a lot of similar tools like the tech lead build for their team, which are Git, Mercurial, Fossil, etc, and the central servers like Github, Gitlab, BitBucket, AWS CodeCommit, and many more.