In almost all of the courses on Test Automation University, you have created some kind of source code file so far. But what happens when you suddenly have different versions of such files?
Do you version control them by hand, by making copies? Really? Or don't you version them at all?
Source control for software projects like every test automation project has become a fundamental part in the everyday life of a developer and automation engineer. Especially when one wants to work with continuous integration, continuous deployment, and delivery pipelines, there is no way around a Version Control System.
Whenever you are part of an automation project, you should have a solid understanding of how such a system works and how you can use it in your unique context to your advantage.
Many people's Version Control System of choice is to copy files into another directory, perhaps a timestamp directory or by renaming and incrementing the file itself. This approach is very common because it is so simple but is also incredibly error prone.
It is easy to forget which directory you were in and accidentally write to the wrong file or copy over files you don't mean to and so on.
A Version Control System, short VCS, is a system that records its changes to a file or a set of files over time, so that you can recall specific versions later.
In the context of software development, it is used to track and provide control over changes made to source code. Of course, it can also be used for maintaining documentation and configuration files of any kind. For example, for CI systems and CD pipelines.
A Version Control System allows us to revert selected files back to your previous date, revert the entire project back to your previous date, compare changes over time, see who last modified something that might be causing a problem and who introduced an issue. When you lose files, you can easily recover to an earlier date.
In regulated environments, there is no way around a Version Control System. All in all, we can round it up and say, version control is inevitable for the traceability of a development project.
It is obvious as for all software test automation projects, it is vital to have a Version Control System in place from its very first line of code.
There are a lot of advantages when a team uses a Version Control System for their automation projects. Here are the 4 advantages which I think are the most essential ones.
The first one is collaboration. When we want to work on automating tests as a whole team, which means testers and developers, much of the collaboration, communication and documentation happens in the Version Control System of that specific project.
Commit messages, pull requests, code reviews, comments, improvements and so on, the Version Control System contains the automation frameworks and the team’s whole working history and thus is a precious artifact.
Pipeline for CI/CD/CD
The second one is pipeline for continuous integration, deployment, and delivery. Without version control in place, it would be quite challenging or nearly impossible to integrate your test automation code into a pipeline.
Tools like Concourse CI, Jenkins, Bamboo, Travis CI, Circle CI, just to name a few, have built-in support for source control sold at one can check out and run the automation code any time, where and when it is needed.
The third one is early testing. Running and testing an application locally from a freshly implemented feature branch in a document container, creates a fast feedback within a team and makes testing a matter of course for everyone and not just the tester.
And the fourth one is learning. Learning source control concepts and strategies is a gateway to other technical skills that are valuable for test automation. An example would be bash scripting for creating a Jenkins file for pipeline integration.