E.3 Teori
G.5.4 Vår användning av Azure DevOps
Vår grupp använde sig under projektets gång endast av Azure Repos. Där hade vi vårt kod- förvar och vi använde oss av tjänsten Pull requests i Azure Repos för att mergea och göra kodgranskning. Kodgranskningen gick ut på att andra medlemmar i gruppen kollade ige- nom ändringarna som gjorts och godkänner eller nekar ändringarna innan det får läggas till i kodförvaret.
I Azure DevOps har tidigare utvecklare av ARCH använt sig av en mer tjänst än vår grupp gjorde. Detta är tjänsten Azure Boards. I Azure Boards har tidigare utvecklare av ARCH an- vänt Boards för att skriva user-stories.
G.6
Diskussion
Här nedan diskuteras det som redovisades i resultat delen. Det finns också en diskussion angående rapportens metod.
G.6.1
Metod
Metoden till denna rapport var en litteraturstudie. Informationen från denna litteraturstudie användes sedan som referens vid jämförelse till hur vi använde Azure DevOps. De akademis- ka källorna som använts i litteraturstudien valdes eftersom de förklarade olika begrepp med deras generella användning. Något undantag på källa har gjorts där källan i helhet hand- lar om ett fördjupat ämne irrelevant till denna rapport. I dessa fall har endast information använts som gäller utanför det fördjupade ämnet.
En sak att notera med litteraturstudien är att den gjorts utefter generella mjukvaruut- vecklingsprojekt och inte nödvändigtvis efter omständigheterna runt ARCH. Detta gör att diskussionen kommer bli mer av en jämförelse av hur man kan göra mot hur vi gjorde. Det kommer inte heller garanteras att de slutsatser som dras kommer vara rätt för andra och framtida projekt.
G.7. Slutsatser
G.6.2
Resultat
Under projektets gång använde vi oss endast av Azure Repos. Valet att använda oss av Repos kom ganska naturligt då det var där den befintliga kodbasen fanns när vi tog över projektet. Vi bestämde oss att använda tjänsten Pull requests för att både underlätta merging och hål- la hög kvalité på koden. Detta gjorde delvis att koden behövde vara kommenterad och att chansen för möjliga krockar med befintlig kod hittas lättare.
Azure Boards Azure Boards användes inte under projektets gång och anledningen till det är att vi bestämde oss i tidigt skede av projektet att vi skulle använda oss av tjänsten Trello. Vi använde Trello för att fördela arbetsuppgifter, planera och ha en backlog på vad som behövs göras.
Azure Pipelines Pipelines används för att sätta upp de automatiska tester och byggningar som behövs för Continuous Integration och Continuous Delivery. Anledningen till att vi inte använt oss av CI och CD och därmed inte Azure Pipelines har att göra med att vi har arbetat så mycket på separata branches. Då vi har arbetat på feature-branches som endast har mergats in i master-branch när hela arbetsuppgiften i feature-branchen är klar, så har det inte kontinuerligt pushats till master-branchen och poängen att bygga och testa koden automatiskt har till stor del försvunnit. Vår lösningsmetod för att behålla den agila kommunikationen mellan oss och kunden, som skapas av CI och CD, var att veckovis demonstrera de olika arbetsuppgifterna vi har arbetat på och visa dem var för sig. Med hjälp av CD hade det möjliggjorts för kunden att ha en version av produkten tillgänglig som de kan testa och ge feedback på utanför de schemalagda demonstrationerna vi hade.
Azure Test Plans Vi har inte arbetat något med Test plans i Azure på grund av att vi redan hade skrivit en testplan som ett dokument. Vi kan skriva manuella tester utav det krav vi har i testplans dokumentet men det är inget vi har gjort än så länge. Något som hade passat att göra när ARCH börjar närma sig en färdig produkt är att ha användartester genom Azure Test plans, där användare kan lämna feedback angående användarvän- ligheten av produkten.
Azure Artifacts Artifacts är inget som var rört när vi tog över projektet och inget som vi har använt oss av. När vi började vidareutveckla ARCH hade vi redan tillgång till en paketfil som hanterar paket. Denna fil gör samma sak som filen som man kan skapa i Artifacts, hanterar publika och privata paketen i projektet. Därmed lade vi ingen tid i att ersätta den befintliga paketfilen med en ny.
G.7
Slutsatser
Här nedan dras slutsatser för var och en av frågeställningarna utifrån resultatet och diskus- sionen.
1. Går det att säkerställa att en projektgrupp arbetar effektivt i Azure DevOps?
En sak som alla projekt inom Azure DevOps påverkas positivt av är ett agilt arbetssätt. Det är det första steget mot ett effektivare och mer lönsamt arbete i Azure DevOps. Som marknadsfört innehåller Azure DevOps tjänster för hela utvecklingsprocessen från planering till färdig produkt. Det krävs en viss kunskap om Azure DevOps för att veta vilka tjänster som finns och vad för delar av utvecklingsprocessen de kan användas för. Därmed tror jag det hade hjälpt att säkerställa ett bättre arbete genom att någon i projektgruppen är erfaren eller läser på om Azure DevOps tjänster.
För att sedan arbeta så effektivt som möjligt i Azure DevOps borde man försöka utnyttja de olika tjänsterna som finns tillgängliga men alla projekt ser olika ut och har olika
G.7. Slutsatser
förutsättningar. Detta leder till att vissa verktyg i tjänsten av olika anledningar ersätts med externa tjänster som löser samma problem. Att försöka centrera projektet och ha alla delar på Azure tror jag hade hjälpt med organisering och därmed effektivitet. Något som jag tror är betydligt viktigare är att fylla ut med Azure DevOps tjänster ifall de aspekter som tjänsten fyller annars hade gåtts miste om. På så sätt utnyttjar man Azure DevOps för att skapa en bättre kommunikation mellan utvecklare och kund på bästa sätt. Så tror jag man som projektgrupp kan säkerställa att man arbetar effektivt i Azure DevOps.
2. Vilka olika verktyg används för versionshantering i Azure DevOps?
Allt angående versionshantering sker i Azure Repos. I Azure Repos kan man använda flera olika versionshanteringsverktyg såsom Git och Microsofts egna TFVC. Det finns tillgång till kodförrådet, dess fulla historik och verktyget Pull requests. Pull requests förenklar merging och är användbart för att hålla standarden på koden hög. Då andra medlemmar kollar igenom pull requesten så får man åsikten av en utomstående som ökar chansen att man hittar potentiella problem som kan skapas av mergen.
3. Vilka delar av Azure DevOps använde sig gruppen av under projektet?
Under projektet använde sig endast gruppen av Azure Repos och de olika verktygen som finns inom Repos. Repos innehåller kod förrådet i mjukvaru projektet och det är där man arbetar med versionshantering. Jag tror det är flertal anledningar till varför vi inte använde andra tjänster i Azure utöver Repos. Första anledningen är att ingen av medlemmarna i gruppen var speciellt erfarna i Azure DevOps när vi började vida- reutveckla ARCH och visste därmed inte vilka tjänster som fanns tillgängliga. Detta ledde oss till att välja andra tjänster som vi visste om sedan tidigare som handskas med samma problem som kan lösas i Azure DevOps.
Som poängterats tidigare använde vi oss inte av CI eller CD under vårt projekt då det inte kändes passande för den arbetsmetod vi valde. Hade projektet pågått en längre tid än ungefär de fyra till fem månaderna som vi har arbetat med projektet så hade vi eventuellt kunnat flytta in de tjänsterna i Azure som för tillfället ligger utanför. Då Azure DevOps täcker utvecklingsprocessen från start till slut så är vissa av tjänsterna i Azure inte relevanta i det stadie vi är i produktutvecklingen. Med andra ord kan fler av Azures tjänster nyttjas när utvecklingen av produkten har kommit längre. Ett exempel på detta är Azure Test plans. Vissa tester kan göras vid en senare fas av utvecklingen som vi inte har hunnit komma till ännu.