Environments

Environments in Nullstone are configured on your stacks. They allow you to launch multiple versions of your entire stack. For each environment, the primary configuration of your infrastructure remains the same. This includes things like the definitions of your applications and datastores as well as their connections. What you can change for each environment are the resource levels and parameters used to launch each application or datastore. Some examples of this are:

• how much CPU or RAM your application will use
• whether your database will perform automatic database backups

As you launch each application or datastore in each environment, you will be prompted to provide the environment specific settings.

Cloud Account

Each environment has its own configuration for cloud account, so you can provide a different account for each to isolate resources. Configuring a separate cloud account for each environment is best practice and advised, however, not required. If a mistake is made (such as an accidental destroy), separate accounts provides a natural barrier for the mistake to remain contained.

A typical set of environments might look like the following:

Promotion Pipeline

When defining the environments for your stack, you also decide their order/sequence. This is done in order for you to follow a pattern of promoting changes from lower environments all the way to production.

A dev environment provides a place for new changes to get promoted without worrying about breaking something important. Developers merge their changes to one central place; and it is the first step in verifying the quality of your application. It generally has very limited resources to keep costs down.

A staging environment allows development teams to get sets of changes ready for production. Developers can stage groups of changes that they intend to release to production. Promote these changes to production once your QA team has finished testing.

Once your changes reach the production environment, the odds of those changes having issues goes way down and your software release quality goes way up.

Nullstone recommends following this same approach for not only the code for your applications but also for the infrastructure. The additional environments make it easy to verify if infrastructure changes are going to work as intended. Test out your infrastructure changes in a dev environment before promoting them to prod.