You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently if you run either of the manual deploy options it goes straight to prod if it's successful. Would be nice if it just validated and then we could quick deploy if we're ready.
Accidentally deployed expecting the same pattern of build/validate/quick deploy to happen as the primary pipeline. Not that the name of the pipeline wasn't clear about the action.
This also opens up letting the client quick deploy, and just validating work in progress that you're not ready to deploy (so you know it'll deploy on the deploy date).
The text was updated successfully, but these errors were encountered:
I kinda disagree. I really prefer this being one and done as I can fire off a deployment and just check back in on it when it's done.
There are also certain metadata packages that cannot be deployed via quick-deploy, in which cases this these manual pipelines are fallbacks.
We could add a separate manual pipeline with two steps, (or perhaps combine it with a flag and an optional second step)
It's worth noting that if you let your client deploy the quick-deploy, you are likely to lose your commit history as it may be picked up by the auto-checkout
Currently if you run either of the manual deploy options it goes straight to prod if it's successful. Would be nice if it just validated and then we could quick deploy if we're ready.
Accidentally deployed expecting the same pattern of build/validate/quick deploy to happen as the primary pipeline. Not that the name of the pipeline wasn't clear about the action.
This also opens up letting the client quick deploy, and just validating work in progress that you're not ready to deploy (so you know it'll deploy on the deploy date).
The text was updated successfully, but these errors were encountered: