Defining roles and environments for multiple projects in Octopus Deploy

Question

We have completed evaluation of Octopus Deploy and are very pleased with our experience with a single project. Now we are extending use of Octopus Deploy to multiple projects, and this step brings a new dimension in our Octopus experience. So we have to verify the following assertions:

1. While it would be great to have only one instance of each environment (e.g. DEV, STAGE, PROD), a single environment puts a simultaneous release constraint: a release of the given project is deployed to all machines sharing the same role, so if our production environment consists of multiple machines, but we some of them must run different release version, then we can't have just Prod environment, we need to split it in several groups, e.g. PROD_OSLO and PROD_BERGEN so we can release in production new version only in Oslo.

2. Machine roles are shared across all projects, so if a machine has a role web-server in STAGE environment, then web applications for any release of any project will be deployed on this machine. This means that if different projects should use different machines for their STAGE environment, then this can be achieved either by creating different roles (proj1-web-server and proj2-web-server) or by splitting STAGE environment in two (STAGE_PROJ1 and STAGE_PROJ2). I wonder if one of these alternatives has any advantages.

If I overlooked or misunderstood something and the above conclusions are incorrect, please elaborate.

Answer 1

I implemented the deploy system at my company with Octopus and most of your concerns are shared with us.

With respect to the first point, we do exactly that. We have defined a CI, QA, Pre-Production and created three separate production deployments: Production Alpha, Production Beta and Full Production. Alpha and beta contain distinct subsets of full production.

When it comes to segregating projects to different physical servers, we implemented multiple roles. We've moved away from tagging machines as being "IIS" or "SQL Server", as it sounds like you have. Our roles are more granular and describe specific functionality that the machine provides.

For example, one of our database servers may be tagged "DB-Sales-Reports" and another could be tagged "DB-Sales-Engine". Functionally, this is identical to what you propose but we impose some semantic meaning on what a tag means.

Ideally, what I would like to see is support for allowing a deploy step to target a machine that fulfills "all of the M roles the deploy step targets" I have it tagged with, rather than the current behavior of "any of the M roles the deploy step targets"