You can start with open source versions of the CI/CD tools, but in the long run, the overall total cost of ownership (TCO) takes a hit as it factors in the time you invest in maintaining, scaling, and operating these solutions. AWS-managed services remove this overhead and allow you to pay as you go. Economies of scale reduce the cost even further, which can be a strong proponent of adopting cloud-based solutions.
However, if you want to host an open source solution on-premises to retain full control and customize it as per your needs, look out for cloud integrations that could simplify a future move.
Having covered the basics of CI/CD, let’s dive into AWS specifics and discuss the core capabilities offered by the cloud provider. Most important of all, we’ll see how seamless it is to integrate them with the overall AWS ecosystem.
Enabling continuous integration with CodeCommit and CodeBuild
AWS CodeCommit and AWS CodeBuild are two services that operate in the CI space. CodeCommit, like other Version Control Systems (VCSs), is an abstraction on top of Git and offers code repository management in supported AWS regions. Similar to how GitHub, GitLab, and other platforms work, it helps software teams collaborate, work with pull requests, manage branching, and so on. Speaking of the overall code management ecosystem, I wouldn’t say that CodeCommit offers something that others don’t, except one thing, which is integrating well with other AWS services. However, at the same time, these services offer similar integration capabilities with other platforms. So, it is very much possible for you to continue using your third-party tools of choice as the teams would already be comfortable with the code management processes offered by them.
Key features offered by CodeCommit
In addition to generic code management capabilities, several other highlights help you establish controls to meet your organization’s coding, security, or compliance requirements.
Granular security controls with IAM
Restricting access to protected branches is as simple as applying the right IAM policies for your users or groups. You can be very specific with the criteria, such as granting permissions for specific Git actions (push, pull, merge, and so on), or limiting access to certain branches.
Let’s see a sample IAM policy that only allows the GitPush action on the dev and test branches for a developer:
{“Version”:”2012-10-17″,”Statement”[{“Effect”:”Deny”,”Action”:”codecommit:GitPush,”Resource”:”arn:aws:codecommit:eucentral1:111111111111:SampleRepo”,”Condition”: {“StringEqualsIfExists”: {“codecommit:References”: [ “refs/heads/test”, “refs/heads/dev” ]}}}]}
It is a good practice to restrict certain Git permissions, such as MergePullRequestByFastForward, to individuals who are more experienced with the code base. By not allowing fast- forward merges to everyone, you avoid scenarios that could pollute the main branch if commits are not written thoughtfully. A squash merge addresses this by squashing all commits from the feature branch into one. Organizations usually align these permissions with the Git branching strategy that has been established for certain software or teams.