- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
TL;DR: Don't modify the existing sample playbooks; there is a bug in the existing code that will require fixing, so even if you know how to clone playbooks read to the end.
Do not modify the out of the box ReleaseOps Playbooks!
Like fancy towels or the antique sofa in your grandmother's living room, the out-of-the-box sample ReleaseOps Playbooks are not meant to be used by you. Instead you should always duplicate the existing ones to use as a starting point.
It is very important when working with ReleaseOps playbooks to not modify the existing out-of-the-box Playbooks. This is because future versions may release useful features and if the playbook gets modified you will be unable to use the new version to learn about the new stuff because it will get skipped during upgrade. (If this happens to you, though, you may go inspect the playbooks in your lower environments).
In addition, keeping modifications to apps in a separate scope is a good practice for a variety of reasons--avoiding introducing conflicts or impacting existing code, keeping upgrades simpler, and isolating your own modifications for easy management.
How to Clone a Playbook
Create new scope
- Create a new scope by selecting the globe in the top right of the header and using the three-lines (hamburger) link for scopes.
- Use the New button at the top of the list.
- Name the new scope something like "ReleaseOps Mods"
- Make sure that this new scope is selected by going back to the globe icon and choosing it.
Duplicate the Playbooks
- Open Process Automation > Workflow Studio
- Filter on Application = ReleaseOps
- Click the checkbox next to the following playbooks one by one and choose "Duplicate": Deployment Request Assessment, Release Deployment, On Demand Deployment Request Assessment.
-
Name: Give it a good name that's not the same as the old name
-
Application: ReleaseOps Mods {Choose the scope you created earlier}
-
Reference the Playbooks
- Go to ReleaseOps > Pipelines
- Open all of the existing Pipelines and change the references for Release and Assessment Playbooks to your new duplicates.
Bug: A Playbook that is not in the ReleaseOps scope will not execute
There is currently a bug in the business rule that fires playbooks in which it does not properly account for scope.
- Select the scope ReleaseOps
- Go to System Definition > Business Rules
- Filter where Application = "ReleaseOps" AND Name Starts With "Run"
- Modify each, setting Active = False (this helps avoid conflicts when the upgrade happens that fixes this bug):
- Duplicate Each by opening and choosing Insert and Stay.
- Playbooks: "Run Release Playbook on Preparing" and "Run Assessment Playbook when Ready"
- Set Active = True
- Script: Find the "triggerPlaybook" line and replace it with this:
// Find the following line near the end: // Run Assessment Playbook when Ready (approximately line 46) // Run Release Playbook on Preparing (approximately line 20) /* sn_playbook.PlaybookExperience.triggerPlaybook(grPlaybook.name, current); */ // And REPLACE it with: const scopeName = grPlaybook.sys_scope.scope; // Don't include scope name if calling to another ReleaseOps playbook const playbookName = (scopeName == 'sn_releaseops' ? '' : scopeName + '.') + grPlaybook.name; sn_playbook.PlaybookExperience.triggerPlaybook(playbookName, current);
Conclusion
You should be ready to go. Remember: it is ok to modify the playbooks--we designed ReleaseOps to be flexible and you'll be amazed what you can do. Just don't modify our playbooks without safely cloning first.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

