Stefkoff's Blog

Introduction

If you are working alone on the development process, pushing directly to the production server is not so bad. Of course, if all tests are passing before this. But working in a large team (4+ developers), first will lead to many-many merge conflicts, and the track for the deployments will be lost, if there is not properly configured CI/CD workflow.

Honestly, in my personal experience I do not like when I hear: Fix the bug and push ASAP!. We are all humans and we make mistakes. Even a small typo could lead that, the clients will not have trust in the software that we are delivering.

Having a good CI/CD workflow, together with automated tests and manual QA testing, will ensure that the software is properly working as the client's expectations.

NOTE: in the entire series, I will not going to talk about securing the application. I'm planning to write a blog for the securing application, but in order to keep this thread not so annoying, I will write this in a completely separate blog post

In the next few posts, I'm going to show you how you can automate the testing and the deployment of your application.

CI/CD is a key concept these days for good software development. Managing good Continues Integrations (CI) and allowing your QAs to test the fixes that are pushed by the developer that can be encapsulated from other unnecessary pieces that do not have to be deployed at the given stage. Continues Delivery (CD) on another hand will help you mentaining a stable production state and not just push any fix to production and loosing track on the deployment.

In the next few series of posts, I will show you how we can automate all of this with GitLab and their powerful pipelines. We will use some Docker containers for the staging servers.

What we will do?

We will play a simple scenario of CI/CD of a small frontend app + node.js as backend server, MongoDB as a database, and an NGINX server as a reverse proxy server to all of this.

On the end we should be able to play the following scenario:

1. The developer pushes a fix to a feature branch.
2. A CI pipeline will be executed on the previous push to validate that all tests are passing.
3. The developer will create a Merge Request (MR) to the staging branch
4. A CI pipeline will be executed and will build an encapsulated staging server for the possible merged fix ONLY and the QAs will receive a link to the staging environment
5. QAs will test the fix and will approve the merge request.
6. Once a week, a weekly release will be initiated from the state of the staging branch and the MR will be created from the staging branch into the weekly
7. CI will again be executed to prepare an encapsulated staging server with all of the weekly fixes. QAs will receive the weekly staging link to test the fixes
8. QAs will test the fixes and will approve the merge request
9. When the weekly release is tested and approved, it will be merged by a CD pipeline to the production branch and will be deployed to the production server

There will be another workflow of the hotfixes that needs to go directly to the production as soon as possible:

1. Developer pushes a fix to the hotfix branch
2. A CI pipeline will be executed on the pushed branch to validate that all tests are passing
3. The developer will create the MR into the production branch
4. A CI pipeline will be executed and will build an encapsulated staging server for the possible merged fix ONLY and the QAs will receive a link to the staging environment
5. QAs will test the fix and will approve the MR
6. A CD pipeline will be executed and the production server will be deployed with the merged fix

Branch model

We are going to use mainly 5 branches:

1. Feature branch: named like feature/ISSUE_KEY

2. Hotfix branch: named like hotfix/ISSUE_KEY

3. Staging branch: named staging

4. Weekly release branch: named like weekly/VERSION_NUMBER

5. Production branch: named production

Branch permissions

We will have strict branch permissions to be sure that no one could push untested code, or code that didn't go through the CI/CD pipeline. Here are the branch permissions that we will have:

• Everyone can push to the feature or hotfix branches

• staging, weekly and production branches can be pushed ONLY by MR

What servers we will use?

We will need the following servers (or a VMs) to do all of the desired workflow:

1. GitLab server - self-managed or cloud-managed.

2. Ubuntu server that we will use for the dynamic staging environments. There we will install docker and we will use docker composer to build encapsulated staging environments that will contain only the provided fix.

3. Production server - we will have a production server. Ideally, this could be a combination of 4 separate servers (one for FE, one for BE, one for the proxy, and one from the DB). Also, this could be done by kubernetes, but this will not be covered in these series. We will deploy all of the apps on a single server, to focus on the CI/CD and not on the correct infrastructure.

What will follow

I will divide the tutorial into the following posts to encapsulate the tools that we will do:

1. Configure GitLab and the repository settings
2. Configure the Apps (FE, BE, DB, proxy). Here we will configure the docker-compose instruction that will help us with the dynamic staging environments
3. Configure that staging server, where the dynamic staging environments will be hosted
4. Configure the production server
5. Configure the CI/CD pipelines

You can proceed with the next step Building CI/CD deployment with GitLab, Part 2: Setup Repository