Skip to main content
SpringerLink
Log in

An empirical study of architecting for continuous delivery and deployment

  • Published:
Empirical Software Engineering Aims and scope Submit manuscript

Abstract

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 in-depth, 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.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Log in via an institution

Price excludes VAT (USA)
Tax calculation will be finalised during checkout.

Instant access to the full article PDF.

Institutional subscriptions

Fig. 1
Fig. 2
Fig. 3
Fig. 4
Fig. 5
Fig. 6
Fig. 7
Fig. 8
Fig. 9
Fig. 10
Fig. 11
Fig. 12

Similar content being viewed by others

Notes

  1. Note that some of icons used in this figure are taken from freepik.com and thenounproject.com

  2. http://www.qsrinternational.com

  3. http://martinfowler.com/bliki/BoundedContext.html

  4. https://martinfowler.com/articles/feature-toggles.html

  5. http://polysingularity.com/branch-by-abstraction/

  6. https://www.spinnaker.io/

References

  • 2015 State of DevOps Report (2015) Available at:goo.gl/oJ2Tvi [Last accessed: 5 October 2015]

  • Adams B, McIntosh S (2016) Modern release engineering in a nutshell -- why researchers should care. Presented at the IEEE 23rd International Conference on Software Analysis, Evolution, and Reengineering (SANER), 14–18 March, 2016

  • Adrian F (1996) Response bias, social desirability and dissimulation. Personal Individ Differ 7(3):385–400

    Google Scholar 

  • Andre van Hoorn PJ, Leitner P, Weber I (2017) Report from GI-Dagstuhl seminar 16394: software performance engineering in the DevOps world. Available at: https://arxiv.org/abs/1709.08951

  • Arun G (2015) Microservices, monoliths, and NoOps, Available at: goo.gl/zou2x3 [Last accessed: 8 November 2016]

  • Balalaie A, Heydarnoori A, Jamshidi P (2016) Microservices architecture enables DevOps: migration to a cloud-native architecture. IEEE Softw 33(3):42–52

    Article  Google Scholar 

  • Bass L (2017) The software architect and DevOps. IEEE Softw 35(1):8–10

    Article  Google Scholar 

  • Bass L, Jeffery R, Wada H, Weber I, Liming Z (2013) Eliciting operations requirements for applications. In 1st International Workshop on Release Engineering (RELENG), pp. 5–8

  • Bass L, Weber I, Zhu L (2015) DevOps: a software architect's perspective. Addison-Wesley Professional

  • Beijer P, de Klerk T (2010) IT Architecture - Essential Practice for IT Business Solutions. Lulu.com

  • Bellomo S, Ernst N, Nord R, Kazman R (2014) Toward design decisions to enable deployability: empirical study of three projects reaching for the continuous delivery holy grail. Presented at the 44th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN), 23–26 June 2014

  • Bosch J (2016) Speed, data, and ecosystems: the future of software engineering. Software, IEEE 33(1):82–88

    Article  Google Scholar 

  • Brandolini A (2013) Introducing event storming, Available at: goo.gl/GMzzDv [Last accessed: 8 July 2017]

  • Brandtner M, Giger E, Gall H (2015) SQA-mashup: a mashup framework for continuous integration. Inf Softw Technol 65:97–113

    Article  Google Scholar 

  • Braun V, Clarke V (2006) Using thematic analysis in psychology. Qual Res Psychol 3(2):77–101

    Article  Google Scholar 

  • Brown A (2015) What’s the best team structure for DevOps success? Available at: goo.gl/3Z11og [Last accessed: 13 September 2017]

  • Capilla R, Jansen A, Tang A, Avgeriou P, Babar MA (2016) 10 years of software architecture knowledge management: practice and future. J Syst Softw 116:191–205

    Article  Google Scholar 

  • Chen L (2015a) Continuous delivery: huge benefits, but challenges too. IEEE Softw 32(2):50–54

    Article  Google Scholar 

  • Chen L (2015b) Towards architecting for continuous delivery. In 12th Working IEEE/IFIP Conference on Software Architecture (WICSA), pp. 131–134

  • Chris R. (2014). Pattern: monolithic architecture, Available at: goo.gl/royZ7i [Last accessed: 4 November 2016]

  • Cito J, Leitner P, Fritz T, Gall HC (2015) The making of cloud applications: an empirical study on software development for the cloud. In 10th Joint Meeting on Foundations of Software Engineering, Bergamo, Italy, pp. 393–403: ACM

  • Claps GG, Berntsson Svensson R, Aurum A (2015) On the journey to continuous deployment: technical and social challenges along the way. Inf Softw Technol 57:21–31

    Article  Google Scholar 

  • Conway ME (1968) How do committees invent? Datamation 14(5)

  • Cruzes DS, Dyba T (2011) Recommended steps for thematic synthesis in software engineering. In International Symposium on Empirical Software Engineering and Measurement (ESEM), pp. 275–284

  • Debbiche A, Dienér M, Berntsson Svensson R (2014) Challenges when adopting continuous integration: a case study. Cham, pp. 17–32: Springer International Publishing

  • Dooley PM (2015) The intersection of DevOps and ITIL, Available at: goo.gl/tqg2hD [Last accessed: 14 June 2017]. Global Knowledge

  • Dragoni N et al (2017) Microservices: yesterday, today, and tomorrow. In: Mazzara M, Meyer B (eds) Present and ulterior software engineering. Springer International Publishing, Cham, pp 195–216

    Chapter  Google Scholar 

  • Easterbrook S, Singer J, Storey M-A, Damian D (2008) Selecting empirical methods for software engineering research. In: Shull F, Singer J, Sjøberg DIK (eds) Guide to advanced empirical software engineering. Springer London, London, pp 285–311

    Chapter  Google Scholar 

  • Elbaum S, Rothermel G, Penix J (2014) Techniques for improving regression testing in continuous integration development environments. In 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering, Hong Kong, China, pp. 235–245: ACM

  • Erder M, Pureur P (2015) Continuous architecture: sustainable architecture in an agile and cloud-centric world. Morgan Kaufmann

  • Ernst N, Klein J, Mathew G, Menzies T (2017) Using stakeholder preferences to make better architecture decisions. In 2017 IEEE International Conference on Software Architecture Workshops (ICSAW), pp. 133–136

  • Evans E (2004) Domain-driven design: tackling complexity in the heart of softwareT. Addison-Wesley Professional

  • Fitzgerald B, Stol K-J (2017) Continuous software engineering: a roadmap and agenda. J Syst Softw 123

  • Ford N (2016) Architecture is abstract until operationalized, Available at: goo.gl/HorpbH [Last accessed: 21 February 2016]

  • Ford N, Parsons R (2016) Microservices as an Evolutionary Architecture, Available at: goo.gl/aysZvA [Last accessed: 20 March 2016]

  • Fowler M (2013) Continuous Delivery, Available at: goo.gl/gB8sTj [Last accessed: 21 October 2015]

  • Fowler M (2015a) Continuous Integration, Available at: goo.gl/5EhHR7 [Last accessed: 21 October 2015]

  • Fowler M (2015b) MicroservicePremium, Available at: goo.gl/3WVKsn [Last accessed: 31 October 2016]

  • Fowler Jr FJ (2013) Survey research methods. Sage publications

  • Gabhart K (2014) Resilient IT Through DevOps, Available at: https://puppet.com/blog/resilient-it-through-devops/ [Last accessed: 1 July 2017]

  • Garousi V, Felderer M, Mäntylä MV (2016) The need for multivocal literature reviews in software engineering: complementing systematic literature reviews with grey literature. In 20th International Conference on Evaluation and Assessment in Software Engineering, Limerick, Ireland, pp. 1–6, 2916008: ACM

  • Gibson S (2016) Monoliths are bad design... and you know it, Available at: goo.gl/xVEbSE [Last accessed: 4 March 2016]

  • Gitlevich V, Evans E (2015) What is Domain-driven design? Available at: goo.gl/S3zMSR [Last accessed: 21 June 2016]

  • Goodman LA (1961) Snowball sampling. Ann Math Stat 32(1):148–170

    Article  MathSciNet  MATH  Google Scholar 

  • Gousios G, Storey M-A, Bacchelli A (2016) Work practices and challenges in pull-based development: the contributor's perspective. In 38th International Conference on Software Engineering, Austin, Texas, pp. 285–296: ACM

  • Hasselbring W, Steinacker G (2017) Microservice architectures for scalability, agility and reliability in e-commerce. In 2017 IEEE International Conference on Software Architecture Workshops (ICSAW), pp. 243–246

  • Hilton M, Nelson N, Tunnell T, Marinov D, Dig D (2017) Trade-offs in continuous integration: assurance, security, and flexibility. Presented at the Proceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering, Paderborn, Germany

  • Hohpe G, Ozkaya I, Zdun U, Zimmermann O (2016) The software architect's role in the digital age. IEEE Softw 33(6):30–39

    Article  Google Scholar 

  • Hove SE, Anda B (2005) Experiences from conducting semi-structured interviews in empirical software engineering research. In 11th IEEE International Software Metrics Symposium, p. 23, 1092163: IEEE Computer Society

  • Humble J (2011) Organize software delivery around outcomes, not roles: continuous delivery and cross-functional teams, Available at: goo.gl/MnFtJN [Last accessed: 10 August 2016]

  • Humble J (2007) Continuous delivery vs continuous deployment, Available at: goo.gl/qE1JoM [Last accessed: 1 March 2016]

  • Humble J, Farley D (2010) Continuous delivery: reliable software releases through build, test, and deployment automation, 1st ed. Addison-Wesley Professional

  • ISO/IEC/IEEE Systems and software engineering -- Architecture description (2011) ISO/IEC/IEEE 42010:2011(E) (Revision of ISO/IEC 42010:2007 and IEEE Std 1471–2000), pp. 1–46

  • Jiang B, Zhang Z, Chan WK, Tse TH, Chen TY (2012) How well does test case prioritization integrate with statistical fault localization? Information and Software Technology,vol. 54, no. 7, pp. 739–758, 2012/07/01/ 2012

  • Jong Md, Deursen Av, Cleve A (2017) Zero-downtime SQL database schema evolution for continuous deployment. In 39th International Conference on Software Engineering: Software Engineering in Practice Track, Buenos Aires, Argentina, pp. 143–152: IEEE Press

  • Kim EH, Na JC, Ryoo SM (2009) Test automation framework for implementing continuous integration. In Sixth International Conference on Information Technology: New Generations, pp. 784–789

  • Kitchenham BA, Pfleeger SL (2008) Personal opinion surveys. In: Shull F, Singer J, Sjøberg DIK (eds) Guide to advanced empirical software engineering. Springer London, London, pp 63–92

    Chapter  Google Scholar 

  • Kitchenham B, Pickard L, Pfleeger SL (1995) Case studies for method and tool evaluation. IEEE Softw 12(4):52–62

    Article  Google Scholar 

  • Laukkanen E, Lehtinen TOA, Itkonen J, Paasivaara M, Lassenius C (2016) Bottom-up adoption of continuous delivery in a stage-gate managed software organization. In 10th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement, Ciudad Real, Spain, pp. 1–10: ACM

  • Laukkanen E, Itkonen J, Lassenius C (2017) Problems, causes and solutions when adopting continuous delivery—a systematic literature review. Inf Softw Technol 82:55–79

    Article  Google Scholar 

  • Leppanen M et al (2015) The highways and country roads to continuous deployment. IEEE Softw 32(2):64–72

    Article  MathSciNet  Google Scholar 

  • Lewis J, Fowler M (2010) Microservices: a definition of this new architectural term, Available at: goo.gl/me6tp5 [Last accessed: 05 January 2016]

  • Luke E, Prince S (2016) No one agrees how to define CI or CD. Available at: goo.gl/Z8Qonq [Last accessed: 1 August 2016]

  • Mäkinen S et al (2016) Improving the delivery cycle: a multiple-case study of the toolchains in Finnish software intensive enterprises. Inf Softw Technol 80:175–194

    Article  Google Scholar 

  • Manotas I, et al (2016) An empirical study of practitioners' perspectives on green software engineering. In 38th International Conference on Software Engineering, Austin, Texas, pp. 237–248: ACM

  • Mäntylä M, Adams B, Khomh F, Engström E, Petersen K (2015) On rapid releases and software testing: a case study and a semi-systematic literature review," (in English). Empir Softw Eng 20(5):1384–1425

    Article  Google Scholar 

  • Mårtensson T, Ståhl D, Bosch J (2017) Continuous integration impediments in large-scale industry projects. In 2017 IEEE International Conference on Software Architecture (ICSA), pp. 169–178

  • Meade AW, Craig SB (2012) Identifying careless responses in survey data. Psychol Methods 17(3):437

    Article  Google Scholar 

  • Meho LI (2006) E-mail interviewing in qualitative research: a methodological discussion: research articles. J Am Soc Inf Sci Technol 57(10):1284–1295

    Article  Google Scholar 

  • Murphy-Hill E, Zimmermann T, Bird C, Nagappan N (2015) The design space of bug fixes and how developers navigate it. IEEE Trans Softw Eng 41(1):65–81

    Article  Google Scholar 

  • Newman S (2015) Building microservices. O'Reilly Media, Inc

  • Northrop L (2015) Trends and new directions in software architecture, Available at: goo.gl/ZAnkQp

  • Palinkas LA, Horwitz SM, Green CA, Wisdom JP, Duan N, Hoagwood K (2015) Purposeful sampling for qualitative data collection and analysis in mixed method implementation research. Adm Policy Ment Health Ment Health Serv Res 42(5):533–544

    Article  Google Scholar 

  • Pauw Td (2017) Feature Branching is Evil, Available at: https://speakerdeck.com/tdpauw/xp2017-feature-branching-is-evil/ [Last accessed: 27 May 2017]

  • Prewer L (2015) Smoothing the continuous delivery path – a tale of two teams, Available at: goo.gl/1oqjsP [Last accessed: 2 October 2016]

  • Prince S (2016) The product managers’ guide to continuous delivery and DevOps, Available at: goo.gl/D8mGkH [Last accessed: 2 November 2016]

  • Rahman MT, Querel LP, Rigby PC, Adams B (2016) Feature toggles: practitioner practices and a case study. In 2016 IEEE/ACM 13th Working Conference on Mining Software Repositories (MSR), pp. 201–211

  • Rodríguez P et al (2017) Continuous deployment of software intensive products and services: a systematic mapping study. J Syst Softw 123:263–291

    Article  Google Scholar 

  • Savor T, Douglas M, Gentili M, Williams L, Beck K, Stumm M (2016) Continuous deployment at Facebook and OANDA. In 38th International Conference on Software Engineering Companion, Austin, Texas, pp. 21–30: ACM

  • Schauenberg D (2014) Development, deployment and collaboration at Etsy, Available at: goo.gl/umGTM2 [Last accessed: 1 September 2017]

  • Schermann G, Cito J, Leitner P, Zdun U, Gall H (2016) An empirical study on principles and practices of continuous delivery and deployment. PeerJ Preprints 4:e1889v1

    Google Scholar 

  • Seaman CB (1999) Qualitative methods in empirical studies of software engineering. IEEE Trans Softw Eng 25(4):557–572

    Article  Google Scholar 

  • Self-Contained Systems: Assembling Software from Independent Systems (2014) Available at: http://scs-architecture.org/ [Last accessed: 1 June 2017]

  • Shahin M, Babar MA, Zhu L (2016) The intersection of continuous deployment and architecting process: practitioners' perspectives. In ACM/IEEE International Symposium on Empirical Software Engineering and Measurement, Ciudad Real, Spain,, pp. 1–10: ACM

  • Shahin M, Babar MA, Zhu L (2017a) Continuous integration, delivery and deployment: a systematic review on approaches, tools, challenges and practices. IEEE Access 5:3909–3943

    Article  Google Scholar 

  • Shahin M, Babar MA, Zahedi M, Zhu L (2017b) Beyond continuous delivery: an empirical investigation of continuous deployment challenges. In 11th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM), Toronto, Canada: IEEE

  • Shahin M, Zahedi M, Babar MA, Zhu L (2017c) Adopting continuous delivery and deployment: impacts on team structures, collaboration and responsibilities. In 21st International Conference on Evaluation and Assessment in Software Engineering, Karlskrona, Sweden, pp. 384–393: ACM

  • Skelton M (2016) How to break apart a monolithic system safely without destroying your team, Available at: goo.gl/pqBVm2 [Last accessed: 4 November 2016]

  • Skelton M, O'Dell C (2016) Continuous delivery with windows and .NET. O'Reilly

  • Sokhan B (2016) Domain driven design for services architecture, Available at: goo.gl/ftCLnR [Last accessed: 10 January 2016]

  • Ståhl D, Bosch J (2014) Modeling continuous integration practice differences in industry software development. J Syst Softw 87:48–59

    Article  Google Scholar 

  • Suneja S et al (2017) Safe inspection of live virtual machines. In 13th ACM SIGPLAN/SIGOPS International Conference on Virtual Execution Environments, Xi'an, China, pp. 97–111, 3050766: ACM

  • Thiele A (2014) Continuous delivery: an easy must-have for agile development, Available at: goo.gl/ymgCSq [Last accessed: 10 July 2016]

  • Vishal N (2015) Architecting for continuous delivery, Available at: goo.gl/zWA5kT [Last accessed: 15 March 2016]

  • Wallgren A (2015) Continuous delivery of microservices: patterns and processes, Available at: goo.gl/Yk6ddH [Last accessed: 10 February 2018]

  • Waterman MG (2014) Reconciling agility and architecture: a theory of agile architecture. PhD Thesis, Victoria University of Wellington

  • What Team Structure is Right for DevOps to Flourish (2017) Available at: goo.gl/KM6N3p [Last accessed: 24 September 2017]

  • Wnuk K (2017) Involving relevant stakeholders into the decision process about software components. In 2017 IEEE International Conference on Software Architecture Workshops (ICSAW), pp. 129–132

  • Woods E (2016) Operational: the forgotten architectural view. IEEE Softw 33(3):20–23

    Article  Google Scholar 

  • Yaniv Y (2014) Closing the gap between database continuous delivery and code continuous delivery, Available at: goo.gl/mERZcV [Last accessed: 21 August 2016]

