Information system development projecs are often considered a costly and uncertain process were projects often exceed the scheduled time and budget. By continuously integrating source code and do regular builds problems can be discovered almost directly and thus minimizing the cost to fix them. In this qualitative study we have focused on which challenges a large public organization who cooperate with an external provider can face when adopting continuous integration and continuous delivery. We have interviewed six employees within the organisation and two employees from the external provider, who are all in some way connected to the software development process. The results showed that our interviewees are interested in agile software development and to be able to deliver high quality software continuously. We also found that the software development process is complex and has a lot of barriers and handovers that slows the process down. Our conclusion is that the organization needs to change their approach to software development. To achieve this the organisation needs to adopt Devops, which means erasing the barriers between development and operations.

The adoption of Continuous Development presents many challenges to users and organizations. The complexity of Continuous Development adoption is partially attributable to the diversity of the challenges faced, including technical challenges, cultural challenges, compliance regulations, and lack of understanding. In this thesis, I worked with industry partner IBM to improve their Continuous Delivery Pipeline offering to overcome adoption challenges faced by their users. Following Hevner’s Three Cycle Design Science Methodology, my research had two distinct stages: Characterizing Continuous Development Adoption Challenges and Creating Design Requirements to Aid Organizations Offering Continuous Development Services. Both stages necessitated involvement from both academic literature and industry collaboration with IBM. Industry collaboration included interviews, surveys, developer forum analysis, and collaboration with IBM’s “Continuous Delivery” teams. The design requirements I developed in this thesis addressed cultural, technical, compliance, and knowledge gap adoption challenges that were identified during the problem characterization stage. When tested within the Continuous Development community, feedback indicated that my design requirements would add value to users’ development process, enabling their Continuous Development adoption. This thesis provides a foundation of empirical research for future study and a set of guidelines for industry practitioners. / Graduate

Continuous delivery (CD) is a software engineering approach where the focus lays on creating a short delivery cycle by automating parts of the deployment pipeline which includes build, deploy-, test and release process. CD is based on that during development should be possible to always automatically generate a release based on the source code in its current state. One of CD's many advantages is that through continuous releases it allows you to get a quick feedback loop leading to faster and more efficient implementation of new functions, at the same time fixing errors. Although CD has many advantages, there are also several challenges a maintenance management project must manage in the transition to CD. These challenges may differ depending on the maturity level for a maintenance management project and what strengths and weaknesses the project has. Our research question was: "What challenges can a maintenance management project face in transition to Continuous delivery?" The purpose of this study is to describe Continuous delivery and the challenges a maintenance management project may face during a transition to Continuous delivery. A descriptive case study has been carried out with the data collection methods of interviews and documents. A situation analysis was created based on the collected data in a shape of a process model that represent the maintenance management projects release process. The processmodel was used as the basis of SWOT analysis and analysis by Rehn et al's Maturity Model. From these analyzes we found challenges of a maintenance management project may face in the transition to CD. The challenges are about customers and the management's attitude towards a transition to CD. But the biggest challenge is about automation of the deployment pipeline steps. / Continuous Delivery (CD) är en metod inom systemutveckling där fokus ligger på att skapa en kort leveranscykel genom att automatisera delar av deployment pipeline vilket innehåller bygg-, deploy-, test- och releaseprocessen. CD bygger på att det alltid under pågående utveckling skall vara möjligt att automatiskt generera en release utifrån källkoden i dess aktuella tillstånd. En av CD’s många fördelar är att man genom kontinuerliga releaser får en snabb feedbackloop vilket leder till snabbare och effektivare införande av nya funktioner, samtidigt som man åtgärdar fel. Även om CD har många fördelar finns det också flera utmaningar ett förvaltningsuppdrag måste hantera vid en övergång till CD. Dessa utmaningar kan skilja sig beroende på vilken mognadsnivå ett förvaltningsuppdrag befinner sig i och vilka styrkor och svagheter uppdraget har. Vår frågeställning har varit: "Vilka utmaningar kan ett förvaltningsuppdrag stå inför vid en övergång till Continuous Delivery?" Syftet med denna studie är att få en ökad förståelse för Continuous Delivery samt vilka utmaningar förvaltningsuppdrag kan stå inför vid en övergång till Continuous Delivery. En beskrivande fallstudie har genomförts med datainsamlingsmetoderna intervjuer och dokument. Av insamlad data skapades en nulägesanalys i form av en processmodell över förvaltningsuppdragens releaseprocess. Den har använts som grund för en SWOT- analys och en analys med hjälp Rehn mfl’s Maturity model. I från dessa analyser kom vi fram till utmaningar ett förvaltningsuppdrag kan stå inför vid en övergång till CD. Utmaningarna handlar dels om kunder och ledningens inställningar inför en övergång till CD. Men den största utmaningen gäller automatisering av delarna i deployment pipeline.

