CI/CD Pipeline - how we solve the deployment of web applications in Dactyl

,,Deployed!”

This is our developers´ favorite shoutout. I am not referring to any event in their private lives though. I'm talking about a frequent event in every development cycle of any project. Yes, we mean the deployment of a new project version in a production environment. How does it look at our office? Come read another tech article. 

From manual copying to an automated tool

As a company, we went through several stages - from manual copying of changed files via FTP or console copying through SCP to the introduction of the GIT versioning system, where it was finally possible to download changes of the environment in a smart way and without conflicts.

However, it was not comfortable. It still required the programmer to log in to the server via the command line and enter the command sets. Soon, it was time to look for an automated aid. For a couple of years, we had been using Jenkins, which is written in Java and could run locally on our servers. Although we would have welcomed a friendlier graphical interface, it did serve its purpose. In addition, our mobile team had been already using it for some time, so it didn't take long to get it started.

For the first 2-3 years, we had versioned all projects on a local GIT repository in one Brno data center. But as time passed and our company continued to grow, many more processes began to come into development, such as program code revisions, project testing, creating copies for various environments, etc. At that time, we said our last goodbye to Jenkins and switched to a much modern solution that handled all encountered problems.

GitLab – the app we use today

We first took him for help around the years 2016/2017. GitLab is a modern (not only) webmaster of Git repositories, inspired by the popular GitHub service. Its concept is focused primarily on working with source code, which makes it different from the classic "management" tools such as Redmine. Unlike GitHub, it is intended mainly for the intranet environment, i.e. for non-public projects.

What can GitLab do and what makes it special? 

• It is a comfortable code viewer with a close connection to Git.
• It allows you to easily add comments to individual commits or directly to specific lines of code.
• It provides issue tracking.
• It contains a simple Wiki with Markdown support.
• It has a smooth and great-to-use UI (written in Vue.js).
• We are pleased with its merge requests (similar to a pull request from GitHub) - creating a request to include a commit from one development branch to another, where authorized members can decide whether to include it or not or have a discussion over it.
• It supports the REST API.
• It includes a Service Desk.
• Code deployment and process automation works over the aka CI / CD code.

Automatization of code deployment and execution processes on the code

Let’s explain this matter with a real example.  After the developer runs the finished code, GitLab automatically runs 2 processes on the code:

1. quality control of the code,
2. project tests. 

We use the Codeclimate module to check the quality of the code. The result is a score of how much the code has deteriorated/improved since the last commit. It also provides an overview of recommended adjustments and problematic areas.

Project tests are defined directly in the code. In our web projects, these are mostly unit tests written for the Codeception module. The success of this module is crucial.

If the tests fail, the automated process (in other words, Pipeline) stops and blocks the commit from its integration into the main branch. The developer also receives an email notification of the problem with his commit and is asked to fix it.

If the tests succeed, the lead developer or controller can incorporate the changes into the main branch. However, they should still go through the code manually, and if it doesn't seem right, they can comment on the given parts of the code and assign them back to the developer.

When the controller is satisfied and the changes are incorporated into the main branch, our automated process triggers the launch of another pipeline, which deploys the changes to the first non-local environment (test environment, test env. for short). Our non-robotic testers work there. They try to detect all mistakes that could otherwise reach the client. 

Deployment to the test env. is automatic without the need for manual action. The same pipeline allows you to deploy a copy of the project to another non-local environment with one click, which is staging, sometimes also called client testing environment. There, we have to be more careful because the client can prepare data there for their later transfer to production. 

Speaking of production - another, the third, pipeline takes care of its deployment. It is triggered after the developer integrates the changes from the main development branch to the production branch. This event is optional, but also recommended immediately after the inclusion. Only this way, the production branch can reflect the real state of production on the server.

At this point, the changes are out, and if possible, we test new adjustments on the production as well. Otherwise, there is nothing left but to pray. 

So to our style of deploying work on applications. The author of this text is Martin Kéri, our senior PHP Developer.