AWS CodeCommit - duplicate test and production repos

Question

I am using AWS CodeCommit with CodePipeline. I have

• two totally separate AWS accounts, one for test and one for production,

• identical Code Pipelines setup in each account, each with a corresponding CodeCommit repo.

• a local code repo on my dev machine.

This allows me to push from the local repo to either the test or production AWS account, depending on what I'm doing.

I'm now in the process of setting up a second local development machine. This feels like a slightly daft question, but

• Which of my test or production AWS accounts should I regard as my 'repository of record'?
• What are other people doing in this regard?
• Is it considered bad practice to have two AWS CodeCommit repositories setup in this way?
• What is the best practice for totally separate AWS accounts which share the same codebase but have duplicated CodeCommit repos on the two AWS accounts?

Answer 1

Which of my test or production AWS accounts should I regard as my 'repository of record'?

None. If you doing software development in a team, a standard model is to have at least three environments:

• development
• test
• production

Depending on the size of the team or product, you may add another "staging" environment in between, or multiple production environments.

I am not an expert on AWS CodeCommit, hence I cannot tell you whether you need a third AWS account for this, or if you should use one existing account for two of the formentioned environments, or maybe for all three. But the idea should be to use one account with its Git repo for development, as single source of truth, and deploy to the test and production environments by some automated build and deployment process from there.

If those test and production environment really need Git repos on their own seems to be debatable - most Git workflows I know map the test and production releases to separate branches inside the existing repos, there is usually no need to set up three different repos for that.

Of course, with Git as a distributed VCS, there are also workflows possible without any central server, but AFAIK this is not the most popular way of working and may not be the right thing for you.