Allow editing a release until it is promoted

[OctopusSchaff]

We have the following flow:

1. Developers create a build and it is auto deploys to the Dev environment via Octopus
2. Once it is ready it goes to the Testing environment
3. Once it is ready it goes to the Prod environment.

While in the Dev environment, the developers like to be able to update the release with changes to the variables. This allows for minor tweaks like URL changes and such to have quick feedback loops.

But once the release goes to Testing or Prod, we need to not allow the release to have its variables updated by developers.

I tried making a role (I called it Release Editor) that had the ReleaseEdit permission on it. I applied this role to my Developers team and scoped it to the Dev environment. But it does not actually stop a developer from updating the variables once the release goes to Testing.

Is there a way to give developers the ability to Update Variables until a release is deployed to Testing for the first time?

Basically I want Octopus to check to see if the Release has a Deployment in the Testing or Prod environments and, if it does, block the “Update Variables” action for the Developers team.

[doug.pipe]

Hi @OctopusSchaff,

Thank you for your questions.

When it comes to editing variables in they way you have described, you could in theory have a custom user role that can either modify environment scoped variables and/or also modify any un-scoped variables within a project to a scoped environment within a team. With the ‘Update Variables’ feature it is an all or nothing permission as part release and not tied to an environment.

Assuming your developers only work in your Development environment, you could look to create a custom role for your Developers so they can only perform certain actions scoped to a specific environment (including scoped variables).

However there are some caveats here, my above comments are not taking into consideration what your current permissions model are for your teams as I am unclear of what this looks like within your set up.

If your Development team are assigned to other user roles that allow these actions within other environments, for example they have the ‘Project Deployer’ role (un-scoped) attached to a team where the permissions to edit variables are included, Octopus will allow users to modify variables within all environments.

Octopus is inclusive when it comes to permissions and not exclusive, so if a role is attached to a team where an action is allowed, Octopus will include this within the permissions for the role/team where it has been applied (which may be what you are seeing after creating your custom role).

User Roles can be quite granular but also can become complex quickly so you need to consider the right approach for you and your organization.

However saying this, my initial thoughts for an idea to try would be looking to create custom roles per environment and manage this at a variable level.

So for example a concept to split this out may work for you (Test and Prod may have the same permissions, which could be 1 role):

• Developer Role - Dev
• Developer Role - Test
• Developer Role - Prod

You can add these roles to your development team and scope the roles to a specific environment (some roles may be duplicated).

However, the downside is that users can only modify variables they are scoped to so the solution may not fit your needs if they need to modify variables for other environments as part of your deployment process.

This means that the developers can only update the variables they are allowed to modify using the ‘Update Variables’ feature.

I hope this helps

Regards
Doug

[OctopusSchaff]

Thank you for the response. I do already limit developers to only being able to edit variables that are in Dev.

However, I am hesitant to call that good enough. If a developer can run “Update Variables” for a release that is Prod, they could cause damage, even if they can’t change the variables. It is possible that Prod variables could have been changed for the next release in the pipeline. Changes that they are not aware of. When they run “Update Variables” it would apply those changes, even if they did not make them. Any subsequent re-deploys or rollbacks using the updated release would use the incorrect variables.

While not a common set of conditions, it is likely enough that my developers will have to just deal with not having access to this feature. They will complain, but I will let them know that Octopus cannot limit the access for this feature and that they will just have to do a new build for each variable change they want to check.

Thank you for looking into this for me!

[doug.pipe]

Hi @OctopusSchaff,

Thank you for your feedback.

Unfortunately it feels like you may need to restrict this if you feel it is necessary to avoid any unexpected changes.

Personally, I feel it is a good approach to avoid updating variables after a release where possible to keep the release snapshot as a source of truth. This way you can trust your deployments will behave in the same way in the event of a re-deploy or rollback.

Thanks
Doug