ezmodo

Releases you can trust

Your CI asksbefore it ships.

Your CI asks ezmodo whether a build may ship, and the answer comes from your tests, bugs and sign-offs.

What’s included

  • Plan releases as milestones, and freeze them so only fixes and tests get in.

  • Release candidates per deliverable that you promote, reject or sign off.

  • Your CI asks ezmodo before it deploys and gets go, warn or hold.

  • Gate on suite pass rate, open bugs, epics complete, a checklist, a sign-off, the previous environment, or an external check. Any gate can be waived with a recorded reason.

  • Choose whether a no-go blocks the deploy or only warns.

  • Test cases, suites and runs, with JUnit results uploaded from CI.

  • A checklist for each release from a template, where any item can become a task.

  • A changelog generated for every milestone.

  • Release a whole epic in one step.

  • Ask why CI is red, how risky a deploy is, or who should review. The answers come from your data, not an AI’s guess.

  • GitHub check runs, deployments and releases recorded against your work.

  • Scope-creep and health badges on every milestone.

  • Feature flags that serve differently per environment, with targeting, percentage rollout, prerequisites and a lifecycle through to sunset.Team and Enterprise

  • A JavaScript and React SDK for your flags, on npm.Team and Enterprise

The gate

One callbefore every deploy.

Before your pipeline deploys, it asks ezmodo whether this build of this deliverable may go to this environment. The answer is go, warn or hold, with the reason and the next thing to do.

You decide what a no-go means, per deliverable. Leave it to warn and the deploy goes ahead with the problem written into the job summary. Turn on holding and the job stops.

It’s one HTTP call with an API key. There’s nothing to install in CI.

# In CI, before the deploy step> curl -sS -X POST https://ezmodo.com/api/v1/releases/gate \    -H "Authorization: Bearer $EZMODO_API_KEY" \    -d '{"projectId":"…","deliverable":"api","version":"2.4.0","environment":"production"}'{  "outcome": "warn",  "verdict": "no_go",  "holdDeploys": false,  "deliverable": "api",  "version": "2.4.0",  "environment": "production",  "nextAction": "Fix \"No serious open bugs\": 1 open high+ bug(s) in v2.4; at most 0 allowed."}# go: deploy. warn: deploy and say why. hold: stop.
Illustration. Names, versions and the reason are examples.

Gates

Each check sayswhy it passed or not.

Set gates per environment. Gate on a test suite’s pass rate, open bugs at or above a priority, epics being finished, a checklist phase, a sign-off, the build having gone through the previous environment, or a named check from your pipeline being green.

Every row carries a reason and the evidence behind it: the run, the bug, the epic. When you decide to ship anyway, waive the gate. The waiver needs a reason, and it stays on the release record.

api 2.4.0 → production

No-go

  • Test suites pass

    Core smoke: 118 of 120 cases passed, 95% required.

    Pass

  • No serious open bugs

    1 open high+ bug, at most 0 allowed.

    Fail

  • Went through the previous environment

    Deployed to staging.

    Pass

  • Checklist phase done

    Waived: “Docs ship the day after.”

    Waived

  • Signed off

    Waiting on 1 sign-off.

    Pending
Illustration. Names and numbers are examples.

Candidates and milestones

Plan it, freeze it,then ship one build.

A release is a milestone. Freeze it for stabilization and only bugs and testing work can start. Each release gets a checklist from your template, and any item that needs real work can become a task. ezmodo writes a changelog for every milestone, and you can release a whole epic in one step.

Each deliverable gets release candidates: the builds that could ship. Your CI reports where each one was deployed and uploads JUnit test results to your suites. You promote a candidate, reject it, or sign it off.

When CI goes red, ask why. Ask how risky a deploy is, or who should review. The answers are worked out from your builds, deploys and history, with the evidence shown. No AI guesses at them.

v2.4 · stabilization freeze

Frozen
Task types and whether they can start during the freeze
Task typeCan start
bugYes
testingYes
featureNo, frozen
choreNo, frozen
Illustration. The milestone name is an example; the rule is the stabilization freeze’s.

Feature flags · Team and Enterprise

Ship the code,turn it on later.

On Team and Enterprise, one flag can serve differently in each environment: fully on in development, 25% of users in production. Target it with rules on the attributes your app sends, roll it out by percentage, and make one flag depend on another.

Each flag has a lifecycle, from draft through rollout to sunset, so the ones waiting to be cleaned up are easy to find. Read them from your app with the JavaScript and React SDK, published on npm as @ezmodo/flags-sdk.

Flags

Each flag’s status and its state per environment
Flagdevelopmentstagingproduction
new_checkoutrolling_outOn · 100%On · 100%On · 25%
bulk_exportin_developmentOn · 100%OffOff
legacy_searchsunsetOffOffOff
Illustration. Flag names and percentages are examples.

In the help centre

More of what ezmodo does

Connect your agent.The record writes itself.

Start freeSee pricing