Problems, causes and solutions when adopting continuous delivery—A systematic literature review

Laukkanen, Eero; Itkonen, Juha; Lassenius, Casper

doi:10.1016/j.infsof.2016.10.001

Cited by 99 publications

(123 citation statements)

References 8 publications

Supporting

Mentioning

108

Contrasting

Unclassified

Order By: Relevance

“…Especially the mechanisms leading to lack of time to improve the CD practice were most emphasized by the participants. All of the mechanisms have been previously known to hinder CD adoption, e.g, in our Ericsson study [16] and SLR [17], and this study supports their existence.…”

Section: Discussionsupporting

confidence: 87%

See 1 more Smart Citation

Bottom-up Adoption of Continuous Delivery in a Stage-Gate Managed Software Organization

Laukkanen

Lehtinen

Itkonen

et al. 2016

Proceedings of the 10th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement

Self Cite

View full text Add to dashboard Cite

Context: Continuous delivery (CD) is a development practice for decreasing the time-to-market by keeping software releasable all the time. Adopting CD within a stage-gate managed development process might be useful, although scientific evidence of such adoption is not available. In a stagegate process, new releases pass through stages and gates protect low-quality output from progressing. Large organizations with stage-gate processes are often hierarchical and the adoption can be either top-down, driven by the management, or bottom-up, driven by the development unit.Goal: We investigate the perceived problems of bottomup CD adoption in a large global software development unit at Nokia Networks. Our goal is to understand how the stagegate development process used by the unit affects the adoption.Method: The overall research approach is a qualitative single case study on one of the several geographical sites of the development unit. We organized two 2-hour workshops with altogether 15 participants to discover how the stagegate process affected the adoption.Results: The stage-gate development process caused tight schedules for development and process overhead because of the gate requirements. Moreover, the process required using multiple version control branches for different stages in the process, which increased development complexity and caused additional branch overhead. Together, tight schedule, process overhead and branch overhead caused the lack of time to adopt CD. In addition, the use of multiple branches limited the available hardware resources and caused delayed integration.Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for third-party components of this work must be honored. Copyright is held by the owner/author(s). Conclusions: Adopting CD in a development organization that needs to conform to a stage-gate development process is challenging. Practitioners should either gain support from the management to relax the required process or reduce their expectations on what can be achieved while conforming to the process. To simplify the development process, the use of multiple version control branches could be replaced with feature toggles. CCS Concepts.Software and its engineering -+ Agile software development; Waterfall model; Software testing and debugging; Software configumtion management and version control systems;

show abstract

Section: Discussionsupporting

confidence: 87%

“…During the workshop, results from an unpublished systematic literature review (SLR) [17] about CD adoption problems were first presented to the participants. The results were presented organized into the categories of design, integration, testing, release, people, organization, resources and tools problems when adopting CD.…”

Section: Research Goal and Questionsmentioning

confidence: 99%

Bottom-up Adoption of Continuous Delivery in a Stage-Gate Managed Software Organization

Laukkanen

Lehtinen

Itkonen

et al. 2016

Proceedings of the 10th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement

Self Cite

View full text Add to dashboard Cite

show abstract

“…Nonetheless, whilst previous works indicate that an unsuitable architecture would be a major barrier to CD transition [18,19,25,39], there has been little empirical research on the role of SA as a contributing factor when adopting CD practices. Some initial efforts on this topic have been reported in [22-24, 32, 45].…”

Section: Architecting For CI and Cd Practicesmentioning

confidence: 99%

“…The other areas of interest in CD research are focused on improving automation in testing and deployment, and integrating performance and security into the deployment process [18]. It has recently been claimed that the fundamental limitations to adopting CD practices are deeply ingrained in the architecture of a system and these practices may bring substantial architectural implications [1,2,18,19]. Whilst the industrial community, through white papers and practitioners' blogs, has investigated the role of software architecture in CD adoption [2, 20,21], there is little empirical effort to study how software architecture is being impacted by or is impacting CD practices [22][23][24].…”

