Version Control Systems and Continuous Deployment Tools: A perfect Fit

Regardless of the size of your project or team, if you want to develop high quality software, you need to choose the right tools. They help you to automate things and enhance your productivity. A proper release management in combination with a version control system is a central component – whether you're a single freelancer, a distributed team of developers, or a small web agency.

In this article we're going to explain briefly what version control is and how a version control system can improve your workflow. After summarizing the differences between continuous integration, continuous delivery, and continuous deployment we're going to make the link: A version control system is one of the key components of a continuous deployment tool – good thing it's easy to connect DeployBot to your Git repositories, whether they're hosted at GitHub, Bitbucket, GitLab, or on your own server.   

So, let’s start with a short explanation on how version control works.

How Version Control works

It doesn't matter if you're working on web sites, if you're coding small scripts or larger software projects – a version control system (VCS) is your friend. Version control, also known as revision control or source control, records and manages changes to files and folders. More importantly, it allows you to look at the history of changes and go back to a previous version if necessary. When it comes to teamwork, a version control system is an indispensable component. It can be used to resolve editing conflicts between several developers working on the same project.

There a various version control systems out there, e.g. CVS (Concurrent Versions System), SVN (Apache Subversion), Mercurial, and Git. Some of them have been around for quite some time like CVS which started in 1990 and is no longer maintained or Subversion that was created almost 20 years ago as a CVS alternative. Git was first published in 2005 and uses a completely different approach than CVS and Subversion: It's a so-called distributed version control system, also known as distributed revision control system, meaning that the complete codebase is always mirrored on every developer's computer.

Let's not look too deep into Git, but mention at least one great feature: branches. The version control system handles different file versions on different branches really well and makes collaboration therefore a lot easier. Separating the master branch from development branches enables team members to develop new features or try out something new without the risk of messing up the stable version(s). Once a branch has been tested and reviewed, it's easy to approve the changes and merge it into the master.

Who needs a Version Control System?

As the name indicates, a VCS stores different versions of your files and folders, so it keeps track of your changes. Especially in larger projects this is a great help as you don't need to decide, which parts you save or how to name the individual versions. Also, it’s not necessary to document the differences in long README files. Instead, write meaningful commit messages, like “fixes typo in index.html”, “fixes bug #5678”, etc. While it’s possible to type anything in those commit messages, it’s good practise to compose them so that other developers can understand the reasons for the code changes. Even if you’re the only person working on a project, try to be comprehensive – commit messages can be a good reminder when you touch your code months or years later. 

A VCS makes sure to store past versions and grants access to any variant at any time (and show the differences). It lets you restore older versions of single files or the entire project if necessary. So, you can sleep better knowing that you can't really destroy a customer's website. Well, to be honest, you can still mess up, but it’s easier and quicker to recover and return to a working state. Besides, using a hosting platform like GitHub, Bitbucket, GitLab, etc. for version control always ensures that there is a backup of your projects online, including their entire history. If the machine you're coding on breaks down, you can simply clone that repository to another machine and continue with your work.

When working in a team, a version control system "isn’t a luxury, it’s a necessity". Forget about shared folders and telling your fellow coders to stay away from file "xyz" because you're working on it. It's not very convenient and will sooner or later result in someone accidentally overwriting someone else's changes. If you use a VCS instead, all team members can work on any file whenever they want and changes can be merged later into a common version.

Continuous Integration, Continuous Delivery, and Continuous Deployment

Before we describe the continuous deployment workflow and the tools involved, let's take a quick look at the terms continuous integration, continuous delivery, and continuous deployment. While a lot of people use them interchangeably, it's important to understand the differences:

• Continuous Integration (CI): The code is built and tested on a regular basis, i.e. daily, several times per day, or – even better – with every commit.
• Continuous Delivery (CD): This is the next step, and its goal is to always have code available that can be released at any point. CD uses some automation (building and testing) but requires human intervention in the end when it comes to releasing to a productive environment.
• Continuous Deployment (CD): All code changes are automatically built, tested, and released. It's similar to continuous delivery but also brings the new version to the production environment without human intervention.

Johanna's article from March 2018 offers a more detailed explanation. It also mentions the pros and cons of all three approaches.

Continuous Integration, Delivery, and Deployment: Workflow

So, you've decided you want to adjust your workflow and you're aiming for continuous integration, delivery, and/or deployment. All three methods rely on a version control system – there is no way around it. Every change to the codebase must be handled by the VCS so that the deployment tool can access it. More precisely, you need to use the VCS and push the current state to a repository after a commit, and the deployment tool takes over from there.

CI/CD workflows are closely linked to other development best practises. We've mentioned the Git branches – separating the tasks and giving each developer his or her own "work space" is a real benefit. They can commit to their branch as often as they like. Once the work is done, it's time to test the code. In DeployBot you can connect up to 50 repositories in the premium version (if you need more, please get in touch). We support GitHub, Bitbucket, Beanstalk, GitLab, and, of course, self-hosted Git repositories via HTTPS or SSH.

After you've connected your branch it's up to you and the other team members how you want to proceed with DeployBot: Quite likely you want to run some tests after you've committed your changes, maybe you want to include one of our predefined Docker containers or create your own. When you're ready, you can create the pull request (GitHub, Bitbucket) or merge request (GitLab) and – as always: Push. Build. Deploy!