AbstractThe increasing amount of data available from software systems has given a unique opportunity for software development organizations to make use of it in decision-making. There are several types of data such as bug reports, website interaction information, product usage extent or test results coming into software-intensive companies and there is a perceived lack of structure associated with the data. The data is mostly scattered and not in an organized form to be utilized further. The data, if analyzed in an effective way, can be useful for many purposes, especially in decision-making. The decisions can be on the level of business or on the level of product execution. In this paper, through a literature review, an interview study and a qualitative analysis we categorize different types data that organizations nowadays collect. Based on the categorization we order the different types of decisions that are generally taken in a software development process cycle. Combining the two we create a model to explain a recommended process of handling the surge of data and making effective use of it. The model is a tool to help both practitioners and academicians who want to have a clearer understanding of which type of data can best be used for which type of decisions. An outline of how further research can be conducted in the area is also highlighted.

The digitisation of the financial markets has led to IT becoming a vitalpart of financial institutions. The principles and practices of ContinuousDeployment (CD) are utilised to increase innovation through flexibilityand swiftness at many IT companies. This thesis explores the encounterof CD and the financial industry through participant observations andsemi-structured interviews with developers.We find in our study that practitioners in the financial industry usepractices that are part of a CD process. The specialisation of the systemsthat is evident in the industry could be considered a barrier for theadoption of a CD process. However, improved transparency that maycome as a result of CD is well aligned with the demands that are evidentin the industry. Furthermore, the requirement for code reviews mightimpact the ability to attain a continuous process, as it must be a manual.

The goals with continuous delivery are to reduce the risk, cost, and time of releasing software to the stakeholders and the users. It is a process which can result in reliable releases and reducing errors in the software. Furthermore, there are some best practices to follow when conducting the continuous delivery process, involving version control, and build tools. There are however some obstacles and challenges for organizations when moving to continuous delivery. For example, complex environments, organizational problems, and lack of automated test cases. This master thesis investigates continuous delivery through a literature review, a multiple-case study, and fieldwork. The result can either be used by software engineers and organizations who are new to the continuous delivery concept. Or the result can be used by more experienced software engineers to gain more knowledge about existing obstacles and for further research.

Kubernetes is a fast emerging technological platform for developing and operating modern IT applications. The capacity to deploy new apps and change old ones at a faster rate with less chance of error is one of the key value proposition of the Kubernetes platform. A continuous integration and continuous deployment (CI/CD) pipeline is a crucial component of the technology. Such pipelines compile all updated code and do specific tests and may then automatically deploy the produced code artifacts to a running system. There is a thriving ecosystem of CI/CD tools. Tools can also be divided into two types: integrated and standalone. Integrated tools will be utilized for both pipeline phases, CI and CD. The standalone tools will be used just for one of the processes, which needs the usage of two independent programs to build up the pipeline. Some tools predate Kubernetes and may be converted to operate on Kubernetes, while others are new and designed specifically for usage with Kubernetes clusters. CD systems are classified as push-style (artifacts from outside the cluster are pushed into the cluster) or pull-style (CD tool running inside the cluster pulling built artifacts into the cluster). Pull- and push-style pipelines will have an impact on how cluster credentials are managed and if they ever need to leave the cluster. This thesis investigates the deployment time, fault tolerance, and access security of pipelines. Using a simple microservices application, a testing setup is created to measure the metrics of the pipelines. Drone, Argo Workflows, ArgoCD, and GoCD are the tools compared in this study. These tools are coupled to form various pipelines. The pipeline using Kubernetes-specific tools, Argo Workflows and ArgoCD, is the fastest, the pipeline with GoCD is somewhat slower, and the Drone pipeline is the slowest. The pipeline that used Argo Workflows and ArgoCD could also withstand failures. Theother pipelines that used Drone and GoCD were unable to recover and timed out. Pull pipelines handles the Kubernetes access differently to push pipelines as the Kubernetes cluster credentials does not have to leave the cluster, whereas push pipelines needs the cluster credentials in the external environment where the CD tool is running.