Download references

Acknowledgments

The authors would like to thank all participants in this study. This work is partially supported by Data61, a business unit of CSIRO, Australia. The first author is also supported by Australian Government Research Training Program Scholarship. We also greatly appreciate the hard work and time spent by the anonymous reviewers and the handling editor in providing insightful comments and help us to improve the manuscript.

Author information

Authors and Affiliations

  1. CREST - The Centre for Research on Engineering Software Technologies, The University of Adelaide, Adelaide, Australia

    Mojtaba Shahin & Muhammad Ali Babar

  2. CREST - The Centre for Research on Engineering Software Technologies, IT University of Copenhagen, Copenhagen, Denmark

    Mansooreh Zahedi

  3. Data61, Commonwealth Scientific and Industrial Research Organisation, Sydney, NSW, 2015, Australia

    Liming Zhu

Authors
  1. Mojtaba Shahin
    View author publications

    You can also search for this author in PubMed Google Scholar

  2. Mansooreh Zahedi
    View author publications

    You can also search for this author in PubMed Google Scholar

  3. Muhammad Ali Babar
    View author publications

    You can also search for this author in PubMed Google Scholar

  4. Liming Zhu
    View author publications

    You can also search for this author in PubMed Google Scholar

Corresponding author

Correspondence to Mojtaba Shahin.

