In deel één van deze blog serie hebben we gezien dat veel organisaties gebruiken maken van Team Foundation Server (TFS) voor o.a. source control en de ondersteuning van hun Agile werkproces. Een alternatief voor TFS is Visual Studio Team Services. In dit deel kijken we naar de mogelijkheden die Visual Studio Team Services biedt. We focussen ons daarbij op de onderwerpen die een relatie hebben met DevOps.

Bepaalde onderdelen in dit blog zijn inmiddels enigzins verouderd. Via de button onderaan deze pagina kunt u een volledig geactualiseerde versie van de blogserie downloaden.

Wat is Visual Studio Team Services?

Visual Studio Team Services (VSTS) is niet de online versie van de Visual Studio ontwikkelomgeving (IDE). We gebruiken VSTS dus niet voor het schrijven van bijvoorbeeld C# code. VSTS is de online versie van Team Foundation Server (TFS). Net als TFS integreert VSTS naadloos met de Visual Studio IDE en Microsoft Azure.

Naast features die we al kennen uit TFS zoals: source control en workitem management, biedt VSTS een aantal extra mogelijkheden die het product zeer interessant maken voor DevOps. Denk hierbij bijvoorbeeld aan ‘Build Service’, ‘Load Testing Service’, ‘Application Insights’, ‘Release Management Online’ en ‘ Continuous Deployment naar Azure’. Hoewel een aantal van deze diensten ook beschikbaar zijn in TFS zullen we later in de blog zien dat het feit dat deze diensten online beschikbaar zijn een aantal voordelen heeft.

Waarom Visual Studio Team Services?

Veel organisaties gebruiken al TFS. In de basis zijn TFS en VSTS gelijk. Ze hebben dezelfde code base, en worden beide door hetzelfde team ontwikkeld. Waarom dan toch kiezen voor VSTS?

Geen beheer, altijd up-to-date, meer flexibiliteit!

Eén van de meest voor de hand liggende voordelen van VSTS ligt in het feit dat we geen beheer hebben over VSTS. Microsoft stelt VSTS als dienst beschikbaar en is daarmee verantwoordelijk voor de correcte werking en beschikbaarheid van deze dienst. Aangezien we VSTS afnemen als dienst, weten we zeker dat we altijd gebruik maken van de meest up-to-date versie.

Dit in tegenstelling tot een eigen on-premise TFS installatie waarbij we zelf verantwoordelijk zijn voor de onderliggende hardware, de back-ups, het installeren van updates, en het uitvoeren van migraties naar nieuwe versies. Organisaties die nu al gebruik maken van TFS kennen het vast wel... Op enig moment wordt gekozen voor een bepaalde versie van TFS die vervolgens binnen de organisatie uitgerold wordt. Vanaf dat moment wordt er vaak meerdere jaren gebruik gemaakt van die versie van TFS. Een eventuele upgrade van TFS in de periode daarna wordt vooraf gegaan door vergaderingen, migratieplannen, budgetaanvragen en beslismomenten. Niet echt Agile…!

Het wegvallen van het beheer op onze eigen TFS omgeving is niet het enige voordeel dat VSTS te bieden heeft. VSTS biedt ons ook extra flexibiliteit in de manier waarop we als organisatie werken. De wereld om ons heen staat niet stil en de manier waarop we softwareontwikkelingstrajecten uitvoeren veranderd nog zeer regelmatig. Dit wordt veroorzaakt door een veranderende markt, projectervaringen, de producten en/of frameworks die we gebruiken en de continue veranderende mogelijkheden van platformen, zoals Azure, waarop we onze software deployen.

Microsoft hanteert voor VSTS een release cycle van drie weken. Dit betekent dat er iedere drie weken nieuwe features worden toegevoegd aan VSTS die dan ook per direct beschikbaar zijn voor gebruikers.
Aangezien Microsoft zelf ook DevOps toepast, gebruikt Microsoft de monitoring informatie die ze verzamelt over VSTS en de feedback die ze ontvangt van gebruikers actief bij het verfijnen van de backlog voor VSTS. Hierdoor is Microsoft in staat om VSTS naadloos aan te laten sluiten aan de sterk veranderende omgeving waarbinnen IT organisaties opereren. Het feit dat Microsoft zelf ook (groot) gebruiker is van VSTS versterkt dit effect alleen maar. Microsoft ondervindt zelf dagelijks waar de verbeterpunten liggen van VSTS.

De meeste van de nieuwe mogelijkheden van VSTS zullen uiteindelijk ook in TFS beschikbaar komen. Echter, dit gebeurt pas veel later. Daarnaast zit er vaak nog een aanzienlijke tijd tussen het beschikbaar komen van een nieuwe versie van TFS en het moment dat deze versie ook daadwerkelijk beschikbaar is binnen de organisatie. VSTS biedt ons de flexibiliteit om direct gebruik te maken van de beschikbare mogelijkheden.

Beschikbaarheid versus toegankelijkheid

