Generate Release Build using Artifacts of QA Build

Version 1 by Robin Shen
on Dec 24, 2009 08:09.

 
compared with
Current by Robin Shen
on Aug 17, 2010 10:38.

 
Key
These lines were removed. This word was removed.
These lines were added. This word was added.

View page history


There are 2 changes. View first change.

 h1. Scenario
 Promote build from QA configuration to release configuration. The release build should use the same artifacts of the QA build being promoted.
  
 h1. Demonstration
 # Visit [the demo QA build|http://demo.pmease.com/build/40.latest/]. A jar file is published as artifacts.
  # Visit [latest build of QA configuration|http://demo.pmease.com/build/40:latest]. A jar file is published as artifacts.
 # Click the promote button, and refresh the page after a while, a promotion arrow will appear at right side of the QA build version pointing to the newly generated release build.
 # Click the newly generated release build. When the build finishes, you will see that the jar file is now copied from QA build and renamed to reflect the release version.
  
 h1. Resolution
 # Edit [advanced setting of the QA configuration|http://demo.pmease.com/setting/advanced/40/] and enable the promotion setting. The property "destination configuration" should be defined as the release configuration, and the property "files to promote" should be defined to include desired files need to be promoted. All promoted files will be copied to workspace of node running the master step of destination configuration.
 # Edit [steps of the release configuration|http://demo.pmease.com/setting/steps/execution/41/] to define desired steps need to be executed during the release process. In this demo, we add steps to change name of promoted artifacts, publish promoted artifacts, and at last create label in the SCM.
 {info}Please make sure that the same repositories are used in QA and release configuration. This makes sure that all repository related steps in the release configuration operate against the repository revision used in the QA build. In our example, we define the repository directly [at the project level|http://demo.pmease.com/setting/repositories/37/] and it is inherited by both QA and release configurations.{info}
 # Optionally you may set up the release configuration so that new releases can only be generated through promotion, and direct triggering of the configuration is disallowed. This can be done by editing [basic setting of the release configuration|http://demo.pmease.com/setting/basic/41/] and set the _Run Mode_ property as _DISABLED_.
  # Edit [promotion setting of the QA configuration|http://demo.pmease.com/settings/40/promotions] and define a promotion, with property _destination configuration_ defined as release configuration, and property _files to promote_ defined as desired files need to be promoted. All promoted files will be copied to workspace of node running the master step of destination configuration.
 # Edit [step setting of the release configuration|http://demo.pmease.com/settings/41/steps] to define desired steps need to be executed during the release process. In this demo, we add steps to change name of promoted artifacts, publish promoted artifacts, and at last create label in the SCM.
 {info}Please make sure that the same repositories are used in QA and release configuration. This makes sure that all repository related steps in the release configuration operate against the repository revision used in the QA build. In our example, we define the repository directly [at the project level|http://demo.pmease.com/settings/37/repositories] and it is inherited by both QA and release configurations.{info}
 # Optionally you may set up the release configuration to disallow direct triggering, so that new releases can only be promoted from QA build. This can be done by editing [general setting of the release configuration|http://demo.pmease.com/settings/37/general] and set the _Run Mode_ property as _DISABLED_.