Deployment events

1. Plan: the day and deploy time, the teams it is for, the flows that deploy it, and a branch deadline.
2. Collect branches: each project waits until someone answers with the branch that is ready (checked against GitHub), or marks it as not deploying. The people asked get an email, and reminders a day and two hours before the deadline.
3. Lock: at the deadline the list locks itself; DevOps can also lock or reopen it. Locking pins each project to its branch’s newest commit.
4. Deploy: DevOps deploys what was locked. Every flow starts at once, and within a flow projects run in its order. If someone pushed to a locked branch, nothing starts until DevOps re-pins it.
5. Result: everyone involved hears when the deploy starts and when it finishes. A failed project can be retried from the event.

• Give the event a release branch (release/4.2) and every project whose repository has it gets it suggested; one click confirms it, for one project or for all.
• Otherwise a waiting project suggests the branch it deployed from last time, while that branch still exists.
• Each answer shows its commit’s checks on GitHub (passing, failing, running). Locking or deploying with failing checks asks first.

On the event’s Changes tab, each project lists the commits and pull requests it adds to what is live where it deploys, from the deploy history. Copy them as Markdown for a changelog or a chat.

Each deploy keeps its release notes as they were when it started; they are on its tab and in the email when it finishes.

On Business, a flow can have gate steps between its deployments. An approval waits until someone it names says yes; a wait gives a deploy time to show problems; a health check asks a URL until it answers as expected.

• Approvers get an email and see it in Needs you. They approve or reject it from the run or the event, with a note.
• A rejected or unanswered approval, or a health check that never passes, fails the step: its failure connections (rollbacks, alerts) run.
• Events never ask anyone to answer for a gate: it comes along when a project before or after it deploys.

When a deployment fails on GitHub, its panel and the failure email show the last lines of the step that failed, so you can see why without opening GitHub.

When a deploy goes wrong, DevOps choose Roll back in the event’s menu, or on the Live page. Each project the event deployed goes back to the commit that was live before it, the last step first, as a new deploy you can watch. Its release notes list the commits it takes back.

DevOps can switch them on under Settings → GitHub. When an event locks, each pull request in its release notes gets a comment saying where and when it deploys. The same comment follows the deploy, and says where the pull request is live once it finishes, so its author knows without asking.

On Team and Business, DevOps set up a release that repeats under Events → Release trains: every Thursday at 14:00, or every second week, with branches due the day before, the teams and flows, and a title such as Release {n}. A few days before each occurrence the train plans its event, numbered, and everyone is asked for their branches as usual.

• Skip or move one occurrence from the train’s page before its event is planned; once planned, change the event itself.
• A release branch template such as release/{n} gives each event its release branch.
• Pausing a train plans nothing until it is resumed. Events it planned stay when it changes or is deleted.

On Team and Business, the calendar button on the Events page gives you private links for Google Calendar, Outlook or Apple Calendar: your releases, the whole organization’s, or a team’s. Each deploy and its branch deadline show at the right moment in your timezone, and release trains’ next dates show as tentative.