Bij het maken van een keuze tussen TFS of VSTS zijn we geneigd een beslissing te nemen op basis van de beschikbare mogelijkheden binnen één van beide de varianten. Een veel gehoorde opmerking is dat VSTS geen mogelijkheid biedt om wijzigingen door te voeren in de process templates, er geen datawarehouse is en dat de integratie met SharePoint ontbreekt. Op het eerste gezicht zijn dit valide redenen om niet te kiezen voor VSTS.

Echter, als we ons realiseren dat we over drie weken de beschikking hebben over een ‘nieuwe’ versie van VSTS, waarin een ‘ontbrekende’ functionaliteit misschien ineens wel beschikbaar is dan kunnen we ons afvragen of we onze keuze tussen TFS en VSTS moeten laten afhangen van beschikbaarheid van mogelijkheden.

Het is misschien veel verstandiger om een keuze te maken op basis van toegankelijkheid van mogelijkheden. Wat bedoel ik hiermee? TFS biedt de mogelijkheid om ‘builds’ in te richten en ‘load tests’ uit te voeren. Echter, om dit in te regelen, hebben we wel een build server en test servers nodig. Deze zijn niet altijd per direct beschikbaar voor het Development team. Op dat moment lopen we het gevaar dat Development besluit om ‘dan maar even geen build in te richten’ en de performance test uit te stellen tot latere iteratie. Is dat wat we willen?

In VSTS is de ‘Build Service’ en de ‘Load Testing Service’ direct toegankelijk. Beide zijn met een paar muisklikken in te richten. Binnen enkele minuten maken we m.b.v. VSTS en Azure een load test voor onze applicatie die enkele miljoenen gebruikt simuleert!

Kortgezegd, toegankelijkheid stimuleert adoptie en maakt het voor Development en Operations een stuk eenvoudiger om zogenaamde ‘best practices’ te integreren in hun werkwijze.

Via Continuous Delivery en Continuous Monitoring naar Continuous Learning

Met behulp van DevOps streven we naar een zo kort mogelijke ‘time-to-market’ van een oplevering van onze software. Dit alles met behoud van een hoge kwaliteit en voorspelbaarheid.
In ons streven naar een organisatie waarin we DevOps optimaal ingeregeld hebben, zullen we een aantal aspecten onder de knie moeten krijgen. Microsoft onderkend een aantal stadia in de weg naar DevOps.

Allereerst zullen we Continuous Delivery moeten implementeren, vervolgens regelen we Continuous Monitoring in om uiteindelijk de vruchten te plukken van Continuous Learning. Klinkt goed…, maar wat betekent dit allemaal precies en op welke manier kan VSTS ons hierbij ondersteunen?

Continuous Delivery

Als we Agile goed toepassen, levert Development een continue stroom op aan opleveringen die ieder een stuk toegevoegde waarde opleveren voor de klant. Continuous Delivery houdt zich bezig met het snel en voorspelbaar opleveren van deze bits in productie. We hebben hierbij een aantal uitdagingen.

Allereerst dienen we beschikking te hebben over ontwikkel- en testomgevingen. Vaak vereisen deze omgevingen diverse instellingen, tools en frameworks. Allemaal verschillende configuraties die gedurende het softwareontwikkelingstraject ook nog eens voortdurend wijzigen. Het niet eenvoudig om de deze verschillende omgevingen onderling consistent te houden. Veel van de problemen die optreden tijdens het testen of bij de in productie name worden veroorzaakt door afwijkingen in configuraties of omgevingen. Wie kent ‘m niet…de uitspraak: ‘It works on my machine!?!’

Daarnaast hebben we een release pipeline nodig. Afhankelijk van het product dat we opleveren kan deze variëren van een eenvoudig proces waarbij we een build, na een korte controle in een testomgeving, direct door zetten naar productie tot een ingewikkelde workflow met verschillende acties, controle slagen en ‘approval’ momenten.

Hoe gaan VSTS en Azure ons hierbij ondersteunen? Een voorbeeld…

Met de komst van de laatste Azure SDK (of de Visual Studio 2015 preview) hebben we binnen Visual Studio de beschikking gekregen over een zogenaamd ‘Cloud Deployment Project’. Dit project stelt ons in staat om onze deployment omgeving en alle bijbehorende configuratie vast te leggen als broncode. Een wizard inspecteert onze Visual Studio Solution en genereert op basis daarvan een beschrijving van de omgeving waarop de applicatie gedeployd kan worden. In deze beschrijving wordt bijvoorbeeld opgenomen op hoeveel virtual machines de applicatie moet worden uitgerold, welke versie van het .NET Framework beschikbaar moet zijn en op welke manier de applicatie in IIS geconfigureerd moet worden. Daarnaast wordt er onderscheid gemaakt tussen de verschillende omgevingen zoals een ontwikkel-, een test- en een productie omgeving. Dit alles wordt opgeslagen in een leesbaar JSON formaat. We kunnen dus zelf heel eenvoudig aanpassingen doorvoeren. Het spreekt voor zich dat dit alles op te nemen is in source control waar door we versiebeheer hebben over onze omgevingsconfiguratie.

