There aren’t necessarily many right and wrong ways to do things when it comes to CI\CD but there are definitely good and bad. Slick CI\CD processes can give an organization a huge productivity boost, reduce operational overheads, drive down labor costs and provide a platform to innovate and deliver business value. With so many different approaches to CI\CD combined with the myriad of tooling decisions needed along the way, sometimes it can be difficult to visualize how to organize a business to deliver application workloads and their inevitable new features and fixes.
Red Hat and Microsoft have entered into a fantastic partnership where Red Hat products are being jointly produced and made available in the Azure cloud marketplace. Recently I was invited onto a podcast by Microsoft in Australia, to discuss my approach to microservice application delivery and CI/CD in the azure cloud.
The podcast is linked at the bottom of this article and discusses a battle tested real world CI\CD solution that I have used in the banking industry. I talk through the deployment of a multi-environment, multi microservice application including its cloud infrastructure and database schema management and the tooling I use to build and deploy it - in particular Helm, OpenShift GitOps and OpenShift Pipelines, I also cover the deployment and configuration of an Azure Red Hat OpenShift (ARO) cluster, my branching and merging strategy, my repository structures, and why I do things this way.
Below is an overview of the key tooling I use in the solution.
ARO (Azure Red Hat OpenShift)
ARO is an Azure-native, turnkey application platform that is a managed offering, jointly engineered and supported by Red Hat and Microsoft. Managed offering means that the OpenShift kubernetes control plane and worker nodes are monitored and supported by both Microsoft and Red Hat SRE’s, in addition to overall cluster health as part of a joint customer\vendor responsibility model. The customer only receives a single bill and customers are able to use their Microsoft Committed Consumption spend towards the product. ARO has numerous benefits, combining the managed control plane, with the hyper scaler worker node autoscaling & provisioning, the seamless integration/authentication with cloud services and then marrying that with the power of OpenShift, it makes ARO the premier application development platform based on Kubernetes. In 2023, I don’t want to have to be managing my own control plane, when I can have ARO doing it for me and that is why OpenShift is my number one choice as a target platform for landing applications on.
There are a plethora of tools available to deliver applications these days, but for me when it comes to choosing a CD solution there is only GitOps and when I think of GitOps the best tool for me is ArgoCD. OpenShift Gitops is a vendor supported and hardened version of the open source project ArgoCD integrated with OpenShift clusters. It is delivered to the cluster using an Operator and managed by the OpenShift Operator lifecycle manager, providing a huge productivity boost in initial set up time, single sign on and with ongoing upgrades. Additionally, unlike the open source project you get vendor support with the product - amazing. OpenShift GitOps (based on ArgoCD) provides the opportunity to deliver applications with DevOps best practices like least privileged access and version control, additionally they allow you to bring the power of Git to your Kubernetes cluster, relieving you of the need to back up your cluster config.
When it comes to CI tooling I am probably less fussy about it then I am about CD tooling, there are a huge range of CI tools out there that provide great benefits, for good examples of those tools look no further than the major Git providers, in the podcast I use GitHub actions for the delivery of the ARO cluster. Once I have a cluster deployed for all other CI tasks I switch to the cloud native CI tooling OpenShift Pipelines which is based on the upstream open source project Tekton and specifically written for OpenShift. Like OpenShift GitOps, OpenShift Pipelines gives me that vendor support I need, there is also some good UI integrations for me to visualize my pipeline runs and also there are some great example tasks on the cluster of how to do things that can be used or tweaked to meet my needs. I love OpenShift pipelines because it's cloud native, I can wrap my pipelines in helm charts and deliver them to my cluster through GitOps and I talk about this extensively during the podcast.
For me what ultimately matters with CI\CD is that your solution is elegant, it's well documented and consumable, it uses the least amount of yaml and is repeatable between your applications and within your organization. It matters that what I build for one application can be reused in other applications, i.e. making consumable Istio configurations, or standardizing the API gateway you use and how it's configured through a pipeline.
There are many different ways to be successful with CI\CD in the podcast I discuss one approach, hope you enjoy it.
Microsoft, Azure, ci/cd, podcasts