Många företag som utvecklar en webb-applikation försäkrar regelbundet med olika testmetoder att de har en fungerande produkt. Ändå dröjer ofta leverans till kund och slutanvändare. Här beskrivs en lyckad implementation av hur leverans regelbundet kan ske till en molntjänst med ett så kallat blue green pattern som gör att applikationen kan uppdateras med minimal påverkan för slutanvändaren. Lösningen består i att webb-applikationenkan driftsättas i två olika miljöer och att användare alltid, via en html-sida som fungerar som en trafikriktare, skickas till den miljö som har den senaste versionen av applikationen. Genom ett script driftsätts den nya applikationen på den miljö som för tillfället inte har några besökare. När applikationen svarar på anrop ändrar scriptet så att slutanvändare i fortsättningen skickas till den nyligen uppdaterade miljön. Slutanvändare loggas regelbundet ut från applikationen så att de också regelbundet besöker trafikriktaren. Av de två testade molntjänsterna, Heroku och Amazon, är Amazon att föredra på grund av större möjligheter för manuell konfiguration.

With the advent of DevOps and its success stories, many large firms in the regulatory sector have begun to study more streamlined software deployment strategies. Traceability and change management is vital in these regulated organizations to keep track of when, why, and what was supplied to the production environment at what time. This thesis intends to provide a technique for one of the major banks in Sweden to deploy software using Azure DevOps pipelines while employing tracing and approving a deployment in an on-premises change management system. Since direct communication between the change management system and Azure DevOps is not possible, the decision was made to create an on-premises RFC handler and use Azure storage account queues to facilitate communication between pipelines searching for deployment grants and the on-premises change management system. To determine what value the RFC handler could provide the organization, interviews were conducted with several change management experts at the bank. One of the most notable conclusions from the interviews was that the RFC handler would likely reduce deployment time relative the old workflow. / Med tillkomsten av DevOps och dess framgångshistorier har många stora företag inom regleringssektorn börjat studera mer strömlinjeformade programvarudistributionsstrategier. Spårbarhet och förändringshantering är avgörande i dessa reglerade organisationer för att förklara när, varför och vad som levererades till produktionsmiljön vid vilken tidpunkt. Detta examensarbete avser att tillhandahålla en teknik för en av de stora bankerna i Sverige att distribuera programvara med hjälp av Azure DevOps-pipelines samtidigt som man använder spårning och godkännande av en driftsättning i ett lokalt förändringshanteringssystem. Eftersom direkt kommunikation mellan ändringshanteringssystemet och Azure DevOps inte är möjlig, togs beslutet att skapa RFC handler och använda Azure Storage-kontoköer för att underlätta kommunikationen mellan pipelines som söker efter driftsättningsgodkännande och den lokala förändringshanteringen. För att avgöra vilket värde RFC handler skulle ge organisationen, genomfördes intervjuer med flera experter på förändringshantering inom banken. En av de viktigaste slutsatserna från intervjuerna var att RFC handler kommer att minska driftsättningstiden jämfört med tidigare arbetsflöde.

To create, update, or deploy a mobile application, a collection of hand-operated works must be satisfied. In this project, regardless of the mobile application's code and its core functionalities, which can be an e-book, an application, or even a mobile game, we will study how to automate, visualize and simplify the following manual procedures: 1.Create a remote Git repository for the mobile application. 2.Constructing or altering the mobile application's configuration or graphical contents. 3.Push all changes to the remote Git repository. 4.Deploy or distribute the mobile application from its Git repository after each push. / För att skapa, uppdatera eller distribuera en mobilapplikation måste en samling handstyrda verk uppfyllas. I detta projekt, oavsett mobilapplikationens kod och dess kärnfunktioner, som kan vara en e-bok, en applikation eller till och med ett mobilspel, kommer vi att studera hur man automatiserar, visualiserar och förenklar följande manuella procedurer: 1. Skapa ett avlägset Git -arkiv för mobilapplikationen. 2.Konstruera eller ändra mobilapplikationens konfiguration eller grafiska innehåll. 3.Push alla ändringar i det externa Git -arkivet. 4. Distribuera mobilappen från sitt Git -arkiv efter varje ändring.

Saab want to examine Hardware In the Loop method as a concept, and how an infrastructure of Hardware In the Loop would look like. Hardware In the Loop is based upon continuously testing hardware, which is simulated. The software Saab wants to use for the Hardware In the Loop method is Jenkins, which is a Continuous Integration, and Continuous Delivery tool. To simulate the hardware, they want to examine the use of an Application Programming Interface between a Raspberry Pi, and the programming language Robot Framework. The reason Saab wants this examined, is because they believe that this method can improve the rate of testing, the quality of the tests, and thereby the quality of their products.The theory behind Hardware In the Loop, Continuous Integration, and Continuous Delivery will be explained in this thesis. The Hardware In the Loop method was implemented upon the Continuous Integration and Continuous Delivery tool Jenkins. An Application Programming Interface between the General Purpose Input/Output pins on a Raspberry Pi and Robot Framework, was developed. With these implementations done, the Hardware In the Loop method was successfully integrated, where a Raspberry Pi was used to simulate the hardware. / Saab vill undersöka metoden Hardware In the Loop som ett koncept, dessutom hur en infrastruktur av Hardware In the Loop skulle se ut. Hardware In the Loop baseras på att kontinuerligt testa hårdvara som är simulerad. Mjukvaran Saab vill använda sig av för Hardware In the Loop metoden är Jenkins, vilket är ett Continuous Integration och Continuous Delivery verktyg. För attsimulera hårdvaran vill Saab undersöka användningen av ett Application Programming Interface mellan en Raspberry Pi och programmeringsspråket Robot Framework. Anledning till att Saab vill undersöka allt det här, är för att de tror att det kan förbättra frekvensen av testning och kvaliteten av testning, vilket skulle leda till en förbättring av deras produkter. Teorin bakom Hardware In the Loop, Continuous Integration och Continuous Delivery kommer att förklaras i den här rapporten. Hardware In the Loop metoden blev implementerad med Continuous Integration och Continuous Delivery verktyget Jenkins. Ett Application Programming Interface mellan General Purpose Input/output pinnarna på en Raspberry Pi och Robot Framework blev utvecklat. Med de här implementationerna utförda, så blev Hardware Inthe Loop metoden slutligen integrerat, där Raspberry Pis användes för att simulera hårdvaran.