Create a custom pipeline

Create a custom pipeline to move changes from your development environment to production (or your target instance) by duplicating one of the ReleaseOps sample playbooks.

시작하기 전에

Role required: releaseops.pipeline_admin and playbook.admin or pd_author

For more information about playbooks, see Exploring Playbook.

이 태스크 정보

Custom playbooks and pipelines enable you to create deployment structures tailored to the unique needs of your organization's development environment. Custom playbooks and pipelines are best suited for deployment processes that are consistent and expected to occur during each release. For deployment processes that are more variable, you might consider adding runbook tasks instead of custom playbooks or playbook activities. For more information, see .

프로시저

1. Duplicate one of the ReleaseOps playbooks.
   중요사항:

   When creating a custom playbook, duplicate one of the ReleaseOps sample playbooks as your starting point. Don’t customize the ReleaseOps sample playbooks directly, so that you can continue to refer back to them as new features are added during instance upgrades.
   1. Navigate to All > Workflow Studio and select the desired playbook.
   2. Enter a name for your new playbook and update any other required details.
   For more information, see Duplicate a playbook.
2. Add or update stages in the playbook as desired.
   주:

   Certain stages make sense at certain parts of the flow. For example, the deployment analyzer runs before the deployment state Move to test. Other stages might need to be run after Move to test or after Run ATF tests. Typically, you shouldn’t add anything after Ready for deploy.

   For more information, see Add and configure a stage in a playbook.
3. Add or update decisions in the playbook as needed.
   For more information, see Decision activities.
4. Select Activate to finalize your updates and make your new playbook available for use.
5. Create a pipeline that leverages your new playbook.
   1. Navigate to All > ReleaseOps > Pipelines and select New.
   2. Give your pipeline a name, and select playbooks for the Assessment playbook and Release playbook fields.
      You can use your own custom playbooks for both, or use a combination of custom and sample playbooks.
   3. Select and hold (or right-click) the header on the Pipeline form and select Save.
6. On your newly created pipeline, locate the Pipeline instances related list and select New.
   1. Select the label Test.
   2. Select your deployment instance.
   3. Select Submit.

Example: Create an assessment playbook

Create a custom pipeline to move changes through your non-production environment by duplicating the Deployment Request Assessment playbook. Add the deployment analyzer to detect if there are code changes in the deployment and skip Automated Test Framework (ATF) tests during assessment.

시작하기 전에

Role required: releaseops.pipeline_admin and playbook.admin or pd_author

프로시저

1. Duplicate the Deployment Request Assessment playbook.
   1. Navigate to All > Workflow Studio and select the Deployment Request Assessment playbook.
   2. Select Duplicate from the More actions menu.
   3. Enter a name for your new playbook and update any other required details.
2. Add a new stage to the playbook by selecting the + icon after Start, and enter a label, for example Analyze Deployment.
   주:

   Certain stages make sense at certain parts of the flow. For example, the deployment analyzer runs before the deployment state (Move To Test). Other stages might need to be run after Move to Test or after Run ATF Tests. Typically, you shouldn’t add anything after Ready for Deploy.
3. Add the Run Deployment Analyzer activity.
4. Select the newly added Run Deployment Analyzer activity to configure it.
   1. Select the Automation tab on the additional options modal.
   2. In the Inputs section of the modal, select the icon and then select Parent Record - Deployment Request.
   3. Select Save and close.
5. Locate the Run ATF Tests section of the playbook, and add a new decision after the Transition to Assessing activity by selecting the + icon, and then selecting Add a decision (if/then).
   For more information, see Decision activities.
6. Select the newly added decision to configure it.
   1. Select the Branches tab, and enter a label, for example Skip Tests.
   2. Select Add Condition.
   3. From the Field dropdown menu, select 1.1 Deployment Analyzer > Outputs > Has Code Change.
   4. Select is from the Operator dropdown menu.
   5. Select false from the True/False dropdown menu.
   6. Select Save and Close.
7. Hover over the Skip Tests branch, select Drag new connector icon, and drag the connector to the junction after the Create Test Failure Task.
   Confirm that the default branch is connected to Run ATF Tests for Deployment.
8. Select Activate to finalize your updates and make your new playbook available for use.
9. Create a pipeline that leverages your assessment playbook.
   1. Navigate to All > ReleaseOps > Pipelines and select New.
   2. Give your pipeline a name, and select your newly created playbook in the Assessment playbook field.
   3. Select and hold (or right-click) the header on the Pipeline form and select Save.
10. On your newly created pipeline, locate the Pipeline instances related list and select New.
    1. Select the label Test.
    2. Select your deployment instance.
    3. Select Submit.

결과

Your custom pipeline, which leverages the custom playbook you created from the default Deployment Request Assessment playbook for its assessment stage, is now ready for use.

주:

• The pipeline instance label (in the example above, the Test label entered for step 10a) is used to map the instance definition with the instance as referenced in the playbook. Mapping the instance definition with the instance label enables a playbook to be used by multiple pipeline definitions with different topologies (but the same process). For example, you can create another pipeline record and associate it to the same playbooks, but define a different test instance mapping.
• The source instance for the playbook is defined in the deployment request, so you can have multiple source or development environments for one release.
• The destination instance is defined in the release, so you can reuse the same pipeline to release to multiple destination or production environments.
• Only intermediate instances must be mapped.