Pipelines, pipelines and pipelines — they are the most interesting part of my DevOps journey after observability which I would still write about in a short while. Well, one of the most relevant parts of deployment and building is the continuous integration and continuous delivery (CI/CD) pipelines. CI/CD embodies a philosophy that enhances application development teams to deliver code changes more frequently and reliably. In context, while CI ensures that small changes in the applications are approved using any form of version control systems, the CD collects the baton to get the code and application to the required infrastructure in the cloud.
One beauty of CI/CD is the ability to automate lots of processes during deployments.
Choosing The Best CI/CD Pipeline Platform
Assuming a team has been briefed on what should be done and how CI/CD could help the teams optimizations, the next step will be deciding what exact pipeline will be utilized — I mean, there are several platforms out there that offer pipeline integrations but in my experience, I believe the choice of pipelines is relatively dependent on the following:
- Type of application/product.
- Budget allocated to the product.
- Pipeline orientation.
- Preference of engineers on site.
- SDLC speed and standards of the team.
- Code Reviews Frequencies.
- Security Standards in the team.
In my experience, I have worked with teams that have switched between platforms because of the build time costs, some others have switched because of market shift and many other reasons may exist in other teams. Well, this piece is to help you decide from my experiences, however, while you take your decision according to your team's metrics and product goals, take a break and do some homework.
AWS CodeBuild is a beautiful way of building your code with CodePipeline especially with deploying CloudFormation stacks and the user experience is not necessarily fun. It is smooth because it does not require any special permissions since it’s built within the span of your normal AWS account so no need for any special procedures to get your code building. If you need to build a mobile application in AWS CodeBuild, you should know that there is still a limit with the macOS building as it is not available. While the cost incurred will be embedded in the general AWS cost, you can check the detailed build ranges here.
Want to read this story later? Save it in Journal.
GitHub Actions happens to be my most preferred over the years and recently I got to understand that it runs on Azure Pipelines. In context, they have a security scanning feature in-built and asides from holding your code, they could publish security policies and checks for any necessary vulnerabilities and could update you via email in case there are project dependencies and from experience, it opens a pull request concerning that issue. Also, GitHub actions could scan your code, lint it and update you for bugs, style fixes, the format required and loopholes as well. GitHub Actions is more streamlined when reporting issues and I mean, this is what every engineer should strive for because it makes the work easier and code releases will definitely be faster. Also, as you merge changes into the main branch, there are release notes/drafts that are rolled out with labels, PR details and you could definitely save them.
I always encourage that your code should be as close to your pipeline service as possible and I think GitHub makes that ultimately possible. While GitHub functions as your VCS, the actions go right ahead to make your CI/CD experience be premium standard.
For some kind of middle ground, GitHub supports self-hosted runners so you can spin up a deployment machine in aws as runners and connect to GitHub with IAM setup completely covered as well. In Deploy/Dev workflow, you can run on the self runners in AWS on the machines and take advantage of all the nice IAM functionalities. Furthermore, I believe these runners can take the applications to the cloud via your preferred public cloud (AWS, Azure and maybe Google Cloud). You can check the range of billings here.
Just like other CI platforms, CircleCI is a cloud-based system that requires a server or further administration but offers an on-prem solution that allows you to run your build in your private cloud. Even though some engineers have started migrating from CircleCI because of the recent changes in the teams set of engineers, on the other hand, you can have access to projects and necessary builds. From observations, it could tick up 3rd party dependencies and starts very fast with an obvious YAML configuration (always very easy to understand).
Despite the fact CircleCI does work with and run on all languages, it supports a few programming languages and they include Go, Java, Python, PHP amongst many others (at least I have used Python and Go). Also, while CircleCI is a cloud-based system, that is a plus from one side, it can also stop supporting any software, and you won’t be able to prevent that so on both sides, it could be beneficial and the opposite. I have not used CircleCI very many times but I know many engineers are leaving the platform pretty quick for some user experience reason while some are going in there. So at the end of the road, it balls down to team preference and product plans. Lastly, you can check billings plans here.
Moving forward, here is a table that summarises some major comparisons for AWS CodePipeline, GitHub Actions and CircleCI.
There could be other preferences but the details and comparisons above are based on experiences but I look forward to getting a more in-depth understanding of all these pipelines and maybe my choices might change — after all, I am open to more learning every day.
Thanks for reading ❤️
Please leave a comment if you have any thoughts about the topic — I am open to learning and knowledge explorations.
I can imagine how helpful this post has been, do leave a clap 👏 below a few times to show your support for the author!
📝 Save this story in Journal.
AWS CodeBuild Vs GitHub Actions Vs CircleCI was originally published in Noteworthy – The Journal Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.