Staging environments

# Use cases

• Feature development: Build a new version while still being able to fix bugs in the running version without uploading all the new feature code.
• Purpose separation: The backend team can break things while the frontend team can still work uninterrupted.
• Continuous integration: Code needs to be tested and monitored before being deployed live.

The use of multiple environments is optional. For smaller websites it might be overkill, for less experienced developers, implications can be a bit mind bending.

Multi-staging environments are part of professional software development processes. They allow for testing and debugging at different stages of the development cycle before releasing a product. A classical multi-stage setup consists of a production, staging and maybe a development environment.

# Developer client workflow example

The client requests a new feature for the website. This is first developed in a local development environment. An additional temporary environment at fortrabbit can be used to collect feedback. Once the new feature has been signed off, it can be merged into production.

# Software development team workflow example

The production environment is the stable live environment. The development environment contains the latest bleeding edge changes. The staging environment is used for quality assurance before go-live.

# Common multi-staging set ups

• staging + production: "Staging" is where you do your development. "Production" runs the live code. From time to time you migrate all the (stable) changes from staging into production.
• temporary + production: Same as above, it's more of a one-time-developed project. Maybe once a year there is an upgrade, a re-brush or alike. For this you utilize an additional, temporary environment, in which you do the upgrades.
• testing + staging + production: Code changes are made to the testing environment. Once they seem stable, they get published to the staging where they are monitored and further tested. Finally they get published to production.

# Multi-staging and local development

Most likely you are developing with a local PHP development environment on your machine. So your laptop is already a of kind of staging while the actual part at fortrabbit is usually production.

# Multi-staging on fortrabbit

All you need to utilize multi-staging on fortrabbit is an app with multiple environments. environments are made to support multi staging setups.

# Multi-staging with framework or CMS

Most modern CMS and frameworks anticipate and support multi-staging workflows. The concepts are similar, implementation differs in detail. In most cases, the stage is defined by an ENV var.

# Multi-staging and Git

Multi-staging is mostly associated with Git deployment. Git supports multiple, named branches of your code. On fortrabbit, each branch can be mapped to an environment.

# Caveat runtime data

The biggest problem introduced with multi stage environments is runtime data: databases, user uploads and anything else that is being generated by the App. Sure you need to separate those as well. If all environments require the latest data to run properly or for testing, you need to figure out a way to synchronize the production data downwards, to the other environments. These problems are highly individual and cannot be solved in a general manner. We are experienced with these kind of things and we love to help you.