So let’s talk about AWS code commit now. So the concept we need to introduce is version control. It’s the ability to understand the various changes that happen to code over time and possibly roll back. So to have version control, that means that you can see what happened in the past, who committed some code, what changed, what was added was removed and so on, and then roll back.
And so to get version control, there is an underlying technology that’s very, very popular nowadays called Git, and a Git repository can be synchronized on your computer, but it’s also very usually uploaded onto a central online repository. And the benefits of having a central online repo for a git repo is that you can collaborate with other developers. So it allows, you know, organizations up to maybe hundreds of thousands developers to work on the same code at the same time, which is amazing.
Make sure that also the code is backed up somewhere. So the code lives on the cloud and not on just someone’s computer, make sure it’s fully viewable and editable so we can see who committed to what line of code when, and we can revert them. You can roll back.
we have a code repository in AWS and our developers.
For example, Emma and John can collaborate and push and pull code from our code repo So why do we want to use Code Commit? Well, Git repository can be quite expensive.
And so there is like some industry, that offer, third party services, which is github, Gitlab, Bitbucket and so on, but the bill could be pretty high, but by using code commits, which is on AWS, you get a private git repository that’s because your code actually lives and stays within your VPC on AWS cloud.
There’s no size limit on the repo. That means that you can scale to, you know, gigabytes of code, if you want it to it’s fully managed is highly available. And the Code, as I said, is only in the AWS cloud. So that means there is increased security and compliance, and maybe for example, unacceptable for you to have your code elsewhere then on AWS also could commit a security.
So it’s encrypted, you have access control using IAM and so on, and you have integrations within code commit and industry standards for such as Jenkins or CodeBuild or other CI tools, which make it a great choice to store your code.
So interactions are done using this standard Git command line, but then you have authentication on top of it. It could be using SSH keys. In which case, as a user, you can configure your SSH keys to be able to go into a Git repo or HTTPS. If you wanted to get access using standard login and password to get repo. for authorization, you have IAM policies are used to manage users and roles permissions to the specific repos, which is nice because that means you only have one way of managing security in AWS Encryption.
So your code is ultimately going to be encrypted using KMS. And that means that no one else, but you can retrieve it. And also while you push your code to code commit, you have encryption in transit because you use HTTPS or SSH protocols, which are both secure.
And then in case of cross account access, of course you would not share you as SSH keys or your credentials with someone else. Instead, you would create an IAM role in your accounts and then use STS the AssumeRoleAPI to get access to a code commit repo.
CodeCommit vs GitHub
So just to finish your high-level overview, because you may be very well familiar with GitHub.
So CodeCommit versus Github is almost a one-to-one comparison in some ways, but so codecommit and Github support code reuse also called pull requests. There is both integration with code build and there is a authentication with SSL and HTTPS for both codecommit and Github. In terms of security. Now it’s very different.
So Github support to Github users and SSO if you have enterprise level, but codecommit is fully integrated with AWS. So you have IAM users and roles for hosting while your code is only on AWS for codecommit, whereas Github, you can host dates directly on GitHub itself, or if you’ll get an enterprise, you can host it on your own servers.
The UI for codecommit, may I say is quite minimal. Whereas I really like GitHub UI it’s fully featured, but again, if you’re just using it as a code repo, then maybe you want to go towards code commit for many reasons that I’ve just said it from before.
Monitoring with EventBridge
So a few extra topics for CodeCommit.
The first one is that you can monitor any kind of events happening in CodeCommit through EventBridge. So anytime there is a pull request that is created or that a pull request status changes, or a new reference is created, or a new comment is created, then you can react to that in EventBridge which gives you some cool automation opportunities because for example, say you wanted to react to a new pull request, you could, through EventBridge, invoke SNS, Lambda, or CodePipeline.
Migrate Git Repository to CodeCommit
Also, how do you migrate a repository from one place to CodeCommit?
Well, if your repository is hosted on another place such as GitHub or GitLab, then you can push it to CodeCommit very simply. The way you do it is that first you need to create your CodeCommit repository, but then you do a git clone.
Now, this git clone command is going to take the entire content of your Git repository from the server and put it on your local computer. That means all project files, all commits, everything. And then once the project is cloned onto your local computer, you can push it to a different URL. So instead of pushing it back to the Git server, you can push it to a new Git place such as your CodeCommit repository. And that’s how you migrate a Git repo.
Cross-Region Replication
So how can we achieve a cross-region replication in CodeCommit?
Well, we would want to do cross-region replication, for example, to have lower latency for pulls for global developers, or to have a backup of a repo. So say for example, we want to have a copy of us-east-1 into eu-west-2 with replication.
So how does that work? Well, for example, whenever we push to an existing branch or we create and delete a branch, CodeCommit will actually emit an event in EventBridge called referenceCreated or referenceUpdated.
So this is the type of event that will appear. And from there, EventBridge can trigger, for example, an ECS task. The ECS task will do a git clone of the CodeCommit repository, and then we’ll replicate it to the target repository in eu-west-2. So we could use an ECS task, but I’m pretty sure we could also use a CodeBuild task if we wanted to. And so this is how thanks to EventBridge we can achieve cross-region replication of a CodeCommit repo.
Branch Security
So what about branch security in CodeCommit? Well, as soon as you grant a user push permission into a CodeCommit repo, they can contribute to any branch they want. And so to restrict to which branch they can contribute to, you need to restrict the users. And for this, we use IAM policies.
So say we have a CodeCommit repo with production, staging, and development branch and we want to only allow the senior developers to push the code to the production branch. So here we allow it through IAM policies, but the other IAM policies we apply to the junior developers will prevent them from pushing into production.
So this is the kind of IAM policy that looks like it. So here we have a deny effect and if we look at the condition, we say, hey, we deny if it looks like you’re pushing into the main or the prod branches. And so this IAM policy must be attached to your junior developer groups, for example, and then they won’t be able to push into prod.
So you may say, well, what about resource policies? What about an IAM policy directly attached into your CodeCommit repository? Well, for now, it is not supported yet. So the only way to do branch security is to deal with it at the user level or the group level directly in IAM.
Pull Request Approval Rules
Now, if there is a pull request, so that means a proposed change into a branch, then you can set up approval rules. So these approval rules ensure that the quality of your code has been reviewed and approved by a certain amount of people before the PR, the pull request is merged.
So with a pull request approval rule, we specify a pool of users to approve and then a number of users we need to approve for the PR.
So for example, we have a pull request on our CodeCommit repo and we’ve defined a pool of five users that can approve this request, but we need two of them to accept it. So maybe user one will review it and accept it. User three will review it and accept it. Therefore, your pull request will be accepted. And once accepted, then it can be merged into the repository.
So to specify who and what can accept pull request, we can specify IAM principles ARN such as users, federated users, IAM roles, IAM groups, and so on.
Also, if you wanted to automatically create these kind of approval rules on any pull request, then we can use a template and we say, okay, you should apply these approval rules directly for any pull request in the dev and the prod branches.
