CI/CD platforms
Over the years, as practices for CI/CD for application code developed, many platforms emerged to support CI/CD workflows triggered from source control. Here we will list out a few of the major CI/CD platforms that exist to support these workflows. Note that this isn’t an exhaustive list or an endorsement of the platforms that are listed here. The goal of this section is to give a few examples of existing platforms and solutions, and cover the trade offs that you should consider when selecting a platform to implement your workflow on. The production-grade design that we cover in the guide is compatible with almost any generic CI/CD platform that you select, but is an alternative to the specialized platforms for infrastructure code.
In general, CI/CD platforms fit one of two categories: self-hosted or SaaS. Self-hosted CI/CD platforms are designed as infrastructure that you run in your data center and cloud for managing the infrastructure in your account, while SaaS CI/CD platforms are hosted by the vendor that provides the platform. In most cases, SaaS platforms are preferred to self-hosted platforms to avoid the overhead of maintaining additional infrastructure to enable developer workflows, which not only cost money but also time from your operations team to maintain the infrastructure with patches, upgrades, uptime, etc. However, in certain fields with strict compliance requirements, it is unavoidable to have self-hosted CI/CD platforms due to the threat model and the amount of permissions that are granted to the platform to ensure the software can be deployed. These fields manage sensitive data that make it hard to entrust third-party platforms that are publicly accessible with the "keys to the kingdom" that hold that data.
Additionally, CI/CD platforms can be further divided into generic platforms for any code, and specialized platforms for application code or infrastructure code. Depending on your use case, it may be desirable to use a specialized platform that accelerates the implementation of specific workflows as opposed to configuring a generic platform.
Here are a few examples of well-known platforms, the general category that they fit in, major features that the platform provides, as well as how they mitigate the threat model that we cover:
Hosting | Self-hosted | SaaS | Hybrid (SaaS control plane, Self-hosted workers) | SaaS or Self-hosted | Self-hosted | SaaS or Self-hosted |
Purpose | Generic CI/CD tool | Generic CI/CD tool | Generic CI/CD tool | Generic CI/CD tool | Specialized to terraform | Specialized to terraform |
VCS integration | Yes, with plugins | Yes | Yes | Yes | Yes | Yes |
Provides static IP addresses for IP whitelisting | Yes | Yes | Yes (for workers) | Yes (self-hosted) | Yes | Yes (TFE) |
Built-in workflows | None | None | None | Kubernetes Workflows | Terraform Workflows | Terraform Workflows |
Custom workflows | Yes | Yes | Yes | Yes | No (Only supports a fixed Terraform-based workflow) | No (Only supports a fixed Terraform-based workflow) |
Credentials storage | Managed by you | Shared with 3rd party | Managed by you | Shared with 3rd party (SaaS); Managed by you (Self-hosted) | Managed by you | Shared with 3rd party (TFC); Managed by you (TFE) |
Update commit statuses | Yes | Yes | Yes | Yes | Yes | Yes |
Annotate pull requests | Requires custom scripting | Requires custom scripting | Requires custom scripting | Yes | Yes | Supports multiple infrastructure tools |