Search the Community

AWS CodePipeline Source Action now supports cloning of AWS CodeCommit repositories. With this improvement, when you define a Source Action, CodePipeline will clone the CodeCommit git repository to fetch the commit history and metadata. View the full article

As a developer working in a large enterprise or for a group that supports multiple products, you may often find yourself accessing Git repositories from different organizations. Currently, to securely access multiple Git repositories in other popular tools, you need SSH keys, GPG keys, a Git credential helper, and a significant amount of setup by the developer hoping to commit to the repository. In addition, administrators must be aware of the various ways to remove all the permissions granted to the developer. AWS CodeCommit is a managed source control service. Combined with AWS Single Sign-On (AWS SSO) and git-remote-codecommit, you can quickly and easily switch between repositories owned by different groups or even managed in separate AWS accounts. You can control those permissions with AWS Identity and Access Management (IAM) roles to allow for the automated removal of the user’s permission as part of their off-boarding procedure for the company. This post demonstrates how to grant access to various CodeCommit repositories without access keys. Solution overview In this solution, the user’s access is controlled with federated login via AWS SSO. You can grant that access using AWS native authentication, which eliminates the need for a Git credential helper, SSH, and GPG keys. In addition, this allows the administrator to control access by adding or removing the user’s IAM role access. The following diagram shows the code access pattern you can achieve by using AWS SSO and git-remote-codecommit to access CodeCommit across multiple accounts. Prerequisites To complete this tutorial, you must have the following prerequisites: CodeCommit repositories in two separate accounts. For instructions, see Create an AWS CodeCommit repository. AWS SSO set up to handle access federation. For instructions, see Enable AWS SSO. Python 3.6 or higher installed on the developer’s local machine. To download and install the latest version of Python, see the Python website. On a Mac, it can be difficult to ensure that you’re using Python 3.6, because 2.7 is installed and required by the OS. For more information about checking your version of Python, see the following GitHub repo. Git installed on your local machine. To download Git, see Git Downloads. PIP version 9.0.3 or higher installed on your local machine. For instructions, see Installation on the PIP website. Configuring AWS SSO role permissions As your first step, you should make sure each AWS SSO role has the correct permissions to access the CodeCommit repositories. On the AWS SSO console, choose AWS Accounts. On the Permissions Sets tab, choose Create permission set. On the Create a new permission set page, select Create a custom permission set. For Name, enter CodeCommitDeveloperAccess. For Description, enter This permission set gives the user access to work with CodeCommit for common developer tasks. For Session duration, choose 12 hours. For Relay state, leave blank. For What policies do you want to include in your permissions set?, select Create a custom permissions policy. Use the following policy: { "Version": "2012-10-17", "Statement": [ { "Sid": "CodeCommitDeveloperAccess", "Effect": "Allow", "Action": [ "codecommit:GitPull", "codecommit:GitPush", "codecommit:ListRepositories" ], "Resource": "*" } ] } The preceding code grants access to all the repositories in the account. You could limit to a specific list of repositories, if needed. Choose Create. Creating your AWS SSO group Next, we need to create the SSO Group we want to assign the permissions. On the AWS SSO console, choose Groups. Choose create group. For Group name, enter CodeCommitAccessGroup. For Description, enter Users assigned to this group will have access to work with CodeCommit. Choose Create. Assigning your group and permission sets to your accounts Now that we have our group and permission sets created, we need to assign them to the accounts with the CodeCommit repositories. On the AWS SSO console, choose AWS Accounts. Choose the account you want to use in your new group. On the account Details page, choose Assign Users. On the Select users or groups page, choose Group. Select CodeCommitGroup. Choose NEXT: Permission Sets. Choose the CodeCommitDeveloperAccess permission set and choose Finish Choose Proceed to Accounts to return to the AWS SSO console. Repeat these steps for each account that has a CodeCommit repository. Assigning a user to the group To wrap up our AWS SSO configuration, we need to assign the user to the group. On the AWS SSO console, choose Groups. Choose CodeCommitAccessGroup. Choose Add user. Select all the users you want to add to this group. Choose Add user(s). From the navigation pane, choose Settings. Record the user portal URL to use later. Enabling AWS SSO login The second main feature we want to enable is AWS SSO login from the AWS Command Line Interface (AWS CLI) on our local machine. Run the following command from the AWS CLI. You need to enter the user portal URL from the previous step and tell the CLI what Region has your AWS SSO deployment. The following code example has AWS SSO deployed in us-east-1: aws configure sso SSO start URL [None]: https://my-sso-portal.awsapps.com/start SSO region [None]:us-east-1 You’re redirected to your default browser. Sign in to AWS SSO. When you return to the CLI, you must choose your account. See the following code: There are 2 AWS accounts available to you. > DeveloperResearch, developer-account-admin@example.com (123456789123) DeveloperTrading, trading-account-admin@example.com (123456789444) Choose the account with your CodeCommit repository. Next, you see the permissions sets available to you in the account you just picked. See the following code: Using the account ID 123456789123 There are 2 roles available to you. > ReadOnly CodeCommitDeveloperAccess Choose the CodeCommitDeveloperAccess permissions. You now see the options for the profile you’re creating for these AWS SSO permissions: CLI default client Region [None]: us-west-2<ENTER> CLI default output format [None]: json<ENTER> CLI profile name [123456789011_ReadOnly]: DevResearch-profile<ENTER> Repeat these steps for each AWS account you want to access. For example, I create DevResearch-profile for my DeveloperResearch account and DevTrading-profile for the DeveloperTrading account. Installing git-remote-codecommit Finally, we want to install the recently released git-remote-codecommit and start working with our Git repositories. Install git-remote-codecommit with the following code: pip install git-remote-codecommit With some operating systems, you might need to run the following code instead: sudo pip install git-remote-codecommit Clone the code from one of your repositories. For this use case, my CodeCommit repository is named MyDemoRepo. See the following code: git clone codecommit://DevResearch-profile@MyDemoRepo my-demo-repo After that solution is cloned locally, you can copy code from another federated profile by simply changing to that profile and referencing the repository in that account named MyDemoRepo2. See the following code: git clone codecommit://DevTrading-profile@MyDemoRepo2 my-demo-repo2 Cleaning up At the end of this tutorial, complete the following steps to undo the changes you made to your local system and AWS: On the AWS SSO console, remove the user from the group you created, so any future access requests fail. To remove the AWS SSO login profiles, open the local config file with your preferred tool and remove the profile. The config file is located at %UserProfile%/.aws/config for Windows and $HOME/.aws/config for Linux or Mac. To remove git-remote-codecommit, run the PIP uninstall command: pip uninstall git-remote-codecommit With some operating systems, you might need to run the following code instead: sudo pip uninstall git-remote-codecommit Conclusion This post reviewed an approach to securely switch between repositories and work without concerns about one Git repository’s security credentials interfering with the other Git repository. User access is controlled by the permissions assigned to the profile via federated roles from AWS SSO. This allows for access control to CodeCommit without needing access keys. About the Author Steven David Steven David is an Enterprise Solutions Architect at Amazon Web Services. He helps customers build secure and scalable solutions. He has background in application development and containers. View the full article

