In the world of multi/hybrid-cloud, where are CD patterns best aligned and applied?

Some housekeeping up front. Continuous integration (The CI of CI/CD) is something all to itself. While CI and CD are commonly conflated, they are two very different stages of the software development lifecycle. As a Detroiter, I see CI as the automobile assembly, while CD is the iterative testing of the car’s multiple components, as they’re integrated, all the way through to the proving grounds. It will go back to engineering for tweaks until cleared for production.

CI can be done anywhere. Take a specification and build it, tell me if there are errors in the code, etc.. CD takes the passed CI build, measures it for function and performance, and determines whether to deploy or rollback. (Overly simplified, but the gist of each)

So, while CI can be performed anywhere, CD is more concerned with the where and how. Enter multi-cloud/cost, and it makes sense to determine which stages of the CD process are targeted to on-prem vs. public cloud.

If your application resides in a public cloud provider’s infrastructure, it makes practical sense to measure the performance and final function in that environment. For iterating over functional testing, it often makes more economic sense to leverage on-prem infrastructure. My next few posts will  focus on the mechanics of iterative functional testing on-prem, with performance and final functional testing performed on public cloud provider infrastructure.

There are possible blockers. Most often, these are presented when the application itself relies on a specific cloud provider API. In these cases, we either integrate from on-prem to the cloud provider for those specific APIs, or leverage an on-prem substitute. For example, we may consume object storage in a cloud provider, but use a service like MinIO locally. Substitution is fine (and preferred). We’re testing function, not performance.

Ideally, we’ll test with a common pipeline workflow. In this case, I’ll use Spinnaker in combination with Cluster API, and potentially Crossplane. Spinnaker will create immutable K8s clusters on-prem with the help of Cluster API, then deploy our application and test it for functionality. Once functionality is confirmed, the pipeline will destroy the local clusters (returning local resources for other uses) and create an identical cluster (nearly identical at least) in the public cloud

This pattern allows us to iterate over the majority of our typical testing stages on-prem. In coming posts, I will build pipelines to show how we achieve this.