# Deploy After Merge --- ## Deploy after merge A Task can end at a production deployment instead of a pull request. Tick **After the PR is merged, deploy to production** when you create or start a Task; once you merge its pull request on GitHub, Deployment.io deploys the change to production and checks it there. The option is off by default. A draft remembers the choice, and **Start** shows it ticked or not as saved. ### When it's available Deploy after merge works for static sites only, and for repositories on GitHub only. It's available when every repository in the Task has exactly one production static site: a static-site deployment, in an environment classified Production, that builds the same repository from the branch the Task starts from. Otherwise the checkbox is disabled, and the reason for each repository is shown under it: - "No production static site deploys <repository> from <branch>." - "<repository> deploys from <branch> to <environment>, which isn't classified as Production. Classify it as Production to deploy there after merge." An environment's classification is chosen when you create it. - "More than one production static site deploys <repository> from <branch> (…). Deploy after merge needs exactly one." - "Deploy after merge follows GitHub pull requests only; <repository> is on <provider>." The production deployment is found when the Task starts and doesn't change afterwards. ### What happens after you merge Merging the pull request is the approval. Review and merge it on GitHub as you normally would — Deployment.io never merges it. Deployment.io notices the merge within about a minute, through GitHub's pull request webhook. A check every 10 minutes catches any merge the webhook missed. Each repository deploys when its own pull request merges. For each one: 1. If the production environment is missing a variable the change needs — the Task's **Before deploying** list — it waits. Add the variable to the environment and the deploy continues within about a minute. 2. If the deployment has [automatic deployment on git push](/docs/dashboard/automatic-deployment-on-git-push/) turned on, Deployment.io doesn't start a second deploy: it follows the first build that deployment starts after the merge. If none has started 30 minutes after the merge, Deployment.io deploys it itself. 3. Otherwise Deployment.io deploys the deployment's branch as it is at that moment, and records the commit that went out. It doesn't pin a commit, so nothing merged in between is rolled back. A deploy that fails is not retried. A pull request closed without merging deploys nothing. ### QA on production Once every repository's deploy has finished and at least one went out, Deployment.io runs QA once more, against the production site: it checks the Task's acceptance criteria there and reports. Acceptance criteria come from the Task's **Acceptance criteria** box (see [Creating and Running a Task](/docs/tasks/creating-and-running-a-task/)), or from the spec of a Task converted from an [Assistant session](/docs/assistant/from-spec-to-task/); a Task without them gets a smoke check instead — each production site loads with no page errors and no failed requests to the site itself. It is report-only — it never changes code or rolls anything back. The browser it uses is read-only. It blocks every request that could change data — anything other than GET, HEAD or OPTIONS — so a form submitted during the check never reaches your server, and a criterion that can only be checked by changing data is reported as not checked. It checks the deployment's custom domain — the one that doesn't redirect to another — or the deployment's own URL when it has no custom domain. The deployment's other domains are allowed too, so redirects between them still load. When production QA fails, its section says what you can do next: "You can roll back production below.", "You can roll back production or revert the change below." or "You can revert the change below.", depending on which actions are available. ### Roll back or revert Nothing is rolled back or reverted automatically: a person always decides. The Task drawer offers two actions, and they do different things. - **Roll back production** is fast and temporary. It puts the previous build back on production straight away, but the change is still on main. - **Revert the change** is durable. It opens a pull request that undoes the change on main, and nothing changes until someone merges it. If you need the change off production now and gone for good, roll back first, then revert. #### Roll back production For each repository the Task deployed, **Roll back production** redeploys the build that was live before the Task's deploy. It uses the deployment's own **Rollback**, so it needs the same permission. It's offered only while nothing else has shipped on top of the Task's deploy. After that the drawer says "<deployment> has been deployed again since this Task, so rolling back from here would undo those deploys too. Roll back from the deployment's Builds tab if you need to." It isn't available while a deploy is in progress — "A deploy is in progress on <deployment>. Try again when it finishes." — or when there's nothing to go back to: "No earlier successful deploy to roll back to." The rollback is shown only to people who can read the deployment, and the button only to those with its Rollback permission. Main still has the change, and the dialog says so: the next deploy brings it back — with automatic deployment on git push turned on, that's the next merge. To remove the change for good, revert it. Once the rollback finishes, the drawer shows "Rolled back on <date> to <short commit>". #### Revert the change For each GitHub repository whose pull request merged, **Revert the change** asks GitHub to open a pull request that reverts it. The drawer then shows "Revert pull request #<n>", linking to it. This works for any Task, whether or not it deployed after merge. Nothing changes until someone merges the revert pull request. With automatic deployment on git push turned on, merging it also deploys it. If GitHub can't revert the change — for example because it conflicts with later changes — the drawer shows GitHub's message. In the rare case that GitHub opened the pull request but Deployment.io couldn't save it on the Task, the drawer shows the link and says "Check GitHub before reverting again." ### What you'll see The Task page shows "Ends at: Production" (or "Ends at: Pull request"). Under each repository, below its pull request, it shows "Deploys to <deployment> in <environment>", then one of: - "after merge" - "Waiting for merge" - "Waiting for variables: <names>" - "Waiting for AutoDeploy's build" - "Deploying" - "Deployed · <short commit>" - "Deploy failed" - "Not deployed", with the reason A **View build** link appears once there is a build. On [the board](/docs/tasks/the-board/), these Tasks have their own status tags: - **Needs action** — "Merge to deploy", "Add 2 variables" (the count varies) or "Deploy failed". - **Running** — "Deploying". - **Done** — "Deployed". A must-fix finding still shows "PR held · must-fix open" first. --- Source: https://deployment.io/docs/tasks/deploy-after-merge/