Application lifecycle management voor Azure application development.
We hebben een belofte waar te maken als IT specialisten. Iedere keer wanneer er een nieuwe technologie beschikbaar komt hebben we de business voorspeld dat zij sneller en beter nieuwe functionaliteiten tot hun beschikking zouden krijgen, als wij het maar zouden gaan gebruiken. Zo ook met de komst van de Cloud. Wiki omschrijft Cloud Computing veelbelovend als:
“A configurable computing resources that can be rapidly provisioned and released with minimal management effort”
Zie dat maar eens waar te maken naar de business als ontwikkel team, een hele uitdaging.
Snel beschikbaar maken van nieuwe functionaliteit met een minimale inspanning, of zoals Salesforce.com het simpel verteld in de verkoopfolder: upgrades worden automatisch uitgevoerd. Maar hoe doe je dat, hoe zorg je als IT afdeling voor dat functionaliteit snel, automatisch met minimale inspanning geleverd wordt aan de eindgebruiker? Als we kijken naar de traditionele cyclus bij de ontwikkeling van een applicatie dan moet er nogal wat gebeuren. Naast de wensen verzamelen, moet de code geïmplementeerd worden, geïntegreerd met andere code, getest, uitgerold en daarna beheerd worden. Aardig wat stappen die afzonderlijk soms al weken kosten.
Application Lifecycle Management 4 Azure
Application Lifecycle Management zorgt dat de rollen betrokken bij de ontwikkeling van een software systeem samenwerken, technische hulpmiddelen als Visual Studio ondersteunen en stimuleren deze samenwerking. Want om onze belofte waar te maken, die van continue en snel nieuwe functionaliteit leveren, moeten we de stappen die nodig zijn om een systeem op te leveren optimaliseren. Dit kan alleen als we efficiënter worden, samenwerken.
In de volgende 4 scenario’s wordt besproken hoe deze samenwerking [ALM] met gebruik van technische hulpmiddelen bijdraagt om de belofte aan de business over Cloud Computing waar te maken.
Scenario 1: ontwikkelaar alleen
In het eerste scenario zit iedereen in zijn eigen silo, de verschillende rollen werken alleen en er is geen samenwerking.
Vanuit Visual Studio is er ondersteuning voor de ontwikkelaar.
1. De ontwikkelaar implementeert de Cloud applicatie en schrijft unit tests.
2. Hoogstwaarschijnlijk wordt er gebruik gemaakt van een source repository (TFS) met een daily build waar de unit tests uitgevoerd wordt en de code geïntegreerd wordt met bestaande code.
3. Voor het uitrollen heeft Visual Studio de mogelijkheid om een package (met configuratie) te maken van de Azure solution. Dit package kan vervolgens in de Azure portal geüpload worden. Zo simpel als rechter muisknop en publish. (zie screenshot)
Een feature van Visual Studio wat de ontwikkelaar in dit scenario goed van pas kan komen is Intellitrace. Het kan zomaar voorkomen, dat de Cloud applicatie het niet doet na uitrol. Configuratie instellingen zijn vergeten om te zetten van lokaal naar de Cloud, of assemblies welke nodig zijn voor de applicatie worden niet mee gepubliceerd, de standaard "works on the devfabric, fails in the cloud"problemen. Met behulp van Intellitrace kan informatie worden opgevraagd over hoe de applicatie zich gedraagt in de Cloud (op Azure).
Intellitrace is een feature die gebruikt moet worden in het ‘developer only’ scenario. Ondanks, of dankzij de snelle, eenvoudige, handmatige manier van deployen met Visual Studio treden er vaak problemen op door vergeten of foute instellingen. Met Intellitrace zijn deze te achterhalen, bovenal omdat de testers pas hierna hun werk gaan doen en je ze niet wil opzadelen met foute deployments.
Dit is niet het ideale scenario om onze belofte waar te maken. We kunnen snel onze applicaties in de cloud zetten, maar veel is handmatig, testers zitten op de ontwikkelaars te wachten en de business weer op de testers. Hoewel de mogelijkheden van Visual Studio handig zijn is er nog handmatig foutgevoelig werk en je weet nog niets over de kwaliteit. Dit kan efficiënter.
Scenario 2: ontwikkelaar en tester samen
De Visual Studio suite of Application Lifecycle Management tools heeft meer als alleen maar ondersteuning voor de ontwikkelaar, zo is er ook de ondersteuning voor de tester. Met de ondersteuning van Microsoft Test Manager is de tester verbonden met de ontwikkelaar. Verbonden doordat ze taken kunnen delen, wat duidelijk efficiëntie voordelen biedt. En verbonden op het gebied van code en test runs middels de Daily Build, wat de eenheid en kwaliteit ten goede komt.
1. Tijdens de ontwikkeling van de Cloud Applicatie staat de ontwikkelaar niet meer alleen. Hij krijgt nu vroeg en snel feedback van de tester over de kwaliteit van zijn implementatie. Deze test namelijk de applicatie al in een vroeg stadium, gebruik makend van de Devfabric omgeving. Naast unit tests kunnen nu ook functionele tests al toetsen of aan de klant wensen voldaan is.
Een uitdaging bij deze manier van testen, voordat de applicatie daadwerkelijk op Azure draait, is dat de tester de beschikking moet hebben over de Devfabric. Deze is te vinden de Windows Azure SDK en hoeft niet noodzakelijk op een omgeving geïnstalleerd te worden welke ook Visual Studio heeft. Een Cloud applicatie is te starten en te testen vanuit een test omgeving met alleen de Devfabric (en IIS7) en een commandline statement, zie figuur onder. Op deze manier kan de tester zijn werk doen, in een vroeg stadium feedback geven over de kwaliteit van de Cloud applicatie en zonder dat er kosten worden gemaakt voor het gebruik van de Azure.
4. Een uitdaging bij het testen van Cloud applicaties is dat de omgeving op bepaalde momenten gerecycled wordt. Tijdens dit recyclen van een Azure instant wordt er een volledige nieuwe omgeving neergezet met de applicatie er op. Dit heeft geen impact op de uitvoering van de test cases, maar wel op het opvoeren van bevindingen. Bijvoorbeeld wanneer een ontwikkelaar een bevinding wil oplossen en hij heeft daar voor de logs nodig van de omgeving, is er een uitdaging. De omgeving waarop de test uitgevoerd is en de bevinding gevonden is, hoeft zeker niet dezelfde omgeving te zijn als de ontwikkelaar gebruikt om de bevinding op te lossen, hij kan alweer gerecycled zijn.
Een oplossing voor deze ‘uitdaging’ is het gebruik van de Data Diagnostic Adapters van Microsoft Test Manager. Data Diagnostic Adapters verzamelen informatie tijdens de uitvoer van een test cases en slaan deze informatie op bij de tests cases en bevinding. Dit helpt de ontwikkelaar natuurlijk enorm bij het analyseren en oplossen van de bevinding.
De standaard Data Diagnostic Adapters hebben niet de functionaliteit om log informatie te verzamelen van een Azure instantie. Om toch de mogelijkheid te hebben om log informatie vanaf Azure te krijgen dien je zelf een Data Diagnostic Adapter te maken. Gelukkig is dit vrij eenvoudig. Met een overerving van de DataCollector class uit Microsoft.VisualStudio.QualityTools.ExecutionCommon krijg je de events:
· SessionStart, Start of your test run
· SessionEnd, End of your test run
· TestCaseStart, Start of each test in the test run
· TestCaseEnd, End of each test in the test run
Door de ontwikkelaar samen te laten werken met de tester, kunnen ze veel voordelen van elkaar hebben. Rijke bevindingen rapportgage, snelle beschikbaarheid over te testen omgevingen en iets wat niet Cloud specifiek is maar wel een enorme toegevoegde waarde heeft is de test impact informatie vanuit de build voor testers, wat het hertesten een stuk efficiënter maakt. Al met al een vooruitgang ten opzichte van scenario 1 waar ieder nog in een silo zat, er kan nu snel op kwaliteit gestuurd worden.
Scenario 3: ontwikkelaar, tester en een automatische uitrol
Wanneer de tester snel en efficiënt kan testen, snel feedback geven over de kwaliteit van het systeem. Is de logische vervolgstap, het snel eenduidig en herhaalbaar beschikbaar stellen van de te testen omgeving, het automatische uitrollen van Cloud applicaties naar Azure.
Dat het eenvoudig is om Azure applicaties te deployen vanuit Visual Studio hebben we gelezen in het eerste scenario. Dat dit nog veel handmatig werk vergt en fout gevoelig is ook bekend, de "works on the devfabric, fails in the cloud” problemen zijn maar al te bekend.
Door een build in te richten die niet alleen test of de code aanpassing integreert en unit test succesvol zijn, maar ook de applicatie daadwerkelijk uitrolt zorg je voor een continu proces van waarde leveren, welke een stuk voorspelbaarder is dan wanneer je het handmatig uitvoert.
Een automatische deploy opzetten voor cloud applicaties is vrij eenvoudig. Er zijn verschillende API’s beschikbaar om een Azure package in Azure te krijgen, deze zijn zelfs nog vereenvoudigt door powershell scripts, de AzureCmdlets (http://wappowershell.codeplex.com/). Nu zijn deze scripts handig om de package in Azure te krijgen, maar ze zorgen er nog niet voor de Visual Studio solution omgezet wordt naar een Azure package en Azure configuration file. Om dit te realiseren kan er gebruik worden gemaakt van de in de Azure SDK te vinden commando CSPack. Om het in pakken met CSPack goed te laten verlopen is er wel nog wat commandline getype nodig. De voorbeelden op MSDN (zie onder) zijn aardig complex.
c:\samples\HelloWorld>cspack HelloWorld\ServiceDefinition.csdef /out:HelloWorld.csx /role:HelloWorld_WebRole;HelloWorld_WebRole /sites:HelloWorld_WebRole;Web;d:\HelloWorld_WebRole\HelloWorld_WebRole /copyOnly
Iedere aanpassing aan de Azure applicatie zal de commandline ook moeten worden aangepast. Een vervelend, handmatig en daardoor fout gevoelig klusje. Nu is het mooie dat Visual Studio zelf ook gebruik maakt van het CSPack commando om de solution te in te pakken als je de applicatie vanuit Visual Studio wil uitrollen. Gebruikmakende van deze Visual Studio functionaliteit (en logica om hem goed in te pakken) wordt het veel gemakkelijker om een automatische deploy in te regelen.
In de msbuild target file Microsoft,Cloudservice.targets wordt CSpack aangeroepen gebruikmakend van de variablen uit het Cloud project (zie screenshot). Door deze te hergebruiken in de CCProj met opvolgend de aanroep naar de AzureCmdLet (zie screenshot) kan de Azure solution automatisch gedeployed worden naar Azure tijdens de build. (zie onder voor de msbuild arguments)
Wel is aan te raden dat dit niet gebruikt wordt voor de Continous Intergration Build.
Meer informatie over geautomatiseerd deployen van Azure applications:
Scenario 4: … en geautomatiseerd testen
Testers en ontwikkelaars werken samen, er is vroegtijdig in het project sturing op kwaliteit. Het team kan herhaalbaar en continu de applicatie uitrollen. Allemaal fantastische stappen vooruit. Maar nu zitten we nog met een tijdrovende klus, die ons belemered om onze belofte waard te maken, we moeten iedere deployment steeds weer testen en hertesten. Duidelijke kandidaten voor automatiseering.
Vanuit Visual Studio is het eenvoudig om de testen van de testers te automatiseren. Al uitgevoerde tests kunnen middels CodedUI opgepakt worden in Visual Studio door de developer en gebruikt worden om C# (of VB.NET) te genereren welke de teststappen van de tester exact na lopen.
Wanneer alle belangrijke test cases van de testers op deze manier geautomatiseerd zijn, kunnen ze uitgevoerd worden tijdens de build. Tijdens de build na de deployment, of beter en goedkoper eerst voor de deployment op een soort test omgeving met de Azure emulator. In het tweede scenario staat beschreven hoe een test omgeving met de Azure SDK geïnstalleerd een Azure applicatie in de emulator kan hosten middels de uitvoer van de CSRun commandline. Dezelfde commandline kan gebruikt worden om tijdens het buildproces een test ‘emulator’ omgeving live te brengen voor het uitvoeren van de geautomatiseerde tests. De test resultaten worden vervolgens verzameld in het build rapport. Wat nog rest zijn de tests die uitgevoerd (al dan niet geautomatiseerd) moeten worden om te verifiëren of om de deployment op Azure goed is.
Conclusie
Genoeg mogelijkheden om onze belofte waar te maken, van het thuis/ zolderkamer scenario naar een full blown ALM omgeving met volledige technische ondersteuning. Continu leveren van waarde, een goed doel om naar toe te werken en Azure met Visual Studio maakt het zeker mogelijk.