Deploy your application as easy as dancing on TikTok (CI/CD Deployment)
Understanding git. ✔️
UX designing by following 10 Nielsen’s heuristic. ✔️
Understanding peoples and team behavior. ✔️
Coding, coding, and coding. ✔️
Finally, the last but not least. Deployment.
After we implement all those things that are required to complete the project, the last thing that we have to do is deploy our project. This is really important because we have to publish our project so other people can use our applications. Otherwise, no matter how hard we code if we don’t deploy the application, people still cannot use our application.
As the time goes by, nowadays deployment can be done automatically. This is why the term continuous delivery (why not deployment?) or mostly known as CD appears. CD doesn’t work alone by itself, there is a process that must have been done before the CD, which is CI or continuous integration.
Confused?? Let’s get more.
Deployment
First of all, lets jump to deployment. Deployment is actually posting or publishing your application so other people can use your application in their machine. The simplest analogy is like you are posting a photo to Instagram or video to YouTube so everyone can access and interact (like, comment, subscribe) with your content. Same goes with web or mobile application, developer have to “post” it to make the application accessible by public. In this project, I do the deployment by utilizing the continuous delivery. It means that I deploy my project, which is a web application, automatically.
Continuous Integration
Continuous integration or usually known as CI is a process (or a method) that usually done by the programmers in order to integrate their new code to the project. The integration will be done by merging lines of code that have been created before to the prior code that have been developed by other development team. So after adding new lines of code, the project expected to have new features (or fixed bugs).
That’s all about the integration. How about the continuous? What does it mean? In short, Continuous means that the code integration supposed to be done continuously. The actual definition is the code merging is done by all of the development team. The project will contain of all team members working result afterwards. In our project, we divided the workload into front end and back end which handles UI/UX design, function and database respectively. 2 people handles the front end and 3 people handles the back end. With this continuous integration, we can minimize the dependencies between each of developer. For instance if the front end developer stuck when handling the function, they can do a commit so other developer can retrieve latest version of the code.
Continuous Delivery
Jumping to the continuous delivery or mostly known as CD, continuous delivery is not similar as continuous integration. Although it has almost similar meaning in the continuous (supposed to be done continuously, by automated deployment), they have different meaning between integration and delivery. Delivery here means we want to deliver our developed app to the user with those prior integration automatedly (because its continuous delivery). This automation is really beneficial to developer because all we need is just set the automated development script (usually in the gitlab-ci.yml, if we use Gitlab) in the beginning of the project. Later on when we commit and push the code, the automated development will work by itself. Usually developer use 3 stages to deliver their product. Those stages or steps are development, staging, and production.
If we observe CD from its flow, first of all the developer will do the coding. After that, each developer in the development team will do the code integration (CI was here!) with particular repository that is set for storing the code and deployment afterwards. Finally, those code (that turns into feature, fixed bugs, etc) are being reviewed, are those code satisfy the requirement? Are there any remaining bug? Does the feature perform well? If all of the answer is yes, we all set to deploy the product.
Unboxing CI/CD in My Project
In this software engineering course, we has 3 kind of branch that really essential in the project development. They are master, staging, and user story branch.
This picture contains our branch name that we used to develop our project. There are master branch, staging, branch, and user story branch. The user story branches are formatted with name, product backlog number, and title. Each of user story branch will be merged into the staging branch at the end of each sprint. This branching part is actually the implementation of the CI because it satisfies the concept of continuous integration, which is integrating new code with the prior one (user story branch to staging) by a continuous process (from each developer to particular branch). For the continuous integration, we write the script inside a .gitlab-ci.yml file.
For this Gitlab CI, we divide our deployment stages into 3 parts which is test, analysis, and deploy. Also we declare a variables that will be used for declaring environment variables in AWS.
For the tech stack, we divide the project into front end and back end. For each stack we made the test individually. The coverage tag is used for running the unit testing and checking the code coverage. The script tag (the most generic one) is used for running the code. And the last one, the only changes is used for checking whether is there any changes inside the back end or front end folder, if there is a changes it will be running the test.
In this deployment stage, refs tag will be executed if the pipeline is triggered by the branch that formatted in user story branch or the staging branch. This action is intended for the deploy-fe-production and deploy-be-production tag.
Finally, if there are no problems in committing and pushing the Gitlab will display the 3 stages of deployment in the pipeline section. Every stage that succeed and passed will show a green checkmark. Otherwise it shows a red cross means the stages fails.
That’s all for this article, I really hope that this blog will help any of you that want to learn and apply autonomous deployment in your project. See you in the next article!!!
