Today I released another Octopus Deploy update, mostly containing small bug fixes following the 1.1 release. However, this release also included one new small feature - the ability to control variable viewing/editing permissions at an environment level.
For example, in the screenshot below I’ve denied variable viewing/editing permission for the Columbia project’s Production environment:
Now when someone tries to view or edit the variables for that project, they’ll find that they won’t be able to see the production values:
When editing, the “Production” environment won’t be available in the environments drop down, and they won’t be able to make changes to variables already in the Production environment.
Typically, you would set this up with one group (perhaps “devops”) that are allowed to view/edit production variables, and deny it to anyone else.
Hopefully this feature makes it easier to manage production settings and passwords in Octopus without making them visible to the whole organization.
Related posts
Certificates Feature
Certificates can be uploaded in PFX, PEM, or DER formats, and may include private-keys. They can be scoped to Environments and\or Tenants.
Deploying to no targets
As part of Octopus Deploy 3.8.7 we released a new feature related to Elastic and Transient Environments that we thought warranted a call out.
Octopus Deploy 3.7 - Effortless step templates
The new release of Octopus Deploy steps it up a notch by improving the UI for adding a step template, providing direct access to community step templates from a project's deployment process and improving the management of step templates in the library.
