My Repositories¶

Once you have access through the process above, you’ll find two main types of repositories in GitHub.com under the rackspace-infrastructure-automation organization, in addition to the reusable code mentioned above:

1. Shared Repository: These are repositories that are shared across all of your accounts in AWS. These are typically reusable Terraform modules that can be applied to more than one AWS account. These start with your customer number, mention the specific cloud provider, and contain a human readable ending. They are unique to you as a customer, and can’t be seen by other customers.

Unless you have managed services across multiple clouds with Rackspace, you will normally only have one ‘shared’ repository.

Example: 12345-aws-LargeCorp

1. Account Repository: These are repositories that map directly to an AWS account. They house Terraform files that are used to directly test and deploy infrastructure in that specific account. These start with your customer number, mention the specific cloud account, and contain a human readable ending. They map directly to the Aviator, Infrastructure as Code accounts we manage for you.

Examples: 12345-aws-9876541-Production1, 12345-aws-9876541-Test1, 12345-aws-9876541-Dev1

Branches, forks, and pull requests¶

Rackspace employs continuous integration and delivery (CI/CD) to deploy your infrastructure based on the master branch of your repository. Therefore, the master branch should always reflect a consistent, deployable, and current expected state of your infrastructure. The master branch is also protected from unreviewed changes, and should only be modified through a pull request process.

Other branches should be short-lived, and used to propose changes using a pull request into master. Branches from forks will not be built (tested or deployed), and we recommend you simply push to a branch inside the main repository. When the shared repository contains code or files needed by an account repository, Rackspace employs tags using the “GitHub release” mechanism.

Repository layout¶

Here is a graphical representation of what you can expect to find in your repository. Not all directories and files may be present in all types of repositories. Below, you’ll find an explanation of what each item is.

- README.md
- .circleci/config.yml
- .terraform-version
- docs
- layers/_main/main.tf
- modules/example/main.tf
- modules/terraform/iam_cicd.tf
- modules/terraform/outputs.tf

• README.md and docs/: All repositories are created with a default readme file and documentation directory. This is used for any documentation or reference material that you wish. Rackers working on your requests will be able to refer to this material as needed.
• .circleci/config.yml: This file configures the CI/CD system with specific workflow steps to execute, and a defines a container in which to run them. This file should not be modified except through coordination with Rackspace.
• .terraform-version: This file is used by our tooling and automation to call Terraform Version Manager (tfenv), which ensures only a specific, intended version of the Terraform CLI will be used when building and deploying your infrastructure.
• layers/: This directory will be present on Account Repositories, and contains different groupings of Terraform files that make up one ‘state’. When your infrastructure is deployed, only layers that contain changes will be tested and deployed. A more detailed explanation of this design can be found on the Terraform section of this guide.
• modules/: This directory will be present on your Shared Repository and contains Terraform modules intended to be reused.

Note that if you run Terraform locally, you may also see a .terraform directory. This contains configuration and data that should not be committed to the repository. This ensures our build process always fetches the latest providers, modules, and state configuration needed to build your environment.