In this post, we walk you through migrating Subversion (SVN) repositories to AWS CodeCommit. But before diving into the migration, we do a brief review of SVN and Git based systems such as CodeCommit. About SVN SVN is an open-source version control system. Founded in 2000 by CollabNet, Inc., it was originally designed to be a better Concurrent Versions System (CVS), and is being developed as a project of the Apache Software Foundation. SVN is the third implementation of a revision control system: Revision Control System (RCS), then CVS, and finally SVN. SVN is the leader in centralized version control. Systems such as CVS and SVN have a single remote server of versioned data with individual users operating locally against copies of that data’s version history. Developers commit their changes directly to that central server repository. All the files and commit history information are stored in a central server, but working on a single central server means more chances of having a single point of failure. SVN offers few offline access features; a developer has to connect to the SVN server to make a commit that makes commits slower. The single point of failure, security, maintenance, and scaling SVN infrastructure are the major concerns for any organization. About DVCS Distributed Version Control Systems (DVCSs) address the concerns and challenges of SVN. In a DVCS (such as Git or Mercurial), you don’t just check out the latest snapshot of the files; rather, you fully mirror the repository, including its full history. If any server dies, and these systems are collaborating via that server, you can copy any of the client repositories back up to the server to restore it. Every clone is a full backup of all the data. DVCs such as Git are built with speed, non-linear development, simplicity, and efficiency in mind. It works very efficiently with large projects, which is one of the biggest factors why customers find it popular. A significant reason to migrate to Git is branching and merging. Creating a branch is very lightweight, which allows you to work faster and merge easily. About CodeCommit CodeCommit is a version control system that is fully managed by AWS. CodeCommit can host secure and highly scalable private Git repositories, which eliminates the need to operate your source control system and scale its infrastructure. You can use it to securely store anything, from source code to binaries. CodeCommit features like collaboration, encryption, and easy access control make it a great choice. It works seamlessly with most existing Git tools and provides free private repositories. Understanding the repository structure of SVN and Git SVNs have a tree model with one branch where the revisions are stored, whereas Git uses a graph structure and each commit is a node that knows its parent. When comparing the two, consider the following features: Trunk – An SVN trunk is like a primary branch in a Git repository, and contains tested and stable code. Branches – For SVN, branches are treated as separate entities with its own history. You can merge revisions between branches, but they’re different entities. Because of its centralized nature, all branches are remote. In Git, branches are very cheap; it’s a pointer for a particular commit on the tree. It can be local or be pushed to a remote repository for collaboration. Tags – A tag is just another folder in the main repository in SVN and remains static. In Git, a tag is a static pointer to a specific commit. Commits – To commit in SVN, you need access to the main repository and it creates a new revision in the remote repository. On Git, the commit happens locally, so you don’t need to have access to the remote. You can commit the work locally and then push all the commits at one time. So far, we have covered how SVN is different from Git-based version control systems and illustrated the layout of SVN repositories. Now it’s time to look at how to migrate SVN repositories to CodeCommit. Planning for migration Planning is always a good thing. Before starting your migration, consider the following: Identify SVN branches to migrate. Come up with a branching strategy for CodeCommit and document how you can map SVN branches. Prepare build, test scripts, and test cases for system testing. If the size of the SVN repository is big enough, consider running all migration commands on the SVN server. This saves time because it eliminates network bottlenecks. Migrating the SVN repository to CodeCommit When you’re done with the planning aspects, it’s time to start migrating your code. Prerequisites You must have the AWS Command Line Interface (AWS CLI) with an active account and Git installed on the machine that you’re planning to use for migration. Listing all SVN users for an SVN repository SVN uses a user name for each commit, whereas Git stores the real name and email address. In this step, we map SVN users to their corresponding Git names and email. To list all the SVN users, run the following PowerShell command from the root of your local SVN checkout: svn.exe log --quiet | ? { $_ -notlike '-*' } | % { "{0} = {0} &amp;amp;lt;{0}&amp;amp;gt;" -f ($_ -split ' \| ')[1] } | Select-Object -Unique | Out-File 'authors-transform.txt' On a Linux based machine, run the following command from the root of your local SVN checkout: svn log -q | awk -F '|' '/^r/ {sub("^ ", "", $2); sub(" $", "", $2); print $2" = "$2" &lt;"$2"&gt;"}' | sort -u &gt; authors-transform.txt The authors-transform.txt file content looks like the following code: ikhan = ikhan <ikhan> foobar= foobar <foobar> abob = abob <abob> After you transform the SVN user to a Git user, it should look like the following code: ikhan = ifti khan <ikhan@abc.com> fbar = foo bar <fbar@abc.com> abob = aaron bob <abob@abc.com> Importing SVN contents to a Git repository The next step in the migration from SVN to Git is to import the contents of the SVN repository into a new Git repository. We do this with the git svn utility, which is included with most Git distributions. The conversion process can take a significant amount of time for larger repositories. The git svn clone command transforms the trunk, branches, and tags in your SVN repository into a new Git repository. The command depends on the structure of the SVN. git svn clone may not be available in all installations; you might consider using an AWS Cloud9 environment or using a temporary Amazon Elastic Compute Cloud (Amazon EC2) instance. If your SVN layout is standard, use the following command: git svn clone --stdlayout --authors-file=authors.txt <svn-repo>/<project> <temp-dir/project> If your SVN layout isn’t standard, you need to map the trunk, branches, and tags folder in the command as parameters: git svn clone <svn-repo>/<project> --prefix=svn/ --no-metadata --trunk=<trunk-dir> --branches=<branches-dir> --tags==<tags-dir> --authors-file "authors-transform.txt" <temp-dir/project> Creating a bare Git repository and pushing the local repository In this step, we create a blank repository and match the default branch with the SVN’s trunk name. To create the .gitignore file, enter the following code: cd <temp-dir/project> git svn show-ignore > .gitignore git add .gitignore git commit -m 'Adding .gitignore.' To create the bare Git repository, enter the following code: git init --bare <git-project-dir>\local-bare.git cd <git-project-dir>\local-bare.git git symbolic-ref HEAD refs/heads/trunk To update the local bare Git repository, enter the following code: cd <temp-dir/project> git remote add bare <git-project-dir\local-bare.git> git config remote.bare.push 'refs/remotes/*:refs/heads/*' git push bare You can also add tags: cd <git-project-dir\local-bare.git> For Windows, enter the following code: git for-each-ref --format='%(refname)' refs/heads/tags | % { $_.Replace('refs/heads/tags/','') } | % { git tag $_ "refs/heads/tags/$_"; git branch -D "tags/$_" } For Linux, enter the following code: for t in $(git for-each-ref --format='%(refname:short)' refs/remotes/tags); do git tag ${t/tags\//} $t &amp;&amp; git branch -D -r $t; done You can also add branches: cd <git-project-dir\local-bare.git> For Windows, enter the following code: git for-each-ref --format='%(refname)' refs/remotes | % { $_.Replace('refs/remotes/','') } | % { git branch "$_" "refs/remotes/$_"; git branch -r -d "$_"; } For Linux, enter the following code: for b in $(git for-each-ref --format='%(refname:short)' refs/remotes); do git branch $b refs/remotes/$b && git branch -D -r $b; done As a final touch-up, enter the following code: cd <git-project-dir\local-bare.git> git branch -m trunk master Creating a CodeCommit repository You can now create a CodeCommit repository with the following code (make sure that the AWS CLI is configured with your preferred Region and credentials): aws configure aws codecommit create-repository --repository-name MySVNRepo --repository-description "SVN Migration repository" --tags Team=Migration You get the following output: { "repositoryMetadata": { "repositoryName": "MySVNRepo", "cloneUrlSsh": "ssh://ssh://git-codecommit.us-east-2.amazonaws.com/v1/repos/MySVNRepo", "lastModifiedDate": 1446071622.494, "repositoryDescription": "SVN Migration repository", "cloneUrlHttp": "https://git-codecommit.us-east-2.amazonaws.com/v1/repos/MySVNRepo", "creationDate": 1446071622.494, "repositoryId": "f7579e13-b83e-4027-aaef-650c0EXAMPLE", "Arn": "arn:aws:codecommit:us-east-2:111111111111:MySVNRepo", "accountId": "111111111111" } } Pushing the code to CodeCommit To push your code to the new CodeCommit repository, enter the following code: cd <git-project-dir\local-bare.git> git remote add origin https://git-codecommit.us-east-2.amazonaws.com/v1/repos/MySVNRepo git add * git push origin --all git push origin --tags (Optional if tags are mapped) Troubleshooting When migrating SVN repositories, you might encounter a few SVN errors, which are displayed as code on the console. For more information, see Subversion client errors caused by inappropriate repository URL. For more information about the git-svn utility, see the git-svn documentation. Conclusion In this post, we described the straightforward process of using the git-svn utility to migrate SVN repositories to Git or Git-based systems like CodeCommit. After you migrate an SVN repository to CodeCommit, you can use any Git-based client and start using CodeCommit as your primary version control system without worrying about securing and scaling its infrastructure. View the full article

Development teams use agile development processes based on Git services extensively. AWS provides AWS CodeCommit, a managed, Git protocol-based, secure, and highly available code service. The capabilities of CodeCommit combined with other developer tools, like AWS CodeBuild and AWS CodePipeline, make it easy to manage collaborative, scalable development process with fine-grained permissions and on-demand resources. You can manage user roles with different AWS Identity and Access Management (IAM) policies in the code repository of CodeCommit. You can build your collaborative development process with pull requests and approval rules. The process described in this post only requires you to manage the developers’ role, without forking the source repository for individual developers. CodeCommit pull requests can integrate numerous code analysis services as approvers to improve code quality and mitigate security vulnerabilities, such as SonarQube static scanning and the ML-based code analysis service Amazon CodeGuru Reviewer. The CodeCommit-based agile development process described in this post has the following characteristics: Control permissions of the CodeCommit repository via IAM. Any code repository has at least two user roles: Development collaborator – Participates in the development of the project. Repository owner – Has code review permission and partial management permissions of the repository. The repository owner is also the collaborator of the repository. Both development collaborator and owner have read permissions of the repository and can pull code to local disk via the Git-supported protocols. The development collaborator can push new code to branches with a specific prefix, for example, features/ or bugs/. Multiple collaborators can work on a particular branch for one pull request. Collaborators can create new pull requests to request merging code into the main branch, such as the mainline branch. The repository owner has permission to review pull requests with approval voting and merge pull requests. Directly pushing code to the main branch of repository is denied. Development workflow. This includes the following: Creating an approval template rule of CodeCommit that requires at least two approvals from the sanity checking build of the pull request and repository owner. The workflow also applies the approval rule to require mandatory approvals for pull requests of the repository. The creation and update of source branch events of pull requests via Amazon EventBridge triggers a sanity checking build of CodeBuild to compile, test, and analyze the pull request code. If all checks pass, the pull request gets an approval voting from the sanity checking build. Watching the main branch of the repository triggers a continuous integration for any commit. You can continuously publish artifacts of your project to the artifact repository or integrate the latest version of the service to your business system. This agile development process can use AWS CloudFormation and AWS Cloud Development Kit (AWS CDK) to orchestrate AWS resources with the best practice of infrastructure as code. You can manage hundreds of repositories in your organization and automatically provision new repositories and related DevOps resources from AWS after the pull request of your IaC as a new application is approved. This makes sure that you’re managing the code repository and DevOps resources in a secure and compliant way. You can use it as a reference solution for your organization to manage large-scale R&D resources. Solution overview In the following use case, you’re working on a Java-based project AWS Toolkit for JetBrains. This application has developers that can submit code via pull requests. Each pull request is automatically checked and validated by CodeBuild builds. The owners of the project can review the pull request and merge it to the main branch. The code submitted to the main branch triggers the continuous integration to build the project artifacts. The following diagram illustrates the components built in this post and their role in the DevOps process. Prerequisites For this walkthrough, you should meet the following prerequisites: Have an AWS account Have a Git client or an IDE that has Git support Install Node.js LTS version, for example, 12.x Install Docker Engine Install AWS Command Line Interface (AWS CLI) and configure it Preparing the code Clone the sample code from the Github repo with your preferred Git client or IDE and view branch aws-toolkit-jetbrains, or download the sample code directly and unzip it into an empty folder. Initializing the environment Open the terminal or command prompt of your operating system, enter the directory where the sample code is located, enter the following code to initialize the environment, and install the dependency packages: npm run init Deploying application After successfully initializing the AWS CDK environment and installing the dependencies of the sample application, enter the following code to deploy the application: npm run deploy Because the application creates the IAM roles and policies, AWS CDK requires you to confirm security-related changes before deploying it. You see the following outputs from the command line. Enter y to confirm the security changes, and AWS CDK begins to deploy the application. After a few minutes, you see output similar to the following code, indicating that the application stack has been successfully deployed in your AWS account: CodecommitDevopsModelStack Outputs: CodecommitDevopsModelStack.Repo1AdminRoleOutput = arn:aws:iam::012345678912:role/codecommitmodel/CodecommitDevopsModelStack-Repo1AdminRole0648F018-OQGKZPM6T0HP CodecommitDevopsModelStack.Repo1CollaboratorRoleOutput = arn:aws:iam::012345678912:role/codecommitmodel/CodecommitDevopsModelStac-Repo1CollaboratorRole1EB-15KURO7Z9VNOY Stack ARN: arn:aws:cloudformation:ap-southeast-1:012345678912:stack/CodecommitDevopsModelStack/5ecd1c50-b56b-11ea-8061-020de04cec9a As shown in the preceding code, the output of successful deployment indicates that the ARN of two IAM roles were created on behalf of the owner and development collaborator of the source code repository. Checking deployment results After successfully deploying the app, you can sign in to the CodeCommit console and browse repositories. The following screenshot shows three repositories. For this post, we use three repositories to demonstrate configuring the different access permissions for different teams in your organization. As shown in the following screenshot, the repository CodeCommitDevopsModelStack-MyApp1 is tagged to grant permissions to the specific team abc. The IAM roles for the owner and development collaborator only have access to the code repository with the following tags combination: { 'app': 'my-app-1', 'team': 'abc', } Configuring CodeCommit repository access on behalf of owner and collaborator Next, you configure the current user to simulate the owner and development collaborator via IAM’s AssumeRole. Edit the AWS CLI profile file with your preferred text editor and add the following configuration lines: [profile codecommit-repo1-owner] role_arn = <the ARN of owner role after successfully deploying sample app> source_profile = default region = ap-southeast-1 cli_pager= [profile codecommit-repo1-collaborator] role_arn = <the ARN of collaborator role after successfully deploying sample app> source_profile = default region = ap-southeast-1 cli_pager= Replace the role_arn in the owner and collaborator sections with the corresponding output after successfully deploying the sample app. If the AWS CLI isn’t using the default profile, replace the value of source_profile with the profile name you’re currently using. Make the region consistent with the value configured in source_profile. For example, this post uses ap-southeast-1. After saving the modification of the profile, you can test this configuration from the command line. See the following code: export AWS_DEFAULT_PROFILE=codecommit-repo1-owner # assume owner role of repository aws sts get-caller-identity # get current user identity, you should see output like below, { "UserId": "AROAQP3VLCVWYYTPJL2GW:botocore-session-1587717914", "Account": "0123456789xx", "Arn": "arn:aws:sts::0123456789xx:assumed-role/CodecommitDevopsModelStack-Repo1AdminRole0648F018-1SNXR23P4XVYZ/botocore-session-1587717914" } aws codecommit list-repositories # list of all repositories of AWS CodeCommit in configured region { "repositories": [ { "repositoryName": "CodecommitDevopsModelStack-MyApp1", "repositoryId": "208dd6d1-ade4-4633-a2a3-fe1a9a8f3d1c " }, { "repositoryName": "CodecommitDevopsModelStack-MyApp2", "repositoryId": "44421652-d12e-413e-85e3-e0db894ab018" }, { "repositoryName": "CodecommitDevopsModelStack-MyApp3", "repositoryId": "8d146b34-f659-4b17-98d8-85ebaa07283c" } ] } aws codecommit get-repository --repository-name CodecommitDevopsModelStack-MyApp1 # get detail information of repository name ends with MyApp1 { "repositoryMetadata": { "accountId": "0123456789xx", "repositoryId": "208dd6d1-ade4-4633-a2a3-fe1a9a8f3d1c", "repositoryName": "CodecommitDevopsModelStack-MyApp1", "repositoryDescription": "Repo for App1.", "lastModifiedDate": "2020-06-24T00:06:24.734000+08:00", "creationDate": "2020-06-24T00:06:24.734000+08:00", "cloneUrlHttp": "https://git-codecommit.ap-southeast-1.amazonaws.com/v1/repos/CodecommitDevopsModelStack-MyApp1", "cloneUrlSsh": "ssh://git-codecommit.ap-southeast-1.amazonaws.com/v1/repos/CodecommitDevopsModelStack-MyApp1", "Arn": "arn:aws:codecommit:ap-southeast-1:0123456789xx:CodecommitDevopsModelStack-MyApp1" } } aws codecommit get-repository --repository-name CodecommitDevopsModelStack-MyApp2 # try to get detail information of repository MyApp2 that does not have accessing permission by the role An error occurred (AccessDeniedException) when calling the GetRepository operation: User: arn:aws:sts::0123456789xx:assumed-role/CodecommitDevopsModelStack-Repo1AdminRole0648F018-OQGKZPM6T0HP/botocore-session-1593325146 is not authorized to perform: codecommit:GetRepository on resource: arn:aws:codecommit:ap-southeast-1:0123456789xx:CodecommitDevopsModelStack-MyApp2 You can also grant IAM policies starting with CodecommitDevopsmodelStack-CodecommitCollaborationModel to existing IAM users for the corresponding owner or collaborator permissions. Initializing the repository The new code repository CodecommitdevopsmodelStack-MyApp1 is an empty Git repository without any commit. You can use the AWS Toolkit for JetBrains project as the existing local codebase and push the code to the repository hosted by CodeCommit. Enter the following code from the command line: export AWS_DEFAULT_PROFILE=codecommit-repo1-owner # assume owner role of repository git clone https://github.com/aws/aws-toolkit-jetbrains.git # clone aws-toolkit-jetbrains to local as existing codebase cd aws-toolkit-jetbrains git remote add codecommit codecommit::ap-southeast-1://CodecommitDevopsModelStack-MyApp1 # add CodeCommit hosted repo as new remote named as codecommit. Follow the doc set up AWS CodeCommit with git-remote-codecommit, or use remote url of repository via https/ssh protocol git push codecommit master:init # push existing codebase to a temporary branch named 'init' aws codecommit create-branch --repository-name CodecommitDevopsModelStack-MyApp1 --branch-name master --commit-id `git rev-parse master` # create new branch 'master' aws codecommit update-default-branch --repository-name CodecommitDevopsModelStack-MyApp1 --default-branch-name master # set branch 'master' as main branch of repository aws codecommit delete-branch --repository-name CodecommitDevopsModelStack-MyApp1 --branch-name init # clean up 'init' branch Agile development practices For this use case, you act as the collaborator of the repository implementing a new feature for aws-toolkit-jetbrains, then follow the development process to submit your code changes to the main branch. Enter the following code from the command line: export AWS_DEFAULT_PROFILE=codecommit-repo1-collaborator # assume collaborator role of repository # add/modify/delete source files for your new feature git commit -m 'This is my new feature.' -a git push codecommit HEAD:refs/heads/features/my-feature # push code to new branch with prefix /features/ aws codecommit create-pull-request --title 'My feature "Short Description".' --description 'Detail description of feature request' --targets repositoryName=CodecommitDevopsModelStack-MyApp1,sourceReference=features/my-feature,destinationReference=master # create pull request for new feature The preceding code submits the changes of the new feature to a branch with the prefix features/ and creates a pull request to merge the change into the main branch. On the CodeCommit console, you can see that a pull request called My feature "Short Description". created by the development collaborator has passed the sanity checking build of the pull request and gets an approval voting (it takes about 15 minutes to complete the checking build in this project). The owner of the repository also needs to review the pull request with one approval at least, then they can merge the repository to the main branch. The pull request on the CodeCommit console supports several code review features, such as change comparison, in-line comments, and code discussions. For more information, see Using AWS CodeCommit Pull Requests to request code reviews and discuss code. The following screenshot shows the review tool on the CodeCommit console, on the Changes tab. The following screenshot shows the approval details of the pull request, on the Approvals tab. When browsing the continuous integration deployment project after merging the pull request, you can see that a new continuous integration build has been triggered by the event of merging the pull request to the main branch. Cleaning up When you’re finished exploring this use case and discovering the deployed resources, the last step is to clean up your account. The following code deletes all the resources you created: npm run cleanup Summary This post discussed agile development practices based on CodeCommit, including implementation mechanisms and practice processes, and demonstrated how to collaborate in development under those processes. AWS powers the code that manages the code repository itself and the DevOps processes built around it in the example application. You can use the IaC capability of AWS and apply those practices in your organization to build compliant and secure R&D processes. View the full article