Environments per project
The problem is, when you have multiple projects, is not very common that they share the same environments.
"Production" for "Project A" means a very different thing than "Production" for "Project B". Different machines or group of machines in case of a web-farm, for example (Deployment Targets).
Currently, the only way that this could be solved, is by creating custom environments per-project (ProjectAProduction, ProjectBProduction), as discussed in the support site (http://help.octopusdeploy.com/discussions/questions/10999-environments-per-project)
But this is more a workaround than an actual solution. The home page Dashboard gets really messy, because you can't filter environments for certain projects.
I think that configuring environments per project could be something worth for you guys to analyze.
Adrian
shared this idea
5 comments
-
Maurus
commented
The "Spaces" concept sounds interesting. Any plan when it will be released?
-
We have some changes in the works that may fit your requirements.
The new concept called Spaces (https://github.com/OctopusDeploy/Specs/blob/master/Spaces/index.md) will allow users to partition their projects. Those that share the same actual environments (which is very common, think about things like micro services or interdependent applications) can be organised together. At the same time other projects which may still have something called a "Production" environment, may in the real world be actually completely different environments.While this feature is largely target towards providing ways to help organize how large teams use Octopus, I could see this approach as providing a potential way to help segment your projects if this is a concern for you.
-
Stewart
commented
I'd like this solved as well. Rather than creating more environments the work around we are investigating is to create more target roles. So we would have a ProjectAWebServer, ProjectBWebserver, ProjectADatabaseServer and ProjectBDatabaseServer. This way we can keep the dashboard uncluttered and most of our projects are similar so would have the same set of environments.
If you could limit the scope of a deployment target to a particular project then it would meet our needs and would possibly work for the issue raised above. -
Chris
commented
I agree with the general problem here. It's easiest to derive the problem statement as 'the dashboard becomes invariably messy when you have multiple projects". Unless there's something I'm missing.
From my point of view, I have 1 existing project, ProjectA. I have environments Production, Staging and Testing. I view the dashboard and my projects are listed vertically and my environments are listed horizontally, all nicely contained in one page. Everything's cool.
I now want to add a new project, ProjectB. I add each of my 3 x new machines (Prod, Staging, Test) as a target to existing environments Production, Staging and Testing, because I feel like that's what they are; my ProjectB Prod server is a Production class server, it just belongs to a different project. I view my dashboard and I still have a simple view of 3 columns - Prod, Stage, Test.
I now have a problem targeting machines for my deployments. To configure deployment steps for ProjectB, I can: target machines by role and by environment, but not by project. So I can't proceed this way, I need more flexibility.
I revisit my environment configuration and decide to break my environments into something that is no longer atomic, i.e. [Production - ProjectA], [Staging - ProjectA], [Testing - ProjectA]. And the same for ProjectB, so I now have 6 environments.
I revisit my deployment steps and everything's cool, I can target the machines I need to.
I revisit my dashboard and it's clunky. Instead of 3 simple columns for Prod, Stage and Test I now have 6, a product of jamming two things into one.
I feel the problem here is that there's no way to represent a 'class' of server on the dashboard, so you can really limit it to a single traffic-light single-page view. You need to keep the environment definition, so my suggestion would be to perhaps consider creating a new entity 'Class' or similar. So you don't change existing environments, other than assigning them to a class, typically Production, Staging, Test or whatever. Then on your dashboard your traffic lights on your horizontal axis are limited to a single page's content, managers are happy, developers are happy and you don't have to change much else.
Food for thought. Like I said, unless I'm missing something.
Chris
-
Anonymous
commented
Isn't that what machine roles are for?
