We have dozens of applications that we deploy across only a handful of servers. In short, we have 4 logical roles (Internal Web, External Web, Web Services, and Batch) and 3 logical environments (Dev, QA, Prod). The attached image shows this, and the targets/servers in each environment that have those roles. RARELY does a project need to be deployed to more than one server per role per environment. In other words, Project A will only ever be deployed to one of Internal web servers per environment, or one batch server per environment.
The problem is that, while a single Project will always follow the same deployment lifecycle, that’s not necessarily true for another Project. For example Project A might be deployed to S422 (Internal web) in Dev and S411 (internal web) in Prod, and it will always do that. But Project B might also be deployed to S422 in dev, but S942 in Prod. Worse, Project C might be deployed to S435 in Dev and S411 in Prod.
We have been getting by with 5 Environments (DV-1, DV-2, QA-1, QA-2, and PD) and 3 Lifecycles. This has limited us to certain projects which can follow the same deployment patterns. But we have recently acquired additional servers, with more on the way. Where an application/project lives in which environment largely depends on load and timing. The more servers we get, the more convoluted either my roles get, or the lifecycles get.
Ideally, what I’d like to do is specify what servers/targets each step can be deployed to. Obviously I can limit it to role and environment. But I need to be able to say “this web app will only be deployed to Target A in Dev and Target G in Prod.” Perusing the documentation a “canary” deployment is the closest I can see. But, to carry that out, I have to customize every release to every environment. I’d rather just specify the servers once and it limits the deployment to those servers every time.
I just want my four roles and 3 environments defined, and limit the deployment to one of the servers in each environment. Is this possible? (please say yes.)
If I understand correctly, you want to say “When deploying a particular step to a particular environment, target a particular server/s”. The thing is, that is exactly what roles are for
A machine can have multiple roles. So, for example, S232 could have both the ‘InternalWeb’ role and the ‘AcmeApp’ role. We don’t provide a way to restrict steps to machines, because again that is the role of … roles.
When creating a deployment you can restrict it to specific machines, but I don’t believe this is what you are looking for.
Why are you reluctant to use roles in your scenario?
Frankly, I didn’t think about making app-specific roles. I think of server roles as “functional use,” and we have our physical servers divided into internal web, external web, web broker/services, batch, and database. They can and do overlap (in dev, a server can be all 3 web roles, but not in prod). And I carried that logic over to Octopus Deploy. And it’s worked “ok” until now.
HSAT, it sounds like you are more loosely using roles. We have over 40 applications that we’d like to eventually make their way into Octopus Deploy. But for our discussion, let’s say I have 3 apps with these deployables (which would correspond to an Octopus Step deploying a Nuget package):
Project A: internal website, external website, web services, batch
Project B: internal website, batch
Project C: internal website, external website, web services, batch
and those deployables could go to any server. Are you saying that I would have roles like:
ProjectAInternal
ProjectAExternal
ProjectAWebSvc
ProjectABatch
ProjectBInternal
ProjectBBatch
ProjectCInternal
ProjectCExternal
ProjectCWebSvc
ProjectCBatch
Basically, a new role for each endpoint in each project’s? While I think I can see how this would work, it makes for a TON of roles. Most of our apps have at least an internal website and batch job – so there’s 80 roles right there. Another 10 or so have an external component and web services, so that’s another 20. So we’re looking at around 100 roles. That seems very cluttered. Is that normal – and is that the only way to do this?
Project-specific roles are not at all uncommon, nor are large numbers of roles.
If we ignore Octopus for a moment…
You have your servers, your environments, and your application-components. And you have a mapping between these (i.e. Application A is deployed to Server B in Environment C).
Now we want to represent that in Octopus. If roles didn’t exist, we would have to configure for every step the mapping between environments and servers. And obviously then if a server was added or removed, or an environment was added or removed, we would have to go and update every step in every project.
Roles are the abstraction that allows your deployment processes to remain independent of changes to your environments.
I hope that made some sense…
I actually think the naming scheme ProjectA-External is nice. It means you can look at a server on your Octopus Environments page, and see everything it does for each project.
Basically your roles will be as complicated as your mapping between components/environments/servers. If you can simplify that, great! If you can’t (for no doubt entirely valid reasons), then it is what it is
