Source Control and Artifact Management with CodeCommit and CodeArtifact

Let’s break down the two core services: CodeCommit and CodeArtifact.

Source Control with AWS CodeCommit

Source control (also called version control) is a system that records changes to a file or set of files over time so that you can recall specific versions later. Think of it as an infinite ‘undo’ button for your entire project. CodeCommit is AWS’s fully managed, private Git repository. Git is a widely used source control system developed by Linus Torvalds. A repository (repo) is the central location where all your project files and their history live. CodeCommit is like a supercharged, cloud-based hard drive that tracks every single edit.

How does it work? When you first create a CodeCommit repository, it’s empty. You then ‘clone’ it to your local computer, which downloads the empty repo. You add your code files, save them, and then you ‘commit’ those changes. A commit is a snapshot of your work at that moment, tagged with a unique ID, your name, and a message explaining the change. You then ‘push’ that commit from your computer up to the CodeCommit repository in the cloud. Now, the change is permanently stored. If your computer crashes tomorrow, the code is safe in AWS. If a colleague pushes a conflicting change, CodeCommit’s merge logic helps you combine them. It also supports ‘branching’ – creating an independent copy of the code to work on a new feature without disturbing the stable, main version (the ‘main’ branch). Once the feature is ready and tested, you ‘merge’ that branch back into main.

Why does this exist? Before source control, developers would copy files to a shared drive, email them to each other, or use clumsy manual processes. Files were constantly overwritten, lost, or corrupted. CodeCommit replaces this chaos with a pristine, auditable history of every change.

Artefact Management with AWS CodeArtifact

An artefact is a packaged, deployable piece of software, like a Java JAR file, a Python wheel, a Node.js package, or a Docker image. CodeArtifact is a secure, scalable artefact repository that stores and manages these packages. It acts as a central, trusted ‘package store’ for your entire organisation.

How does it work? Developers configure their build tools (like Maven, Gradle, npm, pip) to point to a CodeArtifact repository. When a developer needs a library, say a logging library, their build tool asks CodeArtifact for it. CodeArtifact can either serve the package from its own storage or automatically ‘proxify’ the request to a public repository like Maven Central or npmjs.org. This means CodeArtifact acts as a middleman, caching the package locally so that if the public repository goes down, your builds still work. It also prevents ‘dependency confusion’ attacks, where a malicious package with the same name as your internal one is fetched from a public repository.

Why does this exist? Manual download of libraries is insecure and unmanageable. Teams need a single source of truth for all software components. CodeArtifact ensures that every developer, build server, and deployment pipeline uses the exact same, approved, and secure version of every library. It integrates natively with AWS IAM (Identity and Access Management) for fine-grained permission control – you can decide exactly who can publish new packages and who can download them.

Together, CodeCommit and CodeArtifact form the first two stages of a CI/CD pipeline: source (where code lives and evolves) and package (where code is turned into deployable units).

Meet Sarah, a DevOps engineer at a company called FinFlow that builds a mobile banking app. Her team has 15 developers, two QA testers, and one operations person.

Step 1: Setting Up Source Control. Sarah creates a new CodeCommit repository called ‘finflow-app’. She configures IAM policies so that only the senior developers can push directly to the main branch, and every push triggers an email notification to the team. She clones the empty repo, adds the initial application skeleton, and pushes the first commit.

Step 2: Feature Development. A developer named Alex wants to add a new ‘transaction search’ feature. He creates a new branch called ‘feature/search’ from the main branch. He works on this branch for three days, making 17 commits. Each commit is a snapshot of his progress. He can instantly see what he changed at each step using the ‘git log’ command. If he makes a mistake, he uses ‘git revert’ to undo a specific commit without losing his other changes.

Step 3: Collaborative Merging. Alex finishes his feature and pushes his branch to CodeCommit. He then creates a ‘pull request’ (PR) – a formal request to merge his branch into main. The PR triggers an automated test suite via AWS CodePipeline. Sarah reviews the code and sees the diff (the difference between the two code versions) directly in the CodeCommit console. She leaves comments on specific lines of code. Alex fixes the issues, pushes new commits to the same branch, and Sarah approves the PR. CodeCommit automatically merges the branch into main.

Step 4: Building Artefacts. Once code is merged into main, a CodePipeline build action triggers. The build server compiles the Java code, runs unit tests, and then produces a .jar file – the deployable artefact. The build action automatically publishes that .jar file to a CodeArtifact repository called ‘finflow-releases’. This is a private repository. Only authorised build machines have IAM permissions to publish to it.

Step 5: Securing Dependencies. During the build, the build server needs external libraries like a logging framework. Instead of downloading them from the public internet (which is slow and risky), the build tool is configured to fetch them from a CodeArtifact repository that proxies the public Maven repository. CodeArtifact caches the library once, and all subsequent builds use the cached version, making builds faster and more reliable. It also prevents a scenario where a malicious actor publishes a fake ‘log4j’ package to the public repository – CodeArtifact would only serve the version Sarah’s team has approved.

Step 6: Consumption by Deployment. The operations team, using CodeDeploy, pulls the exact .jar file from the CodeArtifact repository and deploys it to an EC2 instance. Because the artefact is in a secure, versioned repository, they know exactly what is being deployed. Rollbacks are simple: just fetch a previous version of the artefact from CodeArtifact and re-deploy it. No more ‘it works on my machine’ problems.

This entire workflow demonstrates how CodeCommit and CodeArtifact move the organisation from a manual, error-prone process to an automated, secure, and auditable pipeline.