Sitecore: Your CI/CD Pipeline as Code

Configuration as Code

Configuration as Code, in the context of CI/CD, is a pattern that allows you to store the entire configuration of your CI/CD pipeline in source control.

As a result, your CI/CD pipeline is bundle up and versioned with your code.

If you're using a system like Travis CI, you're probably familiar with this concept. I personally prefer Azure DevOps Services and while having the our CI/CD pipelines in source control as YAML has been an option (one we immediately took advantage of) for a few years now, for a while there was no CaC option available. This has all improved immensely over the past year or so, especially with the public release of multi-stage pipelines.

Advantages of CaC

Versioning

Your pipeline is versioned just like and along with your code. The benefits of this should be obvious from your existing experience working with source control (if you're not using source control, stop what you're doing and go do that).

CI/CD in sync with your Product

This goes along closely with versioning. As your site evolves and grows, so does your pipeline. By keeping your pipeline configuration alongside your code, you're site can be build/deployed from any point-in-time or any commit.

Peer Reviews

My team has also found having our CI/CD pipeline in source control to be extremely beneficial partially because it opens up the possibility of code reviews for pipeline modifications.

Every pipeline change gets a feature/bugfix branch. We then create a pull request for that branch (we're using CODEOWNERS to auto-assign the PRs). Someone else can then review the changes and approve the PR.

This may seem like an extra, time-consuming step...and it is. However, we've found that the time we spend doing these type of reviews ultimately results in less bugs and technical debt down the road. We see it this way: you can spend time now and get things right, or spend unplanned time later fixing potentially critical issues.

We strive for a "live site culture", so cutting back risk to the production environment is always worth the time for us.

Traceability/Auditing

Since the pipeline is in source control, you can always see who changed what and when. If you're doing pull requests and code reviews (please do) you'll probably also then have additional context for why changes were made and a clear audit trail of who instigated a change and also who approved the change.

Standardized Configuration

Since your pipeline is a file (or collection of files), you can reuse them across projects.

Or better yet, if your CI/CD service provides the feature, you can make use of templates. Azure DevOps Services, for example, allows you to create templates for any part of your pipeline.

These templates can even live in a separate VCS repository and be referenced by your pipeline.

Example

Check out my sc-pipeline-example repository for a basic example of a multi-stage CI/CD pipeline that builds a Sitecore site and deploys to an Azure App Service.

NOTE: This is an extremely naive example. It's meant more to demonstrate the basics and show how to use templates and parameters.