No description available.

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.

Background. DevOps represents a set of principles and practices of the software development (Dev) and information technology operations (Ops) of the product lifecycle requirements. DevOps has become a buzzword in organizations because it is an agile software development offspring. Now-a-days, there is a shift in organizations from DevOps to DevSecOps, which is bringing in a higher level of security built into software delivery pipelines. DevSecOps ensures security is a core component in the workflow to implement secure development and operations processes of automating every aspect. Security inevitably includes issues like compliance in terms of security standards that are concerning with looming cybersecurity threats. There is little known about different concepts of assessing security compliance in terms of security standards in DevOps pipelines. Understanding the artefacts and their dependencies requirements in the software workflow are fundamental to demonstrate compliance. The thesis study proposes to ensure the IEC 62443-4-1 standard for secure product development in industrial systems is incorporated into the artefact model to capture the information related to security compliance. Objectives. The thesis aims to investigate the artefacts and identify its dependencies to develop and design an artefact model for DevSecOps. This artefact model has the possibility to measure security compliance with the IEC 62443-4-1 standard to ensure traceability in DevOps pipeline and evaluate the usability of it. Methods. In this qualitative research, we have conducted a literature review with snowballing to gather information on artefacts that undergo synthesis to develop and design the artefact model. We have conducted interviews with practitioners to collect the data on the usability of the artefact model. Results. The literature review with snowballing is done to identify ten papers in the final data set. We have identified 100 artefacts from the papers. The artefacts are categorized and matched according to practices and activities descriptions. The synthesis of the literature review artefacts provides the basis for designing the artefact model and its dependencies for DevSecOps workflow. The interview results are thematically coded and we have obtained a list of benefits, challenges, and security compliance barriers with DevOps pipelines. This process evaluates the practitioners’ understanding of the designed artefact model usability in the industry to assess the standard’s security compliance. Conclusions. The research study identifies the artefacts that help with developing the artefact model. It provides the practitioners’ understanding of the usability of the artefact model in the industry to meet the secure software development product life-cycle requirements according to the IEC 62443-4-1 standard. The results demonstrated the evidence of assessing the security compliance for DevSecOps workflow in DevOps pipeline.

Background: Organizations want to reach shorter development cycles to stay competitive, meanwhile, many organization wants to globalize their business to obtain benefits like reduced cost, get hold of specific talent or gain global presence.  Typically in software development projects, there is a gap between development and operation resulting in a longer development cycle due to inferior communication and collaboration. DevOps is a framework that intends to reduce this gap with the purpose to reach shorter development cycles. However, currently, there is a lack of literature covering whether it is possible to adopt DevOps and keeping an offshore strategy.  Purpose: The purpose of this thesis is to increase understanding about the use of DevOps in offshore projects. This increased understanding will be the start of filling the current gap in the literature about DevOps in distributed setups and form a basis for future research. The study aims to suggest how DevOps framework can bridge the gap between development and operation in offshore projects.  Method: An exploratory case study was conducted and three different offshore projects, who had adopted DevOps, were investigated. In this study, 15 members from different projects were interviewed to find out how DevOps had been adopted in their projects. Based on a survey, a Social Network Analysis was conducted for each project with the purpose to identify communication patterns between members.  Results: The result of this study provided information, specific to each project, about the setup, DevOps definition, and goal, DevOps practices as well as benefits and challenges with DevOps. Furthermore, the result presented information related to the performance of the project and, information about the collaboration, communication, and trust within the project.  Conclusion: This study presented four possible distribution possibilities of DevOps in an offshore project and suggested different ways to manage the work roles when adopting DevOps. The study indicates that DevOps can be adopted in an offshore project in order to decrease the gap between development and operation by considering three perspectives; roles and responsibility, automated workflow and DevOps practices, and knowledge sharing  Delimitations: This study is limited to only investigate projects from one company. Furthermore, the scope of this study does not include any economic aspects.

Background: Since the conception of DevOps several tools have come into existence that eases its implementation. A variety of these tools are used to implement a standard DevOps pipeline. The process of selection of these tools and the interactions between them is called tool integration. Objectives: This thesis aims to address and solve the various tool integration challenges faced during the DevOps implementation. The primary goal is to identify the tool integration challenges that occur while implementing a standard DevOps pipeline with the help of feedback from experienced DevOps practitioners. After identifying these challenges, the possible mitigation strategies to these challenges are devised by analyzing the responses received from a large population of DevOps practitioners. Methods: Survey is chosen as the research methods for this thesis. Two data collection methods have used for implementing the survey namely interviews and survey questionnaire. Major tool integration Challenges are identified from the analyzed interview data. Using these challenges as inputs a survey questionnaire is prepared for gaining insights on occurrences of these challenges in large population of DevOps practitioners. The main aim of the survey questionnaire is to find out the mitigation strategies to these challenges by analysing the survey responses. Results: The tool integration challenges were identified by conducting semi-structured interviews with eight DevOps practitioners. Seven common challenges have been identified from the interview data using the Immersion approach. A survey questionnaire prepared by using these challenges received 79 responses in total, out of which62 are considered. Using Thematic Analysis the mitigation strategies for these challenges have been extracted from the responses of the survey.Conclusions. Most of the tool integration challenges reported by the interview participants seem to be associated with CI tools when they are integrated and used together with other DevOps tools. Most of the mitigation strategies are aimed towards the "Tool" theme among the various themes found in thematic analysis of survey data.

