“TO ERR IS HUMAN” – It is natural for human beings to make mistakes.
Though it sounds ideal, you cannot (or must not) accommodate mistakes when people’s lives may depend on your software. Especially where users are interacting with your app in real-time and your code impacts their lives, errors must be minimized.
How to do that? Automation.
This is where Continuous Integration and Delivery comes into the picture. Taking the example of the open-source project we’re building with Tech4Dev, I’ll share my story on how CI/CD has started to streamline processes and foreseeing errors.
Before diving into tech, let’s take a quick yes/no quiz:
If any of your answers are yes, this post is definitely for you and your team. If you answered no to all, either you’re yet to reach these situations or are already doing a great job. In any case, I hope you get more insights into making your processes smoother.
CI brings in automation to test-case execution and verifies the system stability when code changes are pushed by anyone. For this project, we implemented CI using GitHub actions.
CD, on the other hand, makes the release process smoother and avoids human errors when a new version of your software is going live. We are using the AWS infrastructure for automated releases.
Since the project development hadn’t started yet, I had a lead time to experiment and set up a robust foundation with CI/CD processes.
I spent the experimentation phase researching and applying the concepts on this test repository.
I started out with setting a simple roadmap:
Getting started in the Phoenix framework was straightforward. The framework supports writing test cases out of the box and has good documentation on it.
Next, to run these test cases using GitHub actions, I created a workflow.yml file that will tell GitHub to execute the test cases every time a developer pushes his/her code changes.
Have a look at ci.yml
Now after some cleanups and fixing errors, I created a feature branch and… Voila! GitHub actions have started triggering on code push.
The roadmap for Continuous Deployment was as follows:
For dockerizing the app, I created a Dockerfile that defines the platform dependencies for the project. When you run the docker-compose run, it creates a container with all the installations mentioned in the Dockerfile.
Have a look at the Dockerfile
Next, the Dockerrun.json file needs to be created that will be executed to deploy the docker image to our Elastic Beanstalk setup.
Finally, setting up AWS CodePipeline. Here are the configurations I used:
|Source:||GitHub repository for the project. Webhook for the master branch.|
|Build:||AWS CodeBuild that installs the application on an Elastic Container Registry (ECR).|
|Deploy:||Pushing compiled code from ECR to the dockerized Beanstalk environment.|
Whenever the master branch was updated, AWS triggers the CodePipeline.
Once CodePipeline execution is complete, we can do a quick health check of our Beanstalk environment
Having the automation in place, clearly, the time-to-market is reduced and the team will ship quality code. This is happening as the errors are being detected early on.
On top of that, setting up the CI/CD early in the process ensures the following things:
To know more about the project, check out the following stories: