Devops and Testers White Paper

Total Page:16

File Type:pdf, Size:1020Kb

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. Operations really autonomous; they cannot DevOps can be a solution to a has more visibility into, and some complete their tasks without problem or a goal in itself. In some influence over, the activities of human intervention in maintenance businesses, the goal is going developers. The motivation for or in handling exceptions. A fully digital, and DevOps is part of the this is primarily to speed up the automated DevOps process is overall approach to delivering deployment and implementation meaningless without consideration frequently and with high quality. of software. Bringing Dev and of the human factor. Although tools But in the marketing of DevOps- Ops closer together in an agile do a lot of heavy-lifting, it is the related technologies and services, team effectively implements agile people running the process that this goal can be obscured. The operations. make it work or fail. challenge of making the cultural change (or more concretely, The most obvious outcome of Is DevOps Just Dev and Ops making the behavioral change) successful DevOps implementations Working More Closely with the Aid required for success is frequently is the reduction in the time it takes of Tools? underestimated. for software changes to transition No, DevOps is not that either. from an idea to production. When a Often, the testers involved in and developer says a software change is The hand-offs between automated affected by DevOps are new to done, the transition to production is processes often involve other the whole idea. This article is an performed with the aid of pervasive processes, usually testing of one introduction to DevOps for these automation. kind or another. testers and is a discussion of its impact on test practices. 1 “What is DevOps,” The Agile Admin, http://theagileadmin. com/what-is-devops/ DevOps and Testers White Paper If there is one mantra that best If there are manual interventions, It might be painful describes the drive towards typically between the automated DevOps it is, “If it hurts, do it stages in the DevOps process, we for you, as a tester, to more.” It might be a bit of a cliché, will see these as the pain points. trust developers and but use that as the context for They are bottlenecks, the causes implementing and improving of delays, and the potentially less automation to do the DevOps test practices. reliable and error-prone aspects of testing job properly. If the process. it hurts, you must do it If It Hurts, Do It More Manual testing is painful. Yes, you more often. The difficulty or pain we experience might love exploratory testing; when doing a particular job and you might fear that only you, influences us adversely. If we do not as a human, can find those gnarly like to do a task, we tend to put it bugs that automation will never Is DevOps Just About off. When we finally take the task find, that you as the tester are the on, it is more painful. This is true only person trustworthy enough to Tools? (cont.) for visiting the dentist, cleaning the prevent disaster happening. Automated tests are created garage, integrating software, doing by developers and testers. The testing, and so on. It might be painful for you, as a output of these tests is focused on tester, to trust developers and providing sufficient information to Our experience is commonly that automation to do the testing job other processes, or just as often the less frequently we perform a properly. If it hurts, you must do it to people, to make transitions task, the more traumatic the task more often. between stages in the pipeline. is when we actually do it. Martin Fowler suggests three reasons why Tests, Automation, and Testers and developers who the frequent or even continuous test provide the assurance that execution of certain tasks reduces Trust the DevOps process delivers the pain.3 There is much debate around the successfully and reliably. meaning of checking and testing4, • First, larger, more complex tasks and the reliance we can place are hard to plan, manage, and What is DevOps, Really? on testers, on checks, and on control. Breaking up large tasks automation5, 6. The question is posed and makes them easier to do, less discussed at length in an excellent risky to do and, if something Can we place all our faith in post on the Agile Admin, “What is does go wrong, easier to unwind. automated checks? 2 DevOps” . DevOps is an evolving, • Second, many tasks (and testing We certainly need more emergent discipline. So the is the shining example) provide sophistication than that. But definition of DevOps is still not feedback. Feedback, if received we can, for the purpose of this settled. Perhaps it never will be. early and often, helps us to article, at least separate tests and rapidly address problems before What does that mean for testers? It test execution activity into four any further time is wasted. means that there is still no one true components. way and that your role in a DevOps • Thirdly, if we practice an activity regime that is evolving (and every more frequently, we get better • Checks that can be automated regime is evolving) is not yet fixed. at it. We learn how to do it by developers as part of their There are two main contributions efficiently. We might also see component-level check-in and you can make: opportunities to automate it in continuous integration processes. some way. • Checks that can be automated • You need to pay attention to From the tester’s perspective, the (typically by system testers) to the things that hurt and work to mantra, “It it hurts, do it more,” exercise API-level, link, or end-to- make them less painful. forces us to take the notion of end transactions. • You need to identify the automation in the testing process opportunities and interventions much more seriously. that will add value to the DevOps 4 “Testing and Checking Refined,” James Bach, Michael process. Bolton, http://www.satisfice.com/blog/archives/856 5 “A New Model for Testing,” Paul Gerrard, http://dev.sp.qa/ download/newModel 2 “What is DevOps,” The Agile Admin, http://theagileadmin. 3 “Frequency Reduces Difficulty,” Martin Fowler, http:// 6 “The New Model and Testing v Checking,” Paul Gerrard, com/what-is-devops/ martinfowler.com/bliki/FrequencyReducesDifficulty.html http://blog.gerrardconsulting.com/?q=node/659 DevOps and Testers White Paper Tests, Automation, and • Which checks need only be run once, manually, as opposed to Certainly, you have to Trust (cont.) checks that need to be retained • Tests that can perform for regression purposes, and are stop believing you are compatibility checks to candidates for automation? the gatekeeper of quality, demonstrate compatibility across • We mentioned the notion of browsers, operating systems, and the last defense, the only trust previously. Another way of platforms. looking at this is to speculate on person who cares. You • Tests that can only be performed how a system could be reliably have to think more like a by a human. tested if there were no late In this article, we offer only a manual testing at all. visionary, risk-identifier, few suggestions on how to make • Imagine an environment where risk manager, pathfinder, these distinctions because every all of the testing was done by environment is different, of course. tools. Would your concerns facilitator, and as a coach be dominated by the fact that and mentor. The more germane question to ask you simply do not trust the is, how does the tester let go of developers to do a good job of 7 late, manual checking? Letting go testing? Moving testing thinking One goal of monitoring is to raise requires proactive effort and trust. to the left should reduce the alerts on failure before users doubt. experience the impact of them. This These areas will be the main focus is rather ambitious, but this is the of your efforts: • If, as a tester, you act more as a pathfinder to identify risks ultimate goal.
Recommended publications
  • 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
    [Show full text]
  • 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.
    [Show full text]
  • 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.
    [Show full text]
  • 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.
    [Show full text]
  • Software Engineering Using Devops - a Silver Bullet?
    UPTEC IT 19 002 Examensarbete 30 hp Januari 2019 Software Engineering using DevOps - a Silver Bullet? Mikaela Eriksson Institutionen för informationsteknologi Department of Information Technology Abstract Software Engineering using DevOps - a Silver Bullet? Mikaela Eriksson Teknisk- naturvetenskaplig fakultet UTH-enheten Today we have technology that help us scan millions of medical databases in a glimpse of an eye and self-driving cars that are outperforming humans at driving. Besöksadress: Technology is developing so fast that new updates in the technology world are Ångströmlaboratoriet Lägerhyddsvägen 1 commonplace to us and we are more often frustrated in case something is not up Hus 4, Plan 0 to speed. Technology is moving so quickly and in order for humans to keep up with the development needed in the tech business, different methodologies for how to Postadress: optimise the development process have been applied, some that work better than Box 536 751 21 Uppsala others. But just as fast as the technology changes, the methodologies used change with them. Recently a new term has entered the methodologies field. This Telefon: term is said to bring faster deployment, decreased failures and improved the 018 – 471 30 03 loyalties within the teams. The term in question, is called DevOps. Telefax: 018 – 471 30 00 This study is about uncovering the world of DevOps. This thesis is exploring the term in real teams in order to find out whether or not DevOps is the silver bullet it Hemsida: makes out to be. The study is based on ten interviews with people at different http://www.teknat.uu.se/student organisations, using DevOps, and will find out how these interviewees use and feel about DevOps.
    [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]
  • Devops Engineer
    DevOps Engineer The IHMC Robotics group is looking to fill a DevOps position. The ideal candidate is somebody who is excited about bringing our lab up to speed on how to best use modern solutions for making our software development and release process super repeatable, reliable, and painless. This is a full-time position. We are huge proponents of strong software engineering practices, leveraging the philosophies of test-driven development, continuous delivery/integration, agile programming, repeatable deployments, and many others that make managing diverse teams and complex software easier. Specifically, the DevOps engineer we’re looking for is awesome at: • Automation. Of everything. An obsession with making every aspect of the development and deployment pipeline painless, testable, repeatable, and reliable is a must-have. • Provisioning and configuration management using tools like Puppet, Chef, Ansible, Salt, etc. The tool of choice is open to discussion, but being comfortable with a provisioning oriented workflow is a must. • Automated Continuous Integration and Continuous Delivery. As a Java shop, we use Gradle as our build system. We are just now beginning to migrate to a full continuous delivery workflow; our builds are becoming more automated with regards to artifact generation, artifact hosting, and integration with tools like Docker. The ideal candidate would be willing to grow a system like this in to something with high reliability so it can be a cornerstone of our open source software workflow. Being test-obsessed is desired, both for making sure our CI stack is doing its job and making sure that your infrastructure automation is just as well tested.
    [Show full text]
  • Introduction to Devops on AWS
    Introduction to DevOps on AWS October 2020 Notices Customers are responsible for making their own independent assessment of the information in this document. This document: (a) is for informational purposes only, (b) represents current AWS product offerings and practices, which are subject to change without notice, and (c) does not create any commitments or assurances from AWS and its affiliates, suppliers or licensors. AWS products or services are provided “as is” without warranties, representations, or conditions of any kind, whether express or implied. The responsibilities and liabilities of AWS to its customers are controlled by AWS agreements, and this document is not part of, nor does it modify, any agreement between AWS and its customers. © 2020 Amazon Web Services, Inc. or its affiliates. All rights reserved. Contents Introduction .......................................................................................................................... 1 Continuous Integration ........................................................................................................ 2 AWS CodeCommit ........................................................................................................... 2 AWS CodeBuild ................................................................................................................ 3 AWS CodeArtifact ............................................................................................................ 3 Continuous Delivery ...........................................................................................................
    [Show full text]
  • Contracting for Agile and Devops
    2019 AN EVEREST GROUP VIEWPOINT R Contracting for Agile and DevOps Recommended Practice for Sourcing Yugal Joshi, Vice President Executives Achint Arora, Practice Director Abhishek Mundra, Senior Analyst Copyright © 2019, Everest Global, Inc. All rights reserved. www.everestgrp.com EGR-2019-32-V-3071 2019 CONTRACTING FOR AGILE AND DEVOPS The “as-is” state of Agile contracting Only 27% of firms have Existing adoption reported more than 50% It has been nearly 20 years since the Manifesto for Agile Software Development was of Agile adoption across released; since that time, four key values and 12 principles that form its bedrock have software teams been instrumental in revolutionizing product delivery across industries and organizations. However, even after almost two decades, many enterprises struggle to scale up Agile adoption – in fact, it is only the last two to three years that we have begin to see contracts customized to an Agile delivery model. In an Everest Group research with over 150 C-level executives, we found: ⚫ 46% of the respondents reported that fewer than 30% of their software development teams leverage Agile methodology, which clearly highlights scalability challenges ⚫ 31% of respondents reported challenges in contracting for something that is difficult to define ⚫ 22% indicated that they had trouble aligning on the appropriate performance metrics Our research also suggests that more than 80% of organizations consider themselves to have low maturity in Agile delivery. To address these challenges, enterprises are looking to third-party service providers to help them move toward enterprise Agile delivery. EXHIBIT 1 Agile adoption across enterprises Source: Everest Group Over 90% of organizations are using Agile development methods in some shape or form However, less than 20% organizations consider themselves to have high levels of maturity in the use of Agile In its current form, an Agile contract is shaped in alignment with the delivery methodology and generally consists of the components described ahead.
    [Show full text]
  • A Brief History of Devops by Alek Sharma Introduction: History in Progress
    A Brief History of DevOps by Alek Sharma Introduction: History in Progress Software engineers spend most of their waking hours wading George Santayana wrote that “those who cannot remember the through the mud of their predecessors. Only a few are lucky past are condemned to repeat it.” He was definitely not thinking enough to see green fields before conflict transforms the about software when he wrote this, but he’s dead now, which terrain; the rest are shipped to the front (end). There, they means he can be quoted out of context. Oh, the joys of public languish in trenches as shells of outages explode around them. domain! Progress is usually glacial, though ground can be covered This ebook will be about the history of software development through heroic sprints. methodologies — especially where they intersect with traditional best practices. Think of it as The Silmarillion of Silicon Valley, But veterans do emerge, scarred and battle-hardened. They except shorter and with more pictures. Before plunging into this revel in relating their most daring exploits and bug fixes to new rushing river of time, please note that the presented chronology recruits. And just as individuals have learned individual lessons is both theoretically complete and practically in progress. In other about writing code, our industry has learned collective lessons words, even though a term or process might have been coined, it about software development at scale. It’s not always easy to always takes more time for Best Practices to trickle down to Real see these larger trends when you’re on the ground — buried in Products.
    [Show full text]
  • Ready to Innovate?
    ReadyThe Visual COBOL 5.0to Azure innovate? DevOps and Serverless Computing Walkthrough June 2019 The Visual COBOL 5.0 Azure DevOps and Serverless Computing Walkthrough 2 Visual COBOL 5.0— blue sky thinking Ready to build your Cloud story? This is primarily a how-to technical guide that enables COBOL and non- COBOL developers to modernize legacy applications using the Cloud— it’s all about bridging the old with the new. New to Visual COBOL? This is your guided tour of everything it can do towards modernizing core COBOL applications. Already on board? This is the update that explains how to take your applications beyond the next level and on to the Cloud. What will you learn? Much of this Guide focuses on the technical, practical aspect of creating next-gen apps from COBOL code. Among other new skills, you will discover how to… • Bring a COBOL application into Visual Studio or Eclipse • Edit, compile and debug COBOL applications using the IDE • Modernize COBOL apps using .NET and C# • Create and deploy a COBOL microservice as a Serverless application in the Cloud • Build, test and publish your application via a DevOps pipeline • Understand the latest native Cloud technologies The Visual COBOL 5.0 Azure DevOps and Serverless Computing Walkthrough 3 What’s new in Visual COBOL 5.0? This latest update of our unrivalled development experience significantly extends Visual COBOL’s capabilities. It brings the Cloud closer, enabling access to DevOps and Serverless computing for COBOL systems. For Micro Focus, Visual COBOL 5.0 is where meet our customers’ need for application modernization using the Cloud.
    [Show full text]
  • 25-Microservices-And-Devops As Given
    Microservices + DevOps Charlie Garrod Michael Hilton School of Computer Science 15-214 1 Administrivia • Homework 6 checkpoint – Monday Dec 4th • Final Exam Review: Dec 13th, 2-4pm Wean 5409 • Final Exam: Dec 15th, 5:30-8:30pm Wean 7500 15-214 2 Last Time: • Architectural styles 15-214 3 Simple Layers App 15-214 4 More functionality 15-214 5 Even more functionality 15-214 6 Organize our backend 15-214 7 How to scale? 15-214 8 Monolith • What happens when we need 100 servers? • What if we don’t use all modules equally? • How can we update individual models? • Do all modules need to use the same DB, language, runtime, etc? 15-214 9 Microservices 15-214 10 Microservices should be: • Modelled around business domain • Culture of automation • Hide implementation details • Decentralized governance • Deploy independently • Design for failure • Highly observable 15-214 11 Microservice prerequisites • Rapid Provisioning • Basic Monitoring • Rapid Application Deployment • Devops Culture 15-214 12 15-214 13 Why are microservices such a big deal? 15-214 14 Impact on development practices • Amazon transitioned to “two-pizza” teams • “Full Stack” developers • ”Devops” as a prereq • Live testing and rollback • Migrating from “monolith to microservices” is popular, but comes at a cost 15-214 15 Microservices benefits • Strong Module Boundaries • Independent Deployment • Technology Diversity 15-214 16 Microservices overhead 15-214 17 Microservice costs • Distribution • Eventual Consistency • Operational complexity 15-214 18 Discussion of Microservices
    [Show full text]