When the traditional approach to system development transitioned over to agile methods the demand for ways to continuously deliver valuable software increased. With the increasing interest in these methods the umbrella term DevOps were introduced in 2008. DevOps is the practice to shorten the time, as well as streamlining the process, between changes in the source code and when it reaches the customer. This study aimed at investigating the process of adopting DevOps practices and identify success factors and challenges in this transition. We conducted a quality approached case study on a DevOps team in a multinational IT-consulting firm. Four explorative interviews were conducted based on categories identified in relevant literature as well as basis provided by the case company. We discovered that an implementation of continuous practices is far more complex than we initially thought. It is related to more fields outside the technical aspect that must be considered during a transition.  Our findings include four critical success factors for a successful DevOps implementation; conscious staff, conscious organization, functional infrastructure and adapted business model. Embedded in these critical success factors we were able to identify challenging fields that should be considered when adopting DevOps. These critical success factors and challenges was the basis for our model presented in the study.

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.

Submitted by Fabio Sobreira Campos da Costa (fabio.sobreira@ufpe.br) on 2016-03-16T12:48:08Z No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) Filipe_Versao_Final_Pos_Defesa_Deposito.pdf: 1855793 bytes, checksum: 366a64a51c618d78933bc62349a182cc (MD5) / Made available in DSpace on 2016-03-16T12:48:08Z (GMT). No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) Filipe_Versao_Final_Pos_Defesa_Deposito.pdf: 1855793 bytes, checksum: 366a64a51c618d78933bc62349a182cc (MD5) Previous issue date: 2015-08-21 / Hoje as organizações de T.I. estão enfrentando um sério desafio, por um lado temos mercados cada vez mais competitivos, com mudanças quase que rotineiras nos softwares e uma variedade imensa de dispositivos e sistemas operacionais; por outro, os sistemas ficam cada vez mais complexos, integrados a outros serviços e exigindo um alto grau de confiabilidade e disponibilidade dos mesmos, exigindo assim um processo de implantação cada vez mais eficiente e robusto. Nos últimos anos o termo DevOps – colaboração entre desenvolvimento e operação - e suas práticas foram amplamente usados e discutidos sob diferentes aspectos. Assim como no movimento ágil, DevOps também nasceu na indústria e a partir da necessidade da mesma. Por mais que várias organizações já adotem práticas que ficaram conhecidas como DevOps, seu uso ainda não é prescritivo, existindo assim uma variedade de diferentes manifestações de uso em termos de definição e padrão dentre as organizações. Diante disso, esta dissertação teve por objetivo realizar um mapeamento sistemático da literatura e um survey em busca do movimento DevOps, áreas de concentração dos estudos, os principais autores da área e as principais práticas e formas de uso de DevOps nas organizações. Como contribuição, esta pesquisa identificou que dentre as principais áreas de DevOps podem-se destacar (i) entrega, (ii) integração, (iii) e testes contínuos, além da (vi) automação da infraestrutura. Como principais práticas foram possíveis destacar: (a) implantações através de máquinas virtuais, (b) visibilidade do pipeline de implantação, (c) processos robustos de roolbacks, além de técnicas como (d) canary release, (e) toogled features e (f) blue-green deployments. / Today's IT organizations are facing a serious challenge, on the one hand we increasingly competitive markets with routine software’s changes and a wide variety of devices and operating systems; on the other hand, the systems are increasingly complex, integrated with other services and requiring a high degree of reliability and availability requiring a deploy process increasingly efficient and robust. In recent years the DevOps term - a clipped compound of development and operations - and DevOps’s practices were widely used and discussed under different aspects. As agile movement, the DevOps term was also born in the industry’s need. Today many organizations already adopt practices that became known as DevOps its use is not prescriptive, so there is a variety of different manifestations of use in terms of definition and standard among organizations. Therefore, this work aimed to carry out a mapping study and a survey in search of the state of the art DevOps movement, concentration areas of study, the main authors of the area and the main practices and the use of DevOps in organizations. As a contribution, this research found that among the main DevOps area can highlight: (i) continuous delivery; (ii) continuous integration; (iii) continuous testing; and (vi) infrastructure’s automation. Additionally, we can emphasize the main practices in the DevOps adoption: (a) deploys through virtual machines; (b) visibility’s deployment pipeline; (c) robust processes roolbacks, and techniques such as (d) canary release, (e) toogled features and (f) blue-green deployments.

