Skip to main content
Version: QB14

Set up Build Pipeline

Situation​

Set up the build pipeline to handle multiple connected phases as described below:

  1. New commit into the SCM triggers the commit verification phase to build the package and run unit tests.
  2. The same commit automatically transit to next phase for running smoke tests if commit verification phase succeeds.
  3. The same commit automatically transit to next phase for deploying into development environment if smoke test phase succeeds.
  4. QA engineers may run some manual tests against the commit deployed to development environment, and if passed, they can recommend the commit.
  5. Some one in the team can manually transit the recommended commit to next phase for deploying into UAT environment.
  6. Mark the commit as recommended if user accepts the new commit.
  7. Again some one in the team manually transits the UAT passed commit to next phase for deploying into the production environment.

Demonstration​

  1. Switch to pipeline view of the demo project. 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.
  2. After triggering the build, you will be brought to the overview 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.
  3. 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.
  4. Now go back to the pipeline page 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.
  5. 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.
  6. Now go back to the pipeline page 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.
  7. At this time, the new commit has finished its life cycle from verification to production.

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.

Please note that:

  1. 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.
  2. 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.
  3. 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.
  4. 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")}.
Last updated on