GOING ALL in with DEVOPS by Andrew Agerbak, Kaj Burchardi, Steven Kok, Fabrice Lebegue, and Christian N

Total Page:16

File Type:pdf, Size:1020Kb

GOING ALL in with DEVOPS by Andrew Agerbak, Kaj Burchardi, Steven Kok, Fabrice Lebegue, and Christian N GOING ALL IN WITH DEVOPS By Andrew Agerbak, Kaj Burchardi, Steven Kok, Fabrice Lebegue, and Christian N. Schmid or too many companies, moving to In many cases, there is. Agile does a good Fagile software development is like job of breaking down silos early in the soft- finding the perfect new strain of grass ware development process. But it can seed—after months of searching—and achieve only so much on its own. To turn then planting the new seeds in your old themselves into digitally ready competitors, backyard. Your lawn may ultimately look a companies have to rethink the entire soft- little better, but it will take longer and the ware development life cycle. They need results won’t be as great as they would be agile, but they also need DevOps. if you had first removed the hidden tree roots, put in new soil, and rethought the DevOps is an approach that integrates criti- irrigation system. cal late-stage activities—like testing and deployment planning—into the code- Many mainstream companies—in financial writing part of software development. (See services, health care, manufacturing, con- Exhibit 1.) With its emphasis on running sumer packaged goods, and other indus- multiple activities in parallel and on multi- tries—have felt compelled to give agile soft- functional teams, DevOps represents a ware development a try. And they have break from the old “waterfall” model, in waited expectantly for the benefits. In theo- which planning, writing, testing, and de- ry, agile’s assignment of a business leader ploying code were discrete steps managed to development teams ensures that the by separate departments. most important software changes get done first, and its emphasis on short coding While many software companies use some sprints ensures that the changes are imple- form of the continuous software develop- mented quickly. The fact that the quick part ment and release that are the hallmark of doesn’t always happen has been discourag- DevOps, the approach (which continues to ing. It has some agile newcomers wonder- evolve and is starting to be referred to as ing if there’s something they’re missing. DevOps 2.0 or BizDevOps by some of its Exhibit 1 | Where Agile and DevOps Fit in the Software Development Life Cycle Plan Code Build Test Deploy Release Operate Monitor AGILE Business units Integrated business • Teams “own” and are responsible for development teams a software-based product or service IT development DEVOPS Continuous • Daily “builds” of error-free software Application integration development • Automated testing Continuous • Ability to update applications Application delivery automatically across environments maintenance IT operations Continuous • Self-service provisioning of hardware deployment • Automated releases of new software IT operations Continuous monitoring • Applications self-repair and autonomic operations • Capacity adjusted automatically WHO DOES THE WORK Standardized and automated • Virtualization enables server and storage constraints to be addressed automatically IT infrastructure infrastructure management • Modular architecture allows services to be provisioned quickly and cheaply Source: BCG analysis. more advanced practitioners) is a lot newer Today, virtualization makes computing and outside the technology and internet services storage capacity available with less opera- industries. Some traditional companies, tional complexity than before and at far notably in financial services, have some lower cost. But we still see companies tak- DevOps pieces in place, such as automated ing a month and 50-plus emails just to testing and mechanisms for provisioning provision hardware and gather all the nec- hardware quickly. (See “Leaner, Faster, and essary permissions. Better with DevOps,” BCG article, March 2017.) But the scope of these practices is Likewise, a control requiring multiple go- limited. The companies haven’t made the live approvals for new software may have overarching changes that would allow them been justified when there were only a few to capture DevOps’ full range of benefits. software updates a year and each one in- volved a critical part of a monolithic sys- tem. But it shouldn’t require two dozen Making DevOps Work people to approve a minor tweak—like To get the most out of DevOps, companies changing the color of the screen users see. must make changes in controls and gover- nance, IT organization roles, and operating With software now a key way of addressing models. fast-changing business and customer needs, the prolonged delays caused by controls Rethink controls and governance. Most big that have become irrelevant put companies companies’ approach to developing and at a fundamental competitive disadvan- releasing software reflects controls they put tage. The delays can pose a reputational in place years ago to maintain quality and risk and even a survival risk if a company avoid costly mistakes. The controls may is the target of a cyberattack. (See “Devel- have made sense at the outset. But as the op a Cybersecurity Strategy as If Your Or- pace of technological change has accelerat- ganization’s Existence Depends on It,” Oc- ed, the controls have lost their relevance. tober 2017.) Now they’re just obstacles. Governance is another area that requires For instance, a control about infrastructure adjustments in the move to DevOps. This provisioning—one of the hurdles that must includes adopting new approaches to fund- be surmounted before a development team ing. In agile, funding isn’t allocated on a can begin its work—may have been imple- project basis: for a set period of time, mented in the days before virtualization. against a defined set of deliverables. In- The Boston Consulting Group | Going All In with DevOps 2 stead, funding is allocated to critical “prod- teams, which are expected to make the ucts”—like a mutual fund company’s “my fixes. There is no one farther down the line account” function or a retailer’s order-and- who would even think of fixing the code, ship system—that require the attention of and no possibility of different departments teams for many months or even years. touching the same code simultaneously DevOps adds complexity by forcing compa- and working at cross-purposes. nies to figure out how to allocate some ap- plication maintenance and infrastructure Ultimately, the best test of governance costs within the product funding paradigm. practices is cycle time. If companies can substantially reduce the time between Another area where DevOps should trigger when they plan software and when they re- a governance change is in the decision lease it in a reliable, high-quality form, that rights related to cloud solutions. In the is a sign that their governance processes past, these decision rights belonged to the are working and that they have the techni- IT organization, and no one questioned cal capabilities they need. that. But that’s changing as more business units create software directly using cloud- Redefine the role of the CIO and the IT based tools. organization. If DevOps is to succeed, there must be changes—some subtle, some more We saw questions about such decision dramatic—in the role of the chief informa- rights at a company where digital product tion officer and the information technology development teams were pushing for direct organization. In companies that adopt agile access to an Amazon Web Services account, models, the specifications for new soft- and the IT operations group, concerned ware—and the coding work itself—become about standardization and security, was re- the implicit responsibility of business units. sisting. In truth, there is no single right an- If this relieves the CIO of responsibility for swer to the question of where the decision individual lines of code, in most cases he or rights should lie, for this company or any she still shoulders the larger burden of other. But it is an issue that must be tack- quality. That is, the CIO must still recruit led in DevOps, which redraws the boundar- and train software developers. He or she ies of software development along multiple must also put in place a better delivery dimensions. model, one that includes an operating environment—standards, services, process- DevOps should also prompt a change in es, tools, and infrastructure—that allows how companies deal with buggy software. developers to maximize their productivity. At companies that haven’t fully adopted The CIO must also front-load more activi- DevOps, there isn’t a “you built it, you own ties in the software development life cycle. it” governance philosophy. Instead, if an issue arises involving software that has The term of art for this sort of front-loading been released, IT support teams report it is the “shift left,” referring to how one through a ticket system (such as Service- would diagram various activities on a soft- Now), and the issue becomes the responsi- ware development life cycle chart. In bility of an application maintenance team. DevOps, technical staff that would once But the original developer of the code, hav- have sat in the IT operations function— ing gotten wind of a problem, may go back whose work kicks in later—are moved into in and try to fix it. The net result is that the product development teams, where they sometimes both the development and have a say in how the code is built. There maintenance teams end up working on the should also be input early on from those re- same software, at the same time, resulting sponsible for a company’s data architecture in inconsistencies, integration problems, and cybersecurity. The shift left of activity and stability issues. By contrast, at compa- and expertise is one way all the code that’s nies that adopt DevOps practices, issues being created—often in many different with released software automatically regis- business units—can get to market quickly ter on the backlog of the development and with the necessary level of security.
Recommended publications
  • An Analysis of Waterfall to Agile Methodology
    University of New Hampshire University of New Hampshire Scholars' Repository Honors Theses and Capstones Student Scholarship Spring 2016 Information Systems Development Methodologies Transitions: An Analysis of Waterfall to Agile Methodology Oriana Karina Eason University of New Hampshire - Main Campus Follow this and additional works at: https://scholars.unh.edu/honors Part of the Business Commons Recommended Citation Eason, Oriana Karina, "Information Systems Development Methodologies Transitions: An Analysis of Waterfall to Agile Methodology" (2016). Honors Theses and Capstones. 286. https://scholars.unh.edu/honors/286 This Senior Honors Thesis is brought to you for free and open access by the Student Scholarship at University of New Hampshire Scholars' Repository. It has been accepted for inclusion in Honors Theses and Capstones by an authorized administrator of University of New Hampshire Scholars' Repository. For more information, please contact [email protected]. Information Systems Development Methodologies Transitions: An Analysis of Waterfall to Agile Methodology Oriana Eason Advised By: Khole Gwebu The University of New Hampshire Table of Contents 1.0 Introduction ............................................................................................................................... 3 1.1 Background ........................................................................................................................... 3 1.2 Research Justification ..........................................................................................................
    [Show full text]
  • O'reilly- Collaborating in Devops Culture
    Compliments of Collaborating in DevOps Culture Better Software Through Better Relationships Jennifer Davis & Ryn Daniels REPORT Teamwork powers DevOps GitHub powers teams GitHub helps more than two million organizations build better software together by centralizing discussions, automating tasks, and integrating with thousands of apps. Embraced by 31 million developers and counting, GitHub is where high-performing DevOps starts. Get started with a free trial at enterprise.github.com/contact Our on-premises and cloud solutions help enterprise teams: Collaborate Innovate Integrate Work across internal and Bring the power of Build on GitHub and external teams securely. the world’s largest open integrate with everything GitHub Enterprise includes source community to from legacy tools to access to on-premises developers at work, while cutting-edge apps, unifying Enterprise Server as well keeping your most critical your DevOps toolchain as Enterprise Cloud—now code behind the firewall so you can keep things with SOC 1, SOC 2, and ISAE with GitHub Connect. simple as you grow. 3000/3402 compliance. Work fast. Work secure. Work together. Start a free trial To find out more about GitHub Enterprise visit github.com/enterprise or email us at [email protected] Collaborating in DevOps Culture Better Software Through Better Relationships Jennifer Davis and Ryn Daniels Beijing Boston Farnham Sebastopol Tokyo Collaborating in DevOps Culture by Jennifer Davis and Ryn Daniels Copyright © 2019 Jennifer Davis and Ryn Daniels. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use.
    [Show full text]
  • Mobile Phones and Cloud Computing
    Mobile phones and cloud computing A quantitative research paper on mobile phone application offloading by cloud computing utilization Oskar Hamrén Department of informatics Human Computer Interaction Master’s programme Master thesis 2-year level, 30 credits SPM 2012.07 Abstract The development of the mobile phone has been rapid. From being a device mainly used for phone calls and writing text messages the mobile phone of today, or commonly referred to as the smartphone, has become a multi-purpose device. Because of its size and thermal constraints there are certain limitations in areas of battery life and computational capabilities. Some say that cloud computing is just another buzzword, a way to sell already existing technology. Others claim that it has the potential to transform the whole IT-industry. This thesis is covering the intersection of these two fields by investigating if it is possible to increase the speed of mobile phones by offloading computational heavy mobile phone application functions by using cloud computing. A mobile phone application was developed that conducts three computational heavy tests. The tests were run twice, by not using cloud computing offloading and by using it. The time taken to carry out the tests were saved and later compared to see if it is faster to use cloud computing in comparison to not use it. The results showed that it is not beneficial to use cloud computing to carry out these types of tasks; it is faster to use the mobile phone. 1 Table of Contents Abstract ..................................................................................................................................... 1 Table of Contents ..................................................................................................................... 2 1. Introduction .......................................................................................................................... 5 1.1 Previous research ........................................................................................................................
    [Show full text]
  • Descriptive Approach to Software Development Life Cycle Models
    7797 Shaveta Gupta et al./ Elixir Comp. Sci. & Engg. 45 (2012) 7797-7800 Available online at www.elixirpublishers.com (Elixir International Journal) Computer Science and Engineering Elixir Comp. Sci. & Engg. 45 (2012) 7797-7800 Descriptive approach to software development life cycle models Shaveta Gupta and Sanjana Taya Department of Computer Science and Applications, Seth Jai Parkash Mukand Lal Institute of Engineering & Technology, Radaur, Distt. Yamunanagar (135001), Haryana, India. ARTICLE INFO ABSTRACT Article history: The concept of system lifecycle models came into existence that emphasized on the need to Received: 24 January 2012; follow some structured approach towards building new or improved system. Many models Received in revised form: were suggested like waterfall, prototype, rapid application development, V-shaped, top & 17 March 2012; Bottom model etc. In this paper, we approach towards the traditional as well as recent Accepted: 6 April 2012; software development life cycle models. © 2012 Elixir All rights reserved. Keywords Software Development Life Cycle, Phases and Software Development, Life Cycle Models, Traditional Models, Recent Models. Introduction Software Development Life Cycle Models The Software Development Life Cycle (SDLC) is the entire Software Development Life Cycle Model is an abstract process of formal, logical steps taken to develop a software representation of a development process. SDLC models can be product. Within the broader context of Application Lifecycle categorized as: Management (ALM), the SDLC
    [Show full text]
  • Drive Business Growth with Agile Processes Through Devops For
    WHITE PAPER DRIVE BUSINESS GROWTH WITH AGILE PROCESSES THROUGH DEVOPS FOR SAP - Pravas Ranjan Rout Executive summary With the launch of SAP S/4 HANA across the globe, there is a higher risk for release defects and increased cost when migrating from legacy processes. To meet the need for robust and agile process innovation without business disruption, Infosys has designed a DevOps implementation methodology that reduces cycle time, accelerates time-to-market and lowers TCO. This paper explains the key elements in the solution approach to DevOps in SAP along with SAP tools and IPs that assure a risk-free and smooth DevOps transformation. External Document © 2018 Infosys Limited External Document © 2018 Infosys Limited Introduction engagements DevOps is relatively new. This creates significant challenges as In an increasingly technology-driven world, customers use several SAP products during DevOps represents a third-generation implementation and maintenance phases. process innovation framework that extends agile methodology to overcome the This new DevOps process will reduce challenges of collaboration, culture and release cycle time, number of defects automation. As technology evolves, so do during maintenance, and total cost of processes – from waterfall to agile and, ownership (TCO) while accelerating time subsequently, to DevOps. to market. To facilitate a smooth transition from waterfall to DevOps, Infosys has DevOps signifies collaboration between designed an iDEV framework that aligns development and operations teams for with the core metrics of DevOps. With a cohesive and integrated environment. this solution, organizations can accelerate While DevOps has had successful mobile execution with fewer defects in a and cloud implementations, for SAP collaborative and automated environment.
    [Show full text]
  • Distributed Programming with Ruby
    DISTRIBUTED PROGRAMMING WITH RUBY Mark Bates Upper Saddle River, NJ • Boston • Indianapolis • San Francisco New York • Toronto • Montreal • London • Munich • Paris • Madrid Capetown • Sydney • Tokyo • Singapore • Mexico City Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the pub- lisher was aware of a trademark claim, the designations have been printed with initial Editor-in-Chief capital letters or in all capitals. Mark Taub The author and publisher have taken care in the preparation of this book, but make no Acquisitions Editor expressed or implied warranty of any kind and assume no responsibility for errors or Debra Williams Cauley omissions. No liability is assumed for incidental or consequential damages in connection Development Editor with or arising out of the use of the information or programs contained herein. Songlin Qiu The publisher offers excellent discounts on this book when ordered in quantity for bulk Managing Editor purchases or special sales, which may include electronic versions and/or custom covers Kristy Hart and content particular to your business, training goals, marketing focus, and branding Senior Project Editor interests. For more information, please contact: Lori Lyons U.S. Corporate and Government Sales Copy Editor 800-382-3419 Gayle Johnson [email protected] Indexer For sales outside the United States, please contact: Brad Herriman Proofreader International Sales Apostrophe Editing [email protected] Services Visit us on the web: informit.com/ph Publishing Coordinator Kim Boedigheimer Library of Congress Cataloging-in-Publication Data: Cover Designer Bates, Mark, 1976- Chuti Prasertsith Distributed programming with Ruby / Mark Bates.
    [Show full text]
  • A Comparison Between Five Models of Software Engineering
    IJCSI International Journal of Computer Science Issues, Vol. 7, Issue 5, September 2010 94 ISSN (Online): 1694-0814 www.IJCSI.org A Comparison Between Five Models Of Software Engineering Nabil Mohammed Ali Munassar1 and A. Govardhan2 1Ph.D Student of Computer Science & Engineering Jawahrlal Nehru Technological University Kuktapally, Hyderabad- 500 085, Andhra Pradesh, India 2Professor of Computer Science & Engineering Principal JNTUH of Engineering College, Jagityal, Karimnagar (Dt), A.P., India Abstract increased recently which results in the difficulty of This research deals with a vital and important issue in computer enumerating such companies. During the previous four world. It is concerned with the software management processes decades, software has been developed from a tool used for that examine the area of software development through the analyzing information or solving a problem to a product in development models, which are known as software development itself. However, the early programming stages have life cycle. It represents five of the development models namely, created a number of problems turning software an waterfall, Iteration, V-shaped, spiral and Extreme programming. These models have advantages and disadvantages as well. obstacle to software development particularly those Therefore, the main objective of this research is to represent relying on computers. Software consists of documents and different models of software development and make a programs that contain a collection that has been comparison between them to show the features and defects of established to be a part of software engineering each model. procedures. Moreover, the aim of software engineering is Keywords: Software Management Processes, Software to create a suitable work that construct programs of high Development, Development Models, Software Development Life quality.
    [Show full text]
  • Example of Waterfall Model in Software Testing
    Example Of Waterfall Model In Software Testing Jarrett usually sectionalizing frumpishly or feezed paradigmatically when vagrom Jermain bitten laxly and fraudulently. Carlos Teletypes prayerlessly. How turgescent is Albrecht when imperishable and endearing Herby harbinger some progeny? What it to implement and software testing It is especially true for example of waterfall model in software testing! There should there is an example of coding is an app for resource utilization of pure waterfall model we thought of these. Therefore focus on making changes into account for alternative approaches within this example of waterfall in software testing model that. Basic prerequisite for many ways which may have been implemented taking into an extension of the demand that of waterfall model, which aspects is easier and adapted to. In progress within given bug free email address is used for example of waterfall in software testing model. Unlike six methodologies such platform for example of waterfall in software model? Being tested by this browser does not a clear. Methods have at various factors and product, its preceding sprints or evolutionary prototype several years before any personal findings, and technology you. It has been arguing over the design of waterfall model in software testing the user interface. Lucidchart document them responsible for example of waterfall in software testing model. They must also suggested that was laid out the requirements are constantly under requirement change the example of waterfall in software model testing and write the traditional methods, and highly skilled to. Learn more product such as well understood and of waterfall in software model testing and accountability are done to see if a review them throughout the items on.
    [Show full text]
  • Comparative Study of Waterfall Model with RAD Model Sunil D
    e-ISSN: 2349-9745 p-ISSN: 2393-8161 Scientific Journal Impact Factor (SJIF): 1.711 International Journal of Modern Trends in Engineering and Research www.ijmter.com Comparative study of Waterfall model with RAD model Sunil D. Mone1 Assistant Professor in Computer Science,R. C. Patel ACS College, Shirpur-425 405(MS) Abstract:Among numerous software development architecture or para diagrams it is important to choose proper architecture. To choose proper architecture, need to consider some criteria based on which we can compare two or more architectures. In this paper I am trying to compare and see feasibility of Water fall model and RAD model based on criteria like Systematic Development, Team sized required, Speed, Involvement of user, Complexity, Parallel Development, Success Ratio, Passions Required, Capacity to handle large project. It seen that when time is more important in that case RAD model is important while when focus is on systematic Waterfall model is more important. Keywords:Architecture, paradiagrams, waterfall model, RAD model, featuers, feasibility, systematic developemtn, economic I. INTRODUCTION Ther are numerus software development architechtures or software development paradiagrams. Mostly it seen that improper selection of architectuer may lead to unpreditably increase in cost and time or even may leads to failuare. Architecture design plays a prominent role in software engineering processes. Regardless of the variations in software engineering processes, software architecture provides the skeleton and constraints
    [Show full text]
  • Software Development a Practical Approach!
    Software Development A Practical Approach! Hans-Petter Halvorsen https://www.halvorsen.blog https://halvorsen.blog Software Development A Practical Approach! Hans-Petter Halvorsen Software Development A Practical Approach! Hans-Petter Halvorsen Copyright © 2020 ISBN: 978-82-691106-0-9 Publisher Identifier: 978-82-691106 https://halvorsen.blog ii Preface The main goal with this document: • To give you an overview of what software engineering is • To take you beyond programming to engineering software What is Software Development? It is a complex process to develop modern and professional software today. This document tries to give a brief overview of Software Development. This document tries to focus on a practical approach regarding Software Development. So why do we need System Engineering? Here are some key factors: • Understand Customer Requirements o What does the customer needs (because they may not know it!) o Transform Customer requirements into working software • Planning o How do we reach our goals? o Will we finish within deadline? o Resources o What can go wrong? • Implementation o What kind of platforms and architecture should be used? o Split your work into manageable pieces iii • Quality and Performance o Make sure the software fulfills the customers’ needs We will learn how to build good (i.e. high quality) software, which includes: • Requirements Specification • Technical Design • Good User Experience (UX) • Improved Code Quality and Implementation • Testing • System Documentation • User Documentation • etc. You will find additional resources on this web page: http://www.halvorsen.blog/documents/programming/software_engineering/ iv Information about the author: Hans-Petter Halvorsen The author currently works at the University of South-Eastern Norway.
    [Show full text]
  • Git Pull Request Best Practice
    Git Pull Request Best Practice Acquirable Vassili hook: he detribalizing his enervation culturally and afterward. Trinal Jordon screws contingently. Isotheral Ahmet never skydives so clamorously or bemuddled any gators pickaback. To the same major changes that are in a small patches usually better thanks to a pull requests, iterating as pull request best practice to pull, eliminating the reference Any interactions between changes are easy comparison see. In any programmer reading it should ask you should be edited with your pr is mttr for these are a code can scroll horizontally, if some prominent open up. Git integrations with your Git provider. Get thus there after start contributing. One way you are important things go together should also show of your future self a practical. To slab the latest changes made a the upstream branch to encourage local repository, enter in following command. That pull request is git and practices are issues referenced on their own? All pull request best practices is an hour goes. It guides the author. Prs are property of specific line of time best practices, a list based patch. But nonetheless should aim for long and organizational optimization. However, apt can also assign it anywhere any reviewer. Pull request that out the young skywalker you follow the git pull best practice for everyone else to? As pull request best practice where you for git? Future self a branch to the commit is about the correct results. Practically useful pull requests come back in git? This tax would then contain to the changes you share here your code reviewers in the floor step.
    [Show full text]
  • Software Engineering
    Software Engineering Computer Science Tripos 1B Michaelmas 2011 Richard Clayton Managing complexity • Software engineering is about managing complexity at a number of levels • At the micro level, bugs arise in protocols, algorithms etc. because they’re hard to understand • As programs get bigger, interactions between the components grow at O(n2) or even O(2n) • … • With complex socio-technical systems, we can’t predict reactions to new functionality • Most failures of really large systems are due to wrong, changing, or contested requirements Project failure, c. 1500 BC Complexity, 1870 – Bank of England Complexity, 1876 – Dun, Barlow & Co Complexity, 1906 – Sears, Roebuck • Continental-scale mail order meant specialization • Big departments for single book-keeping functions • Beginnings of automation with dictation to recording cylinders and a typing pool to create outgoing letters Complexity, 1940 – First National Bank of Chicago 1960s – The ‘software crisis’ • In the 1960s, large powerful mainframes made even more complex systems possible • People started asking why project overruns and failures were so much more common than in mechanical engineering, shipbuilding, bridge building etc. • Software Engineering as a field dates back to two NATO Science Committee run conferences in 1968 and 1969 • The hope was that we could get things under control by using disciplines such as project planning, documentation and testing How is software different? • Many things that make writing software fun also make it complex and error-prone: • the joy
    [Show full text]