CDK Codechecker

When starting new projects with clients, the first thing I often do is to set a foundation, a so-called baseline. We discuss our team/DevOps agreements, some technical ones like; "Thou shalt not push to main" and others more on a process level, like we do scrum etc. When those agreements are signed in blood by everyone, the actual work starts. From a technical point of view, it starts with creating a repository.

As I am an AWS fanboy, and helping clients with their Cloud journey, I try to stick to native AWS services as much as possible. This means for code storing I use AWS CodeCommit as a git repository, not always preferred, but in enterprises often mandatory. As I am also a CDK lover, I combine the AWS services with CDK pipelines, see also the previous post on CDK pipelines.

Back to the DevOps agreements, one of our rules is that you should not push to main and everything which needs to end up in main, needs to be peer reviewed by a colleague. So how can we tackle this via code?

Well first of all, on the role used by developers, we set a refs condition with deny permissions (sometimes you need the platform team for that), so users can't directly push to the main branch anymore:

With this policy in place, users need to create Pull Requests (PR's). Because we also want to prohibit users from approving their PRs, some extra configuration is needed.

CodeCommit can use approval templates for that. What is even nicer is that you can also trigger a CodeBuild project to for example run tests or validations on your code. How to do that in CDK I will describe below.

So within the DevOps Agreements, we have stated 3 important rules:

As we already mentioned how to limit users to directly push to the main branch, I will skip rule number 1. Focussing on numbers 2 and 3, let's create a CDK app which supports peer reviewing and testing. What we want to achieve is explained in the following diagram:

A Developer pushes to a feature branch, and depending on which branch the pull request is created, develop or main branch, several approvals need to be given. The creation of a pull request triggers an event which kicks off a CodeBuild project which will run tests and linting. When everything passes, approval will be given by the CodeChecker and you only need one approval from your colleague to continue the merge to main.

Start with creating a CDK app. My example is in Python:

On constructs.dev there is a cool construct available which takes away a lot of burden to create all the templates. So let's use that package. Install and import it in the cdk app.

When the package is installed, don't forget to put it in your requirements.txt. Oke let's break down the code. Below you see the start of the codechecker_stack.py file. Here we do all the imports, including the installed cloudcomponents construct from constructs.dev.

There are some constant variables to fill in. Let's go by them one by one:

The next part is the actual class CodecheckerStack, so let's explain what the code does. First, create the repository. Then create the pull request check by calling the function self.create_pull_request_check, which will be explained in a minute. There will also be an SNS topic created, which later can be used to hook for example Slack notifications via AWS Chatbot. The failed build notifications are sent to this SNS topic. With the dict approvals_per_branch, it is possible to specify per branch how many approvals are needed. In the above example, the main branch only requires 1 approval. But it is also possible to extend this with checks for a develop branch.

With the cloud components construct, the Codebuild project will, when successfully run, update the PR with an auto approval by one. For our use case, this means that you are allowed to merge the PR.

With the for loop, we create per item in the dict an approval template by calling the function self.create_approval_template and associate it with the branch with the function self.associate_approval_rule_template_with_repositories. As extra a dependency is added between the association and the approval template creation.

So now let's dive into the functions. First the create_pull_request_check function:

This function, as the name already suggests, creates the actual pull request CodeBuild project. What it does is install the requirement.txt file, cfn-lint and cfn-nag in a standard CodeBuild project. In the build part, the templates are synthezised and pytest is running. Then the output of the templates is checked with cfn-lint and cfn_nag_scan for template warnings and security issues. This is fully adjustable to your needs. If you want to embed for example extra security checks, this is the spot to do so.

What is important here is how your templates are structured. This example uses CDK with cdk.out folder, but in our deployment framework CloudFormation native is used, for that example the CodeChecker TEMPLATES_FOLDER variable would point to the folder templates, including subfolders, to check the code.

The function create_approval_template (see above) is responsible for creating the CodeCommit approval rules for pull requests in AWS. The template itself states which members (approval_pool_members) are allowed to approve and how many approvals need to be given to allow the pull request to be merged. There is an extra function to return the approval rule name which later is used in the association. Lastly, It returns the approval rule template which is used inside the for loop over the dicts.

The function associate_approval_rule_template_with_repositories above is responsible for associating the approval template with the repository. Additionally, there is a function create_pull_request_role to be used CodeBuild.

With this, we have created a pull request mechanism which is automatically started when someone creates a pull request. The pull request fires off a CodeBuild project where tests and security checks are executed. When everything is successful, the pull request will receive approval automatically. Depending on the amount of approvals that need to be given, the pull request can be merged. It is easily adjustable with extra checks, by adding more options inside the codebuild project.