# Understanding the DevOps environments
<a name="understanding-the-devops-environments"></a>

To understand the branching strategies, you must understand the purpose and activities that occur in each environment. Establishing several environments helps you separate the development activities into stages, monitor those activities, and prevent the unintentional release of unapproved features. You can have one or more AWS accounts in each environment. 

Most organizations have several environments outlined for use. However, the number of environments can vary by organization and according to software development policies. This documentation series assumes that you have the following five, common environments that span your development pipeline, although they might be called by different names:
+ **Sandbox** – An environment where developers write code, make mistakes, and perform proof of concept work.
+ **Development** – An environment where developers integrate their code to confirm that it all works as a single, cohesive application.
+ **Testing** – An environment where QA teams or acceptance testing takes place. Teams often do performance or integration testing in this environment.
+ **Staging** – A preproduction environment where you validate that the code and infrastructure perform as expected under production-equivalent circumstances. This environment is configured to be as similar as possible to the production environment.
+ **Production** – An environment that handles traffic from your end users and customers.

This section describes each environment in detail. It also describes the build steps, deployment steps, and exit criteria for each environment so that you can proceed to the next. The following image shows these environments in sequence.

![\[Common DevOps environments in sequential order\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach/images/devops-environments.png)


**Topics**
+ [Sandbox environment](sandbox-environment.md)
+ [Development environment](development-environment.md)
+ [Testing environment](testing-environment.md)
+ [Staging environment](staging-environment.md)
+ [Production environment](production-environment.md)

# Sandbox environment
<a name="sandbox-environment"></a>

The *sandbox environment* is where developers write code, make mistakes, and perform proof of concept work. You can deploy to a sandbox environment from a local workstation or through a script on a local workstation.

## Access
<a name="access"></a>

Developers should have full access to the sandbox environment.

## Build steps
<a name="build-steps"></a>

Developers manually run the build on their local workstations when they are ready to deploy changes to the sandbox environment.

1. Use [git-secrets](https://github.com/awslabs/git-secrets) (GitHub) to scan for sensitive information

1. Lint the source code

1. Build and compile the source code, if applicable

1. Perform unit testing

1. Perform code coverage analysis

1. Perform static code analysis

1. Build infrastructure as code (IaC)

1. Perform IaC security analysis

1. Extract open source licenses

1. Publish build artifacts

## Deployment steps
<a name="deployment-steps"></a>

If you're using the Gitflow or Trunk models, the deployment steps automatically initiate when a `feature` branch is successfully built in the sandbox environment. If you're using the GitHub Flow model, then you manually perform the following deployment steps. The following are the deployment steps in the sandbox environment:

1. Download published artifacts

1. Perform database versioning

1. Perform IaC deployment

1. Perform integration testing

## Expectations before moving to the development environment
<a name="expectations-before-moving-to-the-development-environment"></a>
+ Successful build of the `feature` branch in the sandbox environment
+ A developer has manually deployed and tested the feature in the sandbox environment

# Development environment
<a name="development-environment"></a>

The *development environment* is where developers integrate their code together to ensure it all works as one cohesive application. In Gitflow, the development environment contains the latest features included by merge request and are ready for release. In GitHub Flow and Trunk strategies, the development environment is considered to be a testing environment, and the code base might be unstable and unsuitable for deployment to production.

## Access
<a name="access"></a>

Assign permissions according to the principle of least privilege. *Least privilege* is the security best practice of granting the minimum permissions required to perform a task. Developers should have less access to the development environment than they have to the sandbox environment.

## Build steps
<a name="build-steps"></a>

Creating a merge request to the `develop` branch (Gitflow) or the `main` branch (Trunk or GitHub Flow) automatically starts the build.

1. Use [git-secrets](https://github.com/awslabs/git-secrets) (GitHub) to scan for sensitive information

1. Lint the source code

1. Build and compile the source code, if applicable

1. Perform unit testing

1. Perform code coverage analysis

1. Perform static code analysis

1. Build IaC

1. Perform IaC security analysis

1. Extract open source licenses

## Deployment steps
<a name="deployment-steps"></a>

If you're using the Gitflow model, the deployment steps automatically initiate when a `develop` branch is successfully built in the development environment. If you're using the GitHub Flow model or Trunk model, then the deployment steps automatically initiate when a merge request is created against the `main` branch. The following are the deployment steps in the development environment:

1. Download the published artifacts from the build steps

1. Perform database versioning

1. Perform IaC deployment

1. Perform integration tests

## Expectations before moving to the testing environment
<a name="expectations-before-moving-to-the-testing-environment"></a>
+ Successful build and deployment of the `develop` branch (Gitflow) or the `main` branch (Trunk or GitHub Flow) in the development environment
+ Unit testing passes at 100%
+ Successful IaC build
+ Deployment artifacts were successfully created
+ A developer has performed a manual verification to confirm that the feature is functioning as expected

# Testing environment
<a name="testing-environment"></a>

Quality assurance (QA) personnel use the testing environment to validate features. They approve the changes after they finish testing. When they approve, the branch moves on to the next environment, staging. In Gitflow, this environment and others above it are only available for deployment from `release` branches. A `release` branch is based on a `develop` branch that contains the planned features.

## Access
<a name="access"></a>

Assign permissions according to the principle of least privilege. Developers should have less access to the testing environment than they have to the development environment. QA personnel require sufficient permissions to test the feature.

## Build steps
<a name="build-steps"></a>

The build process in this environment is only applicable for bugfixes when using the Gitflow strategy. Creating a merge request to the `bugfix` branch automatically starts the build.

1. Use [git-secrets](https://github.com/awslabs/git-secrets) (GitHub) to scan for sensitive information

1. Lint the source code

1. Build and compile the source code, if applicable

1. Perform unit testing

1. Perform code coverage analysis

1. Perform static code analysis

1. Build IaC

1. Perform IaC security analysis

1. Extract open source licenses

## Deployment steps
<a name="deployment-steps"></a>

Automatically initiate deployment of the `release` branch (Gitflow) or the `main` branch (Trunk or GitHub Flow) in the testing environment after deployment in the development environment. The following are the deployment steps in the testing environment:

1. Deploy the `release` branch (Gitflow) or `main` branch (Trunk or GitHub Flow) in the testing environment

1. Pause for manual approval by designated personnel

1. Download published artifacts

1. Perform database versioning

1. Perform IaC deployment

1. Perform integration tests

1. Perform performance tests

1. Quality assurance approval

## Expectations before moving to the staging environment
<a name="expectations-before-moving-to-the-staging-environment"></a>
+ The development and QA teams have performed sufficient testing to satisfy your organization's requirements.
+ The development team has resolved any discovered bugs through a `bugfix` branch.

# Staging environment
<a name="staging-environment"></a>

The *staging environment* is configured to be the same as the production environment. For example, the data setup should be similar in scope and size to production workloads. Use the staging environment to verify that code and infrastructure operate as expected. This environment is also the preferred choice for business use cases, such as previews or customer demonstrations.

## Access
<a name="access"></a>

Assign permissions according to the principle of least privilege. Developers should have the same access to the staging environment as they do the production environment.

## Build steps
<a name="build-steps"></a>

None. The same artifacts that were used in the testing environment are reused in the staging environment.

## Deployment steps
<a name="deployment-steps"></a>

Automatically initiate deployment of the `release` branch (Gitflow) or the `main` branch (Trunk or GitHub Flow) in the staging environment after approval and deployment in the testing environment. The following are the deployment steps in the staging environment:

1. Deploy the `release` branch (Gitflow) or `main` branch (Trunk or GitHub Flow) in the staging environment

1. Pause for manual approval by designated personnel

1. Download published artifacts

1. Perform database versioning

1. Perform IaC deployment

1. (Optional) Perform integration testing

1. (Optional) Perform load testing

1. Obtain approval from the required development, QA, product, or business approvers

## Expectations before moving to the production environment
<a name="expectations-before-moving-to-the-production-environment"></a>
+ A production-equivalent release has been deployed successfully to the staging environment
+ (Optional) Integration and load testing were successful

# Production environment
<a name="production-environment"></a>

The *production environment* supports the released product, handling real data by real clients. This is a protected environment that is assigned access by least privilege and elevated access should only be allowed through an audited exception process for a limited period of time.

## Access
<a name="access"></a>

In the production environment, developers should have limited, read-only access in the AWS Management Console. For example, developers should be able to access log data for day-to-day operations. All releases to production should be gated by an approval step prior to deployment.

## Build steps
<a name="build-steps"></a>

None. The same artifacts that were used in the testing and staging environments are reused in the production environment.

## Deployment steps
<a name="deployment-steps"></a>

Automatically initiate deployment of the `release` branch (Gitflow) or the `main` branch (Trunk or GitHub Flow) in the production environment after approval and deployment in the staging environment. The following are the deployment steps in the production environment:

1. Deploy the `release` branch (Gitflow) or `main` branch (Trunk or GitHub Flow) in the production environment

1. Pause for manual approval by designated personnel

1. Download published artifacts

1. Perform database versioning

1. Perform IaC deployment