Op basis van de hierboven genoemde beschrijvingen van de verschillende omgevingen, kan Development vanuit Visual Studio een deploy doen naar één of meerdere omgevingen. Hierbij wordt de omgeving automatisch compleet ingericht zoals het beschreven is, inclusief de benodigde virtual machines, (Azure) websites, etc. We introduceren hiermee herhaalbaarheid in het deployment proces en elimineren de problemen die ontstaan door inconsistenties tussen verschillende omgevingen.

Uiteraard is het in de praktijk niet altijd gewenst dat Development, vanuit Visual Studio, een oplevering direct doorzet naar productie. Het is dan ook goed te weten dat VSTS ook de ‘Release Management Online’ (RMO) dienst biedt. Met behulp van RMO krijgen we meer controle op de release pipeline. We kunnen bijvoorbeeld een workflow definiëren waarbij we bepaalde approval momenten introduceren. Hiermee kunnen we voorkomen we dat een release niet eerder naar de volgende omgeving doorgezet kan worden zonder dat er goedkeuring is van een bepaald persoon. De beschrijvingen van onze deployment omgevingen (output van Cloud Deploymen Project) kan ook als input dienen voor RMO.

Continous Monitoring en Continuous Learning

Laten we er voor nu vanuit gaan dat we Continuous Delivery op orde hebben en dat we onze software regelmatig en op een gecontroleerde wijze naar productie kunnen krijgen. Maar dan? Zijn we dan klaar? In veel organisaties lijkt het daar wel op! Zolang de gebruikers niet aan de telefoon hangen is Operations tevreden en start Development direct na de oplevering een volgende sprint waarin ze de volgende items van de backlog oppakken. Beide afdelingen hebben geen enkel idee of de gebruikers tevreden zijn met de oplevering en of de nieuwe features überhaupt wel gebruikt worden.

Stel…we hebben de beschikking over uitgebreide monitoring informatie die Operations antwoord geeft op relevante vragen zoals: is de applicatie beschikbaar?, treden er onverwachte exceptions op? en wat is de performance van de applicatie op dit moment? Met behulp van dergelijke informatie kan Operations pro actief inspelen op eventuele productie problemen. In samenwerking met Development kunnen de productie problemen wellicht zelfs nog voordat gebruikers aan de telefoon hangen worden opgelost.

Het wordt nog interessanter als we ook informatie hebben over de manier waarop gebruikers de applicatie gebruiken. We kunnen dan namelijk de vraag beantwoorden: zijn gebruikers succesvol met de applicatie? Het wordt voor de Business direct inzichtelijk welke onderdelen wel of niet gebruikt worden, hoe ze gebruikt worden en of de aanpassingen die zijn doorgevoerd in de oplevering het gewenste effect hebben.

Application Insights

Dit is nou precies waar Application Insights om de hoek komt kijken. Application Insights is een dienst van VSTS die ‘out of the box’ de hierboven genoemde (en meer!) informatie verzameld en beschikbaar stelt. Het is toepasbaar voor applicaties die gehost worden in Azure maar ook voor applicaties die on-premise beschikbaar worden gesteld. Het feit dat de informatie vanuit Application Insights volledig geïntegreerd is in de Azure (preview) portal maakt het geheel extra krachtig. De portal biedt ons een totale DevOps view voor de applicaties waarvoor we verantwoordelijk zijn. Het geeft ons inzicht in de status van het Azure platform, het toont een inschatting van de gemaakte kosten en biedt een schat aan informatie voor Operations, Development en uiteindelijk ook de Business.

Als we als organisatie in staat zijn om ons Continuous Delivery proces op orde te krijgen dan kunnen we snel en gecontroleerd opleveren naar productie. Combineren we dat met de Continuous Monitoring mogelijkheden van Application Insights dan optimaliseren we daarmee niet alleen onze eigen IT organisatie maar bieden we ook toegevoegde waarde voor de Business. Nieuwe ideeën kunnen snel beschikbaar worden gesteld aan de klant. Op basis van het gedrag van de klant kan de Business toetsen in hoeverre het idee wel of niet levensvatbaar is en indien nodig kan de Business direct haar strategie aanpassen. Kortom we vormen een zelf lerende organisatie die proactief kan inspelen op een markt die continue in beweging is!

Samenvattend

In deze blog hebben we gezien wat VSTS is en hebben we een aantal redenen besproken waarom het verstandig kan zijn om gebruik te maken van VSTS. Daarnaast hebben we op hoog niveau gezien dat VSTS kan helpen bij het implementeren van DevOps in onze organisatie. In een volgende post kijken we in wat meer detail naar een aantal van de mogelijkheden van VSTS en zien we bijvoorbeeld op welke manier we VSTS kunnen inzetten om onze applicatie automatisch naar Azure te deployen.

Wordt vervolgd…

Edward Bakker is een Microsoft Azure MVP en werkt als solutions architect bij Delta-N. Hij focust zich op oplossingen gebaseerd op het Microsoft Azure platform.