I have a configuration that creates a piece of software in the first stage.
I would like to deploy this software to different locations in a subsequent stage, e.g., to Dev, Test, Intern, or Prod. Where this stage deploys to is controlled by a parameter.
Now I would like to be able to trigger the deployment stage multiple times.
Example: I create a piece of software in version 1.2.4 and deploy it to Test by manually promoting the second stage.
Afterward, it turns out that this version is unusable. So I remove the version from the target location.
Now I would like to redeploy the previous version, 1.2.3. To do this, I would have to restart the deploy stage in an old running pipeline.
At this point, I don’t know how to run the stage again.
I would like to be able to run this stage again with different parameters. The stage does nothing more than copy files from A to B. Where it deploys is controlled by a parameter.
At the moment, stages can only be rerun if they’ve failed, and it’s not currently possible to modify variables when rerunning them. We can see how being able to rerun a completed stage with different parameters would be useful, and this is something we’ll consider for a future update. The main challenge here is ensuring that outputs from previous stages haven’t been cleaned up or overwritten, while also managing disk usage efficiently.
Meanwhile, you can restart the entire build with the same or updated parameters, though this will re-execute all preceding stages before reaching the deployment stage again.
A more flexible approach would be to split your workflow so that deployment runs as a separate build configuration. This deployment build could be triggered automatically after the test stage completes (using a Build Completed trigger), but could also be manually started at any time later. If you take this route, ensure that artifacts from the earlier build are copied to a shared location for the deployment build to pick up, and protect this process with a shared resource lock to avoid concurrency issues.
At the moment we are actually already following the approach you have suggested with a further Deployment Configuration. Having these steps in the same configuration where our Setups are built would save some time and make things easier.
It would be super if this could be implemented some day. But I of course understand the hurdles you are talking about.
Thank you again for your fast answer and suggestions!