Additional information

Communicated by: Arie van Deursen

Publisher’s Note

Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Appendices

Appendix 1. Interview Guide

Interviewee’s background

  • Q1. What are your role and responsibilities in the project team?

  • Q2. How long have you performed that role? Are you an architect?

  • Q3. Please talk about the size and domain of your organization.

Project’s description

  • Q4. What is/was the domain and type of project?

  • Q5. Team size: how many people are/were involved in this project?

  • Q6. How often is/was the application in a releasable state? How often do/did you deploy the application to production or the customer?

Operations stakeholders and their requirements

  • Q7. How do/did you consider operations requirements in the design process?

  • Q8. Do/Did you involve operations stakeholders in the decision-making process at the early stage of software development? If so, how?

  • Q9. Do/Did you have any difficulties in prioritizing the concerns of operations stakeholders with other stakeholders? How did you manage them?

Architecture and Continuous Delivery/Deployment Practices

  • Q10. How would you describe the relationship between architecture and CD practice? How does the adoption of CD practice change the architecting process?

  • Q11. How do/did you design the architecture of your system to enable and better support CD practice e.g., improving deployability?

  • Q11.1 How do/did you predict and evaluate the deployability of your software system during the design process?

  • Q11.2 Can you provide one example of architectural decisions you made for improving deployability?

  • Q12. What architecture principles and practices (e.g., patterns, styles, and tactics) did you employ to promote and support CD practice?

  • Q12.1 How do you break down the monolithic applications into independently deployable units/components/services?

  • Q12.2 Are you using any criteria for this purpose?

  • Q12.3 Are you using the microservices style for this purpose? What about other techniques for this purpose?

  • Q13. What challenges do/did you experience whilst designing the application architecture for CD?

  • Q14. What quality attributes are more influenced by the CD context? How is this so?

  • Q15. What quality attributes are in support of or in conflict with deployability? How is this so?

