Page updated Jan 16, 2024

Sandbox environments

Now you have two independent environments (main & dev) in the cloud and have corresponding git branches with your amplify backend infrastructure code on Git. Suppose a team member wants to work on the same Amplify project, add some features to it and then push changes to the dev environment to test some changes. They would perform the following steps:

$ git clone <git-repo> $ cd <project-dir> $ git checkout -b mysandbox $ amplify env add ? Do you want to use an existing environment? No ? Enter a name for the environment mysandbox // Rest of init steps // Add/update any backend configurations using amplify add/update <category> $ amplify push $ git push -u origin mysandbox
1$ git clone <git-repo>
2$ cd <project-dir>
3$ git checkout -b mysandbox
4$ amplify env add
5? Do you want to use an existing environment? No
6? Enter a name for the environment mysandbox
7// Rest of init steps
8// Add/update any backend configurations using amplify add/update <category>
9$ amplify push
10$ git push -u origin mysandbox

Next, suppose the team-member wants to move these changes to dev and main environments/branches:

$ git checkout dev $ amplify env checkout dev $ git merge mysandbox $ amplify push $ git push -u origin dev
1$ git checkout dev
2$ amplify env checkout dev
3$ git merge mysandbox
4$ amplify push
5$ git push -u origin dev

After testing that everything works fine in the dev stage, you could now merge dev to the main git branch:

$ git checkout main $ amplify env checkout main $ git merge dev $ amplify push $ git push -u origin main
1$ git checkout main
2$ amplify env checkout main
3$ git merge dev
4$ amplify push
5$ git push -u origin main

In this approach, you can consider the git branches (dev & main) as the source of truth and all the team members should work off the branches and keep their workspaces in sync.