Healthchecks, der tjente sig selv hjem under en release

Tidligt på projektet byggede jeg healthchecks til en række legacy .NET-services på IIS: ikke endpoints, der altid svarer 200, men tjek, der faktisk åbner en databaseforbindelse og samles i en samlet status. Et par uger senere viste de sig at være det mest nyttige, jeg havde bygget.

Releasen

Kvartalsreleasen samlede omkring 600 timers arbejde. Servicevinduet lå om aftenen og varede to timer, med et fast tidspunkt for, hvornår vi skulle beslutte, om der skulle rulles tilbage. Samme morgen var build-pipelinen i stykker: NuGet restore fejlede, fordi en lokal pakkekilde i NuGet.config pegede på en sti, der ikke fandtes på build-agenten. Da det var løst, lagde jeg det nye build klar ved siden af de kørende sites, tog backup af de gamle services og opdaterede connection strings manuelt på hver server.

Hændelsen

Efter skiftet kunne flere services ikke nå deres databaser. En tastefejl i en connection string var blevet kopieret til mere end én server. I stedet for at behandle hele miljøet som nede viste healthchecks præcis, hvilke services på hvilke servere der fejlede, og rettelsen tog 20–30 minutter, godt inden for vinduet.

Hvad jeg tog med mig

• Et healthcheck er kun noget værd, hvis det tester den rigtige afhængighed.
• Manuelt redigeret konfiguration på tværs af servere er der, hvor releases går i stykker. Det er en stor del af grunden til, at den nye platforms pipelines i stedet ejer konfigurationen pr. miljø.