Appendix 2. Survey Questions

Questions

Scale

Demographic Questions

 How many years have you worked in software or IT industry?

0–2 / 3–5 / 6–10 / > 10 years

 What is your role in the development project?

Developer / Architect / Tester / QA / …

 How large is your organization?

1–100 / 101–1000 / >1000 employees

 What is the domain of your organization?

Consulting and IT services / Embedded system/ …

Practicing Continuous Delivery and Continuous Deployment

 On average, how often is your application in a releasable state (i.e., production-ready)?

Multiple times a day / Once a day / A few times (e.g., one or two) a week / A few times (e.g., one or two) a month / A few times (e.g., one or two) a year

 On average, how often do you deploy/release an application to production or the customer environment?

Multiple times a day / Once a day / A few times (e.g., one or two) a week / A few times (e.g., one or two) a month / A few times (e.g., one or two) a year

Operations Stakeholders and their Concerns

 Despite the adoption of CD in my organization, the operations team’s concerns and requirements still have a lower priority than other stakeholders.

Strongly agree / Agree / Neutral / Disagree / Strongly disagree

 To increase the amount of attention paid to operations team and their concerns, my organization has adopted the following strategies:

Prioritizing operations concerns (i.e., consider the operations and their requirements as being as important as others) …

Early and continuous engagement of Ops staff in the decision-making process for the development process (i.e., design process).

