Het vaste leverpad

Iedere levering doorloopt dezelfde acht stappen, volledig geautomatiseerd: beschrijven, waarbij het team in het portaal de dienst kiest en de dienstbeschrijving invult; voorstellen, waarbij het portaal haar als wijzigingsvoorstel in de opslagplaats Afnemers zet; toetsen; goedkeuren; uitvoeren; de standaardinrichting toepassen; de status tonen; en ten slotte controleren en overdragen. Team en aanvrager volgen uit de centrale aanmelding, niet uit het formulier.

Per stap ligt vast wat automatisch loopt, waar een persoon beoordeelt, welke voorziening uitvoert en wanneer de stap gereed is. De uitvoering volgt een vaste volgorde: cluster met basisnetwerk, standaardinrichting, publicatie, database, verbindingen, identiteiten en geheimen; het team krijgt pas toegang na de controle.

Iedere uitvoeringsstap heeft een normtijd waarbinnen de levering de volgende status moet bereiken: 4 uur voor het aanmaken van het applicatiecluster en 1 uur voor iedere andere stap. Wachten op een beoordeling door een persoon telt niet mee. Na overschrijding wordt de levering ‘Onvolledig’.

Per dienstsoort is er een leverwerkstroom in Ansible Automation Platform van de cel, met de samengevoegde vastlegging als invoer en goedkeuring. Iedere stap draait met de identiteit van haar deel en laat het onderdeel maken door de voorziening die het bepaalt; het netwerkpad loopt via de draaiboeken van netwerkbeheer.

De uitvoerende voorzieningen halen voor alle stappen dezelfde goedgekeurde vastlegging uit het versiebeheer. Iedere voorziening verzorgt één deel, met een eigen technische identiteit en alleen de rechten voor dat deel; de leverwerkstroom krijgt per stap een eigen identiteit met een toegangsbewijs van ten hoogste 15 minuten uit het geheimenbeheer, zonder account in de toegangsvoorziening.

Iedere levering heeft een uniek kenmerk: de naam van haar tak, levering/<kenmerk>. Het portaal kent het toe; bij rechtstreeks indienen kiest het team het en controleert de toetsing de uniciteit. Ieder onderdeel draagt dienstnaam en kenmerk als label of eigenschap, zodat een herhaalde stap alleen maakt wat ontbreekt en niets dubbel.

Een levering heeft deze statussen, elk met een volgende actor.

De leverstatus staat als statusvermeldingen per stap bij het voorstel en de samengevoegde vastlegging in de opslagplaats Afnemers: stap, status, verantwoordelijke en tijdstip. Voorstel, statusvermeldingen en verslagen vormen samen het leverdossier.

Mislukt een stap of overschrijdt zij de normtijd, dan zet de leverwerkstroom de levering op ‘Onvolledig’, met de mislukte stap, de oorzaak en de verantwoordelijke, en meldt zij dat aan platformbeheer. Na herstel van de oorzaak hervat een nieuwe uitvoering met hetzelfde kenmerk vanaf die stap, zonder dubbele onderdelen; de onvolledige dienst krijgt intussen geen toegang en geen gereedmelding.

Een handmatige stap mag alleen tijdelijk, met een eigenaar en een einddatum. Zij heeft een eigen statusvermelding in de leverstatus en telt mee in de maatstaven; voor standaardvarianten is de norm nul handmatige stappen.

Een stap is pas gereed als het onderdeel werkt. Er volgt geen oplevering zonder melding van het vlootbeheer dat de standaardinrichting op het cluster voldoet, tenzij een goedgekeurde uitzondering met einddatum is vastgelegd; anders blijft de levering ‘Onvolledig’.

‘Opgeleverd’ volgt pas op een geslaagde proef langs het gebruikerspad met de eigen applicatie-identiteit van de toepassing en een toegangscontrole voor team en buitenstaander. De proef toont bijvoorbeeld dat de toepassing kan opslaan en toegestane brongegevens kan lezen, maar niet naar die bron kan schrijven. Iedere latere wijziging van de beschrijving vraagt een nieuwe proef.

De toegangscontrole bij het overdragen gebruikt geen aanmelding: met een autorisatievraag aan de API van het applicatiecluster (SubjectAccessReview) stelt de leverwerkstroom vast dat de teamgroep de rechten van haar profiel heeft en een groep buiten het team geen.