abstract: Continuous Delivery, as one of the youngest and most popular member of agile model family, has become a popular concept and method in software development industry recently. Instead of the traditional software development method, which requirements and solutions must be fixed before starting software developing, it promotes adaptive planning, evolutionary development and delivery, and encourages rapid and flexible response to change. However, several problems prevent Continuous Delivery to be introduced into education world. Taking into the consideration of the barriers, we propose a new Cloud based Continuous Delivery Software Developing System. This system is designed to fully utilize the whole life circle of software developing according to Continuous Delivery concepts in a virtualized environment in Vlab platform. / Dissertation/Thesis / M.S. Computer Science 2013

Context. Continuous delivery deals with concept of deploying the user stories as soon as they are finished rather than waiting for the sprint to end. This concept increases the chances of early improvement to the software and provides the customer with a clear view of the final product that is expected from the software organization, but little research has been done on the quality of product developed and the ways to measure it. This research is conducted in the context of presenting a checklist of quality metrics that can be used by the practitioners to ensure good quality product delivery. Objectives. In this study, the authors strive towards the accomplishment of the following objectives: the first objective is to identify the quality metrics being used in agile approaches and continuous delivery by the organizations. The second objective is to evaluate the usefulness of the identified metrics, limitations of the metrics and identify new metrics. The final objective is to is to present and evaluate a solution i.e., checklist of metrics that can be used by practitioners to ensure quality of product developed using continuous delivery. Methods. To accomplish the objectives, the authors used mixture of approaches. First literature review was performed to identify the quality metrics being used in continuous delivery. Based on the data obtained from the literature review, the authors performed an online survey using a questionnaire posted over an online questionnaire hosting website. The online questionnaire was intended to find the usefulness of identified metrics, limitations of using metrics and also to identify new metrics based on the responses obtained for the online questionnaire. The authors conducted interviews and the interviews comprised of few close-ended questions and few open-ended questions which helped the authors to validate the usage of the metrics checklist. Results. Based on the LR performed at the start of the study, the authors obtained data regarding the background of continuous delivery, research performed over continuous delivery by various practitioners as well as a list of quality metrics used in continuous delivery. Later, the authors conducted an online survey using questionnaire that resulted in ranking the usefulness of quality metrics and identification of new metrics used in continuous delivery. Based on the data obtained from the online questionnaire, a checklist of quality metrics involved in continuous delivery was generated. Conclusions. Based on the interviews conducted to validate the checklist of metrics (generated as a result of the online questionnaire), the authors conclude that the checklist of metrics is fit for use in industry, but with some necessary changes made to the checklist based on the project requirements. The checklist will act as a reminder to the practitioners regarding the quality aspects that need to be measured during product development and maybe as a starting point while planning metrics that need to be measured during the project.

Dokumentation av IT-system har enligt tidigare studier ofta brister i form av att den exempelvis inte uppdateras, den kan vara ofullständig och otydlig eller vara på fel nivå för de intressenter som finns. Continuous delivery (CD) är ett sätt att hantera leverans av mjukvara vilket är baserat på kontinuerlig integration av ny och uppdaterad kod till en gemensam kodbas där automatiska tester körs så snart koden är integrerad. Dess förespråkare menar att det leder till bättre mjukvara som kan levereras snabbare och med mindre fel. Uppsatsens syfte är att undersöka hur organisationer kan arbeta med dokumentation när de hanterar leveranser med CD. Studien är en explorativ och kvalitativ designstudie för att ta fram en artefakt i form av riktlinjer för att företa dokumentationen. Den artefakt som tagits fram har utvärderats i workshops av systemutvecklare från den medverkande organisationen. Studiens slutsatser är att det går att arbeta med dokumentation av IT-system på ett sätt som arbetar bort de problem som finns samt att leverera mjukvara med CD inte nödvändigtvis påverkar dokumentationen så mycket.

No description available.

