This thesis applies energy measurements to the domain of continuous integration (CI) and continuous delivery (CD) pipelines. The goal is to conduct transparent and fine-granular energy measurements of these pipelines, increasing awareness and allowing optimizations regarding their energy efficiency. CI and CD automate processes like compilation, running tests, and code analysis tools and can improve the software quality and developer experience and enable more frequent releases. Initially, the applicability of existing energy measurement approaches for these tasks is analyzed. Afterward, a generic framework consisting of a pipeline run analyzer, a resource consumption collector, and an energy calculator is proposed. A representative implementation for a state-of-the-art infrastructure is devised to demonstrate its functionality, enabling the collection, analysis, and interpretation of data from real-world examples. Finally, it is examined whether this data aligns with the theoretical considerations and can be used to optimize the pipelines. The overall goal is to contribute to the sustainability of DevOps processes and therefore counteract the disastrous consequences of unrestrained climate change. / Denna avhandling tillämpar energimätningar på området kontinuerlig integration (CI) och kontinuerlig leverans (CD). Målet är att genomföra transparenta och finkorniga energimätningar av dessa pipelines, vilket ökar medvetenheten och möjliggör optimeringar av deras energieffektivitet. CI och CD automatiserar processer som kompilering, testkörning och kodanalysverktyg och kan förbättra programvarukvaliteten och utvecklarens upplevelse samt möjliggöra tätare lanseringar. Inledningsvis analyseras tillämpligheten av befintliga metoder för energimätning för dessa uppgifter. Därefter föreslås ett generiskt ramverk som består av en analysator för pipelinekörning, en insamlare av resursförbrukning och en energikalkylator. För att demonstrera dess funktionalitet utarbetas en representativ implementering för en modern infrastruktur som möjliggör insamling, analys och tolkning av data från verkliga exempel. Slutligen undersöks om dessa uppgifter stämmer överens med de teoretiska övervägandena och kan användas för att optimera rörledningarna. Det övergripande målet är att bidra till hållbarheten i DevOpsprocesser och därmed motverka de katastrofala konsekvenserna av ohämmade klimatförändringar.

Microservice is an architectural design that promises a more elastic system where a microservice can be allocated compute power according to demand. Through the separation of components, each microservice can have its own hardware or cloud setup. As a result, the code becomes more maintainable through smaller repositories. Development and Operations (DevOps) is a set of best practices to improve software development and operations. Two important components of DevOps are Continuous Integration (CI) and Continuous Delivery (CD). CI is a set of practices that aims to automate testing and increase development velocity through continuously integrate code changes. While CD aims to streamline the deployment process of the code, enabling a shorter time to market. When migrating a monolithic codebase towards a microservice architecture, one faces a lot of decisions that can have a deep impact on the whole organization. From a CI/CD perspective, some decisions can impact the efficiency of the CI/CD pipeline. This thesis investigated how Indicio’s CI/CD pipeline changed when going from a monolith towards a microservice architecture. It documents the decisions Indicio made along the way and investigates how the CI buildtime and CD deploy time were affected. The result showed that Indicio’s decision to keep the new microservice in the same repository added 44% to the median buildtime. The time increase was acceptable since it only resulted in an average of 20 seconds increase in median buildtime. Although, the decision to separate the CD into two independent CD pipelines, one for the old monolith and one for the new microservice didn’t affect the deploy time by any considerate margin. The new microservice was deployed to Microsoft Azure to be able to take advantage of the elastic compute power. The big advantage from a CD perspective by utilizing Azure was the blue-green deployment method resulting in zero downtime. / Mikrotjänster är en arkitektdesign som lovar ett mer flexibelt system där en mikrotjänst kan tilldelas den nödvändiga datakraften. Genom att dela upp komponenter kan varje mikrotjänst ha sin egen hårdvara eller molninställning. Det resulterar i mindre stycken kod som är lättare att underhålla. Development and Operations (DevOps) är en samling av bästa praxis för att förbättra mjukvaruutveckling och operationer. Två viktiga komponenter av DevOps är Continuous Integration (CI) och Continuous Delivery (CD). CI är en samling av verktyg som försöker automatisera tester och öka utvecklingshastigheten genom att kontinuerligt integrera kodändringar. Medan syftet med CD är att effektivisera distribution av kod, vilket möjliggör en kortare tid till marknaden. När man migrerar en monolitiskt kodbas mot en mikrotjänst arkitektur står man inför flera val som kan påverka hela organisationen. Utifrån ett CI/CD perspektiv så kan dessa val påverka effektiviteten av CI/CD processen. Denna uppsats undersöker hur Indicios CI/CD process förändras när dem går mot en mikrotjänstarkitektur från en monolit. Uppsatsen dokumenterar de val Indicio har gjort under migrationen och hur det påverkar CI byggnadstid och CD distribution tid. Resultaten visar att Indicios beslut att behålla den nya mikrotjänsten i samma förvar resulterade i 44% ökad medianbyggtid. Tidsökningen var acceptabel då det endast innebar en snittökning på 20 sekunder. Fastän Indicio beslutade att separera på CD processen till två nya, en för den nya mikrotjänsten och en för den nya monoliten så påverkades inte distribueringstiden särskilt mycket. Den nya mikrotjänsten distribuerades på Microsoft Azure för att kunna utnyttja den elastiska datakraften. Den stora fördelen från ett CD perspektiv med Azure var att man kunde utnyttja blågrön distributionsmetod, vilket gjorde att driftstopp tiden försvann.

