Google Cloud annoncerede den 4. november en ny måde at styre versioner af Compute Engine API på. Virksomheder kan vælge en datomærket udgave, når deres systemer kommunikerer med Googles cloudinfrastruktur. Nyheden giver en god anledning til at få overblik over de integrationer, som virksomhedens daglige arbejde afhænger af.
Hvad har Google annonceret?
Ifølge Googles officielle meddelelse er API-versionering med dato nu generelt tilgængelig for Compute Engine. Den første stabile udgave hedder 2026-09-01. En valgt stabil version fastholder den beskrevne grænseflade, så tekniske ændringer kan vurderes, før virksomheden vælger en nyere version.
Den eksisterende /v1 API understøttes fortsat og er standard, når en datoversion ikke angives. Nyheden gælder Compute Engine. For virksomhedens øvrige forbindelser skal den ansvarlige undersøge den enkelte leverandørs regler. Googles versionsvejledning beskriver valget for direkte API-kald, klientbiblioteker og værktøjer.
Begynd med de forbindelser, der betyder mest
En integration er forbindelsen, som lader to systemer udveksle oplysninger eller udføre en opgave. Det kan eksempelvis være en forbindelse mellem webshop og lager eller mellem en formular og et internt system. Eksemplerne er generelle og skal tilpasses virksomhedens faktiske løsning.
Vores råd er at lave en kort oversigt med systemernes navne, formålet med forbindelsen og en ansvarlig kontakt. Tilføj den API-version og den udgave af integrationskoden, som faktisk er i brug, hvis de kan fastslås. Skriv ukendt, hvor oplysningerne mangler, og aftal, hvem der undersøger dem.
Aftal, hvordan ændringer bliver opdaget
Find den relevante leverandørs dokumentation og meddelelser om ændringer. Aftal, hvem der læser dem, vurderer betydningen og følger op. En varslet ændring bør kobles til en konkret forbindelse i oversigten, så virksomheden ved, hvilken arbejdsgang der kan blive berørt.
Noter en eventuel frist sammen med kilden og tidspunktet for kontrollen. Hvis leverandøren tilbyder både stabile udgaver og prøveversioner, bør valget være tydeligt dokumenteret. Den teknisk ansvarlige skal kunne forklare, hvilken udgave løsningen anvender, og hvad et senere skift kræver.
Beskriv resultatet, før forbindelsen ændres
Vælg et afgrænset forløb, der viser, om integrationen gør det aftalte. For en lagerforbindelse kan det være en bestemt testvare og en forventet beholdning. Beskriv startpunkt, handling og forventet resultat på begge sider af forbindelsen. Brug et egnet testmiljø og testdata efter aftale.
Kontrollen bør også omfatte en situation, hvor forbindelsen ikke kan gennemføre opgaven. Aftal, hvordan fejlen bliver synlig, hvem der reagerer, og hvordan en uafsluttet opgave følges op. Den ansvarlige bør forklare, hvordan et nyt forsøg håndteres, så samme opgave ikke udføres flere gange ved en fejl.
Gem en kort status efter arbejdet
Noter den anvendte version, tidspunktet for ændringen og de faktisk observerede resultater. Beskriv åbne punkter og giv dem en ansvarlig. Hvis virksomheden endnu ikke har afprøvet hele forløbet, skal det fremgå tydeligt af status.
Oversigten og kontrolplanen er også nyttige ved senere leverandørskift eller videreudvikling. De gør det lettere for en ny teknisk kontakt at forstå, hvad der hænger sammen, og hvilke funktioner der skal bevares.
Hjælp til integration og automatisering
Hos KPdesign tilbyder vi egen softwareudvikling, API-integration og automatisering, herunder dokumentation og fejlhåndtering efter aftalt omfang. Vi kan hjælpe med at afklare forbindelserne og planlægge konkrete forbedringer. Arbejdet begynder med virksomhedens behov, de eksisterende systemer og en tydelig aftale om opgaven.