Feedback is an essential part of the software delivery process. Software metrics, as feedback, can give knowledge about the essential parameters that affect the software development process. An improved understanding of the software development process can facilitate more effective software management. With new software development methodologies emerging, such as Continuous Delivery, new information needs arise. The new methodology requires a new way of thinking when designing and developing dashboards for software development. A dashboard is a communication tool that can provide up-to-date information through at a glance interaction. The purpose of this thesis was to investigate how different software metrics related to Continuous Delivery can be visualized in a dashboard system at the company Saab. This thesis used a user-centered approach to find the appropriate visualization and user context to provide the user with feedback that supports the software development. The thesis work included user observations in the form of interviews and contextual inquiry. Thereafter, prototyping and usability testing were conducted in two iterations to design the dashboard and gather feedback. The result of this thesis work was a final prototype that was implemented in the program Kibana using real-time data from a software project. This thesis presents a set of elements that should be included when designing a dashboard for software development based on the findings of this study. / Feedback är en av de essentiella byggstenarna i en mjukvaruleveransprocess. Med mätvärden för mjukvaruutveckling kan organisationen få en större kunskap om de väsentliga faktorerna som påverkar mjukvaruutvecklingen. En ökad förståelse kan leda till en mer effektiv hantering av mjukvaruutveckling. Med nya metoder inom mjukvaruutveckling, t.ex. Continuous Delivery, som betyder kontinuerlig leverans, förändras behovet av feedback och nya utmaningar uppstår. Den nya metoden kräver nya uppläggningar vid utformning och utveckling av informationsradiatorer, en typ av kontrollpanel för mjukvaruutveckling. En kontrollpanel är ett kommunikationsverktyg som kan bidra med aktuell information om situationen genom att ge en överblicksbild. Målet med denna uppsats var att utreda hur mätvärden för mjukvaruutveckling kopplade till Continuous Delivery kan visualiseras på en kontrollpanel på företaget Saab. Detta examensarbete använde en användarcentrerad metod för att undersöka de vilka visualiseringar var lämpliga att använda och i vilken kontextanvändarna ville ha feedback. Examensarbetet utförde användarobservationer i form av intervjuer och kontextuell utredning. Sedan gjordes prototyper och användbarhetstestning. Detta gjordes i två iterationer för att samla in feedback och designa den slutgiltiga prototypen. Den prototypen utvecklades i programmet Kibana och använde realtidsdata från ett projekt. Resultatet i denna uppsats är ett förslag på vilka element som borde tas i hänsyn när en ska designa en kontrollpanel för systemutveckling.

In traditional Software Development Life Cycle, medium and large organizations tend to divide the activities of Operations and Development into separate departments. These groups often have a troublesome relationship because of different incentives during the software delivery process. As a result, conflicts occur between development and operations personnel as they blame each other to be the cause of long lead times and inefficient software delivery processes. The concept of DevOps emerged trying to resolve the problem that arises when separating the work of Development and Operations into organizational silos. The term DevOps is a combination of the abbreviations of Development (Dev) and Operations (Ops). DevOps aim to create a coalition that spans between Development (software developers and quality assurance) and Operation (experts responsible to roll out software to production and managing the infrastructure, e.g. system, network and database administrators and technicians). The idea is to increase the speed of the software delivery process and to quickly solve critical issues, enable organizations to better serve their customers. DevOps means that development teams who previously were solely responsible for the development of their applications now have to manage and govern both development and operational responsibilities. Thus, the adoption of DevOps might introduce new type of challenges and implications for the traditional development teams. Current literature and research about DevOps focus mainly on the challenges that DevOps attempts to overcome. There is a lack of literature on the challenges that practitioners encounter during the adoption of DevOps. As more organizations and companies tend to adopt the concept of DevOps, it increases the need to understand potential challenges and effects of adopting DevOps. Therefore, the aim of this study is to investigate the challenges that development teams encounter during the adoption of DevOps. This research was conducted by an inductive research approach through a single qualitative case study, with the use of semi-structured interviews. In total, four main challenges and fourteen sub-challenges were identified in this study. The four main challenges identified was, lack of awareness, lack of support for DevOps, implementing DevOps technology and adapting organizational processes to DevOps. This study concludes that the adoption of DevOps has a profound impact on the role of a software developer, and that the traditional role of a software developer needs to be evolved. The research provides four recommendations and means to overcome the challenges identified in this research, establishing common ways of working and spreading the knowledge, building commitment and trust by smarter seating, allocate time and resources to transition and trying out with one team and one application. / I traditionell livscykel för mjukvaruutveckling tenderar medelstora och stora organisationer att dela upp verksamheten i drift och utveckling i separata avdelningar. Dessa grupper har ofta en besvärlig relation på grund av olika incitament under mjukvaruleveransprocessen. Som ett resultat uppstår konflikter mellan utvecklings- och driftpersonal eftersom de beskyller varandra för att vara orsaken till långa ledtider och ineffektiva mjukvaruleveransprocesser. Konceptet DevOps uppstod för att försöka lösa det problem som uppstår när man separerar utveckling och drift i organisationella silosar. Termen DevOps är en kombination av förkortningarna för utveckling (Dev) och drift (Ops). DevOps syftar till att skapa en koalition som sträcker sig mellan utveckling (mjukvaruutvecklare och kvalitetssäkring) och drift (system-, nätverks- och databasadministratörer och tekniker). Idén är att öka hastigheten av mjukvaruleveranser och att snabbt lösa kritiska problem för att förbättra organisationens förmåga att betjäna sina kunder. DevOps innebär att utvecklingsgrupper som tidigare enbart ansvarade för utvecklingen av sina applikationer nu även har driftansvar. Således kan antagandet av DevOps introducera nya typer av utmaningar och konsekvenser för de traditionella utvecklingsgrupperna. Aktuell litteratur och forskning kring DevOps fokuserar främst på de utmaningar som DevOps försöker övervinna. Därav finns det brist på litteratur kring de utmaningar som utövare stöter på under antagandet av DevOps. Eftersom fler organisationer och företag tenderar att adoptera begreppet DevOps ökar behovet av att förstå potentiella utmaningar och effekter av att anta DevOps. Därav är syftet med denna studie att undersöka de utmaningar som utvecklingsgrupper bemöter under antagandet av DevOps. Denna forskning utfördes genom en induktiv forskningsinriktning, en kvalitativ fallstudie och datainsamling genom halvstrukturerade intervjuer. Totalt identifierades fyra huvudutmaningar och fjorton sub utmaningar i denna studie. De fyra huvudsakliga utmaningar som identifierades var, brist på medvetenhet, brist på stöd för DevOps, implementering av DevOps-teknik och anpassning av organisationsprocesser till DevOps. Den här studien drar slutsatsen att antagandet av DevOps har en djupgående inverkan på rollen som en mjukvaruutvecklare och att den traditionella rollen som en mjukvaruutvecklare behöver utvecklas. Studien ger fyra rekommendationer och medel för att övervinna de utmaningar som identifierats, etablering av gemensamma sätt att arbeta och sprida kunskapen, bygga upp engagemang och förtroende genom smartare sittplatser, fördela tid och resurser till övergången samt prova med ett lag och en applikation.