Section: Introductionmentioning

confidence: 99%

An empirical study of architecting for continuous delivery and deployment

et al. 2018

View full text Add to dashboard Cite

Recently, many software organizations have been adopting Continuous Delivery and Continuous Deployment (CD) practices to develop and deliver quality software more frequently and reliably. Whilst an increasing amount of the literature covers different aspects of CD, little is known about the role of software architecture in CD and how an application should be (re-) architected to enable and support CD. We have conducted a mixed-methods empirical study that collected data through indepth, semi-structured interviews with 21 industrial practitioners from 19 organizations, and a survey of 91 professional software practitioners. Based on a systematic and rigorous analysis of the gathered qualitative and quantitative data, we present a conceptual framework to support the process of (re-) architecting for CD. We provide evidence-based insights about practicing CD within monolithic systems and characterize the principle of "small and independent deployment units" as an alternative to the monoliths. Our framework supplements the architecting process in a CD context through introducing the quality attributes (e.g., resilience) that require more attention and demonstrating the strategies (e.g., prioritizing operations concerns) to design operations-friendly architectures. We discuss the key insights (e.g., monoliths and CD are not intrinsically oxymoronic) gained from our study and draw implications for research and practice.

show abstract

“…However, Alsaqaf et al [10] did so only in the context of large-scale ASD, whereas Villamizar et al [22] examined only how security is handled in ASD. Existing secondary studies of RSD [8,[23][24][25] also do not specifically focus on QRs. This makes it difficult for researchers and practitioners to obtain a clear understanding of QRs and their management in ASD and RSD.…”

Section: Introductionmentioning

confidence: 99%

Management of quality requirements in agile and rapid software development: A systematic mapping study

Behutiye

Karhapää

López³

et al. 2020

Information and Software Technology

View full text Add to dashboard Cite

Context: Quality requirements (QRs) describe the desired quality of software, and they play an important role in the success of software projects. In agile software development (ASD), QRs are often ill-defined and not well addressed due to the focus on quickly delivering functionality. Rapid software development (RSD) approaches (e.g., continuous delivery and continuous deployment), which shorten delivery times, are more prone to neglect QRs. Despite the significance of QRs in both ASD and RSD, there is limited synthesized knowledge on their management in those approaches.Objective: This study aims to synthesize state-of-the-art knowledge about QR management in ASD and RSD, focusing on three aspects: bibliometric, strategies, and challenges. Research method: Using a systematic mapping study with a snowballing search strategy, we identified and structured the literature on QR management in ASD and RSD. Results: We found 156 primary studies: 106 are empirical studies, 16 are experience reports, and 34 are theoretical studies. Security and performance were the most commonly reported QR types. We identified various QR management strategies: 74 practices, 43 methods, 13 models, 12 frameworks, 11 advices, 10 tools, and 7 guidelines. Additionally, we identified 18 categories and 4 non-recurring challenges of managing QRs. The limited ability of ASD to handle QRs, time constraints due to short iteration cycles, limitations regarding the testing of QRs and neglect of QRs were the top categories of challenges. Conclusion: Management of QRs is significant in ASD and is becoming important in RSD. This study identified research gaps, such as the need for more tools and guidelines, lightweight QR management strategies that fit short iteration cycles, investigations of the link between QRs challenges and technical debt, and extension of empirical validation of existing strategies to a wider context. It also synthesizes QR management strategies and challenges, which may be useful for practitioners.

show abstract

Problems, causes and solutions when adopting continuous delivery—A systematic literature review

Cited by 99 publications

References 8 publications

Bottom-up Adoption of Continuous Delivery in a Stage-Gate Managed Software Organization

Bottom-up Adoption of Continuous Delivery in a Stage-Gate Managed Software Organization

An empirical study of architecting for continuous delivery and deployment

Management of quality requirements in agile and rapid software development: A systematic mapping study

Contact Info

Product

Resources

About