Codebases

Wat een codebase is

Een codebase is één repository of bronmap waar FixControls agents aan mogen werken. Het is het object dat antwoord geeft op "waar staat deze code, en hoe komen we erbij".

Twee dingen staan bewust los van elkaar:

• een verbinding beantwoordt hoe FixControl bij je code komt. GitHub, GitLab en Bitbucket verbind je onder Instellingen → Kanalen → Code- & patch-levering (zie Git-providers). Een SSH-server of een map op een computer met de FixControl-desktopapp verbind je onder Instellingen → Infrastructuur (zie Infrastructuur);
• een codebase beantwoordt welke repository, op welke branch, met welke instellingen.

Een codebase registreren geeft geen enkele agent een reden om hem aan te raken; werk bereikt een codebase alleen via een project.

Je kunt hier ook gewoon om vragen. Command Center kan bij je gekoppelde providers zoeken naar een repository die je losjes noemde, een verwijzing oplossen, er één koppelen en ontkoppelen, de werkkopie synchroniseren, en een codebase analyseren om de technische documentatie opnieuw te genereren — en hij kan vertellen aan welke repositories een project gebonden is.

Een repository aan een project koppelen

De gewone weg loopt via het project zelf: Project → Verbindingen → Repository koppelen. De wizard neemt je mee door:

1. Waar staat de code? — GitHub, GitLab of Bitbucket; Meer opties (technisch) biedt een server via SSH of een map op een computer.
2. Aanmelden — gebruik een verbinding die je organisatie al heeft, of verbind een nieuw account. Alleen een beheerder van je organisatie kan een nieuw account verbinden.
3. Organisatie kiezen — als de verbinding er meer dan één ziet.
4. Repository kiezen (of, bij een server of map, de map).
5. Branch kiezen — FixControl stelt wijzigingen voor tegen deze branch en pusht er nooit rechtstreeks naartoe.
6. Controle — Koppelen aan {project} koppelt de repository, en de wizard controleert of FixControl hem kan lezen.

Is een repository elders in je organisatie al verbonden, dan biedt de wizard hem aan onder Al verbonden in je organisatie, zodat een tweede project hem hergebruikt in plaats van hem dubbel toe te voegen. Iemand zonder beheerdersrol kan een repository koppelen die de organisatie al heeft, maar geen nieuwe toevoegen.

Instellingen → Codebases is het alternatief: het overzicht voor de hele organisatie, met elke geregistreerde codebase en Codebase toevoegen om er direct een te registreren. Het is een beheerderspagina en hoort bij de engineeringfuncties van je abonnement. Is er nog geen verbinding, dan zegt de pagina dat en stuurt je eerst naar het verbinden, in plaats van je een formulier te laten invullen dat niet opgeslagen kan worden.

De naam is van jou — die staat op issues, patches en runs. Gebruik de naam die je team uitspreekt, niet de slug.

Er een verwijderen

Een codebase verwijderen haalt de verbinding met de repository weg, niet de historie. De bevestiging zegt het voluit: "De verbinding met de repository wordt verbroken. Historische commit-referenties, patch-lineage en verificatiebewijzen blijven bewaard, en een beheerder kan hem terugzetten."

Dat is de algemene regel in FixControl: operationele objecten worden zacht verwijderd, en het bewijs dat iets gebeurd is overleeft het object waaraan het gebeurde. Zie Governance & beleid.

Runtimeversies

Standaard leidt FixControl af welke runtime een repository nodig heeft door de repository te lezen — het manifest, de lockfile, het versiebestand, de Dockerfile, de CI-configuratie. Dat klopt meestal, en het is altijd op bewijs gebaseerd.

Waar dat niet zo is, kan een project een runtime pinnen onder Runtimeversies voor dit project (Project → Omgevingen → Hoe wijzigingen worden gevalideerd): een taal, een versie, en optioneel een specifieke image. Een lege lijst zegt wat hij bedoelt — "Geen runtime vastgelegd — FixControl leidt dit af uit de repository."

Pin er een wanneer:

• je build een base-image nodig heeft die je eigen registry levert en de publieke niet;
• de repository niets verklaart en je de standaard niet wilt;
• twee projecten in dezelfde workspace verschillende versies van dezelfde taal nodig hebben — dat kan, en de pin is hoe je dat zegt.

Een pin wijzigen trekt de geverifieerde omgeving van het project in. De volgende run wordt bewezen onder de nieuwe pin in plaats van een image te hergebruiken die de pin niet meer noemt. Dat is de bedoeling: een pin die je zonder herbewijs kon zetten, zou een bewering zijn, geen configuratie.

Database voor verificatieruns

Database voor verificatieruns bepaalt of een verificatierun de databasemigraties van deze codebase uitvoert voordat hij de wijziging test. De opties op het scherm:

Migratiestappen draaien alleen als er voor de run ook echt een database is. Met de standaard — geen database — worden ze overgeslagen, en een wijziging die van een migratie afhangt kan die run dan niet bewijzen.

Wijs bij URL naar een geïsoleerde wegwerpdatabase. Een verificatierun voert migraties uit; een migratie is geen alleen-lezen operatie, en een database waar je aan hecht is niet de plek om er een te bewijzen.

Sidecar-database-engine kiest PostgreSQL of MySQL voor de wegwerpdatabase. Kies MySQL voor Laravel- of Magento-codebases waarvan de migraties MySQL-specifieke SQL gebruiken. Laat je hem op Standaard, dan volgt de codebase de keuze voor de hele workspace, en dat is PostgreSQL tenzij je beheerder het heeft gewijzigd.

Waar deze instelling geldt, hangt af van waar de run draait:

• Een run die de geverifieerde omgeving van je project gebruikt, krijgt zijn database uit de services die die omgeving declareert, en deze instelling wordt daarvoor niet gebruikt. De gehoste cloud-lane werkt zo: die start goedgekeurde databasecontainers naast de run, op basis van wat de geverifieerde omgeving nodig heeft.
• Elke run een verse wegwerp-database wordt toegepast waar FixControl de verificatie in zijn eigen container-lane draait. Komt een run terecht op een lane die er geen kan leveren, dan krijgt de run geen database en worden de migratiestappen overgeslagen in plaats van tegen niets te draaien.

WINDEV-codebases

WINDEV-projecten worden anders geregistreerd, omdat ze geen repository met een manifest zijn: je geeft de projectroot, het .wdp-projectbestand, het soort broncodebeheer, eventuele analysebestanden, en verwijzingen naar geëxporteerde technische documentatie voor kennisretrieval.

Wees duidelijk over wat dat vandaag oplevert. Een WINDEV-codebase wordt gedetecteerd, beschreven en gerouteerd; hij wordt niet geverifieerd. Er is geen WINDEV-runner in het product, dus een verificatie stopt met een weigering die benoemt wat ontbreekt in plaats van een oordeel te leveren. Wijzigingsvalidatie vertelt welke stacks een echt oordeel halen.

Wat agents met een codebase mogen

Een codebase registreren is geen toestemming. In het hele product geldt:

• codelevering gaat alleen via een pull- of merge-request — er is geen toestand waarin FixControl naar je standaard- of productiebranch pusht;
• een agent leest de repository binnen het project waarin hij werkt, en de context van het ene project bereikt nooit het andere;
• wat een agent mag, wordt bepaald door governance, nooit door wat hier geregistreerd staat.

Veelgestelde vragen

Kunnen twee projecten een codebase delen? Ja. De codebase wordt één keer geregistreerd; projecten verwijzen ernaar. Instellingen die bij het werk horen — de validatiestrategie, omgevingsinstellingen, runtimepins — staan op het project.

Heeft een private repository iets bijzonders nodig? Een verbinding die hem kan zien. De repositorylijst toont alleen wat de verbinding al kan bereiken; ontbreekt een repository, geef FixControl er dan toegang toe bij de codehost en kom terug.

Ik heb per ongeluk een codebase verwijderd. Een beheerder kan hem terugzetten. De patch-lijn en het verificatiebewijs zijn nooit verwijderd.

Gerelateerd: Verificatie en resultaten · Git-providers · Infrastructuur · Projecten · Wijzigingsvalidatie