Denna studie undersöker implementeringen av DevOps i företag som hanterar flera kunder. Studien syftar till att identifiera nyckelfaktorer som bidrar till framgångsrik implementering av DevOps i denna specifika kontext. Motiveringen till studien ligger i det växande behovet av att förstå hur DevOps kan anpassas till olika kunders unika behov och krav, vilket är en avgörande aspekt för företagens konkurrenskraft och effektivitet. Studien baseras på en utförlig litteraturstudie och intervjuer med sex deltagare från olika företag. Studien har lyckats generera betydande insikter. Resultatet framhäver vikten av att skräddarsy DevOps till varje kunds unika behov, att främja en öppen och stödjande kultur och att använda automatisering för att förbättra effektiviteten och pålitligheten i leveransprocessen. Studiens resultat är främst användbara för IT-ledare, utvecklare och driftpersonal som jobbar med eller överväger att införa DevOps inom sin organisation. Den erbjuder också värdefull insikt för forskare och studenter inom programvaruutveckling och IT-hantering. Slutsatserna bekräftar och utvidgar tidigare resultat och bidrar till en större förståelse av hur företag kan förbättra sin hantering av DevOps. Trots studiens begränsningar i antal deltagare, har den lyckats uppnå sitt syfte. Resultaten av denna studie kan förbättra processer inom andra områden av programvaruutveckling och IT-hantering. Framtida studier bör fokusera på att ytterligare validera och fördjupa dessa resultat, undersöka mer specifika aspekter av DevOps och hur dessa principer kan tillämpas i andra kontexter.

Scrum is a widely used methodology for software development that is born of the Agile movement. In recent years DevOps has been increasing in popularity within the software industry. The purpose of this thesis is to firstly, explore the technical and social challenges a Scrum team may face when adopting DevOps. Secondly, to explore what collaboration mechanisms that can facilitate a closer cooperation between development and operations. A multiple case study was conducted using semi-structured interviews as the data collection method. The interviews were transcribed and analyzed using thematic analysis. Three technical challenges and one social challenge emerged from the analysis. Additionally, four mechanisms were identified during the analysis as ways to achieve a closer collaboration between the development and operations teams. The result discussion showed that challenges of adopting DevOps when using Scrum are comparable to the findings of previous research where the scope of methodology is not limited to Scrum. Furthermore, the identified collaboration mechanisms can be used by organizations to enhance collaboration between development and operations but should not be seen as strict guidelines.

In today's industry the DevOps work-style is adopted in more and more companies. Following the work-style often leads to companies being more efficient at delivering new feature and high quality software at higher speeds.However, one thing that the DevOps work-style fail to address is the process of writing good and reliable non-code documentation. The non-code documentation often becomes a bottleneck for the companies following the work-style and is in need of an updated process to make it more effective and sustainable over time. In this thesis, the problem is addressed by designing and building a prototype system capable of automating the process of creating non-code documentation. In order to create a system capable of automating the process and thus increasing the flow and efficiency of the DevOps work-style, the prototype system has been built by combining powerful pre-existing tools like Pandoc, LaTeX and Docker together. The resulting system is implemented in a platform like GitLab or Bitbucket and can be used to automatically generate documentation with new releases. The documents are written in plain-text markdown files, letting the user focus on the content rather than the aesthetics of the document. This resulted in an increase of creating non-code documents 33.8% faster than existing methods like using Microsoft Word. Finally, the prototype system also generates more aesthetically looking documentation.

