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:
- 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.
We need this desperately. 3 Votes from me.
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
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.
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.