Welcome back. Let's take a deeper look at AWS CodePipeline and Azure DevOps. Both are CI/CD platforms, but they come from different worlds with different approaches. CodePipeline is part of what AWS calls CodeSuite, but I tend to refer to it as CodePipeline and Friends.

It's built by AWS for AWS, but it supports connections to an ever expanding number of external services and is fully customizable. So, we can get it to interact with anything that can make or take an HTTP request.

But that customization mechanism, using Lambda, can be fiddly, and there's no marketplace for plugins like there is for Azure DevOps. Azure DevOps is a full ALM (application lifecycle management suite) with project management, boards, repos, pipelines, test plans.

Microsoft have been iterating over it for over 20 years now, so it's a mature product compared to CodePipeline and Friends' mere decade of existence. Any pipeline, any orchestration tool involves three things: getting stuff from somewhere, doing something with it, and putting it somewhere else.

In terms of a CI/CD pipeline, that becomes at its simplest, get the source code, build it, then deploy it. But that wouldn't be a very good DevOps pipeline, would it? Where's the testing?

A more thorough one might look more like: get the source, build if necessary, run BVTs (build verification tests), stand up some testing infrastructure, run some more tests, integration, performance, penetration, UI, etcetera.

Tear down the testing infrastructure, stand up new infrastructure for production. Gradually move all the traffic across to the new infra, tear down the old infra. Repeat.

In CodePipeline, we define any number of stages such as source, build, test, and deploy, and AWS handles the orchestration. We can define pipelines using IaC tools: the CLI or via the UI in the console. Individual actions within a stage within a pipeline can be configured to run in sequence or in parallel.

Azure DevOps uses YAML pipelines which are stored in our code repo. There's also a classic mode for UI-based pipelines which newer accounts can't access. It supports hosted agents on VMS, self-hosted runners, and has integrations with many third-party services including AWS via the Visual Studio Marketplace.

Let's start with source. CodePipeline lets us choose from several different source providers including GitHub, GitLab, and Bitbucket. Azure DevOps? Yes, really. Amazon ECR, Elastic Container Registry, and S3. That last one is useful if we want to integrate with a non-natively supported SCM.

As long as we can get the SCM to put new code pushes into S3, that can kick off a pipeline. It also supports, and I'm really not sure if I want to mention this, AWS code commit which is Amazon's managed git. The reason I'm not sure about mentioning it is because they've deprecated it. No new accounts will have access to it as of July 2024. No, we don't know why.

Azure DevOps can use Azure Git repos, GitHub, or Bitbucket as its source. Older accounts can still use TFVC, which stands for Team Foundation Version Control, pointing at its roots in TFS, but Git is the preferred choice.

Next is build. AWS CodeBuild is quite poorly named in my opinion because we can do so much more than just build code with it. Build, test, pretty much anything we like. It uses a buildspec.yaml file stored in the repo for us to describe what we mean by build.

Azure Pipelines also uses YAML to define what we mean by build. A pipeline consists of stages. Stages are made-up of jobs, which are made-up of steps. Jobs are run by agents which can be running in the cloud or locally. Then we test. Or maybe we test before we build and then we test afterwards as well.

Anyway, Code Pipeline has several native integrations with third-party testing services like Storm Run and Run scope. And there are a number of AWS services, like Device Farm for running tests on mobile devices and websites, and Fault Injection Service for simulating what if the network goes down or what if this compute resource fails.

Azure DevOps testing framework has been around for a long time and fully integrates with our pipelines. They also have a Chaos Studio for simulating faults like network latency or segmentation. As an aside, these name choices are quite unusual for the two vendors. AWS normally has interesting names for things, whereas Microsoft tends to go with boring, descriptive names. FIS doesn't sound nearly as fun as Chaos Studio in my opinion.

Finally, we deploy. CodePipeline supports multiple deployment stages to multiple services, including CloudFormation, Service Catalog, EKS, and others.

The main tool used by CodePipeline and Friends for deployments is the aptly named CodeDeploy, which will deploy to EC2 and on-prem servers, Lambda, and ECS in a number of different configurations.

We can just upload a deployable artefact into S3 if we're not quite ready for that continuous deployment bit. But we can also have a manual approval action as part of our pipeline. And although it's not baked in, we could use a custom action or even a CodeBuild project to deploy via Terraform.

Azure Pipelines also supports multiple deployment stages to multiple services, including virtual machines, AKS, and app services, and ARM and Terraform. It also supports gated approvals and package deployment to artefacts. We can deploy to other targets using extensions or custom code.

Let's talk about DevSecOps. I hope you could hear the air quotes I put around it. In my opinion, there is no such thing. It's just DevOps, okay? Security is a vital component in putting better quality code into production. If it ain't secure, it ain't good quality. But folks like to use the term to remind us to consider these things.

And as always with security, there's two parts: "of" and "in." We want to be securing access to the pipeline, to who is allowed to modify it, who is allowed to observe it, and so on. But we want the pipeline itself to be secure.

We only want the component that needs to execute an IaC update to have permission to do so, not the other components. And that IaC component doesn't need access to the source repo.

It's the principle of least privilege. Code Pipeline and Friends naturally uses IAM, which gives us very fine grained control over which things can do what, even down to the level of only being able to run a build if the resource is tagged dev.

And this part I like a lot. Code Suite is all definable using IaC. We can define a pipeline that no human has direct permissions on. If they want to modify the pipeline, they'll need to update the IaC template and push it to the repo, which will perform various checks to ensure that they're not breaking things, or security most importantly, before updating the stack.

Yes, I'm talking about having a CI/CD pipeline for our CI/CD pipeline, which is mind blowing. Azure DevOps naturally uses RBAC with its roles, scopes, and policies, which is fine for most use cases but not quite as surgical as I am.

I want to summarize this. I've tried to make it clear that both vendors allow us to create multi-stage CI/CD pipelines with testing, customizations, manual approvals, and integrations with lots of external services. Hashtag just another cloud, right?

I didn't want to appear biased in any way, but the truth is that to me, Azure feels slicker and more polished. As I said earlier, it's twice as old as CodePipeline and Friends, so that's to be expected.

Don't get me wrong, neither is fun to try and debug at 3:00 in the morning, but setting up those pipelines feels more straightforward and requires less custom code and duct tape in Azure than in AWS.

And Azure DevOps has all that project management tooling as well. For AWS, you'll have to tack on something like Jira onto it. I may have hinted about it above, but CodePipeline and friends does have the edge when it comes to security.

This is my personal opinion, your mileage may vary. The bottom line is, obviously, for AWS native workloads, Code Suite makes sense. Azure DevOps is a full development lifecycle tool and integrates more easily with more things. Both can communicate with each other.

But if we're doing multicloud, which is the whole point of this lesson, maybe we should look at things like GitHub Actions, Gitlabs, CI/CD, and Bitbucket Pipelines.

Key takeaways: CodePipeline is AWS-native and event and API-driven. Azure DevOps is a full ALM suite. Azure DevOps supports locally-hosted agents and has a marketplace full of integrations. Code Suite integrates tightly with AWS services and has fine-grained security.

AWS CodePipeline and Azure DevOps

About