4 votesBlair Paine shared this idea ·
Would love to see this. We need to execute steps under different accounts in order to take certain actions. It's less secure to give one account rights to everything needed.
Our business has a requirement to have all PowerShell scripts signed. This policy is forced by security software installed on deployment targets. Unfortunately without this capability we can no longer use Octopus Deploy as an enterprise application.
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.
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.
Recreating a release also puts the list out of order. Releases may need to be recreated because of the snapshots feature.
Allow the any page listing the releases or release drop downs to be sorted by the release version number rather than the assembled date. If simple enough, you could also allow releases to be sorted by other properties.
Our problem/issue is posted here:
I agree with this. It shouldn't be difficult to implement, it's just an extra field and can use the same description fields as other screens.
Rather than hard coding in some text I may just provide a link to documentation explaining that step i.e. in Confluence.
Thanks everyone who voted on this. We’ve spent a lot of time thinking about how best to version control Octopus configuration, and came to an approach that is a little different to what was imagined in this blog post. I just published an RFC post with our plans – I’d really appreciate if you could take a look and leave a comment!
Scripts, configuration, variables, every input should be able to be stored in source control and fully audited i.e. GIT. We're looking to integrate with etcd or consol to obtain key/value pairs of variable information from JSON/YAML configs in GIT and share across all of our pipeline via the API. If anyone changes a configuration we'll know when it was changed and who changed it and for what reason.
I don't want my variables and configuration data for an entire pipeline tied to just Octopus. Octopus is a key part of our delivery pipeline but I don't believe it should own the inputs to make it work.
Voted up after posting here: