Now that we have technologies such as containers, it is possible to complete even the most complex deployments in seconds or minutes.
We can have a "deploy" button that allows us to safely promote changes to our code and our environments into production through our deployment pipeline.
Staging server idea - production server taken out of rotation and tested by the QA team, this ensures it matches exactly the production environment.
So far we can ensure that we are doing fast and frequent production deployments throughout feature development, with the goal of reducing the risk of errors. The remaining risk is a release risk, which is whether the features we put into production achieve the desired business outcomes.
Two or more environments that we deploy into, but only one is receiving live customer traffic. Release is performed by moving traffic to this environment. Example patterns: blue-green, canary, cluster immune.
We modify the application to selectively release and expose specific functionality by change of configuration: dark launching - feature flags that expose it to our internal employees and a fraction of users. We can also invisibly test our functions with live traffic before exposing and fixing what is needed to be fixed.
Two production environments, only one serving customers. We deploy to inactive where we perform tests and then switch the load balancer. Rollback is as easy as switching back.
Two versions running can cause issues with the database, especially when we have schema changes. To mitigate this we can use the following approaches: