I suggest you...

Allow Variables to be Version Controlled

Imagine you have a connection string variable and you want to update it. You would update the variable and redeploy, however if you made a mistake (edited the wrong variable or the new connection string was not live yet) then you cannot roll back. This is even more of a problem if the variable is sensitive as you can't copy it beforehand.

I would like to be able to version octopus variables, this would include:
- Who
- When
- When deployed
- The ability to roll back/forward.

At the moment we have to source control much of this type work, this obviously negates much of the valuable octopus functionality around environment handling/sensitive variables.

84 votes
Sign in
Password icon
Signed in as (Sign out)
You have left! (?) (thinking…)
Adam Griffiths shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Password icon
Signed in as (Sign out)
  • David commented  ·   ·  Flag as inappropriate

    It would be great if one could view the variable snapshot of a *deployment*, not just a release. Sometimes people will update a release snapshot when they should create a new release (I know, the best solution would be for them to stop doing that), and in those cases it is very difficult to find out what changed

  • Erik commented  ·   ·  Flag as inappropriate

    Actually, you can in fact roll back. Octopus keeps a snapshot of the variables at the time the release was created, and thus if you re-deploy the previous version, it redeploys with the old variables. So I don't think your use case is all that great, although from an archival perspective it sort of makes sense. Additionally, you can view the audit information in the audit logs.

  • Anonymous commented  ·   ·  Flag as inappropriate

    I think the one key point here is that it would be good to see who has modified a variable and what changes were made to that variable so we can understand whether it was an impacting change.

Feedback and Knowledge Base