Submitted by Fabio Sobreira Campos da Costa (fabio.sobreira@ufpe.br) on 2016-03-16T14:48:51Z No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) Filipe_Versao_Final_Pos_Defesa_Deposito.pdf: 1855793 bytes, checksum: 366a64a51c618d78933bc62349a182cc (MD5) / Made available in DSpace on 2016-03-16T14:48:52Z (GMT). No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) Filipe_Versao_Final_Pos_Defesa_Deposito.pdf: 1855793 bytes, checksum: 366a64a51c618d78933bc62349a182cc (MD5) Previous issue date: 2015-08-21 / Hoje as organizações de T.I. estão enfrentando um sério desafio, por um lado temos mercados cada vez mais competitivos, com mudanças quase que rotineiras nos softwares e uma variedade imensa de dispositivos e sistemas operacionais; por outro, os sistemas ficam cada vez mais complexos, integrados a outros serviços e exigindo um alto grau de confiabilidade e disponibilidade dos mesmos, exigindo assim um processo de implantação cada vez mais eficiente e robusto. Nos últimos anos o termo DevOps – colaboração entre desenvolvimento e operação - e suas práticas foram amplamente usados e discutidos sob diferentes aspectos. Assim como no movimento ágil, DevOps também nasceu na indústria e a partir da necessidade da mesma. Por mais que várias organizações já adotem práticas que ficaram conhecidas como DevOps, seu uso ainda não é prescritivo, existindo assim uma variedade de diferentes manifestações de uso em termos de definição e padrão dentre as organizações. Diante disso, esta dissertação teve por objetivo realizar um mapeamento sistemático da literatura e um survey em busca do movimento DevOps, áreas de concentração dos estudos, os principais autores da área e as principais práticas e formas de uso de DevOps nas organizações. Como contribuição, esta pesquisa identificou que dentre as principais áreas de DevOps podem-se destacar (i) entrega, (ii) integração, (iii) e testes contínuos, além da (vi) automação da infraestrutura. Como principais práticas foram possíveis destacar: (a) implantações através de máquinas virtuais, (b) visibilidade do pipeline de implantação, (c) processos robustos de roolbacks, além de técnicas como (d) canary release, (e) toogled features e (f) blue-green deployments. / Today's IT organizations are facing a serious challenge, on the one hand we increasingly competitive markets with routine software’s changes and a wide variety of devices and operating systems; on the other hand, the systems are increasingly complex, integrated with other services and requiring a high degree of reliability and availability requiring a deploy process increasingly efficient and robust. In recent years the DevOps term - a clipped compound of development and operations - and DevOps’s practices were widely used and discussed under different aspects. As agile movement, the DevOps term was also born in the industry’s need. Today many organizations already adopt practices that became known as DevOps its use is not prescriptive, so there is a variety of different manifestations of use in terms of definition and standard among organizations. Therefore, this work aimed to carry out a mapping study and a survey in search of the state of the art DevOps movement, concentration areas of study, the main authors of the area and the main practices and the use of DevOps in organizations. As a contribution, this research found that among the main DevOps area can highlight: (i) continuous delivery; (ii) continuous integration; (iii) continuous testing; and (vi) infrastructure’s automation. Additionally, we can emphasize the main practices in the DevOps adoption: (a) deploys through virtual machines; (b) visibility’s deployment pipeline; (c) robust processes roolbacks, and techniques such as (d) canary release, (e) toogled features and (f) blue-green deployments.

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.

The Eiffel Protocol provides traceability downstream and upstream of all activities that transpire inside the CI/CD pipeline. The traceability achieved by the Eiffel Protocol comes with great benefits even though it does not cover all development activities as it pertains only to the CI/CD pipeline. Our research aims to explore the idea of extending the Eiffel Protocol to cover all activities and discuss what benefits could be seen, especially in the scope of reducing the number of integration failures. A literature study was first carried out to find the root causes of these failures. After the literature study, we conducted a focus group session to gather data about the potential benefits and problems of an extension, what analyses could be drawn, and how it can affect integration errors. Our results show that an extension is beneficial as analyses that can be made with the generated data can tackle some of the biggest issues found in software development teams, especially in larger organizations. The complexity, cost involved and the time needed to see a return on investment does however weigh it down. Thus, while it is beneficial it is not enough for organizations to consider it as a priority to integrate with their environments when thinking of the costs involved to do so. Further implementation solutions need to be researched before it shows its worth.

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.

