Platform Engineering — Path to production

The deployment to production is considered a very important milestone for businesses around the world. Every change going to production is suppose to add some value to the business. That’s why its important that we build a safe, secure, robust and sustainable path to production especially when it comes to our code infrastructure.

With migration to cloud, business are now moving along the path of platform engineering. The core idea behind platform engineering is to have a core infrastructure team which can build a product (internal developer platform or landing zone). The product should offer enough automation to let product teams quickly, reliably and securily deploy their applications but providing enough abstraction for product teams so that they don’t need to know the internals of the product.

While platform engineering as an idea has been a great source of guideline for many organisations as they start their cloud journey, with infra being written as code there is a lot of confusion around how the typical path to production should look like for most platform teams. We will talk about the typical path to production further in this post.

Path to production

With a lot of debate on this topic, there is a good news. The path to production for platform engineers is not different than for regular development teams. In simple terms

• Write Code. Yes write Infra as Code (IaC).
• PR to main branch should start Continuous Integration (CI).
• A successful CI + PR merge after Code Review should start Continuous delivery till production.

Write Infra as Code (IaC)

• Write everything as code.
• There are a lot of tools which are used to deploy infra written in configuration files.
• Terraform is most popular tool which lets you deploy infra to many target platforms using a common config language (HCL).

Create a continuous Integration (CI) pipeline

The second step in path to production is to write CI pipeline. The basic idea to write small pieces of code and validate it continuously as we write. The pipeline should run with a PR to main branch. The idea is to do trunk based development by pushing code to temp branches for CI and then merge them to main branch for Continuous Delivery (CD). The CI pipeline should perform below tasks.

Static Code Analysis

• Validate the format. ie: terraform fmt -check
• Scan the code against common security vulnerabilities. ie: tfsec
• Scan the code for formatting, best practices etc. ie: tflint

Incremental Analysis against organisation policy

• This should be done against all the environments as we might have different policies for different environments. If using GCP, then it can be achieved using terraform vet option in gcloud CLI. More details here.

Unit Testing

• Use kitchen-terraform to test your infrastructure code for unit testing. Tool provisions infra to a sandbox environment and run the test cases against it. In the end it destroys all the infra in the sandbox environment.

Run terraform plan

• The last step of the CI process is to run terraform plan.
• This should be executed against all the environments in order for reviewer to review plans for all the target environments.
• This helps reviewer to verify the desired and expected result and approve the PR.

Create a Continuous Delivery (CD) Pipeline

The last step in path to production is to write CD pipeline. The basic idea of CD is to broaden the scope of our testing by deploying the infra to a testing environment. This can help to verify if functionally everything works as expected. Below are the minimal characteristic for this pipeline.

• The CD pipeline should start as soon as code is merged to main branch after successful PR approval + successful CI build.
• The pipeline should deploy to atleast 2 environments. One should be a prod like environment before deploying to production.
• The deployment to production should require at-least one approval.

This is all for now. Hope this will help you guide to your path to production. Happy Reading.