Wijzigingen opleveren

Wat je hiermee bereikt

Een goedgekeurde patch is nog geen wijziging in je codebase. Opleveren maakt er een pull request (bij GitLab: merge request) van in je eigen Git-provider, op een aparte branch. Daar beoordeelt en merget je team hem zoals elke andere wijziging. FixControl merget nooit en schrijft nooit rechtstreeks op je hoofdbranch.

Zes gebeurtenissen, zes statussen

FixControl houdt deze stappen bewust uit elkaar. Een eerdere stap is nooit bewijs voor een latere.

Gebeurtenis	Wat het betekent	Waar je het ziet
Gemaakt	Een AI-agent heeft een patch voorgesteld. Er is nog niets getest of aangepast.	Patches → Te reviewen, en op de issue- of werksessiepagina.
Getest	Een sandboxrun op precies deze versie van de patch is geslaagd.	De controle Sandbox-validatie op de patch, en Sandbox-runs. Zie Verificatie en resultaten.
Goedgekeurd	Iemand die mag beslissen, of bij werk zonder risicomarkering de CTO Review-agent, heeft de patch goedgekeurd.	Patches → Goedgekeurd.
Opgeleverd	Het pull request is geopend in je Git-provider. In FixControl heet dat toegepast.	Patches → Toegepast, met de link Pull request bekijken.
Gemerged	Je team heeft het pull request samengevoegd, in je Git-provider.	De leverstatus op de patch: open, nog niet gemerged, gemerged of gesloten zonder merge.
Gedeployed	De wijziging draait in een omgeving. Dat regelt je eigen pijplijn.	Alleen zichtbaar in FixControl waar een deploymentkoppeling is ingericht.

Wat je vooraf nodig hebt

Een repository die aan het project is gekoppeld, onder Verbindingen → Repository koppelen. Zie Projecten.
Een goedgekeurde patch. Zie Goedkeuringen.
Een geslaagde sandboxrun van die versie. Zonder die run weigert FixControl het opleveren, tenzij iemand bewust afwijkt met een reden (zie hieronder).

Wie dit mag

Opleveren mag iedereen met de organisatierol admin of manager. Een operator kan een patch bekijken en een test starten, maar niet goedkeuren of opleveren. Gebruikt je organisatie projectrechten, dan bepaalt ook je projectrol wat je in dat project mag.

Een wijziging opleveren

Open de patch: via Patches, of via de knop Toepassen op de issuepagina (die verschijnt zodra de patch is goedgekeurd en getest).
Klik op Pull request openen. Het venster Pull request controleren toont het doel (repository en branch), de Titel, de Omschrijving en, op een eigen tab, het Commit-bericht.
Pas aan wat nodig is.
Bevestig met Pull request openen. Wat je bevestigt, is precies wat in je Git-provider verschijnt.

FixControl maakt een nieuwe branch aan met een naam die met fix/ begint en opent het pull request tegen de doelbranch.

Wat je daarna ziet

De patch staat onder Patches → Toegepast, met de link Pull request bekijken.
De leverstatus staat eerst op open, nog niet gemerged.
Merget of sluit je team het pull request, dan ziet FixControl dat via een webhook van GitHub, GitLab of Bitbucket Cloud, waar die is ingericht. Komt er geen bericht binnen, klik dan bij de levering op Controleren: FixControl vraagt de status dan zelf op bij je Git-provider.

Automatisch opleveren

Een project kan opleveren automatisch laten gebeuren. Na goedkeuring — ook een goedkeuring door de CTO Review-agent — opent FixControl dan direct het pull request. Mergen blijft een menselijke stap in je Git-provider.

Dit staat standaard uit. Een beheerder zet het aan in het project onder Verbindingen, bij de GitHub-koppeling, onder Meer opties: Code automatisch leveren — open een PR op deze repo na patch-goedkeuring.

Afwijken zonder geslaagde test

Is de sandboxrun niet geslaagd en moet de wijziging toch als pull request naar je team, dan kan een bevoegde gebruiker dat bewust doen. Daarvoor is een reden verplicht. Die reden wordt vastgelegd en komt bovenaan de omschrijving van het pull request, zodat de reviewer het als eerste ziet. Dit kan alleen bij levering als pull request.

Andere manieren van opleveren

Naast pull requests kent FixControl technische routes waarbij een patch rechtstreeks op een machine wordt toegepast, bijvoorbeeld een map op een computer of een server via SSH. De knop heet dan bijvoorbeeld Lokaal toepassen. Die routes richt een beheerder in. Ze gaan niet via een Git-provider, dus er is geen pull request en geen merge-review. Gebruik ze alleen waar dat bewust zo is afgesproken.

Deployments

FixControl start, maakt of terugdraait nooit zelf een deployment. Waar je beheerder dat inricht, kan een goedkeuring in FixControl een deployment vrijgeven die je eigen pijplijn al heeft gepauzeerd: een gepauzeerde Argo Rollout, een goedkeuringsstap in GitHub Actions of GitLab, of een input-stap in Jenkins. Dat staat standaard uit. Zie DevOps & CI/CD.

Terugdraaien

Een pull request dat nog niet gemerged is, kun je in je Git-provider sluiten.
Een gemerged pull request draai je terug met een revert in je Git-provider. FixControl doet dat niet automatisch.

Als het niet lukt

Wat je ziet	Wat het betekent	Wat je doet
Geen knop Pull request openen	De patch is nog niet goedgekeurd, of je rol mag niet opleveren.	Kijk bij Goedkeuringen wie moet beslissen.
Opleveren wordt geweigerd omdat de test ontbreekt of verouderd is	De laatste geslaagde run hoort niet bij deze versie van de patch, de omgeving of het plan.	Start de verificatie opnieuw. Zie Verificatie en resultaten.
Opleveren wordt geweigerd omdat niet bewezen is dat de applicatie start	De omgeving weet hoe de applicatie start, maar geen run heeft dat aangetoond.	Zie Problemen oplossen.
De leverstatus blijft open, nog niet gemerged terwijl het pull request al gemerged is	Er kwam geen webhookbericht binnen.	Klik op Controleren.
Het openen van het pull request mislukt	De Git-koppeling werkt niet (meer), of de branch kon niet worden aangemaakt.	Kijk naar de status van de koppeling onder Verbindingen en probeer opnieuw. De fout staat bij de levering.

Zie ook

Goedkeuringen · Verificatie en resultaten · GitHub · Git-providers · Problemen oplossen