Denna uppsats studerar förutsättningarna för att implementera mjukvaruutvecklings - metoden Continuous Delivery (CDE). Problemställningen som lade grunden för studien, var att det inte finns någon enhetlig standard för CDE. Studien ämnade att undersöka om detta innebar att metoden har varierande innebörd inom olika företag och om de således, i viss mån tillämpar skilda tillvägagångssätt med metoden. Ytterligare en aspekt var att se vilka utmaningar företagen upplevde vid övergången till CDE. Att undersöka om det var främst organisatoriska eller utvecklingsrelaterade problem som upplevts. Samt hur de hanterade kommunikation och tillit till medarbetarna och arbetet inom verksamheten under förändringen. För att belysa problemen, beskrevs teori med fokus på organisatoriska och tekniska utmaningar med Continuous - metoderna: Continuous Integration (CI), Continuous Delivery (CDE) och Continuous Deployment (CD). Teorikapitlet samt tidigare studier inkluderade även forskning om kringliggande koncept som DevOps och LEAN. Metoder, vilka kan underlätta implementationen av CDE. Datainsamlingen genomfördes med öppna individuella intervjuer med representanter från sex stycken företag, där de delade med sig av deras erfarenheter av och syn på CDE. Studien visar att anledningen till att företag väljer att arbeta med CDE, är att de vill gå från utvecklingsmetoder, vilka kräver många beslut inför varje förändring, till ett mer flexibelt arbetssätt där de funnit fördelar som: bättre kvalitet på det som levereras, snabbare leverans av affärsvärde till kunder samt kortare feedback - loopar. Företag som gör en övergång till CDE väljer dessutom ofta att inte automatisera hela vägen ut till produktion, enligt CD, då de ser utmaningar med att säkra kvalitén. Studien har identifierat ett antal faktorer som viktiga för en framgångsrik implementering av CDE, samt faktorer som kan resultera i en svår övergång. / This thesis studies the conditions needed for implementing the software development method Continuous Delivery (CDE). The problem identified for the study, is that there is no standardized approach for CDE as of today. The intentions of the study were to determine whether this means that the method will have a shifting tenor within different companies, and if so, will these companies implement the method with different approaches. Another aspect was to determine which types of challenges the companies were faced with during the transition towards CDE. To review whether the challenges were foremost organisational or development related. And how the organisations handled the communication and trust towards the co-workers and the development work within the organisation during the change towards the method. To highlight these issues, we presented theories with focus on organisational and technical challenges with the different Continuous practices were made. The practices being: Continuous Integration (CI), Continuous Delivery (CDE) and Continuous Deployment (CD). The theory chapter and former studies also contains research about surrounding concepts such as DevOps and LEAN methods, which can aim to facilitate the implementation of CDE. The empirical data collection was performed using open individual interviews with informants from six different companies, where they shared their experience and views on the method CDE. The study demonstrates that the reason organisations chose to implement CDE, is that they want to transform from software development methods, which requires a lot of decision making for any change, to a more flexible work procedure, in order to experience benefits such as: better quality of what is delivered, faster deliveries of business value to the customers and faster feedback-loops. Organisations that make the transition towards CDE also tend not to automate all the way to production, as in agreement with CD, this because the organisations identify challenges with assuring that the quality is sufficient. The study has identified a number of factors that are essential for a successful implementation of CDE, along with factors that may result in a less successful implementation.

The last couple of years the trend within the software industry has been to releasesmaller software updates more frequent, to overcome challenges and increase flexibility, to alignwith the swiftly changing industry environment. As an effect, we now see companies moving over tocapitalizing on subscriptions and incremental releases instead of charging for upgrades. By utilizingneo-institutional theory and Oliver’s (1991) strategic response theory, an enterprise systemsvendor’s response to the emerging DevOps trend can be determined.