Leveraging logs and metric data for operational activities. We collect and structure logs, metrics (e.g., CPU usage) and operational data in appropriate formats to enable …

Other (Specify):

Software Architecture and Quality Attributes in Continuous Delivery and Deployment

 How would you grade the importance of software architecture design in successfully adopting and implementing CD practice?

Very important / Important / Moderately important / Of little importance / Unimportant

 When we are designing the architecture of an application, we also consider the operational aspects, requirements and concerns (e.g., to make the architecture readily supportive of CD).

Almost Always / Often / Sometimes / Rarely / Never

 Operational aspects and concerns impact on our architecture design decisions.

Strongly agree / Agree / Neutral / Disagree / Strongly disagree

 It is “possible” to successfully practice CD in “monolithic applications”.

Strongly agree / Agree / Neutral / Disagree / Strongly disagree

In order to break down (monolithic) applications into smaller and independent units/components/services as STRONGLY recommended by CD practice, how would you define small services/components/units in your organization?

 A component/service is small if it can be scaled independently.

Strongly agree / Agree / Neutral / Disagree / Strongly disagree

 A component/service is small if it can be deployed independently.

Strongly agree / Agree / Neutral / Disagree / Strongly disagree

 A component/service is small if it can be tested independently.

Strongly agree / Agree / Neutral / Disagree / Strongly disagree

 A component/service is small if it can be modified independently.

