The code used to define an infrastructure doesn't have the traditional "feedback loop" that you've been accustomed to while working on other projects.
Usually, when you write some code, the feedback loop is very tight. You write code, then run it by clicking on a "Build and Run" button somewhere or by refreshing a webpage.
The code that will define your infrastructure cannot be tested this way. To ensure that your infrastructure works the way it needs to work, you need to create real resources in real environments.
Moreover, the code that define your infrastructure cannot be run with some random configuration. To ensure that your code will work on live environments, you will need to run it with similar configuration.
Adding to these difficulties, while we often write code alone, creating products typically takes a whole group of people to work together.
As a result, you and your teammates need to be able to create fully-configured sandboxed environments on demand.
That's why sandboxes have been created. Sandboxes in Scaffold are local environments that inherit default configuration values from live one while creating new Terraform state.
Suppose that one of your teammate wants to contribute to the infrastructure code used to deploy your React application.
We recommend you to treat your infrastructure code the same way you will treat any software code and to use a VCS to store it.
As a result, the first thing needed to do is to clone the repository containing your infrastructure code:
$ git clone [email protected]:myorganization/my-infrastructure-code.gitOnce done, your teammate will run the scaffold init command to configure their first sandbox:
$ scaffold init
No sandboxes found. Choose an environment to create a sandbox from.
? Environment to create a sandbox from: (Use arrow keys)
❯ dev
prod
If you remember correctly from the previous parts, the infrastructure for your React app has two distinct environments: dev and prod.
The init command is only used to configure a sandbox when all environments are unconfigured and no sandboxes exist.
If you want to create another sandbox, you need to run the sandbox:create command:
$ scaffold sandbox:create prod
Configuring a sandbox for prod environment:
...
The way you work with sandboxes is identical to the way you work with environments. The sole difference is that all the commands need to have a --sandbox flag:
$ scaffold apply dev --sandbox
$ scaffold plan dev --sandbox
$ scaffold destroy dev --sandbox
Now that you have created a sandbox for your dev and prod environment, you can run the sandbox:list command to display them:
$ scaffold sandbox:list
dev
prod
Configuring a sandbox means configuring an AWS account and creating a Terraform state to work on an exact replica of your live infrastructure without risking of breaking anything.
The way you will deploy these modifications in your live infrastructure may vary depending on your team size.
If you are in a small team, the most easiest way of deploying modifications may be to have one people with access to live environments "pulling" modfications and running the scaffold apply command directly.
If you want to let one of your teammates update live infrastructure directly, he will need to run the env:configure command and fill the required environment variables:
$ scaffold env:configure prod
Configuring prod:
...
The automated way uses the same paradigms that you've been accustomed to while working with software code, namely "Continuous Integration" and "Continuous Deployment".
You and your teammates will push their modifications in a central repository that will run the plan and apply command for you.
The way to do this will vary depending on the tools used, but, in a nutshell, you will certainly run the plan command before running scaffold apply with the Terraform "-auto-approve" flag.