Release features and watch them live

Plan a release, ship it, let the release check confirm it on the real site, and see which live features work or are broken.

In short

A release groups the features that ship together. Your own pipeline ships it; then you mark it shipped in {{brand}}. Right after that, the release check runs each feature's checks once on the real site: passed - the feature moves to Live by itself; failed - the card turns red with what failed, and you roll back in your own pipeline. In Live, monitors watch the feature's checks. A failing check turns the card red and files a bug.

Before you start

• Who: anyone who can change cards plans a release and sets a feature's release. Someone who manages the board releases it.
• {{brand}} does not deploy your product. Release in {{brand}} after your own pipeline has put it live.

Steps

1. Open the board's menu, choose "Reports" and then "Releases".
2. Press "New release", type a "Name" and, if you like, a "Target date".
3. Press "Add release".
4. On each Feature card, choose its "Release".

1. When your product is live, open "Releases" and press "Release {name}".
2. Read what happens and press "Release".

Result: each feature in Release runs its release check. When it passes, the feature moves to Live by itself. A feature with no check to run moves as "Shipped, to Live" says: with Ask me it gets "The release went out. Move the card to Live?".

Watch what is live

• The Live column folds into one count, with any red or just released cards on top.
• Choose "Reports" and then "Live features" in the board's menu, or "See all live features", for the list: "Working", "Broken" and "Just released".
• "Product health" on top of the board counts "Live and working" and "Broken right now".

When a live feature breaks

• A failing live check turns the card red and says "Broken on the live site".
• With "A live check fails" set to "Open a bug automatically", {{brand}} files a bug under the feature.
• The card turns green again once the check passes.
• Fixing it live, or rolling back, is your pipeline's job. {{brand}} does not roll back.

Good to know

• A release is ready when every feature in it passed its checks and was merged.
• A target date is a reminder only. Nothing is released by itself on that day.
• Deleting a release keeps its features on the board, without a release.
• Monitors run the checks on the live site. Set them up in the tester that owns the check. For API checks, see /help/api-testing/monitors-and-alerts.
• {{brand}} never deploys and never rolls back. When the release check fails, roll back in your own pipeline, fix the code, then run the card's checks again.
• A bug fix follows the same board: reported in Idea, then Develop, Test, Release and Live, without design or plan. Its likely cause shows on the card, a regression check is made from the failing case once the fix reaches Test, and the bug card closes itself when it is live.
• A board synced with Jira or Azure Boards writes each stage change back to the work item: a comment with the proof and a stage label such as kamocore-release.

If something goes wrong

• "Add features to this release first." - the release has no features.
• "3 features are not ready yet." - only features in Release take part. Wait until they reach Release.
• "Someone who manages the board releases it." - ask a board manager.

Related

• /help/boards/test-and-ready
• /help/boards/how-a-feature-moves
• /help/api-testing/monitors-and-alerts
• /help/boards/start-a-product-board
• /help/boards/portfolio