We have multiple environments (Dev, QA, Staging, Production) and it wasn’t clear from the documentation how to support the following scenario:
We have a build that has gone to Dev and then QA and then Staging but then we realize a configuration value is wrong just in Staging. Do we have to redeploy the build to each environment that preceeds Staging (Dev then QA then Staging) before we can redeploy it to Staging or can we just fix the config value and redeploy to Staging?
Generally variables are snap-shotted with a release. This is so you can change variables without affecting existing releases.
To cater for situations like yours, you can refresh a release’s variables. If you correct the variable, then go to the release page and expand the variables section, you will see an “Update Variables” button. This will do the obvious.
I hope this helps,
Thanks Michael, it does. How about for binaries? Would we have to start in Dev then deploy to QA then staging all the time or could we go just QA to staging?
There is no corresponding “Update” functionality for binaries. If you modify your binaries, you should create a new package and a new release. This is by design.
But Lifecycles are your friend here. You can modify your project’s Lifecycle to allow the first environment deployed to be either Dev or QA for example. Then when you create your new release, you can skip Dev and go straight to QA.
I hope this helps!
Michael - how would this solution work? If both dev and QA are in the first phase/step, what is preventing the team from skipping QA jumping straight to prod? Because, as I understand it, if the Dev/QA phase only required one environment, then Dev satisfies that and if it requires both, then that does not allow the omission of Dev like jay was asking about.
Help me understand your answer please.