Continuous Integration-Deployment
CI/CD
Continuous Integration
CI is the act of continuously merging their work or changes into the main branch as often as possible. CI puts a great emphasis on testing automation to check whether the application is working correctly whenever a new commits are integrated into the main branch.
Continuous Delivery
The first CD, is the act of continuously of releasing new changes to your customer quickly and reliably.
Continuous Development
The second CD, is similar to Continuous Delivery but this time, every changes that passes all stages of automated test will then be release to the customer.
Automated Deployment
Using an automated build to check each integration of codes, we will be able to check for any error or bug much earlier in the process. Furthermore, having an automated deployment, we, as the developer could focus more on creating features for the customers.
DOCKER
Docker is a tool designed to create and deploy applications by using containers. Containers will allow developer to packaged their works with all of the parts it needed and will allow other people to run our application regardless of any customized settings on another machine.
We are using docker to deploy our frontend service application, although for our backend service we use AWS serverless for deployment.
Docker Image
Docker uses a file called Dockerfile that contain a list of instruction dependencies on how to make our Docker image. Docker image contain everything that is needed to run our applications including our codes, list of requirements needed, and the commands to run the apps. When the Docker runs the image, the instance is called the container.
Our Application
Our application uses REACT-based application for the frontend. Every time we push to the Gitlab, it’ll execute the scripts that exists inside the gitlab-ci.yml file. Inside there we will check if there are any errors regarding the test and linting to stop any problems from being deployed.
Inside the .gitlab-ci.yml file, there are 3 stages that consist of: development (dev), staging (stag), and production (prod). These stages can be seen as the stages on our project and are depended on how ready our branch is.
This is for our frontend application.
these codes are just to show some part of the stages as to not take too much space
The test job is to test our app and display it’s coverage. If all of the tests pass then, it will then proceed to pull the latest existing image, re-create the Docker image and finally push the new image to the docker registry (the gitlab of docker images). All of this is located in the script part.
NGINX
Nginx is an open source software for web serving, reverse proxy-ing, load balancing, etc. Because it’s purpose is to create the fastest web server, we decided to use this for our front end deployment.
Docker will use the Dockerfile from above to tell how to run our react application. To simplify the explanation, the Docker will make our application files into a static files, which then later on will be serve with nginx when the image is running.
DIND
DIND (means Docker in Docker) allows Docker engine to run as a container inside Docker. We implement this in our apps to prevent the container to run its own Docker daemon. This means that all of the of the container will be connected to only one, same for everyone, Docker Daemon.
This next codes is for creating the DIND service:
services:
- name: docker:19.03.0-dindAnd that’s it :)