Znížená efektivita spôsobená robením repetitívnych a manuálnych prác je častým problémom v IT. Vývojári často testujú a nasadzujú svoj software manuálne, čo je nielen náročné na čas, nezáživné a náchylné k chybám. Táto práca sa snaží v rámci jedného DevOps tímu, vyriešiť tento problém pomocou zjednotenia vývojárskych a testovacích nástrojov, a pomocou aplikovania pricípov CI a CD do produkčného prostredia. Zároveň sa sústredí na software využívajúci Python, Jenkins a kontajnery. Hlavnými použitými nástrojmi sú GitLab CI, OpenShift a Tox. Vďaka tejto práci sa podarilo zvýšit počet projektov, ktoré používajú CI/CD zo 7 na 50 percent, zvrátiť rastúci trend v počte porušení štýlu v jazyku Python, opatriť kontajnery metadátami, zautomatizovať proces tvorby kontajnerov, ušetriť čas nerobením repetitívnych úloh a pod.

Continuous integration, continuous delivery och continuous deployment har blivit väldigt viktiga inom systemutveckling eftersom de hjälper att säkerställa att en programvara håller sig till en viss kvalité samt att den snabbt kan levereras till slutanvändarna. Organisationer som tidigare använde continuous practices i samband med mer traditionella programvaror som till exempel webb-, server- och skrivbordsapplikationer försöker idag även implementera continuous practices i samband med mobila applikationer som till exempel hybrida appar. Bygg- och leveransprocessen för hybrida mobila applikationer består av många steg som ska göras i rätt ordning. När den processen utförs manuellt ökar det risken för att en app inte kommer att hålla en genomgående hög kvalité samt att det kan bli svårt att säkerställa att appen kan levereras vid behov till slutanvändarna. Det kan bero på flera faktorer. En av dessa faktorer är att människor inte är bra på att utföra långa och upprepbara processer och begår därför ofta fel och misstag. Tidigare studier som gjordes inom continuous integration, -delivery och -deployment saknar hur continuous practices kan appliceras till bygg- och leveransprocessen för hybrida mobila applikationer samt hur det kan göras i en organisation där det finns en existerande bygg- och leveransplattform. På grund av det utfördes den här studien med syftet att skapa en IT-artefakt i form av en pipeline som kan minska eller utesluta mänsklig påverkan på bygg- och leveransprocessen för hybrida mobila applikationer. Studien genomfördes med Action Design Research som bestod av tre iterationer och resulterade i en IT-artefakt i form av en pipeline som kunde utföra automatisk bygg och leverans av hybrida mobila applikationer. Förutom IT-artefakten kunde även ett antal designprinciper identifieras som var lämpliga när en pipeline för hybrida appar formades. Studiens resultat visade att med hjälp av continuous practices är det möjligt att automatisera bygg och leverans av hybrida appar samt att det går att implementera en pipeline för hybrida appar i en bygg- och leveransplattform som används för andra typer av programvaror.