Recent supply chain attacks on a larger scale in combination with a growing adoption of the set of automated software development and deployment practices commonly referred to as ’DevOps’, made us interested in the security of the underlying infrastructure supporting these practices. If a malicious commit in a piece of software can expose internal systems and networks of all users of said software to vulnerabilities, questions regarding trust and repudiation becomes central, in the platforms themselves as much as in each digitally signed software update version. GitLab is a DevOps platform that offer an open-source (Community Edition, (CE)) of their application, for anyone to use and even modify to better suit their own needs. Anyone who chooses to use GitLab will as a result thereof also choose to put the trust others put in them in the hands of the open-source community around GitLab. Since any vulnerability in GitLab could affect users or organizations that use software developed and shipped with the help of GitLab, we wanted to try finding one for ourselves. We employed well-known techniques from the ethical hacker playbook (threat modeling, risk assessment) in order to identify candidates for attack vectors, and found GitLab’s GraphQL Application Programming Interface (API) to be a great starting point since it not only was but still is under development, but that the body of previous work seemed to suggest inconsistencies in the business logic layer underneath. Our main findings are: at least two instances where we were able to gain unauthorized access to data within our self-hosted GitLab instance. We also found that a new feature could be used for privilege escalation under certain conditions. We were then able to conclude that open source software and a prolific bug bounty program does not guarantee the security of GitLab, in and of themselves. All findings have been reported to GitLab through their bug bounty program. / Under det senaste decenniet har mjukvaruutvecklande organisationer visat ett tilltagande intresse för de metoder för automatiserade utvecklings- och distributionstekniker som vanligen brukar samlas under termen DevOps. Den trenden taget i kombination med det senaste årets större försörjningskedjeattacker (SolarWinds, Microsoft Exchange Server) gjorde att vi började intressera oss för säkerheten kring den infrastruktur som möjliggör dessa metoder. Om en utvecklare med ont uppsåt lyckas få in en ändring i en mjukvara innan den digitalt signeras och distribueras till mjukvarans användare, kan denne lyckas utnyttja svagheten för att få tillgång till eller modifiera de system och nätverk mjukvaran körs på. Frågor om tillit och avsändarintegritet kring vem som står bakom ett kodavsnitt blir i förlängningen därav oerhört viktiga. GitLab är en DevOps-plattform som erbjuds i en version med öppen källkod, vilken alla kan använda och rent av anpassa för sina egna behov. Att använda GitLab innebär dock att man lämpar över den tillit och säkerhet ens användare lagt i ens händer på de som utvecklar plattformen. Eftersom en enskild sårbarhet i GitLab potentiellt kan påverka ett stort antal aktörer som aldrig själva använt GitLab gjorde att vi ville se efter om även vi kunde hitta en sådan sårbarhet. Vi använde oss av välbekanta metoderi etisk hackning-kretsar (hotmodellering) genom vilka vi identifierade GitLabs GraphQL-Application Programming Interface (API) som en potentiellt gynnsam attackvektor. Detta både eftersom API:t fortsatt är under utveckling och att tidigare forskning antytt logiska brister i applikations-lagret. Arbetet ledde fram till ett par fynd. Vi fick åtkomst till otillåten data vid två tillfällen. Med hjälp av en ny funktionalitet kunde vi under vissa omständigheter utöka en användares behörighet. Vi kunde därmed dra slutsatsen att öppen källkod och ett väletablerat bug bounty-program inte i sig är några garantier för säker mjukvara. Samtliga fynd har rapporterats till GitLab via deras bug bounty-program på plattformen HackerOne.

