Azure DevOps Server is de on-premises versie van Azure DevOps Services (vroeger Team Foundation Server genaamd), die vooral door bedrijven gekozen wordt die hun data binnen het eigen netwerk willen houden, of als ze gebruik willen maken van SQL Server reporting services die geïntegreerd zijn met de data van Azure DevOps.
Voor de installatie en gebruik van Azure DevOps Server, zijn er enkele handige tips, tricks en good practices die goed om weten zijn en goed in gebruik.
- Azure DevOps Server heeft, net zoals zijn voorgangers (TFS 2018, TFS 2017,…) een service account nodig om onder te draaien. Deze kan je aangeven bij het installatieproces. Het is echter wel zéér belangrijk dat je voor dit installatieproces niet deze account gebruikt, maar een andere account.
Ook belangrijk is dat de gebruikte service account de “Log on as a service”-permissions heeft. Het is een best practice dat deze account een Active-directory-account is, die gebruikt kan worden als impersonation account om de achterliggende SQL Server-database te gebruiken. Op deze manier krijgen de gebruikers zelf geen rechtstreekse toegang tot de Azure DevOps-databases.
Wat betreft de account die gebruik maakt van de SQL Server reporting-services (SSRS): deze is best ook een Active Directory-account en moet de “Allow log on locally”-permission hebben - Om de gebruikers te managen in Azure DevOps Server, zijn er telkens een aantal groepen voorzien waar leden aan toegekend kunnen worden, zoals o.a. contributors en project administrators.
Het kan zeer handig zijn om hier telkens een Active Directory-groep aan te koppelen (als member) en de gebruikers die moeten toegevoegd worden via deze Active Directory-groep te beheren: zo wordt het beheer van gebruikers op één plaats gehouden en moet er minder tijd besteed worden aan het onderhoud van de security: als een persoon bijkomt of vertrekt, is dit zeer eenvoudig te beheren via Active Directory. - Voeg een “TFS Admin” project toe in je project collection: hiermee kan je gemakkelijk een aantal dingen monitoren op je server:
- Het sturen van alerts bij het wijzigen/aanmaken van workitems. Je kan bijvoorbeeld binnen dit project op een regelmatige tijdstip (bv. elke maandagochtend) een test uitvoeren (of rechtstreeks testen als er mensen zouden problemen hebben bij het ontvangen van alerts).
- Definieer hier ook een aantal buildscripts die op zicht geen grote builds creëren, maar laat deze naar de verschillende build agents toegaan. Schedule deze op een regelmatig tijdstip, zodat je snel kan controleren of een build controller of build agent onbeschikbaar is.
Het toewijzen van een agent kan je doen door bij het buildscript onder de options bij “Demands” een Agent.Name te definiëren:
- Soms is een Project manager iets te overijverig en verwijdert een workitem iets te voorbarig. In de backlog is er echter een recycle bin voorzien, van waaruit je verwijderde items terug kan restoren naar de backlog. Je kan hier ook de verwijderde items permanent leegmaken.
- Bij het maken van buildscripts, kan je bij het maken van de scripts enkele – logisch bij elkaar horende – taken groeperen in een Task Group, welke je ook kan hergebruiken in andere buildscripts. Enig nadeel is wel dat Task Groups beheerd worden op project-niveau en dus niet kunnen hergebruikt worden over verschillende projecten binnen de project collection.
- Kijk de Retention policies van je build goed na, zodat de drop folders tijdig leeggemaakt worden: als er geen plaats meer is op de schijf waar de drop folder op staat, kunnen de builds vrij snel in de soep draaien. Bovendien is het handig om de builds automatisch op te schonen: oude builds (waarvan er al een aantal opnieuw hebben gelopen) hebben meestal nog weinig nut en maken het overzicht van de gelopen builds onoverzichtelijk. Bovendien nemen deze ook veel plaats in op de build controllers.
- Soms zijn er custom buildsteps die je nodig hebt, die niet out-of-the-box bestaan en op maat van klant gemaakt dienen te worden: dan kan je zelfs je buildsteps voorzien. Je kan dit doen een powershell-script te maken (dat je toevoegt als buildstep). Hierbij kan je een filepath opgeven op je buildcontroller, maar je kan ook een volledig inline-script schrijven. Je kan ook een script schrijven in powershell en zelf toevoegen als custom build step: hoe je dit aanpakt, kan je lezen op deze blogpost: https://blog.devmatter.com/custom-build-tasks-in-vso/. Met een powershell-script kan je ook een eigen .net-library aanspreken!