Abstract Continuous software engineering (CSE) has instigated academic debate regarding the rapid, parallel cycles of releasing software and customer experimentation. This approach, originating from Web 2.0 and the software-as-a-service domain, is widely recognised among software-intensive companies today. Earlier studies have indicated some challenges in the use of CSE, especially in the context of business-to-business and product-oriented, embedded systems development. Consequently, research must address more explicit definitions and theoretical models for analysing the prerequisites and organisational capabilities related to the use of CSE. This dissertation investigates various approaches to conducting empirical evaluations related to CSE. The study aims to improve existing models of CSE and to empirically validate them in the context of software companies. The study also aims to accumulate knowledge regarding the use of CSE, as well as its impacts. The case study method is applied for the collection and analysis of empirical data. Twenty-seven interviews are conducted at five companies. In addition, a systematic literature review is used to synthesise the empirical research on agile release engineering practices. Design science research is used to portray the model design and the evaluation process of this dissertation. Three approaches for evaluating CSE are constructed: (1) LESAT for software focuses on enterprise transformation using an organisational self-assessment approach, (2) STH+ extends the “Stairway to Heaven” model and evaluates company practices with respect to evolutionary steps towards continuous experimentation-driven development, and (3) CRUSOE defines 7 key areas and 14 diagnostic questions related to the product-intensive software development ecosystem, strategy, architecture, and organisation, as well as their continuous interdependencies. This dissertation states the relevance of CSE in the context of product-intensive software development. However, more adaptations are anticipated in practices that involve business and product development stakeholders, as well as company external stakeholders. / Tiivistelmä Jatkuva ohjelmistotuotanto on herättänyt keskustelua nopeasta, samanaikaisesta ohjelmistojulkaisemisesta ja asiakaskokeiluista. Toimintatapa on peräisin Web 2.0 ja software-as-a-service yhteydestä, mutta se tunnetaan nykyään yleisesti ohjelmistoja kehittävissä yrityksissä. Aiemmat tutkimukset ovat osoittaneet haasteita jatkuvan ohjelmistotuotannon käytössä. Erityisesti haasteita on havaittu yritykseltä yritykselle liiketoiminnassa ja tuotepainotteisten sulautettujen järjestelmien yhteydessä. Näin ollen on havaittu tarve tutkimuksen avulla kehittää täsmällisempiä määritelmiä ja teoreettisia malleja, joilla voidaan analysoida jatkuvan ohjelmistotuotannon käyttöön liittyviä edellytyksiä ja organisaatioiden kyvykkyyksiä. Tässä väitöskirjassa tutkitaan malleja, joilla voidaan empiirisesti arvioida jatkuvaa ohjelmistotuotantoa. Tutkimuksella pyritään parantamaan nykyisiä malleja ja arvioimaan niiden käyttöä ohjelmistoyrityksissä. Lisäksi tutkimuksella pyritään kasvattamaan tietoa jatkuvasta ohjelmistotuotannosta ja sen vaikutuksista. Tiedon keräämiseen ja analysointiin käytettiin tapaustutkimus menetelmää. Kaksikymmentäseitsemän haastattelua tehtiin viidessä yrityksessä. Lisäksi tehtiin ketterään ohjelmistojulkaisuun keskittyvä systemaattinen kirjallisuuskatsaus. Väitöskirjassa käytetään Design Science Research menetelmää kuvaamaan tutkimuksen eri vaiheita, joissa malleja suunniteltiin ja arvioitiin. Tutkimuksessa rakennettiin kolme tapaa jatkuvan ohjelmistotuotannon arvioimista varten: (1) LESAT for Software keskittyy organisaation muutoskyvykkyyden arviointiin käyttäen itsearviointimenetelmää, (2) STH+, laajentaa ”Stairway to Heaven” mallia ja arvioi yrityksen käytäntöjä eri evoluutioaskelmilla matkalla kohti kokeilupainotteista tuotekehitystä, (3) CRUSOE määrittelee seitsemän pääaluetta ja 14 kysymystä liittyen tuotekehityksen ekosysteemiin, strategiaan, arkkitehtuuriin, organisointiin sekä näiden välisiin jatkuviin riippuvuuksiin. Väitöskirja osoittaa jatkuvan ohjelmistokehityksen olevan merkityksellinen myös tuotepainotteisessa ohjelmistokehityksessä. Nähtävissä kuitenkin on, että useita nykykäytäntöjä on tarvetta muokata. Erityisesti muokkaustarvetta on tuotekehityksen ja liiketoiminnan sidosryhmiin ja yrityksen ulkoisiin sidosryhmiin liittyvissä käytännöissä.

Multirepo model přístupu ke správě a verzování zdrojového kódu, jež zahrnuje použití mnoha oddělených repozitářů verzovacích systémů, je poslední dobou často zmiňován v odborné literatuře. Jednou z jeho nevýhod je množství zdlouhavých, nezajímavých a repetitivních úkonů, které je nutno provádět při hromadných operacích tvořících transakce napříč těmito repozitáři. Multirepo repozitáře navíc umožňují využití široké škály technologií, což jen umocňuje riziko lidské chyby, ke které při ručně prováděných hromadných operacích může dojít. V rámci této práce je navrženo, implementováno a otestováno řešení pro automatizaci operací prováděných napříč množstvím repozitářů uspořádaných v multirepo modelu, což s nimi uživatelům zlepšuje zkušenost.

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.

Цель работы – внедрение необходимых практик 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.