Dependency Story Process & Template

Our Tools & Cadence for Managing Dependencies

Tools

In Playbook, we use Renovate to help us manage our updates. Renovate maintains two open PRs for updating. https://github.com/powerhome/playbook/pulls/app%2Frenovate

Cadence

A story (once-a-week) should be made for investigating the two open renovate PRs. It should be assigned to a playbook engineer. As an engineer, you are responsible for following the story assigned to you.

Here's the story template for Playbook's Dependency's that a producteer can use to make a story for the runway board.

Story Template

User Story

As a Playbook engineer, I want to keep my dependencies up to date so that I feel confident Playbook is secure and upgrade ready for clients.

Upgrade Best Practices for Risk Management

• LOW: For upgrades that are only in the playbook-website folder are generally considered low risk as they should only affect the website. Simple testing locally and Milano should suffice before merging.
• MED: Upgrades are small version bumps and a supporting library is considered a medium risk. Simple testing locally and Milano should suffice in most cases.
• MED/HIGH: Upgrades that directly support kits should be considered as a medium to high risk depending on what was updated. These usually require some digging into what was changed. These MAY require alpha testing with Ninjas depending on what you discover.
• HIGH: First class dependencies (rails, or node updates) should be treated with care and are considered high risk. These WILL require an alpha test with Ninjas before merging.

Note this is just a guide but does not replace discussing with the team. When in doubt ask others what classification to give and what level of testing should be required.

Acceptance Criteria

• It has been tested thoroughly based on the risk factor listed above.
• If needed an alpha has been tested by the team and the ninjas.
• It was tested locally in all the major pages and kits.
• It was tested in Milano in all the major pages and kits.
• Confirmed nothing is broken
• It contains a label that targets the correct update

Testing & Release

• Add a Milano label
• Merge to master after feedback has been addressed and approved code review.
• The release team will make a release and update Nitro accordingly (no action from you is required)

Any other technical details?

• Should any more details we have discussed be included?

Breaking Changes

Breaking changes are the things that cause the most problems & errors with the release. First, if you are unsure about whether a PR is breaking reach out to the Playbook team. Any deletion or rename of a prop is a breaking change unless it’s made backward compatible. Changes to prop types are also breaking. Changes to enum values can also be breaking depending on the use cases. Another clue for breaking changes is changes made to tests. If a PR includes a breaking change we need to treat it will considerable scrutiny. If possible help makes the PR backward compatible and adds comments about depreciation. The most ideal path is to first make changes backward compatible and flag for depreciation. We can then plan a future sprint to deprecate as well as handle any updates that need to be made in our sister apps.