1 open besluit1414 voorstellen

Onderwerp

Beoordelen en samenvoegen in versiebeheer

Versiebeheer is beschermd met ondertekende vastleggingen, een beschermde hoofdtak en twee beoordelaars naast de auteur. Binnen de vastgestelde varianten voegt alleen een samenvoegidentiteit automatisch samen; sjablonen en beleid nooit.

Nog niet bevestigd door een mens. Eigenaar: vdo89. Bron in de atlas

Domein
Volgt uit
Functies
Producten
Verwant

Wat het is

Versiebeheer is de enige bron van het leverpad: iedere aanvraag en iedere wijziging is een voorstel dat pas na samenvoegen wordt uitgevoerd. Dit onderwerp legt vast hoe versiebeheer is beschermd, wanneer een voorstel automatisch wordt samengevoegd, wie anders beoordeelt en hoe een team ook zonder portaal kan indienen.

Waarom zo

Een standaardaanvraag binnen de vooraf goedgekeurde varianten hoeft niet opnieuw door ieder beheerdomein te worden beoordeeld, als de controles slagen op precies die vastlegging. Een afwijking met nieuwe risico’s vraagt wel een oordeel van een ander dan de aanvrager. Omdat de takbeveiliging en de samenvoegidentiteit die regels afdwingen, gelden ze langs iedere ingang, ook als iemand het portaal omzeilt.

De termijnen voor signalen en opruimen en de keuze voor eigen beheer van Forgejo zijn een voorstel.

Uitspraken

1 vastgesteld10 voorstellen

Alle 10 voorstellen vaststellen

Beschermd versiebeheer

VoorstelRegel#

In alle opslagplaatsen, Forgejo voor het platform en GitLab voor toepassingen, zijn ondertekende vastleggingen verplicht en is de hoofdtak beschermd, met een eigenaarsbestand en zonder geforceerd overschrijven. De beschermingsregels van Forgejo staan als code in versiebeheer en worden via de API toegepast; rechten en beschermingsregels worden dagelijks met hun vastgelegde waarden vergeleken, en een afwijking wordt gemeld.

Toelichting

Een wijziging van beleid of inrichting buiten versiebeheer valt onder een detectieregel. De bouwpijplijn start alleen op een ondertekende vastlegging; zie het domein softwarelevering.

VoorstelRegel#

Iedere productiewijziging krijgt twee beoordelaars naast de auteur, zonder zelfgoedkeuring. Een standaardwijziging wordt alleen automatisch samengevoegd als vooraf goedgekeurde variant en na geslaagde geautomatiseerde controles op precies die vastlegging. Dezelfde regels gelden voor het portaal, de API en het rechtstreekse gebruik van versiebeheer; de takbeveiliging dwingt ze af.

Toelichting

Platformbeheer is eigenaar van deze regels. Voor de opslagplaatsen Platform en Beleid gelden extra beperkte rechten, omdat een wijziging daar alle clusters raakt.

VoorstelOntwerpbesluit#

Forgejo, het versiebeheer van het platform, is een opensourceproduct zonder leverancierscontract en valt onder eigen beheer: versies volgens het versiebeleid van het project, beveiligingsupdates binnen de termijnen van het SAK Patch Management en een onderhoudsplan met een contactroute naar het project. De functies waarop het leverpad steunt, zijn voorwaarden bij de acceptatie, elk met een terugvaloptie.

Toelichting

Die functies zijn statusvermeldingen per stap; verplichte controles met de werkstroomdefinitie van de hoofdtak, zonder geheimen voor code uit een voorstel; samenvoegen alleen door een aangewezen identiteit en bij aansluiting op de hoofdtak; en ondertekening van vastleggingen via de API. De terugvaloptie: wat Forgejo niet zelf afdwingt, controleert de samenvoegidentiteit vóór het samenvoegen (aansluiting op de hoofdtak, ongewijzigde werkstroomdefinitie en goedkeuringen); de leverwerkstroom zet de status dan als opmerking bij het voorstel, en de eigen sjabloonstap ondertekent haar vastleggingen met een eigen sleutel uit het geheimenbeheer. De jaarlijkse herziening van de baseline beoordeelt of een ondersteuningscontract nodig is. De inrichting van Forgejo als basisdienst staat in het domein basisdiensten.

Samenvoegen

VoorstelRegel#

Voor dienstbeschrijvingen in Afnemers en de daaruit gegenereerde clusterdefinities is een voorstel binnen de varianten de vooraf goedgekeurde standaardwijziging: het wordt automatisch samengevoegd na geslaagde beleidstoetsen op precies die vastlegging, en in Afnemers alleen als het aansluit op de hoofdtak. Een voorstel buiten de varianten gaat naar de beoordelaars.

