h1. Situation
Set up the build pipeline to handle multiple connected phases as described below:
# New commit into the SCM triggers the commit verification phase to build the package and run unit tests.
# The same commit automatically transit to next phase for running smoke tests if commit verification phase succeeds.
# The same commit automatically transit to next phase for deploying into development environment if smoke test phase succeeds.
# QA engineers may run some manual tests against the commit deployed to development environment, and if passed, they can recommend the commit.
# Some one in the team can manually transit the recommended commit to next phase for deploying into UAT environment.
# Mark the commit as recommended if user accepts the new commit.
# Again some one in the team manually transits the UAT passed commit to next phase for deploying into the production environment.
h1. Demonstration
# Switch to pipeline view of the [demo project|http://demo.pmease.com/pipeline/111]. The _Commit Verification_ configuration is set up to poll SCM periodically to trigger a build whenever there are new commit. Since you can not commit into the demo SCM repository, for demonstration purpose, you may manually run the configuration to verify latest commit.
# After triggering the build, you will be brought to the [overview|http://demo.pmease.com/overview/111] page. When the build finishes, you may switch back to the pipelines page. You will see three big arrows connected together with each arrow representing a phase. You will also see that current SCM revision is pulled from _Commit Verification_ phase and stops at _Deploy to Dev Servers_ phase.
# Now assume you are QA engineers, and have tested the commit deployed in development environment. You decided to recommend the commit by following the link of _Deploy to Dev Servers_ in the pipeline and recommending the build.
# Now go back to the [pipeline page|http://demo.pmease.com/pipeline/111] and the _Deploy to Dev Servers_ phase can now be transited into next phase. Hover mouse over that phase, and hit the displayed _Promote_ button, and you will see that next phase _Deploy to UAT Servers_ is triggered.
# Wait for a short period of time for the phase to be completed. Assume your users are satisfied with the new feature and again you play the role of some other one in your team to recommend the commit by following the link of _Deploy to UAT Servers_ in the pipeline and recommending the build.
# Now go back to the [pipeline page|http://demo.pmease.com/pipeline/111] and the _Deploy to UAT Servers_ phase can now be transited into next phase. Hover mouse over that phase, and hit the displayed _Promote_ button, and you will see that next phase _Deploy to Prod Servers_ is triggered.
# At this time, the new commit has finished its life cycle from verification to production.
h1. Resolution
In QuickBuild build pipeline is based on the build promotion feature. Each phase we described is represented by a separate configuration, and transitions between different phases are accomplished with defined promotions. Check promotions definition of below configurations and there is a promotion named "Promote" defined for each of them with the target configuration set to next phase configuration.
* [Commit Verification|http://demo.pmease.com/settings/111/promotions]
* [Run Smoke Tests|http://demo.pmease.com/settings/116/promotions]
* [Deploy to Dev Servers|http://demo.pmease.com/settings/117/promotions]
* [Deploy to UAT Servers|http://demo.pmease.com/settings/113/promotions]
Please note that:
# Promotion definition for the first two configurations are marked as _Auto Promotion_ when the build is successful. This enables the commit transits to next phase without human intervention. However if the build fails, the commit will cease to transit to next phase.
# Promotion definition for the last two configurations are NOT marked as _Auto Promotion_, and the promote condition is set to met only if build is recommended. This means that transition to important environments can only be enabled upon manual approved.
# All promotion definitions passes the generated artifacts to next phase so that next phase works on the verified artifacts of previous phase instead of rebuilding the artifacts from scratch.
# All promotion definitions passes the variable _version_ to next phase so that next phase uses the same build version as previous phase for same commit. To support this, next build versions of all phases except the _commit verification_ are set to inherit from parent configuration, which is set to _$\{vars.getValue("version")\}_.
Set up the build pipeline to handle multiple connected phases as described below:
# New commit into the SCM triggers the commit verification phase to build the package and run unit tests.
# The same commit automatically transit to next phase for running smoke tests if commit verification phase succeeds.
# The same commit automatically transit to next phase for deploying into development environment if smoke test phase succeeds.
# QA engineers may run some manual tests against the commit deployed to development environment, and if passed, they can recommend the commit.
# Some one in the team can manually transit the recommended commit to next phase for deploying into UAT environment.
# Mark the commit as recommended if user accepts the new commit.
# Again some one in the team manually transits the UAT passed commit to next phase for deploying into the production environment.
h1. Demonstration
# Switch to pipeline view of the [demo project|http://demo.pmease.com/pipeline/111]. The _Commit Verification_ configuration is set up to poll SCM periodically to trigger a build whenever there are new commit. Since you can not commit into the demo SCM repository, for demonstration purpose, you may manually run the configuration to verify latest commit.
# After triggering the build, you will be brought to the [overview|http://demo.pmease.com/overview/111] page. When the build finishes, you may switch back to the pipelines page. You will see three big arrows connected together with each arrow representing a phase. You will also see that current SCM revision is pulled from _Commit Verification_ phase and stops at _Deploy to Dev Servers_ phase.
# Now assume you are QA engineers, and have tested the commit deployed in development environment. You decided to recommend the commit by following the link of _Deploy to Dev Servers_ in the pipeline and recommending the build.
# Now go back to the [pipeline page|http://demo.pmease.com/pipeline/111] and the _Deploy to Dev Servers_ phase can now be transited into next phase. Hover mouse over that phase, and hit the displayed _Promote_ button, and you will see that next phase _Deploy to UAT Servers_ is triggered.
# Wait for a short period of time for the phase to be completed. Assume your users are satisfied with the new feature and again you play the role of some other one in your team to recommend the commit by following the link of _Deploy to UAT Servers_ in the pipeline and recommending the build.
# Now go back to the [pipeline page|http://demo.pmease.com/pipeline/111] and the _Deploy to UAT Servers_ phase can now be transited into next phase. Hover mouse over that phase, and hit the displayed _Promote_ button, and you will see that next phase _Deploy to Prod Servers_ is triggered.
# At this time, the new commit has finished its life cycle from verification to production.
h1. Resolution
In QuickBuild build pipeline is based on the build promotion feature. Each phase we described is represented by a separate configuration, and transitions between different phases are accomplished with defined promotions. Check promotions definition of below configurations and there is a promotion named "Promote" defined for each of them with the target configuration set to next phase configuration.
* [Commit Verification|http://demo.pmease.com/settings/111/promotions]
* [Run Smoke Tests|http://demo.pmease.com/settings/116/promotions]
* [Deploy to Dev Servers|http://demo.pmease.com/settings/117/promotions]
* [Deploy to UAT Servers|http://demo.pmease.com/settings/113/promotions]
Please note that:
# Promotion definition for the first two configurations are marked as _Auto Promotion_ when the build is successful. This enables the commit transits to next phase without human intervention. However if the build fails, the commit will cease to transit to next phase.
# Promotion definition for the last two configurations are NOT marked as _Auto Promotion_, and the promote condition is set to met only if build is recommended. This means that transition to important environments can only be enabled upon manual approved.
# All promotion definitions passes the generated artifacts to next phase so that next phase works on the verified artifacts of previous phase instead of rebuilding the artifacts from scratch.
# All promotion definitions passes the variable _version_ to next phase so that next phase uses the same build version as previous phase for same commit. To support this, next build versions of all phases except the _commit verification_ are set to inherit from parent configuration, which is set to _$\{vars.getValue("version")\}_.