Scenario
Your application is deployed to multiple geographic regions (or multiple Data Centers) to provide for your end-customer’s performance (think latency) or legal requirements (like data sovereignty).
Strict solution using environments
You can use Environments to represent each region or data center. In the example below we have defined a Dev and Test Environment as per normal, and then configured two “production” Environments, one for each region we want to deploy into.
By using this pattern you can:
- Use lifecycles to define a strict process for promotion of releases between your regions. Lifecycles can be used to design both simple and complex promotion processes.
- For example, you may want to test releases in Australia before rolling them out to the USA, and then to Europe.
- In another example, you may want to test releases in Australia before rolling them out simultaneously to all other regions.
- Scope region-specific variables to the region-specific Environments.
- Quickly see which releases are deployed to which regions on the main dashboard.
- Quickly promote releases through your regions using the Project Overview.
- Use Scheduled Deployments to plan deployments for times of low usage.
Environments and Lifecycles are a really good solution if you want to enforce a particular order of deployments through your regions.
Rolling solution
Cloud Regions enable you to configure rolling deployments across your regions or data centers. In this case you can scope variables to the Cloud Regions and deploy to all regions at once, but you cannot control the order in which the rolling deployment executes.
By using this pattern you can:
- Scope region-specific variables to the Cloud Region targets.
- Conveniently deploy to all regions at the same time.
If you don’t mind which order your regions are deployed, or you always upgrade all regions at the same time, Cloud Regions are probably the right fit for you.
Tenanted solution
Alternatively you could create Tenants to represent each region or data center. By doing so you can:
-
Use variable templates to prompt you for the variables required for each region (like the storage account details for that region) and when you introduce a new region Octopus will prompt you for the missing variables:
-
Provide logos for your regions to make them easier to distinguish:
-
Quickly see the progress of deploying the latest release to your entire production environment on the main dashboard:
-
Quickly see which releases have been deployed to which regions using the Dashboard and Project Overview:
-
Quickly promote releases to your production regions, in a particular sequence, or simultaneously:
-
Use Scheduled Deployments to plan deployments for times of low usage:
You do give up the advantage of enforcing the order in which you deploy your application to your regions, but you gain the flexibility to promote to your regions in different order depending on the circumstances.
Tenants offer a balanced approach to modeling multi-region deployments, offering a measure of control and flexibility.
Conclusion
Environments, Tenants and Cloud Regions can be used to model multi-region deployments in Octopus, but each different choice is optimized to a particular style of situation. Choose the one that suits your needs best!
Learn more
Help us continuously improve
Please let us know if you have any feedback about this page.
Page updated on Sunday, January 1, 2023