I dagens IT-landskap kan det vara väldigt besvärligt för organisationer att navigera sig. Med den snabba utveckling som sker med teknik och applikationer, men även kring ramverk och arbetsmetoder som alla säger sig vara det bästa för just ens egen organisation. Det är därför viktigt att skapa sig en förståelse för vad som lämpar sig att kombinera, men även vilka kombinationer som bör undvikas. Ett av de största ramverken rörande IT-service Management (ITSM) är Information technology infrastructure library (ITIL). ITIL har funnits sedan 80-talet och har som syfte att hjälpa organisationer med sin hantering av tjänster. Sedan finns DevOps som är ett arbetssätt som växte fram ur den agila rörelsen. Syftet med DevOps är att bryta ned de silos som finns mellan utveckling och den operativa verksamheten i en organisation. Syftet med denna studie är att identifiera hur väl ITIL:s senaste version, ITIL4 kan kombineras med DevOps med syftet att hjälpa till att effektivisera organisationer. Detta för att tidigare forskning har påvisat att DevOps och ITIL är uppbyggda på ett sätt som gör det svårt för organisationer att kombinera dem. Tidigare forskning har granskats för att identifiera vilka problem men även vilka möjligheter det kan finnas med att kombinera dem. Utöver det genomfördes även fyra semi-strukturerade intervjuer med experter gällande ITIL4 och DevOps. Detta för att få en klarare bild kring hur de båda fungerar och kan användas i verkligheten, samt få en inblick hur utövarna ser på kombinationen med varandra. Det studien kommer fram till är att ITIL4 och DevOps har mer gemensamt än vad tidigare versioner av ITIL haft. Det finns flera olika organisatoriska områden som berörs av ITIL4 respektive DevOps som har stora likheter. Där de båda skapar ett holistiskt synsätt som man bör använda på sin organisation, men även hur kontinuerlig utveckling i kombination med återkoppling är centralt i både ITIL4 och DevOps. Men även där går det att se skillnader i hur de kan komplettera varandra. ITIL4 kompletterar DevOps i form av att vidga dess vyer utifrån de centrala element som DevOps har. Medan DevOps kan hjälpa ITIL4 med att etablera ett iterativt arbetssätt inom organisationen, men även vara en starkt bidragande faktor till kontinuerlig förbättring. / It can be difficult for organizations to navigate the IT-landscape that we have today. Through rapid development regarding technology and applications, but also with frameworks and work methods saying they’re perfect for your organization. Therefore, it’s important to create an understanding for which things you can combine, but also which combinations should be avoided. One of the biggest frameworks regarding IT-Service management (ITSM) is called information technology infrastructure library (ITIL). ITIL has been around since the 80’s and its main purpose is to help organizations with management of their services. Then there’s DevOps which is a work method that emerged from the agile movement. The purpose of this study was to identify how the latest version of ITIL can be combined with DevOps to help organizations to become more effective. The reason behind that is because previous studies have shown that ITIL and DevOps are structured in a way that makes it hard for organizations to combine them. Therefore, a qualitative study was conducted with a literature review surrounding both ITIL4 and DevOps, to create a better understanding of what they are, and how they are used. But additional research was also reviewed to understand which problems and possibilities there were if they both were combined. Four semi-structured interviews were also conducted with experts regarding ITIL4 and DevOps. These interviews were conducted to create a better understanding of how ITIL and DevOps operate in the real world, but also to get an understanding of the respondents view of the combination. The result from this study shows that ITIL and DevOps have more in-common than previous versions. There are several areas that both ITIL4 and DevOps touch which have big similarities. They both create a holistic view for organizations, but also shows continual development in combination with feedback is essential for them both. But where there are differences, it can be identified where they complement each other. ITIL4 complements DevOps by expanding its views based on the three central elements in DevOps. While DevOps can help ITIL4 by establishing an iterative workflow throughout the organization, but also be a strong contributor to continual improvement.

En växande trend inom informationssystem är användningen av mikrotjänster som arkitekturstil för att bygga och underhålla system. Tidigare forskning har visat på fördelar som modularitet, skalbarhet samt möjlighet till snabb driftsättning av kodförändringar. Men tillsammans med välkända fördelar kommer även utmaningar. I den akademiska världen råder en begränsad tillgång till mikrotjänstapplikationer i stor skala, och det är därför intressant att undersöka systemutvecklares perspektiv. Denna studie kompletterar existerande litteratur med erfarenheter och insikter från systemutvecklare som jobbar med utveckling av mikrotjänster. Syftet med denna studie var att undersöka och analysera hur systemutvecklare tillämpar mikrotjänstarkitektur för att utnyttja dess teoretiska fördelar och hantera eventuella utmaningar, samt att identifiera vilka förutsättningar som är nödvändiga för en framgångsrik implementering av mikrotjänstarkitektur. Genom att utföra en kvalitativ intervjustudie med åtta systemutvecklare från sex olika organisationer kartlade vi de mest betydelsefulla fördelarna med mikrotjänster, inklusive tydliga avgränsningar, smidigare versionshantering samt möjlighet till kontinuerlig integration och leverans. Samtidigt identifierade vi även centrala utmaningar såsom tekniskt och operativt arv, organisatorisk tröghet samt komplexitet i hur mikrotjänster sammankopplas. Studiens resultat ledde fram till att en uppsättning framgångsfaktorer för att lyckas med mikrotjänstarkitektur kunde urskiljas. Dessa inkluderade bland andra tydligt ägandeskap, DevOps och centraliserad loggning. / A growing trend in information systems is the use of microservices as an architectural style for building and maintaining systems. Previous research has highlighted benefits such as modularity, scalability, and the ability for rapid deployment of code changes. However, along with these well-known advantages comes also challenges. In academia there is limited access to large-scale microservice applications, making it interesting to explore the perspectives of system developers. This study complements existing literature with experiences and insights from system developers involved in the development of microservices. The purpose of this study was to investigate and analyze how system developers apply microservice architecture to utilize its theoretical advantages and manage potential challenges, as well as to identify the prerequisites necessary for successful implementation of microservice architecture. By conducting a qualitative interview study with eight system developers from six different organizations we mapped the most significant benefits of microservices, including clear boundaries, easier version management, and the possibility of continuous integration and delivery. We also identified central challenges such as technical and operational legacy, organizational slowness and complexity in how microservices are interconnected. The results of the study led to the identification of a set of success factors for successful implementation of microservice architecture. These included clear ownership, DevOps and centralized logging.