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.

50 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Adam Griffiths shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    2 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      Submitting...
      • 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