Mooi, zo'n dag waarop de opdrachtgever verwacht dat ik thuisblijf!

Ik heb m'n eigen Team Foundation Server maar weer eens op orde gebracht.
Het is de source control- en buildserver voor m'n hobbyprojecten. Er staat nu zo'n tweeënhalf jaar aan code in, gemigreerd van TFS Express 2010 op m'n vorige server. Allereerst kwam ik erachter dat de backup er al zo'n vijf maanden uit lag.

Nu heb ik me de laatste tijd gelukkig enkel gefocust op wat nieuwe dingen leren, waardoor de uiteindelijke code veel minder waard is dan de ervaring, maar het zou toch sneu zijn als het kwijt zou raken.
De backup van m'n databases werkt met een
dumpscript in de taakplanner. Laatstgenoemde weigerde dus al enkele maanden dienst, vanwege een
voorwaarde die de taak blijkbaar steevast stopte:
"Stop if no longer idle". Vinkjes uit en de taak werkte weer.
Toen stonden er nog tachtig builds gequeued (
“Queue” is just “Q” followed by 4 silent letters.) voor een build controller die niet langer bestond. Handmatig verwijderen vanuit de Build Explorer in Visual Studio werkte niet, en na een soft-delete in de database (er is een deleted-kolom) was er nog meer stuk. Een hard delete zorgde daarentegen wel weer voor een heerlijk lege wachtrij.
Op dat moment kon ik mijn Continuous Integration-builds weer inschakelen, en warempel: het werkte bijna. Er misten nog wat packages in de private NuGet-cache-server die ik voor m'n builds gebruik. Die workflow moet nog wat gestreamlined worden. Het niet hoeven downloaden van packages versnelt het compileren behoorlijk, maar als ik nieuwe packages aan een project toevoeg, moet ik die ook op de server deponeren. Op zoek naar meer leesvoer... Ook wil ik nog af van een TfsBuild-specifieke .sln en .csproj, die ik nu nodig heb om de hint paths van de packages aan te passen naar de directorystructuur op de buildserver. Ook dat schijn je te kunnen transformeren, of te kunnen oplossen middels wat environment variables.
Sinds de eerste incarnatie van mijn TFS-server ben ik ook nog van internetprovider gewisseld, dus het leek me wel zo netjes om hun SMTP-server even te vervangen door die van mijn nieuwe ISP zodat alerts (check in, build failed/completed) weer in mijn mailbox belanden. Toen dát werkte, heb ik mijn nightly builds hersteld en nu ook eindelijk naar IIS laten deployen met een configuratie-transform. Nu staat er iedere nacht een verse site op de webserver, met z'n eigen, desgewenst schone database.
En toen waren de boot-partitie van m'n Ubuntu-VM's weer eens vol omdat er dertig oude kernels op staan... Het wordt echt tijd voor iets van Nagios/Check_MK op m'n thuisnetwerk om dit soort ongein proactief te detecteren, in plaats van wanneer iets niet werkt.
Hobbyen is leuk.