Staging Environments
Codesphere’s flexible workspace setup makes updating your services super easy and reduces the risk of production failures significantly if set up properly. In this document we will explain how you can use Codesphere to set up a staging environment and test updates via preview deployments.
A staging environment is basically a copy of your production environment. This environment has its own server with storage, computing power, and a dedicated way of accessing it, usually via an internal testing URL.
The major advantage of a dedicated staging environment is that any updates to your application can be (thoroughly) tested without interfering with your live system. This by itself makes outages and failures after updates less likely. With Codesphere setting up a Staging Environment is really easy.
With our Staging Environments you can even do more than just test updates before deploying them to production. The whole process of deploying becomes a matter of one single click and you can switch back and forth just as easily. This is called preview deployments.
Navigate to your Codesphere Team and click New Workspace. Assuming your production workspace is already set up, all you need to do is select the Github repository and branch containing your code, provide a name (i.e. Staging) select a plan with appropriate computing and disk capacity and click start coding.
This will create another workspace containing your application. Now repeat all the steps you would do in production to deploy your application, like installing packages and dependencies, building and running the app. If you need to connect an external database we recommend creating and connecting a separate copy of it as well, in some cases a separate partition of an existing DB will also work.
Once completed you should have a running copy of your app that you can access via the internal Codesphere URL or the open deployment icon.
Now that we have set up the workspaces let’s go through the updating process. First make updates to your code or data like you would normally do, either in Codesphere directly (in the staging workspace!) or make changes locally and commit them to your GitHub branch.
Once the changes are committed to your repository, open the staging workspace we created earlier, click the + icon to open a terminal and type
git pull. You can perform any of the usual git commands here as well (i.e. switching remote branches, rolling back etc.). If your repository is private you will need to use a personal access token to authenticate (see GitHub Documentation if you need to set one up first).
Make sure your application is running with the latest version of the code (i.e. running the build command or CI stage again) and open the Codesphere URL of this workspace. Test your changes as thoroughly as needed. Once you are confident that everything works as expected you can deploy the changes to production.
Updating your production URL to use the latest version of the code you just tested in the Staging Environment can be done with a few clicks.
- 1.Navigate to the Domains tab
- 2.Click "Edit"
- 3.Switch the workspace currently running your production environment with the staging workspace
- 4.Click "Update"
Now your users will be instantly directed to the new application version.
What’s unique about this setup is that should you realize something is going wrong afterwards you can switch back to the old version just as easily by connecting the other workspace again. This minimizes the risk of production downtime significantly.
Last modified 1mo ago