NÃO CONSEGUIR ATIVA EM MEU APARELHO ASUS_X00LD, A DEPURAÇÃO ATIVADA E MESMO ASSIM DANDO ERRO ... COMPREI O APP PANDA QUE O MESMO TAMBEM NÃO ATIVA

I was just hoping to use this feature today when I found it doesn't exist :(

Would love to have "UAT 1", "UAT 2", etc... environment all scoped to "UAT" for variables and such.

This would be extremely useful for us also, since we now have a massive number of environments and don't want to have to start looking at tenants etc.

Environment groups with associated permissions - surely this is a must-have if OD is going to be an enterprise-class tool?

In our production environment we have tenenats that are hosted by the same hostingpartner.
Therefore It would be nice to group all our tenants for a specific hostingpartner in a subgroup to our "Production" environment.

Ditto. Before we moved to Octopus we called them "Server Classes" (which we used as "roles" also). But "Environment Class" or "Environment Group" works just fine. Whatever makes that interface easier to navigate.

Our environments screen is getting very ugly very quickly as we add more and more deployment targets. We currently have over 4000 potential deployment targets in our environment across multiple environments. Groups would allow better filtering on the environments page and in other places.

It would be fantastic if:
- We could filter on various attributes including tenant, role, domain, connectivity status etc

- On the tenants screens we can see which deployment targets have been assigned.

- You could apply tags to deployment targets which can then be used to filter much like tenant tag as suggested here - https://octopusdeploy.uservoice.com/forums/170787-general/suggestions/5782511-allow-tagging-environments-with-keywords

- More granular restrictions could be placed on which groups of deployment targets can be seen by certain teams/users.

Correct me if I'm wrong, but isn't this now possible using tenants? So instead of Project 1 having Environments Test-Proj1 and Prod-Proj1 and Project 2 having Environments Test-Proj2 and Prod-Proj2, you could now just have 2 environments Test and Prod and create tenants for the projects, wire them up to these environments and apply permissions there. You could then create tenants, just not add 'Prod' environments to them.

I still like the idea of Environment Groups for those not using tenants or in a transition phase, but I think the permission you're trying to achieve is doable using tenants.

Let groups be hierarchical and participate in scoping.
E.g. a variable scoped to a group called "uat" would apply to "uat1","uat2","uat3", etc.

It would be great to be able to group environments in a way that allows a "live" and "implementing" environment. For example, we often create new environments and build them in parallel to existing active environments. We may have an active Production environment and a Production environment being built but not completed/enabled/released yet. Both are considered "production", and I could have a different release deployed to each.

When deploying a release, it should be possible to select if I am to deploy to the implementing production or the live production. If it's live production then there may be additional checks or steps.

Collapsing groups would be amazing when you have hundreds of machines per environment and some servers with 80 Roles etc on them the Environments screen scrolls for days.
Even with the chrome extension you still have to scroll depending on how many roles the server has.

Please provide a way to group environments and scope variables to environment groups.

It would be nice to apply variables to environment groups like DEV/UAT or US/UK instead of having to add individual environments to each variable hoping that I don't forget one or add the wrong one. If instead DEV-UK and DEV-US could be added to a DEV group and DEV-UK and PROD-UK could be added to a UK group variable assignment could be made much safer and easier.

Collapsing groups on the Environments page and the Dashboard would be great.

Also, assigning permissions to a group, is invaluable. Then when servers are added to a group, the relevant permissions would be automatically inherited for that server, too (the same as for files in a folder).

+3 for environment groups. It would be good to have separate groups for Production and test environments. We also have several different types of test environments that also would benefit from separate groups.

When you have more than 20 environments with many machines in each the environment page in Octopus gets very crowded

Also it would be nice to have 'Environment Groups' in the sense of just a logical grouping of environments (perhaps all having the same owner/approver etc) also for organisation in the Dashboard etc

+1
I'm looking at the current permissions set for Octopus and can see how having this feature would greatly simplify the scope of access rights required to deploy across different environments.

This could help us greatly because we would be able to consolidate all our individual customer dev, uat and production environments into a "Dev" "Uat" and "Production" groups. Then with variables that we want to set appropriately depending on whether its a Dev, Uat or Production environment we would no longer need to duplicate those variables scoping them to particular environments all the time, we could just scope them at the environment group level..

+1
This would be an amazing feature. We have 7 QA environments with different configurations. It would be great to be able to group them under a "QA environment group", and deploy to all environments at once.

+1
We have 3 regions each for Dev, UAT and Prod making up 9 environments. It would be great if we could group them by Dev/UAT/Prod so we only had to trigger a single deploy...

+1
Env. groups to govern access would really make my life easier.

I'd be great if the Environment Groups would then become a permissionable unit, i.e. restrict permissions to an Environment Group instead of (or in addition to, perhaps) an Environment.