Delivering changes

What you achieve

An approved patch is not yet a change in your codebase. Delivering turns it into a pull request (on GitLab: a merge request) in your own Git provider, on a separate branch. There your team reviews and merges it like any other change. FixControl never merges and never writes directly to your main branch.

Six events, six statuses

FixControl deliberately keeps these steps apart. An earlier step is never evidence of a later one.

Event	What it means	Where you see it
Created	An AI agent proposed a patch. Nothing has been tested or changed yet.	Patches → Pending, and on the issue or work-session page.
Tested	A sandbox run on exactly this version of the patch passed.	The Sandbox validation check on the patch, and Sandbox runs. See Verification and results.
Approved	Someone allowed to decide — or, for work without a risk flag, the CTO Review agent — approved the patch.	Patches → Approved.
Delivered	The pull request was opened in your Git provider. In FixControl this is called applied.	Patches → Applied, with the View pull request link.
Merged	Your team merged the pull request, in your Git provider.	The delivery status on the patch: open, not merged yet, merged or closed without merging.
Deployed	The change runs in an environment. Your own pipeline handles that.	Only visible in FixControl where a deployment connection is set up.

What you need first

A repository connected to the project, under Connections → Connect repository. See Projects.
An approved patch. See Approvals.
A passing sandbox run of that version. Without it FixControl refuses the delivery, unless someone deliberately departs from that with a reason (see below).

Who may do this

Anyone with the organization role admin or manager may deliver. An operator can view a patch and start a test, but cannot approve or deliver. If your organization uses project permissions, your project role also decides what you may do in that project.

Delivering a change

Open the patch: from Patches, or with the Apply button on the issue page (it appears once the patch is approved and tested).
Click Open pull request. The Review pull request window shows the target (repository and branch), the Title, the Description and, on its own tab, the Commit message.
Adjust whatever needs adjusting.
Confirm with Open pull request. What you confirm is exactly what appears in your Git provider.

FixControl creates a new branch whose name starts with fix/ and opens the pull request against the target branch.

What you see afterwards

The patch is listed under Patches → Applied, with the View pull request link.
The delivery status starts as open, not merged yet.
When your team merges or closes the pull request, FixControl learns that through a webhook from GitHub, GitLab or Bitbucket Cloud, where one is set up. If no message arrives, click Check on the delivery: FixControl then asks your Git provider for the status itself.

Auto-deliver

A project can let delivery happen automatically. After approval — including an approval by the CTO Review agent — FixControl then opens the pull request straight away. Merging stays a human step in your Git provider.

This is off by default. An administrator switches it on in the project under Connections, on the GitHub connection, under More options: Auto-deliver code — open a PR on this repo after the patch is approved.

Departing without a passing test

If the sandbox run did not pass and the change must still reach your team as a pull request, an authorized user can do that deliberately. A reason is required. The reason is recorded and placed at the top of the pull request description, so the reviewer sees it first. This is only possible for delivery as a pull request.

Other delivery methods

Besides pull requests, FixControl has technical routes that apply a patch directly on a machine, for example a folder on a computer or a server over SSH. The button then reads, for example, Apply locally. An administrator sets these routes up. They do not go through a Git provider, so there is no pull request and no merge review. Use them only where that was deliberately agreed.

Deployments

FixControl never starts, creates or rolls back a deployment itself. Where your administrator sets it up, an approval in FixControl can release a deployment that your own pipeline has already paused: a paused Argo Rollout, an approval step in GitHub Actions or GitLab, or an input step in Jenkins. This is off by default. See DevOps & CI/CD.

Rolling back

A pull request that has not been merged yet can be closed in your Git provider.
A merged pull request is rolled back with a revert in your Git provider. FixControl does not do that automatically.

When it does not work

What you see	What it means	What you do
No Open pull request button	The patch has not been approved yet, or your role may not deliver.	Check Approvals for who has to decide.
Delivery is refused because the test is missing or out of date	The last passing run does not belong to this version of the patch, the environment or the plan.	Run the verification again. See Verification and results.
Delivery is refused because it was not proven that the application starts	The environment knows how the application starts, but no run showed that it does.	See Troubleshooting.
The delivery status stays open, not merged yet although the pull request was merged	No webhook message arrived.	Click Check.
Opening the pull request fails	The Git connection no longer works, or the branch could not be created.	Check the connection's status under Connections and try again. The error is shown on the delivery.