Understanding Buddy for CI/CD
CI/CD (Continuous Integration/Continuous Deployment) is the practice of continual build, test, and deployment of an application delivered by the development team.
One of the easy platforms for implementing CI/CD practices is Buddy. From the Wikipedia definition, “Buddy is a web-based and self-hosted continuous integration and delivery software for Git developers that can be used to build, test and deploy web sites and applications with code from GitHub, Bitbucket and GitLab.”
In Buddy, a project can be created for each application. Your GitHub project, for instance, can be represented with the help of the project definition in Buddy. As per the use-cases, different pipelines can be created for the project. This is illustrated in the figure above as well. Each pipeline consists of actions to be executed in a specific order.
The figures above demonstrate the division of pipelines of the same project with respect to the environment for which the application is supposed to be deployed. In figure 1: dev branch is used to deploy the application to the dev server. In the same way, in figures 2 and 3, uat branch and master branch are used to deploy the same application to UAT and Production server respectively.
For defining any pipeline, the settings can be easily configured. The branch, as well as the mode of triggering(manual or automatic), should be given. The important pipeline definitions to be considered are its actions and environment variables. Environment variables can be project wide, pipeline, or action wide. For the action definition, various templates are provided by the buddy itself under various categories like Devops, Amazon web services, Google Cloud Platform, Docker, Kubernetes, and many more. You should explore it for yourself. The templates have taken care of most of the things that developers might need for CI/CD.
The list of actions defined for one of my pipelines can be viewed in the figure above. For the first and second actions, I have used the Node.Js template. For the second template, I have used the template from docker, where the dockerfile is built, tagged, and pushed to ECR. The template is so flexible that every attribute and variable that I need for building, tagging, and pushing the image to ECR is provided there. The option to select the dockerfile, its context, and to enter target stage, build arguments, tags (used to tag the dockerfile), aws credentials to push to ECR and repo name make this action so useful and time saving. Similarly, for the third action and the fourth action, I have used Local Shell, which is solely focused on deploying the application in the EKS cluster. Finally, the changed code is pushed to GitHub using the last template.
Also, I have defined a notification action, where the message is sent to the defined slack channel with execution, project, and pipeline details.
In the above figures, we can see that each action has the option to be on or off. This is the feature that makes Buddy much convenient. In addition, the execution logs can be viewed in each action and the history from each execution can later be navigated.
Lastly, my experience with Buddy was awesome. Whoever is reading this article till the end is strongly recommended to use Buddy, at least for once. And don’t forget to share me your experience with buddy.