Embedded devices in the Internet of Things world mostly only have one connection channel, and smaller consumer devices usually communicate with other devices only over a wireless connection. Developers constantly upgrade the Internet of Things devices with Android phones connecting to the devices. If developers break the only possible connection, the devices become unusable, because the devices do not have a wired port. This study explores the options to test the wireless upgrade channel during the development workflow and implements a continuous integration pipeline for the devices. Literature in the field of continuous integration focuses primarily on Cloud and Web-related workloads. The few papers targeting embedded devices with continuous integration are primarily theoretical and discuss the possible advantages of utilizing continuous integration but do not implement a prototype. Our contribution creates a continuous integration pipeline for embedded devices, which automatically tests the update channel between Android phones and embedded devices over Bluetooth on every commit. To verify the correct functionality, we use previously faulty commits from the git history and run the pipeline with the buggy commit to check the pipeline’s functionality. The pipeline evaluation shows that the time improvements for our update validation process with continuous integration is insignificantly faster for the upgrade procedure. However, developers are required to test a combination of versions and here, the automated testing setup excels over the human testing method by being scalable. Furthermore, automated testing enables easier identification of the root cause for an issue and a faster delivery time of fixes. While the pipeline works reliably, we identify issues in adopting the continuous integration process by the developers. Additionally, the analysis summarizes essential tools and features to run the pipeline with an overview of required elements for similar projects. The work was created in cooperation with Wrlds Creations AB and we used the devices actively developed by the company. / Inbäddade enheter i Internet of Things världen har oftast bara en kommunikationskanal, och mindre konsumentenheter kommunicerar vanligtvis via en trådlös Bluetooth-anslutning. Utvecklarna uppgraderar ständigt enheterna med Android-telefoner som ansluts till enheterna. Om utvecklarna bryter den enda möjliga kommunikationskanalen blir enheterna obrukbara. Denna studien undersöks alternativen för att testa den trådlösa uppgraderingskanalen under utvecklingsarbetsflödet och implementeras en continuous integration pipeline för enheterna. Litteraturen inom området continuous integration fokuserar primärt på Cloud och webbrelaterade arbetsbelastningar. De få artiklar som är inriktade på inbäddade enheter med continuous integration är främst teoretiska och diskuterar de möjliga fördelarna med att använda continuous integration, men implementerar inte någon prototyp. Vårt bidrag skapar en continuous integration pipeline för inbäddade enheter, som automatiskt testar uppdateringskanalen mellan Android-telefoner och inbäddade enheter via Bluetooth vid varje commit. För att verifiera den korrekta funktionaliteten använder vi tidigare felaktiga commits från git-historiken och körde pipelinen med den felaktiga commit för att kontrollera funktionaliteten av pipelinen. Utvärderingen av pipelinen visar att tidsförbättringarna för valideringskanalen är obetydligt snabbare för hela uppgraderingsproceduren. Utvecklarna krävs dock testa en kombination av versioner och här är den automatiska testuppställningen bättre än den mänskliga testmetoden eftersom den är skalbar. Automatiserad testning gör det dessutom lättare att identifiera grundorsaken till ett problem och att leverera korrigeringar snabbare. Även om pipelinen fungerar på ett tillförlitligt sätt identifierar vi problem när det gäller utvecklarnas antagande av continuous integration-processen. Dessutom sammanfattas i analysen de viktigaste verktygen och funktionerna för att driva pipelinen med en översikt över vad som krävs för liknande projekt. Arbetet skapades i samarbete med Wrlds Creations AB och använde de enheter som företaget aktivt utvecklat.

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.