Strongly agree / Agree / Neutral / Disagree / Strongly disagree

 Can you describe (e.g., in one sentence) how a component or service should be to be suitable for successfully practicing CD?

Free text

 In the projects that have adopted or are adopting CD practice, deployability concerns impact(ed) the design of individual classes.

Almost Always / Often / Sometimes / Rarely / Never

 In the projects that have adopted or are adopting CD practice, deployability concerns impact(ed) the design of individual components/services.

Almost Always / Often / Sometimes / Rarely / Never

 In the projects that have adopted or are adopting CD practice, deployability concerns impact(ed) the design of interactions among components/services.

Almost Always / Often / Sometimes / Rarely / Never

 In the projects that have adopted or are adopting CD practice, deployability concerns impact(ed) the design of an entire application.

Almost Always / Often / Sometimes / Rarely / Never

 In order to improve deployability of an application, I can sacrifice performance, security, usability, etc.

Almost Always / Often / Sometimes / Rarely / Never

 Focusing too much on reusability at component or application level can be a bottleneck to continuously deploying software.

Strongly agree / Agree / Neutral / Disagree / Strongly disagree

 Since moving to CD practice, the need for monitoring (i.e., having a centralized monitoring system) has increased.

Strongly agree / Agree / Neutral / Disagree / Strongly disagree

 Since moving to CD practice, the need for logging (i.e., having a centralized logging system) has increased.