Toelichting

Automatisch samenvoegen blijft zo binnen vooraf goedgekeurde grenzen. De instellingen van versiebeheer en de acceptatieproef Afgewezen aanvraag tonen het aan.

VoorstelRegel#

Sjablonen en beleid worden nooit automatisch samengevoegd. Een wijziging in de opslagplaats Catalogus, zoals een dienstsjabloon, het pijplijnsjabloon of het register van toegelaten software, en een wijziging van toelatingsbeleid of vertrouwensbasis vragen altijd twee beoordelaars naast de auteur; bij de Catalogus is de productverantwoordelijke een van hen.

Toelichting

Een sjabloon bepaalt iedere latere levering, en toelatingsbeleid en vertrouwensbasis bepalen welke software op alle clusters mag starten. De beschermingsregels en de melding bij een wijziging buiten versiebeheer controleren het.

VoorstelOntwerpbesluit#

Alleen een samenvoegidentiteit voegt in Afnemers samen, na alle verplichte controles, bij aansluiting op de hoofdtak en met de werkstroomdefinitie van de hoofdtak; zij kan de takbeveiliging niet wijzigen. De verplichte controle ‘beoordeling’ slaagt binnen de varianten direct, daarbuiten pas na twee goedkeuringen naast de auteur.

Toelichting

Zo dwingt de takbeveiliging de beoordelingsregels af. Het token van het portaal kan niet samenvoegen; een negatieve proef toont dat aan.

VoorstelRegel#

Alleen een teameigenaar laat, langs iedere ingang, een voorstel voor zijn team samenvoegen; de rol geldt op het moment van toetsen. De aanvrager is de auteur van een vastlegging van het portaal, of de ondertekenaar bij rechtstreeks indienen; zijn rol volgt uit de teams van het versiebeheer.

Toelichting

De bevoegdheid volgt uit de rol. Een negatieve proef per ingang toont aan dat een gebruiker zonder de rol teameigenaar geen aanvraag voor een team kan doen, ook niet rechtstreeks via de API van het portaal of van het versiebeheer.

Beoordeling door een persoon

VoorstelRegel#

Valt een voorstel buiten de varianten, zoals bij een andere netwerkvariant, dan beoordelen twee beoordelaars naast de auteur het: één van platformbeheer en één van het geraakte beheerdomein. Een verbinding buiten de toegestane stromen beoordeelt netwerkbeheer. Het besluit staat met motivering bij het voorstel, dat daarna opnieuw wordt getoetst; een goedkeuring geldt alleen voor die verbinding of dat voorstel.

Toelichting

Zelfservice geeft snelheid binnen vooraf afgesproken grenzen, maar geen mogelijkheid om zelf een nieuwe risicovolle uitzondering goed te keuren. De instemming van de eigenaar van de bron blijft vereist. Voor een verbinding in beoordeling geldt bij netwerkbeheer een termijn van 2 werkdagen; zie het domein netwerk.

VoorstelOntwerpbesluit#

Een voorstel buiten de varianten krijgt, net als een verbinding buiten de toegestane stromen, de status ‘In beoordeling’ zolang een persoon aan zet is. De beoordelaars zijn dan de volgende actor.

Toelichting

Zo is de wachttijd op een persoon meetbaar.

VoorstelWaarde#

Wacht een voorstel 2 werkdagen op een persoon, dan herinnert het versiebeheer de beoordelende rol; na 5 werkdagen krijgt de productverantwoordelijke een melding. Takken zonder voorstel worden dagelijks verwijderd, en afgewezen voorstellen zonder nieuwe vastlegging na 30 dagen gesloten.

Toelichting

De signalen sluiten aan op de beoordelingstermijn van netwerkbeheer. Zo raakt geen aanvraag vergeten.

Eén pad langs iedere ingang

VastgesteldOntwerpbesluit#

Een team kan zijn dienstbeschrijving ook rechtstreeks in het versiebeheer als wijzigingsvoorstel indienen, als terugval bij uitval van het portaal of om zijn levering vanuit software aan te sturen. Toetsing, beoordeling en uitvoering verlopen dan precies als bij een aanvraag via het portaal, die ook als wijzigingsvoorstel in het versiebeheer begint; het portaal is geen voorwaarde.

Toelichting

Portaal, API van het portaal en rechtstreeks gebruik van het versiebeheer leiden alle drie tot hetzelfde voorstel in Afnemers. De digitale assistent en de API-catalogus komen later als ingangen bij.

Verwijzen hiernaar

Onderwerpen 4