I’m debating my current environment strategy in Octopus and would like some guidance. Currently, some of my projects are deployed to environments that are completely separate from others. For example, I have App1Dev and App1Production environments. I also have App2Dev and App2Production environments. The App1 environments might live on AWS, while the App2 environments might be in Azure.
I’m wondering if this is the right approach or if I should have logical environments instead. In that scenario, I’d have a Dev environment and a Production environment. I’d then need to have app-specific roles assigned to the machines though, such as app1-webserver and app2-dbserver.
The major problem with the physical environments that I see is that I end up with lots of environments on my dashboard that aren’t applicable to many of my projects.
Thanks for any guidance.
I’d recommend the logical environments setup. Where I am at we have about (checking now…) 80 projects in Octopus Deploy with Development, QA, and Production environments. Each of the servers have separate roles as you describe.
It works out very well because specifying the roles that the process steps are applied to combine with the environment being deployed to gets the one (or more) specific servers you want. THen you only have the logical environments and its easier to see that each application is in their respective Dev|Test|Prod environment.
Here’s the beginning in a series of articles on how one company does it very well. They are a consulting firm that is using Octopus Deploy for about 100 clients so its on the larger side but it explains the Logical environment setup pretty well.
Thanks for the link, I’ll look it over. My only concern with logical is that we may very well have multiple production environments that we want to deploy to. For dev and QA, logical makes sense, but for production we may want to keep things physical. For example we have only one place per project we would deploy dev and test to, but we may have east-coast and west-coast production environments that are deployed to at different times.
The East/West coast environments sounds like a good use for different environments. So you could have the Dev,Test,Production(East),Production(West) and all the projects goto their assigned servers via the roles.
Now on the East/West coast being deployed to at different times. Is that for a canary scenario? Deploy to east production environment smoke test and if everything is fine deploy to west coast? If so you could do something like described in the Canary deployment pattern in the Octopus Deploy docs.
I hit accidently. Here’s the link to the Canary deployments pattern in the Octopus docs.
Hi Brian and David,
Just to weigh in on this. We recommend setting up whatever is best for you to manage. Which may in the end be a combination of both.
Previously, pre-2.6 you would have to setup environments in ways that you want to deploy, as you could not deploy to more than one environment at a time.
Now with Lifecycles you can deploy to more than one at once, so if it’s easier to manage have a combination like David suggested with two production environments that are also based on physical.
There is no real ‘correct’ way, but it also doesn’t make sense to make something harder to manage than it has to be!
Vanessa
Since I don’t have multiple production environments per-app right now, I went with the logical environment option. This simplifies the screens, naming conventions, etc, at the cost of assigning roles that are physical-environment specific.
My current setup gives me this:
19 projects
3 project groups
2 logical environments (dev and production)
6 physical environments (a physical dev and production environment per project group)
We’ll see how this works, but I don’t see it being an issue. The dashboard is clean and concise and the lifecycles make promotion quite easy. In the future, I may add a Production 2 or Production West, but for now I’m happy with how things turned out.