How we save 30 min a day of developer's time with Continuous Deployment automation

Introduction

Continuous Deployment (CD) is a software development practice in which every change to the code base goes through a pipeline of automated tests, resulting in an automatic deployment on each successful test. 

This is extremely useful for small teams that want to get features out as fast as possible without having to worry about an entire release cycle.
 

First, why do we need CD?

Let's say you're a developer. You spend most of your day working in a code editor, writing code that will eventually become the application your users use. 

When you finish coding a feature or fixing some bug, what do you do? Do you immediately push the changes to master and deploy them? Or do you run a build and then manually review the results before uploading anything? 

The answer is probably "manual review"; after all, this kind of automation is still fairly new. But there's one big downside: in order for your change to be deployed into production (or staging), it needs to pass through at least two manual processes:

• A build server will build your code automatically when someone triggers it by pushing commits into another repository (usually called "master"). That may take anywhere from 30 seconds up to 10 minutes depending on what kind of tests are running during this process.
• After the automated build has been done successfully, someone needs to manually approve those changes before they can get deployed into production/staging environments. It could take 5 minutes to install, but if there are any issues with the new release candidate or its dependencies — which is common in this late stage of development — it may take up to an hour.

Before the automation

Before you can automate, you must do all the manual work. That means:

• merge pull requests
• deploy manually
• run tests on every push

That's a lot of steps for one developer, and it can take up a lot of time. Even worse, it's easy for little mistakes like typos or missing files to go unnoticed until after deployment; at which point your whole team has to start over.

What did we decide to automate?

You can automate the following tasks:

• Merging pull requests
• Deploying your application
• Running tests and static analysis locally before deploying
• Pushing to the staging environment

How did we automate it

You can use git hooks to automate your new deployment process.

It's open-source software that allows you to automatically do things when certain events happen in a git repository (e.g., push new commits or create merge requests). We used Git hooks to automate the code deployment process by triggering them on each commit pushed into the origin branch of our repository.

For example, if you are using Gitflow workflow then you will have master and develop branches for your project. In this case, every time there is a new commit pushed on develop branch then it should trigger two jobs: one for deploying code and another one for testing it locally before pushing changes live.

What did we get in the end as a result of automation

In the end, you will get:

• The time saved by developers
• The time saved by the QA team
• The time saved by the release manager

And now each time you push to the master branch all pull requests are merged together and the application is deployed automatically

You might think: "What a pain! How many developers does it take to deploy a new feature?" No more than one, actually. As mentioned before, it's not your job anymore. 

That is why we call this process Continuous Deployment because it's automatic and continuous (as opposed to an on-demand deployment). You push code to the master branch and the application is deployed automatically. 

Nothing more needs to be done by you or anyone else on your team unless there are errors during the deployment that need attention from someone knowledgeable about how these things work (more on this later).

In addition to saving time for you as a developer, this automation has also enabled us to save time for our customers in two ways: 

1) reduced testing time because when we release a change, we already know that most likely everything works fine; 

2) faster feedback cycle because customers get access to new features within minutes instead of days or weeks after they have been coded and tested by us internally.

Conclusion

Now it's much easier for us to manage all the deployments and pull requests. My developers can focus on implementing new features and improving existing ones, without thinking about manual work. The whole team is happier because we spend less time doing repetitive tasks that do not bring any value to our customers.

In the next article we will provide an example of how to build the CI/CD process for Drupal projects based on Gitlab.