Devops: a Software Architect's Perspective
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
Devops and Testers White Paper
White Paper DevOps and Testers DevOps is part of an overall approach that organizations use to deliver software frequently and with high quality. The most obvious outcome of successful DevOps implementations is the reduction in the time it takes for software changes to transition from an idea to production. What Does DevOps Mean If you are an experienced DevOps Automated tools and processes practitioner, we hope that you are used in system configuration, for Testers might still find the article useful. If the build process, testing, the Background you are not a tester, we hope that deployment to test, staging and The DevOps movement (for want you will at least see the tester’s production environments, post- of a better label) is progressing perspective. deployment monitoring, evaluation, rapidly. Like many other and operations. movements in the industry, the What Is DevOps? speed of adoption accelerates Is DevOps Just About faster than the definition of the Simplistically, DevOps is a label movement itself. DevOps is still to describe an ecosystem in Tools? not well defined and the nuances which development teams and At one level, the goal of DevOps of culture, the emergent capability systems operations teams work is to eliminate bottlenecks in of new technologies, and range of more closely together. In the the delivery pipeline through (mostly successful) case studies so-called delivery pipeline, from automation. But the automation means that the issues at hand are committing source code to putting of staged processes still still widely debated.1 code into production, developers requires governance. Most accommodate and automate some automated processes are not Depending on who you talk to, of operations activities. -
Revealing the Secrets of David Parnas
Revealing the Secrets of David Parnas H. Conrad Cunningham Department of Computer and Information Science University of Mississippi March 7, 2014 Those of us in the fast-changing field of computing often dismiss anything writ- ten more than five years ago as obsolete. Yet several decades-old papers by David L. Parnas [1, 4, 5, 6, 7, 8] are as timely as those published in recent issues of the top journals. Parnas articulates the timeless software design concepts known as information hiding and abstract interfaces. Most programmers would describe a module as a unit of code such as a sub- routine or class. Parnas focuses on the programmers rather than the programs. He defines a module as \a work assignment given to a programmer or group of programmers" as a part of a larger software development project [7]. His goals are to enable programmers to develop each module independently, change one module without affecting other modules, and comprehend the overall system by examining one module at a time [5]. Programmers often design a software system by breaking the required pro- cessing into steps and making each step a module. Instead, Parnas uses in- formation hiding to decompose the system into modules that satisfy his goals (2); each module keeps its own secreta design decision about some aspect of the system (e.g., choice of a data structure). A modules design decision can change but none of the other modules should be affected. If some aspect is unlikely to change, the design can distribute this knowledge across several modules and the interfaces among them. -
IBM Developer for Z/OS Enterprise Edition
Solution Brief IBM Developer for z/OS Enterprise Edition A comprehensive, robust toolset for developing z/OS applications using DevOps software delivery practices Companies must be agile to respond to market demands. The digital transformation is a continuous process, embracing hybrid cloud and the Application Program Interface (API) economy. To capitalize on opportunities, businesses must modernize existing applications and build new cloud native applications without disrupting services. This transformation is led by software delivery teams employing DevOps practices that include continuous integration and continuous delivery to a shared pipeline. For z/OS Developers, this transformation starts with modern tools that empower them to deliver more, faster, with better quality and agility. IBM Developer for z/OS Enterprise Edition is a modern, robust solution that offers the program analysis, edit, user build, debug, and test capabilities z/OS developers need, plus easy integration with the shared pipeline. The challenge IBM z/OS application development and software delivery teams have unique challenges with applications, tools, and skills. Adoption of agile practices Application modernization “DevOps and agile • Mainframe applications • Applications require development on the platform require frequent updates access to digital services have jumped from the early adopter stage in 2016 to • Development teams must with controlled APIs becoming common among adopt DevOps practices to • The journey to cloud mainframe businesses”1 improve their -
(Perry & Wolf 92) Software Architecture (Garlan & Shaw
ICS 221, Winter 2001 Software Architecture Software Architecture (Perry & Wolf 92) “Architecture is concerned with the selection of architectural elements, their interactions, and the Software Architecture constraints on those elements and their interactions necessary to provide a framework in which to satisfy the requirements and serve as a basis for the design.” David S. Rosenblum ICS 221 “Design is concerned with the modularization and detailed interfaces of the design elements, their Winter 2001 algorithms and procedures, and the data types needed to support the architecture and to satisfy the requirements.” Software Architecture Software Architecture (Garlan & Shaw 93) (Shaw & Garlan 96) “Software architecture is a level of design that goes “The architecture of a software system defines beyond the algorithms and data structures of the that system in terms of computational computation; designing and specifying the overall components and interactions among those system structure emerges as a new kind of problem. Structural issues include gross organization and components. … In addition to specifying the global control structure; protocols for communication, structure and topology of the system, the synchronization, and data access; assignment of architecture shows the correspondence functionality to design elements; physical between the requirements and elements of distribution; composition of design elements; scaling the constructed system, thereby providing and performance; and selection among design some rationale for the design decisions.” alternatives.” Analogies with Differences Between Civil and Civil Architecture Software Architecture Civil Engineering and Civil Architecture “Software systems are like cathedrals—first we are concerned with the engineering and design of build them and then we pray.” civic structures (roads, buildings, bridges, etc.) — Sam Redwine ! Multiple views ! Civil: Artist renderings, elevations, floor plans, blueprints ! Physical vs. -
Software Architecture and Agility
Agility and Architecture May 18 2010 Agility and Architecture: An Oxymoron? Philippe Kruchten Saturn May 18, 2010 Philippe Kruchten, Ph.D., P.Eng., CSDP Professor of So)ware Engineering NSERC Chair in Design Engineering Department of Electrical and Computer Engineering University of BriIsh Columbia Vancouver, BC Canada [email protected] Founder and president Kruchten Engineering Services Ltd Vancouver, BC Canada [email protected] Philippe Kruchten 1 Agility and Architecture May 18 2010 Agile & Architecture? Oil & Water? • Paradox • Oxymoron • Conflict • IncompaIbility Outline • Agility?? • SoSware architecture? • A story • Seven viewpoints on a single problem • The zipper model • A clash of two cultures • Summary Philippe Kruchten 2 Agility and Architecture May 18 2010 Agility • A definiIon – Agility is the ability to both create and respond to change in order to profit in a turbulent business environment. Jim Highsmith (2002) • CharacterisIcs – IteraIve and incremental – Small release – Collocaon – Release plan/ feature backlog – IteraIon plan/task backlog Sanjiv AugusIne (2004) Agile Values: the Agile Manifesto We have come to value: • Individuals and interacIons over process and tools, • Working soSware over comprehensive documents, • Customer collaboraIon over contract negoIaIon, • Responding to change over following a plan. That is, while there is value in the items on the right, we value the items on the leS more Source: hp://www.agilemanifesto.org/ Philippe Kruchten 3 Agility and Architecture May 18 2010 Geng at the Essence of Agility • SoSware development is a knowledge acIvity – Not producIon, manufacturing, administraIon… • The “machines” are humans • Dealing with uncertainty, unknowns, fear, distrust • Feedback loop -> – reflect on business, requirements, risks, process, people, technology • CommunicaIon and collaboraIon -> – Building trust Named Agile Methods • XP = eXtreme Programming (K. -
Keeping Secrets Within a Family: Rediscovering Parnas
Keeping Secrets within a Family: Rediscovering Parnas H. Conrad Cunningham Cuihua Zhang Yi Liu Computer Science Computer & Information Systems Computer Science University of Mississippi Northwest Vista College University of Mississippi University, MS, 38677 San Antonio, TX 78251 University, MS 38677 Abstract of related programs. The motivation for product lines and frameworks is to take advantage of the David Parnas wrote several papers in the 1970’s commonalities among the members of the product line and 1980’s that are now considered classics. The to lower the overall cost of producing and maintaining concepts he advocated such as information hiding and a group of related software systems. use of abstract interfaces are generally accepted as Since the foundation of software product lines and the appropriate way to design nontrivial software frameworks is what Parnas proposed in his papers, an systems. However, not all of what he proposed has examination of the concepts in these papers (collected been fully appreciated and assimilated into our in [5]) can still reveal much of value to current-day practices. Many of his simple, elegant ideas have software developers and researchers. Many of the been lost amongst the hype surrounding the lessons taught in these works should also be technologies and methods that have arisen in the past incorporated into our college-level teaching. two decades. This paper examines Parnas’s ideas, This paper examines several of the lessons on the especially his emphasis on program families, and design of program families taught by Parnas that are proposes that college-level computing science and still important for contemporary students to learn. -
Designing Software Architecture to Support Continuous Delivery and Devops: a Systematic Literature Review
Designing Software Architecture to Support Continuous Delivery and DevOps: A Systematic Literature Review Robin Bolscher and Maya Daneva University of Twente, Drienerlolaan 5, Enschede, The Netherlands [email protected], [email protected] Keywords: Software Architecture, Continuous Delivery, Continuous Integration, DevOps, Deployability, Systematic Literature Review, Micro-services. Abstract: This paper presents a systematic literature review of software architecture approaches that support the implementation of Continuous Delivery (CD) and DevOps. Its goal is to provide an understanding of the state- of-the-art on the topic, which is informative for both researchers and practitioners. We found 17 characteristics of a software architecture that are beneficial for CD and DevOps adoption and identified ten potential software architecture obstacles in adopting CD and DevOps in the case of an existing software system. Moreover, our review indicated that micro-services are a dominant architectural style in this context. Our literature review has some implications: for researchers, it provides a map of the recent research efforts on software architecture in the CD and DevOps domain. For practitioners, it describes a set of software architecture principles that possibly can guide the process of creating or adapting software systems to fit in the CD and DevOps context. 1 INTRODUCTION designing new software architectures tailored for CD and DevOps practices. The practice of releasing software early and often has For clarity, before elaborating on the subject of been increasingly more adopted by software this SLR, we present the definitions of the concepts organizations (Fox et al., 2014) in order to stay that we will address: Software architecture of a competitive in the software market. -
Reflections on Software Architecture Linda Northrop SEI Fellow
Reflections on Software Architecture Linda Northrop SEI Fellow Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213 © 2016 Carnegie Mellon University Distribution Statement A: Approved for Public Release; Distribution is Unlimited Notices Copyright 2016 Carnegie Mellon University This material is based upon work funded and supported by the Department of Defense under Contract No. FA8721-05-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the United States Department of Defense. NO WARRANTY. THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN “AS-IS” BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT. [Distribution Statement A] This material has been approved for public release and unlimited distribution. Please see Copyright notice for non-US Government use and distribution. This material may be reproduced in its entirety, without modification, and freely distributed in written or electronic form without requesting formal permission. Permission is required for any other use. Requests for permission should be directed to the Software Engineering Institute at [email protected]. Carnegie Mellon® and CERT® are registered marks of Carnegie Mellon University. -
Devops Point of View an Enterprise Architecture Perspective
DevOps Point of View An Enterprise Architecture perspective Amsterdam, 2020 Management summary “It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change.”1 Setting the scene Goal of this Point of View In the current world of IT and the development of This point of view aims to create awareness around the IT-related products or services, companies from transformation towards the DevOps way of working, to enterprise level to smaller sizes are starting to help gain understanding what DevOps is, why you need it use the DevOps processes and methods as a part and what is needed to implement DevOps. of their day-to-day organization process. The goal is to reduce the time involved in all the An Enterprise Architecture perspective software development phases, to achieve greater Even though it is DevOps from an Enterprise Architecture application stability and faster development service line perspective, this material has been gathered cycles. from our experiences with customers, combined with However not only on the technical side of the knowledge from subject matter experts and theory from organization is DevOps changing the playing within and outside Deloitte. field, also an organizational change that involves merging development and operations teams is Targeted audience required with an hint of cultural changes. And last but not least the skillset of all people It is specifically for the people within Deloitte that want to involved is changing. use this as an accelerator for conversations and proposals & to get in contact with the people who have performed these type of projects. -
Automated Software Process Performance Analysis and Improvement Recommendation
FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO Automated Software Process Performance Analysis and Improvement Recommendation Mushtaq Raza MAP-i Doctoral Program in Computer Science Supervisor: João Pascoal Faria June 27, 2017 c Mushtaq Raza, 2017 Automated Software Process Performance Analysis and Improvement Recommendation Mushtaq Raza MAP-i Doctoral Program in Computer Science Dissertation submitted to the Faculty of Engineering, University of Porto in partial fulfillment of the requirements for the degree of Doctor of Philosophy Approved by: President: Dr. Eugénio da Costa Oliveira Referee: Dr. António Manuel Ferreira Rito da Silva Referee: Dr. Paulo Jorge dos Santos Gonçalves Ferreira Referee: Dr. Fernando Manuel Pereira da Costa Brito e Abreu Referee: Dr. Ademar Manuel Teixeira de Aguiar Supervisor: Dr. João Pascoal Faria June 27, 2017 Abstract Software development processes can generate significant amounts of data that can be periodically analyzed to identify performance problems, determine their root causes and devise improvement actions. However, there is a lack of methods and tools for helping in that kind of analysis. Con- ducting the analysis manually is challenging because of the potentially large amount of data to analyze, the effort and expertise required and the lack of benchmarks for comparison. Hence, the goal of this dissertation is to develop methods, models and tools for automating the analysis of process performance data and identifying and ranking performance problems and their root causes, reducing effort and errors and improving user satisfaction as compared to previous approaches. The main contributions of the dissertation are a novel method for process performance analysis and improvement recommendation (the ProcessPAIR method), a support tool (the ProcessPAIR tool), and a performance model for instantiating ProcessPAIR for the Personal Software Process (the ProcessPAIR model for the PSP). -
Continuous Testing for Devops Evolving Beyond Simple Automation
Technical Whitepaper 1 Continuous Testing for DevOps Evolving Beyond Simple Automation INTRODUCTION DevOps represents a cultural shift that stresses collaboration be- on acceleration. Moreover, adopting a bona fide Continuous Testing tween the business, developers, and IT professionals. Software test process (more than just automated tests running regularly) helps automation can enhance these connections and help organizations promote all of the core pillars of DevOps: Culture, Automation, Lean, achieve desired SDLC acceleration, but it’s important to recognize Metrics, and Sharing. that automation is just one piece of the DevOps puzzle. In this paper, we’ll explore why and how Continuous Testing’s real- Since testing is often one of the greatest constraints in the SDLC, time objective assessment of an application’s business risks is a optimizing quality processes to allow testing to begin earlier, as well critical component of DevOps. as shrink the amount of testing required, can have a marked impact DEVOPS PRINCIPLES There are several key pieces to understanding DevOps revolutions and they are often brought about by a compelling event at an organization, such as a shift to agile. As organizations start to move into an agile development methodology, they start to uncover other processes that can be accelerated, such as delivery by DevOps and testing by Continuous Testing. The acceleration that is set in motion via agile makes it necessary to accelerate the release schedule. In order to ensure a successful release, an organization must adopt continuous testing to make sure the conveyer belt does not break down. The modernization maturity model has these three distinct phases: AGILE Agile software development is a different way of thinking about approaching the challenge of development time. -
Stephan Goericke Editor the Future of Software Quality Assurance the Future of Software Quality Assurance Stephan Goericke Editor
Stephan Goericke Editor The Future of Software Quality Assurance The Future of Software Quality Assurance Stephan Goericke Editor The Future of Software Quality Assurance Editor Stephan Goericke iSQI GmbH Potsdam Germany Translated from the Dutch Original book: ‘AGILE’, © 2018, Rini van Solingen & Manage- ment Impact – translation by tolingo GmbH, © 2019, Rini van Solingen ISBN 978-3-030-29508-0 ISBN 978-3-030-29509-7 (eBook) https://doi.org/10.1007/978-3-030-29509-7 This book is an open access publication. © The Editor(s) (if applicable) and the Author(s) 2020 Open Access This book is licensed under the terms of the Creative Commons Attribution 4.0 Inter- national License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence and indicate if changes were made. The images or other third party material in this book are included in the book’s Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the book’s Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use.