A Survey of DevOps Concepts and Challenges <s> Implications for managers <s> Rally Software transitioned from shipping code every eight-weeks, with time-boxed Scrum sprints, to a model of continuous delivery with Kanban. The team encountered complex challenges with their build systems, automated test suites, customer enablement, and internal communication. But there was light at the end of the tunnel - greater control and flexibility over feature releases, incremental delivery of value, lower risks, fewer defects, easier on-boarding of new developers, less off-hours work, and a considerable up tick in confidence. This experience report describes the journey to continuous delivery with the aim that others can learn from our mistakes and get their teams deploying more frequently. We will describe and contrast this transition from the business (product management) and engineering perspectives. <s> BIB001 </s> A Survey of DevOps Concepts and Challenges <s> Implications for managers <s> Abstract Context Continuous Deployment (CD) is an emerging software development process with organisations such as Facebook, Microsoft, and IBM successfully implementing and using the process. The CD process aims to immediately deploy software to customers as soon as new code is developed, and can result in a number of benefits for organisations, such as: new business opportunities, reduced risk for each release, and prevent development of wasted software. There is little academic literature on the challenges organisations face when adopting the CD process, however there are many anecdotal challenges that organisations have voiced on their online blogs. Objective The aim of this research is to examine the challenges faced by organisations when adopting CD as well as the strategies to mitigate these challenges. Method An explorative case study technique that involves in-depth interviews with software practitioners in an organisation that has adopted CD was conducted to identify these challenges. Results This study found a total of 20 technical and social adoption challenges that organisations may face when adopting the CD process. The results are discussed to gain a deeper understanding of the strategies employed by organisations to mitigate the impacts of these challenges. Conclusion While a number of individual technical and social adoption challenges were uncovered by the case study in this research, most challenges were not faced in isolation. The severity of these challenges were reduced by a number of mitigation strategies employed by the case study organisation. It is concluded that organisations need to be well prepared to handle technical and social adoption challenges with their existing expertise, processes and tools before adopting the CD process. For practitioners, knowing how to address the challenges an organisation may face when adopting the CD process provides a level of awareness that they previously may not have had. <s> BIB002 </s> A Survey of DevOps Concepts and Challenges <s> Implications for managers <s> Context: Development and Operations (DevOps) is an emerging software industry movement to bridge the gap between software development and operations teams. DevOps supports frequently and reliably releasing new features and products-- thus subsuming Continuous Deployment (CD) practice. Goal: This research aims at empirically exploring the potential impact of CD practice on architecting process. Method: We carried out a case study involving interviews with 16 software practitioners. Results: We have identified (1) a range of recurring architectural challenges (i.e., highly coupled monolithic architecture, team dependencies, and ever-changing operational environments and tools) and (2) five main architectural principles (i.e., small and independent deployment units, not too much focus on reusability, aggregating logs, isolating changes, and testability inside the architecture) that should be considered when an application is (re-) architected for CD practice. This study also supports that software architecture can better support operations if an operations team is engaged at an early stage of software development for taking operational aspects into considerations. Conclusion: These findings provide evidence that software architecture plays a significant role in successfully and efficiently adopting continuous deployment. The findings contribute to establish an evidential body of knowledge about the state of the art of architecting for CD practice <s> BIB003 </s> A Survey of DevOps Concepts and Challenges <s> Implications for managers <s> The DevOps phenomenon is gaining popularity through its ability to support continuous value delivery and ready accommodation of change. However, given the relative immaturity and general confusion about DevOps, a common view of expectations from a DevOps role is lacking. Through investigation of online job advertisements, combined with interviews, we identified key Knowledge Areas, Skills and Capabilities for a DevOps role and their relative importance in New Zealand's job market. Our analysis also revealed the global dimensions and the emerging nature of the DevOps role in GSE projects. This research adds a small advanced economy (New Zealand) perspective to the literature on DevOps job advertisements and should be of value to employers, job seekers, researchers as well educators and policy makers. <s> BIB004 </s> A Survey of DevOps Concepts and Challenges <s> Implications for managers <s> It's not magic, it just requires continuous, daily improvement at all levels. <s> BIB005 </s> A Survey of DevOps Concepts and Challenges <s> Implications for managers <s> For many software development teams, the first aspects that come to mind regarding continuous delivery (CD) are the operational challenges and competitive benefits. In the authors’ experience, CD was much more: it was a survival technique. This article presents how and why they applied CD in a large governmental project for the development of a collaborative development environment. They share the challenges they faced and the strategies they used to overcome them. The article concludes with a set of lessons learned that can be valuable for readers in a variety of situations. This article is part of a special issue on release engineering. <s> BIB006
Based on the reviewed literature, we list implications related to how managers must face the DevOps phenomenon: required management and cultural paradigms, training people, structuring and assessing the DevOps-adoption process, as well the expected outcomes from this process. Adoption of lean principles: since DevOps is based on lean principles BIB002 , organizations eager for DevOps adoption should take a step back and learn them  . In particular, Kim recommends  : 1) mapping the value stream for optimizing global system performance, rather than for local optimization; 2) amplifying continuous feedback loops to support necessary corrections; and 3) improving daily work through a culture promoting frequent experimentation, risk-taking, learning from mistakes, and knowing that practice and repetition are prerequisites to mastery. DevOps adoption: how to deploy DevOps in an organization is a critical question for managers. However, the lack of a consensual definition of DevOps is a reason for making it a hard decision. Many studies explore this subject, organizations still struggle with it, and we discuss it in more depth in Section 8.2. Assessment: an organization should be able to measure the success of a DevOps adoption process. Nonetheless, any top-down imposition of a metric-based evaluation must be used with care. If personal evaluation depends on such metrics, engineers can focus on producing good numbers rather than improving the software process  . We further discuss how to assess the quality of DevOps practices in Section 8.3. Training: DevOps demands additional technical skills from software professionals. Developers must acquire skills from operators and vice versa. It is necessary to conduct training in using not only tools but also in using DevOps concepts to keep pace with tooling's rapid pace evolution BIB003 . Top management sponsorship for training is often necessary for many contexts. Job titles: Defining job titles impacts hiring and training. Although the DevOps movement emerged to approximate developers and operators, nowadays, the industry adopts the role of DevOps engineer, which executes tasks mostly linked to scripting automation and CI/CD practices BIB004 . However, this role blurs with other ones, such as release engineer and build engineer. There is no consensus in industry and academia when defining these roles. By analyzing hiring ads, Hussain et al. found that DevOps positions usually do not impose build and release management as attributions BIB004 , whereas Kerzazi and Adams found that these three roles share common activities  . The challenge for managers to define job titles is also related to how to structure development and operations teams, which we discuss in Section 8.2. Culture: Humble stated that, typically, the obstacle to continuous delivery adoption is not the skill level of individual employees, but failures at the management and leadership level BIB005 . Highperforming organizations strive, at all levels, towards continuous improvement, rather than treating workers as fungible "resources" that should merely execute tasks as efficiently as possible BIB005 . Top and low-level management are responsible for creating an environment in which failure is allowed, and people seek continuous improvement. Increase in delivery throughput: Neely and Stolt reported that the delivery throughput per developer in their company increased with the adoption of continuous delivery and defect rate became more predictable BIB001 . Siqueira et al. also reported how, after investments in DevOps and continuous delivery, the number of releases per semester remained the same even after a considerable decrease in the number of team members BIB006 . Building trust: when an organization builds software for other large organization, especially the government, it is common for the relationship between the contractor and contracted to be dominated by mistrust, which leads to cumbersome development processes. However, Siqueira et al. advocate, based on their experience, that continuous delivery leverages a trust relationship among the contractor and contracted in software development, even in governmental projects BIB006 . Building for the government: although building software for government involves more bureaucratic processes, requirements and prioritization can often change due to political reasons BIB006 , which leads to the need to shorten the release cycle by adopting agile and DevOps practices in the governmental scenario.