Reputation: 227
I am trying to look for a solution where our developers want to deploy a different version of their build. My train of thought was to add an env variable to our cicd configs, and then in our cd playbook evaluate if that var is None, and if so override the version we normally get from the package or pom file.
This is turn will grab that XXX version from our helm and docker container registry allowing them to roll back without or redeploy an older version quickly and efficiently.
I see that Azdo provides environment variables, but I wanted something that would only set or store the env variable for the run from the pipelines and would not be persistant.
Upvotes: 0
Views: 753
Reputation: 114461
You can configure so-called queue time variables. The idea is that you set a default value, like latest, and check the for to change the value at queue time:
If a variable appears in the variables block of a YAML file, its value is fixed and can't be overridden at queue time. Best practice is to define your variables in a YAML file but there are times when this doesn't make sense. For example, you may want to define a secret variable and not have the variable exposed in your YAML. Or, you may need to manually set a variable value during the pipeline run.
You have two options for defining queue-time values. You can define a variable in the UI and select the option to Let users override this value when running this pipeline or you can use runtime parameters instead. If your variable is not a secret, the best practice is to use runtime parameters.
To set a variable at queue time, add a new variable within your pipeline and select the override option.
To allow a variable to be set at queue time, make sure the variable doesn't also appear in the variables block of a pipeline or job. If you define a variable in both the variables block of a YAML and in the UI, the value in the YAML will have priority.
See:
Upvotes: 1