The purpose of this study is to continue development of a benchmarking model to help companies assess their technical maturity when it comes to adopting Continuous Integration, Continuous Delivery and DevOps in their organization. The goal of the research is to assess how to improve the quality of qualitative models. Which conclusions can be drawn from comparing companies using benchmark and to assess which actions are the most effective to take to reach higher Continuous Integration, Continuous Delivery and DevOps maturity. The benchmark consisted of a questioner of two hundred statements that were answered for level of agreement with a current situation analysis and an ought-to-be analysis to be able to draw conclusions from the possible discrepancy between these categories. The questioner was answered during an interview study with chosen clients. Conclusions drawn from this study were that a lot can be done to improve the quality of qualitative models for examining Continuous Integration, Continuous Delivery and DevOps maturity. Different actions are necessary but the most important seems to be to ask open ended questions as well ass questions about different aspects of the same problem to promote discussion. It was also showed to be important to peer review the questions in the interview material beforehand to increase quality. The study also showed that it is possible to see trends in Continuous Integration, Continuous Delivery and DevOps maturity when comparing qualitative results for research subjects. The study showed that the most effective method for increasing Continuous Integration, Continuous Delivery and DevOps maturity is to use extensive automated testing suites that covers all testing disciplines. / Syftet med studien är att vidareutveckla ett benchmarkingverktyg för att hjälpa företag att bedöma sin tekniska mognad när det gäller att anta Continuous Integration, Continuous Delivery och DevOps i sin organisation. Målet med forskningen är att bedöma hur man kan förbättra kvaliteten på kvalitativa modeller för att mäta detta, samt vilka slutsatser som kan dras av att jämföra företags resultat som nyttjat studien. Samt att undersöka vilka åtgärder som är effektivast att ta för att nå en högre mognadsgrad inom Continuous Integration, Continuous Delivery och DevOps. Benchmarken bestod av ett frågebatteri av tvåhundra påståenden som besvarades av kunden i hur mycket de instämde till ett påstående. Resultatet samanställdes till en aktuell nulägesanalys och en börlägesanalys, med målet att dra slutsatser i vilka skillnaden som fanns mellan dessa två kategorier. Kunden besvarade frågebatteriet under en intervjustudie med utvalda anställda. Slutsatser som härrör från denna studie var att mycket kan göras för att förbättra kvaliteten på kvalitativa modeller för att undersöka Continuous Integration, Continuous Delivery och DevOps mognadsgrad. Olika åtgärder är möjliga, men det viktigaste förefaller vara att fråga öppna frågor för att främja diskussion samt att ställa frågor om olika aspekter av samma problem. Samt att opponera frågorna internt i intervjuundersökningen innan det utförs hos en kund, för att öka kvaliteten. Studien visade också att det även är möjligt att se trender i Continuous Integration, Continuous Delivery och DevOps mognad hos deltagarna när man jämför de kvalitativa resultaten. Studien visade att de mest effektiva metoderna för att öka Continuous Integration, Continuous Delivery och DevOps mognadsgrad är att använda omfattande automatiserade testsviter för samtliga testmetoder.