CI/CD Never Forfeti
Hello there ! It’s me again. This time we will discuss about the CI/CD
What is CI/CD ?
CI/CD is a tool to help the developer to maintain the product’s delivery and sustainability by having an automated system that handles deployment. The process includes continuous build, test, and deployment at every small iterations.
Continuous Integration
Continuous Integration or CI, is where the autonomous build and test take place. The automated system will help the developers to detect errors early in the development. Developers practicing continuous integration merge their changes back to the main branch as often as possible. The developer’s changes are validated by creating a build and running automated tests against the build.
Continuous integration puts a great emphasis on testing automation to check that the application is not broken whenever new commits are integrated into the main branch.
Continuous Deployment
Continuous Deployment or CD is an extension of continuous integration to on top of having automated your testing, you also have automated your release process and you can deploy your application at any point of time.
In theory, with continuous delivery, you can decide to release daily, weekly, fortnightly, or whatever suits your business requirements. However, if you truly want to get the benefits of continuous delivery, you should deploy to production as early as possible to make sure that you release small batches that are easy to troubleshoot a problem.
CI/CD in UKM Indonesia
Our project owner requested to use the Amazon Web Service. Our product will be deployed to the Amplify Console
AWS Amplify Console is a Git-based workflow for deploying and hosting a front-end full-stack serverless app. After a commit is pushed to a connected app on a specific pre-configured branch, the deployment will be triggered. Amplify Console can only connect to a 4 Git service which is Gitlab, Github, Bitbucker, and AWS Code Commit, but we can only connect to one instance of Gitlab. So the workaround that we came up with is to setup a repository in Gitlab and then setup a repository mirroring. Our amplify.yml script
Docker is a set of platform-as-a-service (PaaS) products that use OS-level virtualization to deliver software in packages called containers. Containers are isolated from one another and bundle their own software, libraries and configuration files; they can communicate with each other through well-defined channels. All containers are run by a single operating-system kernel and are thus more lightweight than virtual machines.
Docker will containerize our Angular app so that we can easily deploy and run it anywhere. For our docker deployment, we will use built in Gitlab CI/CD. The deployment will be triggered because we have the “.gitlab-ci.yml” file, after any push, Gitlab can detect the file and will run those scripts. Currently, we have 2 stages. Testing stage for testing our code, though for now the only test is the default one generated by Angular. The second stage is the deployment to Fasilkom’s Docker registry.
There are 3 deployment jobs. Each of them triggered by different branch, master by master, staging by staging, and dev by other than master and staging which also triggered manually.
The Docker in Docker
Docker in Docker that is actually a docker engine inside of a docker image, so we can have a docker for staging or deployment inside one. If we happen to already have built an image before, we can use it as reference from the cached image to make image building faster.
The downside of Docker in Docker
Even though Docker in Docker gives some advantages to the development, docker in docker or dind can have some issues. Based on the community report and experience, docker can have some trouble interpolating data or services from the “inner docker” to the “outer docker” since the outer docker use normal filesystem while the inner one has copy-on-write filesystem.
The other issue is that we would most likely face conflicts between the security profiles on inner and outer docker. This resulted if we have different system on the inner and the outer one.
In order to run our Docker deployment, we need 2 files which is the “Dockerfile” and the “.gitlab-ci.yml” file. The “Dockerfile” serve as the recipe for building the Docker image. It tells the Docker how do we want our image to be build.
I think that briefly explain what’s going on in our CI/CD progress.
Thanks !
