When you publish an application to a stage, your rules are deployed immediately to that system. To allow stakeholders to inspect and verify changes before they are deployed the stage, configure a manual task in on the previous stage. When the pipeline runs, it is paused during a manual step that is assigned to a user, which allows stakeholders to review your changes before they approve the step and resume running the pipeline.

1. In App Studio, do one of the following actions:
   • Click Turn editing on, and then, in the navigation pane, click SettingsVersions.
   • In the App Studio header, click Publish.
   The Settings page displays the stages that are enabled in the application pipeline in Deployment Manager. The available stages are, in order, quality assurance, staging, and production.
   It also displays the application versions that are on each system. The version numbers are taken from the number at the end of each application deployment name in Deployment Manager. For example, if a deployment has a name of "MyNewApp:01_01_75", the dialog box displays "v75".
2. Submit an application from development to quality assurance or staging in your pipeline by completing the following steps:
   1. Click either Publish to QA or Publish to staging.
   2. To add a comment, which will be published when you submit the application, add a comment in the Publish confirmation dialog box.
   3. If Agile Workbench has been configured, associate a bug or user story with the application, in the Associated User stories/Bugs field, press the Down arrow key and select the bug or user story.
   4. Click OK.
      Result: Each unlocked ruleset version in your application is locked and rolled to the next highest version and is packaged and imported into the system. The amount of time that publishing application changes takes depends on the size of your application.

      A new application is also copied from the application that is defined on the pipeline in Deployment Manager. The application patch version is updated to reflect the version of the new rulesets; for example, if the ruleset versions of the patch application are 01-01-15, the application version is updated to be 01.01.15. A new product rule is also created.

      In addition, this application is locked and cannot be unlocked. You can use this application to test specific patch versions of your application on quality assurance or staging systems. You can also use it to roll back a deployment.
3. Make changes to your application in the unlocked rulesets, which you can publish again into the pipeline. If an application is already on the system, it is overridden by the new version that you publish.
4. If you configured a manual step, request that stakeholders review and test your changes. After they communicate to you that they have completed testing, you can publish your changes to the next stage in the pipeline.
5. Publish the application to the next stage in the pipeline by clicking the link that is displayed.
   The name of the link is the Job name field of the manual task that is defined on the stage.
   Result: If you do not have a manual task defined, the application automatically moves to the next stage.