This thesis explores applying DevOps practices to mitigate knowledge loss in project-based environments. In the context of high developer turnover, the study aims to implement a standardised DevOps workflow using automation and knowledge management. The research questions of the thesis are answered by following a method consisting of interviews, requirements gathering, implementation of a DevOps workflow focusing on knowledge management practices and evaluation using a DevOps maturity model. The study finds that explicit knowledge practices, including issue tracking, code reviews, and knowledge repositories, are complemented by developers’ tacit knowledge. Additional practices including testing standards, coding standards, and containerisation also contribute to knowledge retention. Integrating these practices into a DevOps workflow involves automation, tool integration, and continuous workflow through a CI/CD pipeline. The research evaluates the organisation’s initial maturity level at level 1 ("Initial") in technology and process areas. However, implementing the proposed DevOps workflow increases the maturity level to level 3 ("Defined"). This, in turn, indicates that knowledge management practices can be integrated into a DevOps workflow to mitigate knowledge loss further.

Цель работы – внедрение необходимых практик DevOps в компании «Технопарк-Автоматизация» и снижение затрат на используемое программное обеспечение. Объектом исследования является управление жизненным циклом создаваемого программного обеспечения. Методы исследования: анализ существующих DevOps-практик, анализ и сравнение различных DevOps-инструментов, операционных систем и web-серверов. Результат работы: разработана DevOps-инфраструктура проектов компании, проведена оценка экономической выгоды от реализации данной работы. Магистерская диссертация состоит из введения, 4 глав и заключения, изложенных на 70 страницах, а также библиографического списка. / The goal of the work is to implement the necessary DevOps practices in the Technopark-Automation company and reduce the costs of the software used. The object of the study is the life cycle management of created software. Research methods: analysis of existing DevOps practices, analysis and comparison of various DevOps tools, operating systems and web servers. Result of the work: a DevOps infrastructure for the company’s projects was developed, and the economic benefits from the implementation of this work were assessed. The master's thesis consists of an introduction, 4 chapters and a conclusion, presented on 70 pages, as well as a bibliography.

DevOps is an ill-defined but trending approach to software development. Many companies are seduced by its promises of reduced costs and risks. DevOps life-cycle is often represented as a continuous everything, but very little is said about how to get the ball rolling. This report examines how DevOps definitions are represented in the initiation of Agile projects. By interviewing developers and mapping their project initiation activities in a DevOps context, a set of guidelines was formed. Continuous Integration and Deployment were found most prominent DevOps attributes from a developer’s perspective. The operational responsibility is skewed toward maintenance, with low interest in further adjustment.

Many organizations have difficulty adopting advanced software development practices. Some software development project managers in large organizations are not aligned with the relationship between performance expectancy, effort expectancy, social influence, and facilitating conditions, as moderated by experience, with intent to adopt the DevOps practice of continuous delivery. The purpose of this study was to examine the statistical relationships between the independent variables—performance expectancy, effort expectancy, social influence, and facilitating conditions, as moderated by experience—and the dependent variable of behavioral intent to adopt a continuous delivery system. Venkatesh, Morris, Davis, and Davis's unified theory of acceptance and use of technology provided the theoretical framework. A stepwise multiple linear regression analysis was performed on survey data from 85 technical project managers affiliated with LinkedIn project management groups. The analysis reflected that only performance expectancy was significant in predicting intent to adopt continuous delivery. The findings may contribute to social change by providing project managers with the information they need to support organizational change, collaboration, and facilitation. The knowledge gained may additionally help organizations develop operational efficiency, competitive advantage, and generate higher value to their clients and society.

Manual deploys and testing of code can be both time-consuming and error-prone. Many repetitive manual steps can lead to critical tests or necessary configuration being forgotten or being skipped due time-constraints resulting in software that doesn’t work as intended when deployed to production. The purpose of this report is to examine whether continuous delivery(CD) could lead to any positive effects and if there are any obstacles for CD in an Episerver project at Sigma ITC. The study was done by implementing a CD pipeline for a project similar to a real project at Sigma then letting the developers work with it and interviewing them about their current workflow, their attitude towards the different steps involved and if they saw any problems with CD for their project. Even if the developers, in general, where positive to CD they had some reservations about it in their current projects. The main obstacle the developers saw where the time/cost which would affect the customer and also some uncertainty around the complexity in testing Episerver. The results show that there could be positive effects of CD even if the project type is not optimal for reaping all the CD benefits, it all depends on people involved seeing a value in testing and the questions around testing in Episerver are straightened out.