Strongly agree / Agree / Neutral / Disagree / Strongly disagree

 Since moving to CD practice, Domain Driven Design and Bounded Context patterns have been applied MORE often and practiced when designing loosely coupled architectures.

Strongly agree / Agree / Neutral / Disagree / Strongly disagree

 Compared with less frequent releases, we avoid big upfront architectural decisions for CD practices to support evolutionary changes (i.e., architectural decisions are made as late as possible).

Strongly agree / Agree / Neutral / Disagree / Strongly disagree

 CD practice increases the need for resilience (i.e., design for failure).

Strongly agree / Agree / Neutral / Disagree / Strongly disagree

Challenges and Barriers to Adopting Continuous Delivery and Deployment Practices

How important are the following challenges (if any) during adopting and implementing CD and which may put you in trouble?

 Huge dependencies and coordination among software development team members.

Very important / Important / Moderately important / Of little importance / Unimportant

 Difficulty of splitting a (monolithic) application into independently deployable and autonomous components/services.

Very important / Important / Moderately important / Of little importance / Unimportant

 Inflexibility of the organization’s structure with the spirit of CD practice.

Very important / Important / Moderately important / Of little importance / Unimportant

 Difficulty of breaking down a single-monolithic database into smaller and continuously deployable databases (i.e., decentralized data).

Very important / Important / Moderately important / Of little importance / Unimportant

 Difficulty of identifying autonomous business capabilities.

Very important / Important / Moderately important / Of little importance / Unimportant

Rights and permissions

Reprints and permissions

About this article

Check for updates. Verify currency and authenticity via CrossMark

Cite this article

Shahin, M., Zahedi, M., Babar, M.A. et al. An empirical study of architecting for continuous delivery and deployment. Empir Software Eng 24, 1061–1108 (2019). https://doi.org/10.1007/s10664-018-9651-4

Download citation

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s10664-018-9651-4

Keywords

Search

Navigation