In this project based on a real-world scenario, I implemented Git repositories for application- and infrastructure-code using AWS CodeCommit and AWS Cloud9. I got hands-on experience with the Proof of Concept (PoC) process of committing, pushing, and reverting code changes.
My mission was to set up a remote Git repository using AWS CodeCommit for “HumanGov,” a hypothetical Software as a Service (SaaS) company providing services for a government organization.
To setup the development environment, I signed into the AWS Management Console, went into CodeCommit, and created 2 new Git repositories (repos):
- “human-gov-application” which will be used by the team of Software Developers to store the ‘humangov’ application source code.
- “human-gov-infrastructure” which will be used by the team of DevOps Engineers to store the ‘humangov’ infrastructure source code, such as the configuration files for Terraform and Ansible.
Rather than running the Git application on my local system, I ran Git in an AWS Cloud9 development environment running on Amazon Linux. That way there is no company intellectual property stored on my local machine, and I have the ability to access the development enviroment from any internet-connected device with a web browser.
In order to use Cloud9 to make code changes in my CodeCommit repositories, I configured the AWS Cloud9 CLI credential helper to manage the credentials for connections to my CodeCommit repositories by running the following commands:
> git config — global credential.helper ‘!aws codecommit credential-helper $@’
> git config — global credential.UseHttpPath true
Note: These commands can be found in the AWS CodeCommit documentation (located here).
I then cloned my CodeCommit repositories into my Cloud9 developement environment using the following commands:
> git clone https://git-codecommit.us-east-1.amazonaws.com/v1/repos/human-gov-infrastructure
> git clone https://git-codecommit.us-east-1.amazonaws.com/v1/repos/human-gov-application
I used the ls command in the Cloud9 command-line-interface (CLI) to confirm the repos had been successfully cloned to Cloud9.
> ls -la h*
To simulate the proof of concept for committing, pushing, and reverting code changes to the remote repository, I created 2 additional Cloud9 environments, one for ‘developer1’ and another for ‘developer2’ and accessed those environments and played the part of the 2 developers.
Upon accessing the environment for developer1, I noted that developer1 diud not have the humangov folders, which made sense, as this is a new Cloud9 environment.
Developer1 cloned the ‘human-gov-application’ repo from CodeCommit to the developer1 Cloud9 environment.
> git clone https://git-codecommit.us-east-1.amazonaws.com/v1/repos/human-gov-application
The ‘human-gov-application’ repo was then listed in the developer1 Cloud9 environment, as seen below.
Developer1 created a new ‘index.html’ file in the working directory of the ‘human-gov-application’ repo, added some basic html code, and then added the index.html file to the staging area using ‘git add’, commited index.html to the git repository using ‘git commit’ and then pushed index.html to the remote repository using ‘git push’ as shown below.
Next, I simulated an issue by having developer1 make a change to the header size in the index.html file, and while doing so also ‘accidentally’ create a typo in the website header. Developer1 then saved the index.html file, and added, committed, and pushed the misconfigured file to the remote repository. Developer1 then headed out of town on vacation. A short time later a manager noticed the mistake but could not reach developer1, as developer1 had boarded a plane for Tahiti. The manager reached out to the developer-on-call, developer2, to fix the issue. The manager advised developer2 that developer1 made some changes to the website, but the manager wasn’t sure what exactly was changed, and so asked developer2 to revert the most recent changes made by developer1.
Acting as developer2, I connected to Cloud9 environment of developer2 and cloned the CodeCommit ‘human-gov-application’ repo, viewed the git log, saw the 2 commits made by developer1, reverted the commit titled, ‘changed header size’ and confirmed that the website once again displayed correctly. Developer2 then made the originally requested changes to the header size in the index.html file, and performed a git add/commit/push to the remote repository.
We can see all the commits performed on the ‘human-gov-application’ repo by viewing the commit logs for the repo in AWS CodeCommit.
This was a great lab for demonstrating the capabilities of the Git version control system when combined with remote repositories. I can definitely see how beneficial git would be in coordinating the efforts of teams working on complex projects that require many individuals working from a shared code base, whether that be for software development or infrastructure configuration, deployment, and management, which I believe is my next project!
