Du har ændret proxyadgangskoden. Et build har stadig den gamle kopi.

Den nye adgangskode virker i browseren. Projekt A bygger. Projekt B returnerer 407. Proxyen behøver ikke vælge tilfældigt: en af dens klienter fremviser måske stadig en gammel legitimationsoplysning.

Følg forbrugerne, ikke kun filerne

En projektspecifik egenskabsfil kan afvige fra brugerens standard. En miljøværdi kan fanges, når en launcher starter. En legitimationshjælper kan have sin egen lagrede post. Ingen af dem opdateres, blot fordi en anden applikation accepterede den nye adgangskode.

Lav en kort fortegnelse over de forbrugere, der faktisk bruger kontoen: interaktive værktøjer, byggetjenester, planlagte opgaver og applikationsklienter. Noter for hver, hvor værdien kommer fra, og hvornår den læses. Hold selve værdien uden for fortegnelsen.

Sammenlign den fejlende proces med den fungerende

Kontroller kontoen, arbejdsmappen, den valgte konfiguration og legitimationskilden. To projekter med lignende afhængigheder kan bruge forskellige lokale filer. En langvarig agent kan beholde input fra før rotationen, selv efter at en ny terminal ser det opdaterede miljø.

Brug en bevidst genstart eller dokumenteret konfigurationsopdatering kun der, hvor den klient har brug for det. Genstart af alt på én gang skjuler, hvilken forbruger der var forældet, og kan afbryde urelateret arbejde.

Forveksl ikke klientopdatering med tilbagekaldelse

Opdatering af klienter og gørelse af gamle legitimationsoplysninger ubrugelige er separate handlinger. En proxy kan have godkendelsescache, og en etableret forbindelse kan have en anden livscyklus end adgangskodefilen. Følg operatørens tilbagekaldelsespolitik i stedet for at antage, at en enkelt vellykket anmodning beviser, at det gamle kontomateriale er forsvundet.

Gør forbrugerlisten til en del af ændringen ved næste rotation. Et vellykket resultat er, at hver tilsigtet klient bruger sin tilsigtede kilde og konto, ikke blot at adgangskodedialogen lukkes på én arbejdsstation.