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.
I hear ya Erik. Utilize your variable snapshots within the release to lay them back down or retrieve the old one but this sounds like the way we always have done it.
Sensitive variables. I have had to re-deploy a previous release with the old variable value un-encrypted then jump on the box to get the plain text value then run my encryption again.
Variables in my opinion are what make Octopus truly great. I just went from 2018.5.1 to 2019.10 LTS. All that time and not much change in the variables was made. I think what Adam is asking for is AWESOME. Take some time and improve your core functionality. Variables needs an overhaul and leverage some of those features from within the variables screen and not outside of it with audits, or snapshots.
That will be grate.
I would also add version for a specific target/roll ..
We need this desperately too. 10 votes from our team as well.
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.