Teamet får det de behöver genom att ändra i en fil och öppna en PR. En ny namespace, en databas, en behörighetsgrupp, en DNS-record. Plattformsteamet granskar undantagen, resten går igenom på automatik.
Varför ADOPT
Det här är den billigaste self-servicen som finns, och den finns redan i verktygen du har. Ingen portal behöver byggas, ingen ny frontend behöver underhållas. Granskningen, historiken och möjligheten att backa ligger i git från början, vilket är samma sak revisionen kommer att fråga efter.
Det viktiga är inte PR-formatet i sig, utan att förfrågan blir kod. Ett Terraform- eller Kubernetes-manifest är ett kontrakt som går att validera automatiskt. En ticket är en önskan i fritext som en människa måste tolka.
Vad det kostar
Väntan flyttar från kön till reviewen om du inte automatiserar bedömningen. En PR som ligger två dagar för att en plattformsingenjör ska hinna titta är samma flaskhals i annan förpackning. Sätt ett mål: de vanliga ändringarna ska gå igenom utan mänsklig review, med policy och tester som grind, och bara undantagen ska landa på en människa.
Tröskeln finns också. Ett team som inte kan HCL skriver ingen PR, de skriver en ticket ändå. Mallar och exempel i repot är inte trevliga att ha, de är själva gränssnittet.
När det är fel val
När ändringen behöver ett mänskligt beslut varje gång, till exempel åtkomst till produktionsdata. Då är automatiken bara en fasad över ett godkännande, och det är ärligare att ha en synlig process.