devopsy.kinsta.cloud

Category: Continuous Delivery

Continuous delivery is a software engineering discipline that allows organizations to consistently develop and release quality software at a rapid pace. It is achieved by automating the software development lifecycle, enabling tasks such as development, testing and release to occur concurrently and continuously.

  • DevOps Chat: Aruna Ravichandran, Co-Author, DevOps for Digital Leaders

    DevOps Chat: Aruna Ravichandran, Co-Author, DevOps for Digital Leaders

    Our first podcast of 2017 is with Aruna Ravichandran, co-author of DevOps for Digital Leaders. Of course when not authoring books or helping financially challenged but gifted students attend college, Aruna is a VP of DevOps marketing at CA Technologies. I have interviewed Aruna before on DevOps TV and discussed her career that has seen her go from a million lines of code contributor at HP and Juniper to business line executive.

    Aruna is a very interesting person who also has some great things to share. That is why I think you will find not only this DevOps Chat interesting, but her book as well.  Also, we will be doing a full hour Q & A with Aruna on January 17th that you can sign up and attend for free. If you like this interview, don’t miss the webinar. Also, if you would like to download the book you can here: http://www.apress.com/us/book/9781484218419

    In the meantime, as is usual on our DevOps Chats below is a streaming audio of our Chat with the written transcript below. Enjoy!

    Alan Shimel:                Hey everyone, Alan Shimel here with our first DevOps chat of 2017 and we’re lucky to have Aruna Ravichandran, a VP DevOps Marketing at CA Technologies. Aruna welcome.

    Aruna Ravichandran: Thank you Alan. Thanks for actually having me. I’m excited to be here with you.

    Alan Shimel:                Well, you are leading of 2017 so we’re going to set the bar high right away Aruna and hope to live up to it.

    But Aruna, truth be told, we don’t have you on today in your VP of DevOps role: you’re here as Aruna the author today and we’re going to talk about a book that actually came out I guess towards the end of last year but it’s still out there and we’re going to be doing a webinar on it later this month, and I wanted to really talk to you about that a little bit.

    The book is called DevOps for Digital Leaders. Correct?

    Aruna Ravichandran: Yes, that’s correct.

    Alan Shimel:                And why don’t – just from the get-go why don’t you give our listeners a little bit of an overview of what the book is about.

    Aruna Ravichandran: Sounds good. So this book is called DevOps for Digital Leaders, it’s all about how one can reignite their business with a modern DevOps-enabled software factory. I embarked on this journey on writing this book almost about a year-and-a-half ago along with two of my co-authors Karen Taylor as well as Peter Waterhouse.

    We looked at all the different books within the market – there is no dearth for books in the market when you think about DevOps – but what we saw was that even though there are so many different books in the market nothing really talks about some of the pain points which we constantly encounter customers asking us when we talk to them.

    Some of the pain points which customers constantly ask us are, “I want to be able to start this journey called DevOps. How do I start? What should my journey be? Where can I start? How do I develop? What should be my maturity model?” And so that’s one question which we constantly get across the board.

    Second pain point which we have heard from customers is, “How do I actually measure the success of DevOps? What kind of metrics can I use? How is success actually going to look like which I can report back to my management chain that whatever initiative I have embarked on with DevOps is now actually successful?”

    So we talked to several – over 100-plus customers – we learned from their experiences on what metrics are actually used and what is actually built practically in the industry and shared those in the form of use cases as well as actual metrics in the book.

    So the book primarily focuses on DevOps adoption in terms of a journey as well as what are some of the key metrics one can actually use in order to embrace DevOps.

    Alan Shimel:                Great. Aruna you hit on a couple things that are kind of near and dear to me. One is something that I’ve spoken about and talked to people now for a while which is too many people – you know, DevOps is so hyped and so many people are positioning DevOps to be, you know, it’s this great, white unicorn that’s crapping out rainbows for everyone but it doesn’t always work like that, right?

    There are failures, there are challenges, there are hurdles, and not everyone who just wants to do DevOps can wave a magic wand and become a DevOps factory or a modern software factory. So I’m glad to hear that this is kind of something that you guys are exposing in the book.

    The other thing is, you know, in almost three years of doing devopsy.kinsta.cloud now I find that our listeners, our readers learn the most from listening to how their peers have dealt with stuff: so case studies, case scenarios and these kinds of things. So the fact that you had access to hundreds – literally hundreds if not thousands – of customers who CA Technologies – CA has worked with – really gives us some great insight.

    Can you give our listeners a little bit of a taste for the kind of – I know you call them case scenarios – and they’re kind of case studies, right? – can you give us a little flavor for what those are like?

    Aruna Ravichandran: Yeah, absolutely. So if you look at the book it’s organized across the entire software factory. Let’s say if you think about customer deployments DevOps basically goes all the way down from planning to requirements to development, testing, release, and then into operations.

    And so what we did was we talked to – we interviewed several different practitioners who are existing CA customers, sometimes we even talk to non-CA customers – understood the role DevOps plays in terms of culture and collaboration as well as the toolsets which they’re actually leveraging in order to implement DevOps within their companies.

    And we looked at – we _____ the use cases around the whole software delivery to the chain. So if you look at the book – even though we talked with several thousand customers – you know, we couldn’t basically put all those case studies within the book, so what we did was we broke up the book across the entire software delivery chain and there is a chapter dedicated for every aspect of the software factory starting from planning to development to testing to release to operation and we leveraged one customer example on how they actually implemented DevOps best practices along with the underlying toolset and what are some of the metrics or the results they actually got in terms of being able to show what success actually looks like.

    Alan Shimel:                Got it. So Aruna I wanted to touch on another aspect of DevOps adoption that you hit on in the book, and that is the idea that not everyone started their DevOps journey at the same time or are going at the same speed or at the same rate, right? Some organizations are relatively mature in their DevOps adoption and DevOps practices: others are still talking about starting. So is there something for everyone in the book or do you need to be sort of on-your-way DevOps expert to really get value?

    Aruna Ravichandran: No. So, you know, like I said because we knew that there is no clear-cut framework, right – like if you think about I-_____ there is a very prescriptive framework in terms of where you can actually start and how you can actually end. With DevOps one can start many different ways.

    So what we actually did was we looked at some of the best practices a lot of the customers have actually implemented and built a framework in terms of a maturity model and we shared that as best practices.

    So if you think about accelerating the maturity we talk about, you know, three different examples of how customers could actually start. The first way is to basically build an end-to-end release management system; and the second one is to how can you operationalize with feedback loops going all the way from Dev to Ops and vice versa.

    And the last one is how could you actually optimize the continuity stability pipeline?

    So we shared some of the best practices in terms of where one can actually start and how they can actually modify their processes to give them a lifecycle regardless of where they want to start. They could start in Dev and end in Ops; they could start with Ops and make changes to Dev. But we shared some of the best practices in terms of maturity model which customers can actually implement.

    Alan Shimel:                Excellent. Aruna, again, we only have 12 minutes or so on these podcasts but we’re going to spend about an hour – 45 minutes plus 15 minutes in questions – on an interactive Q&A webcast with you on this subject.

    And I just wanted to, in our remaining time here, remind everyone or let everyone know that the webinar is scheduled for January 17th – so about two weeks from today or so – a little less than two weeks – at 2:00 PM Eastern Time. And within these show notes – if you’re listening to this on Sound Cloud or iTunes – within the show notes there we’ll have a link to the webinar. And if you’re reading along or listening on devopsy.kinsta.cloud we’ll have a link to the registration there as well. You can get to the registration on devopsy.kinsta.cloud – go to the webinar section and of course it will be listed there.

    But importantly Aruna I wanted to mention the book itself is free, correct, for download?

    Aruna Ravichandran: So the software version of the book is free. If they want to get the hardcopy they can buy it through Amazon or through our publisher which is Apress. I also want to call out and say that if they buy a hardcopy version of the book we are donating all the proceeds – the royalty from the book are being donated to a nonprofit corps Foundation of Excellence – the Foundation of Excellence’s mission is to award university scholarships for exceptionally talented but economically underprivileged high school graduates in India in order to embrace stem carriers.

    And so they can either go through the softcopy of the book or they can download the hardcopy and that all of their contributions are going to be donated to the nonprofit.

    Alan Shimel:                That’s great Aruna. Fantastic. I also want to mention that for those who register and attend our webinar we are going to give out ten signed copies – signed by Aruna and her co-authors – to ten folks who attend the webinar. I have to mention that those are US-based folks only as the logistics of mailing hardcopy books make it prohibitive to send them across the oceans. But ten US attendees will win signed copies of the book and everyone who attends will get a link to download the soft version, and of course you can buy the hardcopy version – the hard-book version on Amazon or Apress. Again, we can register that at devopsy.kinsta.cloud.

    Aruna, we’re almost here at the end but just to give some of the people – some of our listeners a little tease of what we’ve got going on. I know there’s some CA-sponsored DevOps research that’s due out shortly and that kind of reinforce this idea that organizations that do DevOps are doing better. Can you give us a preview or you’re not allowed yet?

    Aruna Ravichandran: I can give a little bit of preview. But what I can say is we did our research with one of our analyst vendors and partners with over 1,200 participants around DevOps and what I can say is that 87 percent of DevOps adopters have reported an improvement in customer experience.

    There is a lot of rich statistics which we uncovered as a result of that particular survey and we will be able to share the results from that particular survey report on January 11.

    Alan Shimel:                Great. Maybe we can speak about it a little bit on the webinar for January 17 as well – or incorporate it into –

    Aruna Ravichandran: Absolutely we will.

    Alan Shimel:                That sounds great. Well, Aruna, we certainly look forward to the webinar on January 17, but more, you know, as importantly, congratulations on authoring or co-authoring what sounds like a great book, and kudos actually for your donating the proceeds of the book to a worthy cause: I think it says a lot about who you are and what are the kind of reasons behind that, so thank you.

    Anything else before we wrap up?

    Aruna Ravichandran: Nope. I’m very excited to partner with you in order to share our experiences around writing this book and the journey, and hope that this book will be insightful for all of our DevOps practitioners who are embarking or are already on their way within DevOps.

    Alan Shimel:                Okay. Well, Aruna Ravichandran, co-author of DevOps for Digital Leaders, thank you so much for appearing on this episode of DevOps chats and we look forward to our interactive Q&A webinar on January 17 at 2:00 PM with you to continue our discussion. Thank you.

    Aruna Ravichandran: Thank you Alan.

    Alan Shimel:                Thank you. This is Alan Shimel for devopsy.kinsta.cloud and we’ll see you soon on another DevOps chat.

    — Alan Shimel

  • Customer Demands Outpacing Business Requirements

    Customer Demands Outpacing Business Requirements

    As more organizations adopt agile and DevOps, many recognize quickly that the related gains are significant but further business efficiencies can be realized.

    IT and the business now are working closer than ever. No longer is the business throwing requirements over the wall into the IT “sausage factory”—they’re now an integral part of the entire process. IT has finally transitioned into a profit center.

    In the application economy, it’s not the layout or cleanliness of your brick and mortar store nor the friendliness of a customer service representative that makes your business successful. It’s the application’s user experience.

    As a result, the gains we’re seeing must be optimized continuously. One of the biggest challenges we face today lies in how we get business requirements translated into IT output, at the speed of business.

    In the old days, it was easy to move your best-selling, highest margin products into the ideal location or open another checkout when the lines got too long. With today’s virtual stores, the question becomes, How can we quickly pivot to tend to our real-time customer needs and shareholder expectations?

    We must be able to deliver software faster, and to do that, we need to marry our strategy to execution and delivery. We must optimize across the entire business to create true agility that paves the way for reactive and proactive acceleration.

    Case in point: If you optimize execution but not delivery, you’ll be creating software that cannot realize value at the pace of development. In reverse: If you optimize delivery but develop software slowly and poorly, your efficient delivery process will merely sit waiting—or worse yet, deliver poor quality software quickly.

    As a result, we must optimize all three of these areas while working in conjunction, overlapping and providing constant feedback and properly timing the impact of revenue and potential risk to customer experience.

    Unsurprisingly, to support all of this, we’re also seeing broader adoption of an end-to-end solution stack that supports acceleration of process from ideation through outcome. Let me walk you through this scenario:

    Your business is managing your strategy through the lens of its portfolio. As changes are set in motion at the highest levels, that data must be tracked—how much it costs to implement new functionality, how much time it should take and what ROI looks like—along with constant reviews to inform ongoing decision making.

    Your portfolio decisions are then loaded and tracked systematically at the project level, with resources assigned systematically to deliver the designed functionality through epics and user stories. Related data must also be made available in real time to be viewed at the program, project, epic or user story level, providing complete visibility from the level of developers all the way up to the board of directors.

    Simultaneously, your user stories must be imported into a system that turns them into test cases and test automation assets, then builds the test data synthetically to validate each test case. Once the data is generated, it’s imported into your service virtualization system, where application behavioral virtualization eliminates the need for constrained and non-existing back-end systems, simulating an end-to-end environment for any application that is being tested. This also should update your virtual services automatically with the data required for the test cases and any planned test automation.

    Let’s pause and review what we just did.

    We’re now managing our new functionality items across portfolio, program, project, user story and resource levels, all in real time. We’ve automatically created our test cases, test automation, test data and virtual services, all from the epics and user stories.

    So what have we done? We’ve provided the visibility and insight necessary to make business decisions in real time and track progress. We’ve also also minimized the need for test-case designers (or the business analysts that create them), test automation engineers, test data engineers and the DBA support for test data, freeing these experts to focus on other activities.

    Hopefully, we’ve achieved the desired result of massive reduction in resource allocation, acceleration of the entire software development life cycle, elimination of error-prone manual tasks and, most importantly, elimination of the ambiguity involved in translating actual requirements into test cases.

    Finally, we’ve now got all the necessary elements—team execution, prioritization by value, connection of value to execution, a platform that provides a single source of the truth, communication, and metrics—that will allow you to focus on creating value for your customers, instead of simply creating process.

    Transformation is difficult. Culture/environment eats process for breakfast. However, by focusing on changing your entire approach instead of merely recasting process and teams, you can truly change how you provide value to your customers and shareholders.

    This is how we translate business requirements into innovative software at speed.

    For added perspective on all things DevOps and Continuous Delivery, join my colleague Aruna Ravichandran for a live webcast highlighting the details of her new book “DevOps for Digital Leaders”—it’s sure to be an exciting discussion.

    — Ron DeCanio

  • 15 DevOps Expert Opinions on Continuous Integration and Delivery

    15 DevOps Expert Opinions on Continuous Integration and Delivery

    We at Shippable recently approached some DevOps experts and asked them what they really think about continuous integration (CI) and continuous delivery (CD). The responses were just amazing, proving that CI/CD’s future is just bright and long in the software development process.

    Perhaps this insight might be of help to organizations, regardless of whether they already practicing CI/CD or have yet to adopt it in their organization.

    Sit back, relax and read these opinions from DevOps Experts:

    1. Chris Nwamba

    Chris Nwamba is a self-described code beast who works with scotch.io. “Continuous integration is simply ‘building big and shipping small,’” he said. “The developer or engineer is not expected to produce a complete result; the project is divided into milestones and he or she can produce the expected output for each milestone which is reviewed and pushed. Continuous delivery, on the other hand, involves delivering and deploying a tested and usable feature to the end user as soon as it is available from the engineer. No constraints such as milestones or daily reports are placed on the engineer; rather, the product is delivered when it is ready and tested within a reasonable amount of time.”

    2. David Bernstein

    David Bernstein is the author of “Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software.” He says, “I’ve written a lot about CI and CD. It’s one of the nine core practices in my new book. The first principle of the Agile Manifesto is, ‘Our highest priority is to satisfy the customer through the early and continuous delivery of valuable software.’ The practice of continuous delivery is the only way I know to achieve this principle and is at the very core of Agile software development.”

    3. Tomohiro Iizuka

    Tomohiro Iizuka is a full-stack web application developer. He says, “Continuous integration and delivery are still at the frontier of IT technology, like NoSQL. It will change the business style of freelance engineers. Businesses using cloud servers will especially change. However, there are some issues to solve in order to execute it. An IT system consists of some subsystems that affect how teams work together on development and management after the first release. If an engineer can provide a subsystem that’s comprehensive to end users, freelance engineers can have their own product and they can concentrate on maintaining their own product continuously. That will make use of cloud platforms more popular, and they can have opportunities to gain profit continuously in addition to development fees. Open-source products like Eclipse, Firefox, WordPress are some examples. However, in general, that is not done. I think that the platform for making independent software components is necessary for freelance engineers to make new businesses with continuous integration and delivery.”

    4. Anubhava Srivastava

    DevOps expert Anubhava Srivastava is a lead engineer-architect at AOL Inc. According to him, some of the advantages of CI and CD are: “DevOps and CI/CD give more power to developers. Developers have greater control over the application stack and require access to production servers. The exact same repeatable deployment process is used across different environments like dev, QA, staging and production. Everything is automated right after code is checked in. There’s fast and quick resolution time for emergencies. Due to code coverage reports being monitored and shared widely, developers are forced to write test cases for every line and every condition in the code. Due to stress on TDD, developers are producing higher-quality applications with significantly fewer bugs. It has definitely helped the organization, as they don’t need the same headcount for QA and Ops teams anymore.”

    5. Erik Dietrich

    Erik Dietrich is the founder and principal of DaedTech, LLC. He says, “In short, both of those [CI and CD] are practices that I endorse and help people move towards. On the whole, I’m a huge fan of automating the automatable to avoid mistakes and save time.”

    6. Tom Zorde

    Tom Zorde is an enterprise architect at Monadelphous. He says, “There is an inevitable need for CI, no doubt. But developers need to have autonomy to self-elect to skip a check-in if they don’t feel their code contribution is ready. This will reduce the wasted effort of dealing with failed integrations and keep developers focus in the zone.”

    7. Ian Robertson

    Ian Robertson is a product owner at River Island. He says, “I work in retail (fast fashion). While we do build core ranges to meet the seasons, it is our quick response to rapidly changing trends that generates the excitement that drives our brand values. An emerging style cue seen on the catwalks one Friday can be in our stores and online by the following weekend. Those same customers expecting the latest fashion will be interacting on our app and website, so we need to be as Agile in development and deployment as we are in apparel design and production to keep up with customer expectations. It’s not just the front end; our supply chain, logistics and merchandising systems need to be able to respond rapidly to real-world changes. Adopting CI and CD allows us to reduce the time to market, reduce risk, deliver better customer experiences and drive value for the business.”

    8. The Folks at Browser Up

    Browser Up is a performance and load testing tool. Folks there say, “Using CI and CD is a force multiplier that amplifies the speed at which software can be developed and delivered. To be effective, a CI and CD pipeline must include a robust test suite that include continual performance and functional testing.”

    9. Georg von Sperling

    Georg von Sperling is a practitioner, evangelist and general geek on software development methodologies, technology, patterns, systems, delivery practices and DevOps. He says, “CI and continuous deployment are very technical in nature and benefit the technical teams. They are crucial to address. They do not, however, define continuous delivery. CI could be defined as an early detection system at the code and build level. Early detection at those levels have been proven beneficial as these are types of bugs that are exponentially more costly to remediate at later stages. Continuous deployment is an ability to promote code technically down the pipe into production at velocity, allowing consumption faster. There are facets of continuous deployment that must be considered: rollback, A/B testing and metrics gathering. Many fail here very quickly. Continuous delivery (of which I am an avid advocate for) is a business subject; although, in software powered organizations and/or digital business models, it has a fairly large technical component. It is very difficult, if not impossible, to translate CI and continuous deployment into direct business benefits. Continuous delivery, however, is business metrics-driven and defensible at the CxO level to stakeholders and shareholders.”

    10. Endi Sukaj

    Endi Sukaj is a full-stack developer who specializes in back-end development. He’s currently a community team member at Slant.co. He says, “CI is a crucial part in the development and deployment process of projects of a certain size especially if two or more people are working on it. The most valuable resource is time, and a good CI service and implementation helps developers in saving as much time as possible by avoiding ‘integration hell’ and by running all unit tests in the same environment as in production.”

    11. Jordi Mozcode

    Jordi Mozcode is a software developer focused on .NET Core, MVC, TDD, SOLID, clean, software quality, best practices, secure coding and pentesting. He says, “In my professional experience, the adoption of continuous integration and continuous delivery improves three basic facts: quality, flexibility, and speed. Quality, because CI guarantees a much lower rate of development bugs and CD provides a robust and secure system throughout the development cycle. Flexibility, because at every step of the development cycle you have the control of continue to next step or going backward easily. Speed, because in an idyllic case with no development bugs the release can be deployed in production almost instantly.”

    12. Dave Kerr

    Dave Kerr is a software developer for everything from device drivers to full enterprise applications. He says, “If the org is building tech services or products, CI and CD are critical. Deployment doesn’t need to be continuous but the team needs to be confident that what they are building is shippable.”

    13. Matt Kurleto

    Matt Kurelto is a serial entrepreneur and CEO at Neoteric. He says, “I think it’s a necessity if you are thinking seriously about cloud services. I think that microservices architecture can only be well-leveraged with automated CI, CD and QA flow, and for me, this setup is a must if you want to take advantage of lean business and agile project management.”

    14. Sean Handley

    Sean Handley is the lead cloud applications engineer at DataCentred. He says, “CI and CD are things we practice on our tech team. They allow us to ship production changes many times per day in confidence. My view is that any software team not using CI and CD needs to seriously reconsider their methods!”

    15. Manisha Sahasrabudhe

    DevOps Expert Manisha Sahasrabudhe is the co-founder at CMO at Shippable. She says, “All companies are software companies today, and faster innovation is the key to winning against your competitors. Continuous integration and delivery are crucial in helping you accelerate your release cycles and innovate faster than anyone else. This will become especially important as microservices become ubiquitous and your application is composed of hundreds of services that need to be deployed, scaled and monitored independently. CI and CD automation is the only way to bring some method to the madness.”

    We hope these DevOps Experts opinions are enough for you to figure out how important it is to adopt to CI/CD practices.

    — TeamShippable

  • Closing the Gap on Continuous Delivery Metrics that Matter

    Closing the Gap on Continuous Delivery Metrics that Matter

    Management guru Peter Drucker once said, “If you can’t measure it, you can’t improve it.” I would take a step back and say, If you can’t measure it, you can’t get it off the ground. Many companies that I work with are amid digital transformation initiatives, such as the adoption of DevOps and continuous delivery. For these initiatives to gain momentum and acceptance within their organizations, they must be able to demonstrate quick time to value or risk being sidelined. And then, these organizations must be able to actualize their transformations and improve their processes—both enabled by the right metrics.

    Indeed, one of the core pillars of DevOps culture—going all the way back to the first DevOpsDays event in 2010—is measurement. It is the M in the CAMS (Culture, Automation, Measurement, Sharing) acronym coined by Damon Edwards and John Willis.

    Glaring Gap in Continuous Delivery Metric Definitions

    Despite the prominent placement of measurement in the DevOps world, there is not really a lot of guidance about metrics in the common literature. For example, the original “Continuous Delivery” book by Jez Humble and David Farley devotes maybe a dozen pages out of 500 to it. And the recent “DevOps Handbook” by Gene Kim, et al is thin on the topic as well.

    The coverage gap around measurement and metrics is driven primarily by the fact that the DevOps space is new and there are few standards around which to build an easily documented metrics structure. That leaves practitioners with the challenge of creating something they can use pragmatically within their own organizations. Anyone building a system of measurement for their organization must have a reasonable understanding of metrics as a discipline and a good understanding of the processes they intend to measure.

    Back to Basics on Measurement

    There are two types of metrics that I discussed in a recent session at CA World ’16 that are important when measuring a complex enterprise process.

    • Result metrics are concerned with the cumulative outcome of a set of activities. For example, a company’s revenue or net income would be common, classic result metrics.
    • Performance metrics measure how well individual activities are working. These often are more difficult to define, as they can vary by businesses and teams and be obscured by silos.

    Performance and result metrics are very closely linked: Performance metrics measure the effectiveness of the activities that drive the result metrics. For example, measuring the average number of deals closed per salesperson per period would be one measure of the effectiveness of a sales organization (a performance metric) which, in turn, would be a factor in driving revenue (a result metric).

    While DevOps literature generally does not provide a lot of detail about metrics, it does provide advice on key result metrics. The primary one is lead time. Lead time is a powerful measurement that originated in Lean manufacturing. It originally dealt with how long it took a company to deliver a product to a customer after receiving an order. In DevOps terms, lead time summarizes the amount of time it takes to deliver one single change or feature from business idea through to running software in Production.

    Lead time is calculated by aggregating the work time (referred to as cycle time) on a change plus the time when the change is in progress, but not being worked on (referred to as wait time). The formula that LEAD TIME = CYCLE TIME + WAIT TIME is a powerful tool for understanding the result metric level; however, the challenge in most enterprises is figuring out a workable system of supporting performance metrics.

    Value Stream Mapping to Uncover Performance Metrics

    You’ll find that the result metrics part of the effort—calculating the lead time for an application change—is relatively straightforward even when corporate structures can obscure exactly when work (cycle time) is happening versus when things are waiting (wait time). The Lean manufacturing world provides techniques for analyzing a flow.

    A common technique is called value stream mapping (VSM). VSM provides guidance for breaking down a complex process into identifiable “steps” to provide measurement points throughout the process for cycle time and wait time. The measurement points then provide milestones for tracking the progress of the single change or feature from business idea through to production use.

    For example, in an enterprise application development situation, typical application delivery pipelines provide several logical points that can be used as steps for VSM. Using those points, it is simple to measure linear time through the process. The common logical measurement points are:

    • Assembly (aka Development): the time required to assemble a configuration package (code, database, infrastructure, and network) that the team declares as an instance of the application including the change
    • Time Spent at Each Pipeline Phase: the time spent in various QA environments, such as Integration, Functional, Performance, UAT, etc., and to finally put the configuration package into the Production environment.
    • Time Spent on Promotion Decisions: the time spent waiting for a decision to promote a given version of the configuration package to a higher environment or to reject it at the end of that validation phase.

    The performance metrics that determine how efficiently cycle time and wait time are utilized, however, are significantly less obvious. Software development is iterative by nature. That means that individual steps in the value stream will be repeated many times and the cycle and wait time metrics ultimately will obscure the quality of what is happening at the measurement points due to natural tendencies to aggregate and average the values.

    Performance Metrics for Continuous Delivery

    Establishing the performance metrics for a continuous delivery pipeline requires a bit of analysis. The performance metrics must be geared to understanding how to reduce the cycle time per repetition and the overall number of repetitions at each measurement point in the delivery pipeline. Here is a pragmatic, two-part pattern you can follow:

    The first part is to break down the iterative pieces of the pipeline into logical ‘mini’ value streams. For example, each QA environment must be provisioned, configured, have changes deployed, and then validation activities occur. Those steps can provide measurement points and, more interestingly, can be used symmetrically in all environments in the pipeline enabling questions such as, “Does one take a disproportionate amount of time relative to the others?”

    The second part is to look at the qualitative items that drive either long repetitions or increase the number of repetitions. For example, how many environments does a configuration package go through before rejection? More can actually be more expensive, slower and likely to be indicative of requirements problems, while fewer may indicate code quality problems. Another example might be smoke test failure rate in each environment. Variance in one environment could indicate problems in either the configuration management or deployment automation, but would require repetition of the deployment or manual correction. Finding that problem and fixing it ensures better cycle time at that step and stage, and serves to keep lead time down.

    End Game: Demonstrate Business Value

    It may be a very long time before the DevOps movement reaches consensus on a system of metrics. The variability in software environments and industry needs means that it is unlikely for one size to fit all. However, with a pragmatic approach and some lessons from the Lean manufacturing world, it is possible to produce a workable and effective system of metrics for continuous delivery pipelines in the enterprise.

    Vendors, such as my employer, CA Technologies, are helping by building more integrated systems of pipeline management tools to help shift from merely reporting metrics to applying them with modern analytics-driven techniques. The dividend of these approaches and tool improvements is that it is getting easier to gain a clear understanding of your process and to demonstrate to the business that the DevOps initiative is, in fact, worth the effort and investment.

    — Dan Zentgraf

  • A Holiday Tradition: 2017 Continuous Delivery Predictions

    A Holiday Tradition: 2017 Continuous Delivery Predictions

    It’s that time of year. As the calendar year comes to a close, many of us are following time-honored traditions: making preparations for the holidays, planning some much-deserved time off and enjoying time with friends and family.

    In the business world, the year-end also brings its own traditions, and first among those is making predictions for the coming year. I’m not one to forgo traditions, so in this article I’ll share my thoughts on the upcoming year within the context of the continuous delivery movement.

    To level set, continuous delivery is the most evolved and modern state of software development and testing—and is core to a successful DevOps strategy. Organizations that are able to achieve continuous delivery can rapidly develop, test and release applications—with higher quality and at lower costs.

    Simply put, the ability to more continuously deliver software is one of the biggest advantages to attain in the application economy, where the battleground for consumer loyalty is most often found in the ability to deliver superior applications.

    Now that we know what continuous delivery means, let’s get to my predictions for 2017:

    1. Continuous Delivery Means Continuous Everything

    Continuous delivery is still a relatively new concept, and one that many organizations strive to achieve. As a new concept, it suffers from some of the misconceptions that often plague emerging technologies or trends. Many technology providers latch on to the term and claim to provide “continuous delivery solutions” that in reality only address a small part of the continuous delivery challenge.

    Truly delivering software continuously means that all the tasks within the software development life cycle (SDLC) must be optimized to occur in parallel and continuously. This means development must be continuous, testing must be continuous, and likewise for release and operations.

    2017 will be the year that industry embraces the importance of an end-to-end continuous delivery value stream. In 2016, many organizations began their continuous delivery journey by addressing certain aspects of the SDLC; in 2017 many organizations will begin to realize a truly open and integrated continuous delivery workflow.

    1. Democratization of Continuous Delivery Tools (via the Cloud)

    Optimizing all aspects of the SDLC for continuous delivery, as mentioned above, means that related tools need to be easier to use and easier to access. Developers who have access to testing tools (left-shift) can improve the quality of code they produce. Similarly, QA engineers who have access to design requirements sooner can create more accurate test data and scenarios, earlier.

    However, for this to occur, the tools have to be both easy to access and simple to use. Developers have avoided complex testing frameworks, but with simple, easy-to-use tools available—often in SaaS forms—developers can certainly incorporate testing into their methodologies.

    In 2016, CA acquired BlazeMeter, which pioneered the notion of cloud-based performance testing employing a simple and easy-to-use (yet very powerful) product. We expect to see this trend expand into other tools within the continuous delivery value chain in 2017.

    1. The Industry Embraces Open Source (Really)

    In the past, we’ve noted that commercially motivated technology providers have tried to keep open-source technology “at arm’s length.” There may have been some lip service paid to openness, but in reality many commercial providers felt threatened by open-source solutions that were seen as competitive to their products.

    This perception has already started to change, but I believe 2017 will mark the tipping point where companies will truly embrace open-source solutions as part of their strategy; those companies that continuously resist (pun intended) will be at a significant disadvantage.

    Open source is important for many of the same reasons as the cloud: It is broadly adopted because it creates advantage in time to market, quality and cost effectiveness. Embracing open source—and by that I mean both integrating with open-source solutions and using them as part of a product strategy—only makes good business sense. It helps software development teams meet their objectives in delivering quality software faster, and at lower cost.

    Another year is rapidly coming to a close and we have a lot to look forward to in 2017.

    On the topic of continuous delivery, looking forward means spreading continuous delivery throughout the SDLC, using the cloud more and embracing open source.

    All of those things combined will help us advance the continuous delivery movement together as an industry. Here’s to another year of continuous delivery advancements!

    Don’t forget, you can also take a closer look at the ongoing evolution of continuous delivery and other DevOps-related trends by picking up a copy of my colleagues’ new book, “DevOps for Digital Leaders: Reignite Business with a Modern DevOps-Enabled Software Factory.” If you have some extra time over the holidays, you’ll find it to be an interesting deep-dive.

    — Jeff Scheaffer

  • How Often Should You Release with Continuous Delivery?

    How Often Should You Release with Continuous Delivery?

    If you do continuous delivery, you could release software updates as frequently as you want. But should you? Here’s what to consider when deciding how often to release.

    Although the terms continuous delivery and continuous deployment are often used interchangeably, they don’t mean the same thing. Under continuous delivery, you prepare all software updates as potential candidates for release. But continuous delivery on its own does not mean that you release all of those updates into production as soon as they are complete. You would have to adopt continuous deployment to do that.

    So, if you’re doing continuous delivery, you have the option of releasing as frequently as you like—every day, every month or even every hour. Determining how often you actually release requires weighing several important factors, including:

    • How important are your updates? If changes to your app mostly involve mundane things such as interface tweaks, continuous deployment probably will confuse users more than please them. They will have to adapt constantly to new features. But if you can roll out big, user-friendly changes on a continual basis, then deploying continuously can help keep your users happy.
    • Is there a marketing advantage to be gained by waiting longer to release? Sometimes, advertising new features but waiting a while to release them can help build excitement. Case in point: Apple Inc.
    • Do other apps depend on your app? If you’re working within an ecosystem where your app integrates with other apps or platforms, continuous deployment makes the lives of partner developers more difficult because it requires them to adjust constantly to changes in your app. To help them ensure their work will always be compatible with yours, provide space between your releases.
    • Is your development pace consistent? If not, continuous deployment can be problematic because users will see rapid updates at some times, but stagnation at other times. Continuous deployment only works well for users if they can count on a relatively steady stream of updates.
    • Do your updates create a learning curve? If users will have to learn new tricks to use an updated app, continuous deployment may create more confusion than happiness.
    • Can multiple versions of your app coexist? If all users need to be running the same version of your app in order to be current, continuous deployment can help assure that they are. But if you can support multiple versions of the same app at once, less frequent releases should work for you.

    If you can’t decide how frequently to release, you might consider releasing on a fixed time schedule—once every two months, every six months, every year or whatever works for you. This is what Canonical has done with Ubuntu Linux for a long time: It releases a new version of the operating system on the second Thursday of October and the fourth Thursday of April each year (with a few exceptions). This system assures that developers and users always know the schedule for a new release.

    Whatever approach you take, the most important thing is to realize that continuous delivery does not require you to release as often as you can. It gives you the flexibility to release as often as you want. Deciding how often that should be is up to you.

    — Chris Tozzi

  • Assembling the Key Components of Continuous Delivery

    Assembling the Key Components of Continuous Delivery

    As agile methodology was popularized at the start of last decade, engineering teams gained the opportunity to begin producing software in shorter cycles, while releasing it reliably at more frequent intervals.

    This concept garnered greater attention in 2009, when Tim Fitz published his thoughts on continuous deployment. By the time Jez Humble authored his seminal book, “Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation,” in 2010, the approach started to get significant mindshare. In the book, Humble advanced the three building blocks of continuous delivery: configuration management, continuous integration and continuous testing.

    Thereafter, Agile Operations—the practice of using end-to-end monitoring, fueled by analytics, to increase operational agility—appeared. This complemented continuous delivery, with the goal of increasing the quality and velocity of software delivery while minimizing overhead.

    Since then, and particularly over the last six years as DevOps adoption has exploded, there’s been significant discussion (and confusion) over the opportunity to embrace “continuous everything” across the software development life cycle (SDLC) to deliver functionality continuously and optimize end-user experience.

    Today, having spoken to hundreds of organizations employing agile and DevOps, it’s possible to expand on these concepts to better define the key components of continuous delivery.

    In this blog, I’ll detail the precepts of “CD” that CA’s customers recognize as critical in reducing the time, risk and expense of software delivery by frequently releasing smaller batches of code with extensive visibility and traceability.

    These building blocks of continuous delivery are:

    • Continuous development & integration,
    • Continuous testing. and
    • Continuous release.

    Continuous Development and Integration

    When it comes to delivering quality apps faster, every second counts.

    That’s why it’s important to automate the planning, development, unit testing and integration of code with different inter-dependent components, all while packaging it for quality assurance. We categorize these activities under continuous development and integration, as shown in Fig 1.

    This all starts with sprint planning and modeling of requirements in agile management software. Unit tests can be created automatically, based on requirements and use case stories. These unit tests then can be executed automatically based on pre-defined criterion, using automatically generated synthetic data.

    Fig 1: Continuous Development and Integration

    Next, virtual service interfaces can be generated automatically by simulating unavailable systems across the SDLC, allowing developers, testers, integration and performance monitoring teams to work in parallel—driving faster delivery, along with higher quality and reliability.

    The integrated code can be built and tested automatically against validation criterion, and upon passing, made available for continuous testing. This later phase, after code development and before QA, is also commonly referred to as continuous integration.

    Continuous Testing

    Continuous testing across app delivery not only enables enterprises to shift testing left, engaging it earlier in the SDLC, but it also helps them shift right, leveraging the same processes throughout staging and production.

    After the unit tests are passed and integrated builds are made available for QA, functional and performance tests can be completed—before the build is made available for staging and production. Various activities during continuous testing are shown in Fig 2.

    Before the functional and performance tests are performed, the build promotion criterion and configuration also need to be validated. Testers require provisioning of QA environments to deploy the build, along with virtual services and test data. Using test data management to create a subset of production data and mask sensitive information is another continuous testing requirement.

    Fig 2: Continuous Testing

    It’s also important to engage application performance monitoring in the QA environment before running automated tests, providing feedback about any problems back to developers.

    After the automated tests are executed and promotion criterion are met, the build is ready for deployment in staging or production environments.

    Continuous Release

    Continuous release matches release velocity to development velocity through controlled and scalable deployments.

    The goal of continuous release (sometimes referred to as continuous deployment) is to continually and automatically deploy the build into production; similar activities also can be performed in a staging environment.

    As shown in Fig 3, build configuration needs to be validated, with the production environment configuration updated before being sent to production. As with application code, configuration is also maintained in the version control system and can be automated for deployment.

    Fig 3: Continuous Release

    After the build is deployed into production, application monitoring should be initiated to track performance and customer experience. Feedback from the production environment can be passed back to developers to guide enhancements or sprint backlogs.

    This blog aims to outline core CD activities, and in subsequent articles I’ll provide additional details on entry and exit criterion, as well as metrics useful in tracking continuous development & integration, continuous testing and continuous release.

    In the meantime, check out, “DevOps for Digital Leaders: Reignite Business with a Modern DevOps-Enabled Software Factory,” a new book authored by my colleagues Aruna Ravichandran, Kieran Taylor and Pete Waterhouse.

    Based on learnings gained from numerous customers who have already embraced CD and DevOps, it highlights key practices for starting this journey, related ROI metrics and other useful tips.

    — Anand Akela

  • Should Continuous Deployment Be Renamed?

    Should Continuous Deployment Be Renamed?

    I’m a technologist turned into a word person. For those of you who know me, I started as a developer, learned ops and security as it was needed, and eventually my love of talking about technology lead me to writing, tech marketing and evangelism. I still develop, though; I can’t stop that—it’s kind of a part of me.

    But as a technologist at heart, words are a way to convey concepts, and any that don’t contribute to the conversation in a meaningful way aren’t necessary.

    So it is pretty weird for me to be saying, “What if we renamed CD?” But I think there is a real point here that we could address. If you look across the industry, you will find quotes (and in IT departments, the reality) that for most of us, CD is not about continuous deployment. It is about continuous delivery and on-demand deployment. Unfortunately, “on-demand deployment” makes a pretty terrible acronym in the English-speaking world, so perhaps we should use “on-demand update.” Deployment is looking at it from the application’s perspective, but as DevOps, we get to look at it from both perspectives and we are updating the server(s) to run our application(s). So on-demand update (ODU) would work, but I’d be open to alternatives.

    In this case, the wording change is useful. There are a few organizations with very special needs that do actual continuous deployment. No one else does. The ability to say, “OK, we’ve got enough together and tested to warrant the disruption this will cause. Update the app,” is what most organizations use CD for. And I think that’s right. While purists will roll their eyes and talk about the advantages of each bug fix, no matter how small, rolling out in a timely manner, most orgs aren’t going to do 15 updates a day. And orgs that like stability don’t want to. Testing doesn’t resolve every issue; otherwise, we wouldn’t need things like Bugzilla for anything in production, risking introduction of new ones 15 times a day. That’s just not on the list of priorities for most organizations, particularly if their CI system is on longer run-times.

    So I like CI/CD/ODU. Then you are separating continuous delivery and on-demand deployment, which I would argue is a huge piece of the problem. I’ll quote Georg von Sperling of CA Technologies during the Q&A section of a webinar:

    Continuous delivery does not equate continuous deployment to production. If I may be so bold, I would state continuous delivery is a practice to allow deployment to production at any time with a high degree of quality and a low amount of risk with zero downtime and zero touch. A business leader recently said to me that whereas, in the past, ‘Deployment to production was an IT decision, it is now a business decision at a push of a button.’ But, CD certainly played a part in this paradigm shift, as the entire delivery process, including testing, is visible and predictable.

    Which makes sense, once explained, but it’s truly a source of confusion in the field, so separating the two makes sense. The point is to communicate clearly, and requiring a further clarification of what exactly CD is says we’re not communicating clearly at all. Indeed, delivery and deployment definitions that are meaningful to IT are close enough in context as to automatically cause the confusion when a single “CD” is presented.

    So even though I don’t get terribly wrapped up in wording, I think this is a worthwhile change to consider. Words convey meaning; let’s ensure the meaning they convey is clear.

    For those of you knee-deep in CI/CD, yes I am aware of Fowler’s definitions, but this clears up the fact that he has to explain how continuous delivery is different from continuous deployment in the definition for continuous delivery.

    In short, we’re being confusing. Stop it. Let’s talk about tools/technologies/methodologies to get there, not keep clarifying confusing terminology.

    — Don Macvittie

  • DevOps Chat: Jeff Schaeffer, CA Technologies, on Everything Continuous

    DevOps Chat: Jeff Schaeffer, CA Technologies, on Everything Continuous

    I recently had a chance to sit down with Jeff Schaeffer, senior vice president and general manager of Continuous Delivery and DevOps Business Unit at CA Technologies. I have interviewed Jeff before, most recently at Jenkins World, where we did a video on our DevOpsTV YouTube channel. Jeff is a great interview who always gives good insight into what CA’s and his views of the dynamics shaping the DevOps market are.

    Jeff and I had a chance to talk about the launch of the new CD neighborhood sponsored by CA Technologies. Specifically, we discussed how CD—and, for that matter, the whole idea of continuous IT—is reshaping the way organizations do business. It is a great conversation that I hope you will enjoy.

    Below is a streaming audio of our DevOps Chat and below that is the transcript of our conversation.

    Alan Shimel: Hi, everyone. This is Alan Shimel, editor in chief, devopsy.kinsta.cloud, here for another DevOps Chat. Today’s DevOps Chat guest is Jeff Schaeffer, who is responsible for CA Technologies’ continuous delivery CD business.

    Jeff, welcome to DevOps Chat.

    Schaeffer: Thank you, Alan. Glad to be here today.

    Shimel: Good to have you here. Jeff, of course, I think the last time you and I spoke was at—it was at the Jenkins World event, and we had a chance to actually sit down on video and talk a little bit about, you know, where do you see the market, where you see the DevOps market going, what CA’s involvements are and where you guys are kind of placing your bets and moving your pieces around as this market continues to evolve.

    And we were, of course, talking offline before we started today’s podcast about kind of how you view the different waves, if you will, of maturation of companies’ life cycles with software and so forth, and you mentioned third wave, fourth wave.

    I’d love, if you don’t mind, if we could share a little bit of that context with our audience in terms of your view of the historical ebb and flow here of history, if you will, of where we are. So would you mind sharing that?

    Schaeffer: Thanks, Alan. So, Alan, as we were discussing, our—the thesis and the drivers for continuous delivery actually start kind of in the history of technology, and it’s probably never been a more exciting time for any of us to actually be involved in application development and technology in general as it’s transforming all the markets.

    And the history is useful to the extent that it helps us understand the future as well, and when we think about it, you know, we’re really in the midst of the third wave, in which businesses have disruptively adopted technology in the business.

    The first wave was back in the 1960s and it was really about the mainframes and the digitization of the paper processes in the company. I mean, it was a process disruption.

    The second wave was in the ‘90s, and it was really about ERP and CRM systems where we were automating the supply chains of companies, and again, it was a process disruption.

    Today we’re in the third wave, around the application economy, and in the context of digital transformation and the app company, you know, companies today, they promote their brands, their products, their services through their web and their mobile applications, and it’s become the primary methodology by which they engage their end users. And it is actually underpinning and enabling business model disruption, which is very different than the prior two waves of disruption.

    So when we look at it, it’s an entirely new business model. We’re all familiar with the majority of those in terms of, for example, Uber disrupting transportation and Netflix disrupting media, et cetera.

    And one of the challenges about the third wave is that—following the third wave, actually, I think is the fourth wave, and the fourth wave is gonna be around systems of insight and engagement, by which companies are able to take all of the multitude of data that they’re generating in terms of every interaction with their end consumers—you know, with suppliers and providers—and be able to analyze those data sets’ multivariate analysis and derive deep insights, and to be able to then, in turn, customize their offerings. Companies would be able to use that data to make more of the right decisions more often, to drive efficiencies, et cetera.

    And so naturally, the fourth wave—and it’s coming, but before we can actually fully benefit from the fourth wave, we actually still need to master the third wave. And in the context of the third wave, the app economy, it’s really about, how do you get these applications, these web or mobile applications into the hands of end consumers more quickly and, you know, great quality and at lower cost and factor of production.

    And so that’s really the area where companies today are focused. And, to do that, what most companies are doing is, they’re adopting agile methodologies, right? They have to increase their competitiveness and their ability to deliver this custom software. So they look to get development up to velocity, so they’re adopting agile methodologies, and then they quickly realized that the rest of the value streams are not at velocity—so testing, release, operations—which then leads them to adopt DevOps, which is where we’re gonna have a great conversation today.

    And, with DevOps, they start to adopt the culture and the practices, and then realize they need a new enabling tool chain, and so if you think about any technological disruption and being a function of organization and people being a function of process and being a function of tools and technology, they now adopted a new tool chain, which is the continuous delivery tool chain.

    And that’s an area where we at CA are focused about how do we provide the coaching around the organizational transformation and the practices in the process transformation and then, you know, from a product perspective, we’re building the next generation tool chains, building block fashions, and bringing those to market to support companies’ transformation and competitiveness in the application economy.

    Shimel: Perfect. And you know what, Jeff, that actually dovetails into, of course, just today, we announced on devopsy.kinsta.cloud that we’ve added a new CD—or continuous delivery—Neighborhood, which CA has graciously sponsored. And we’re really looking to build this into a—I don’t want to use the word portal, it’s so 1999—but a destination where people can come and get some great content and some great education around this whole CD tool chain and the CD economy, if you will, that is growing up.

    But, you know, Jeff, going back to what you were talking about, we can’t get to the fourth wave until, I think, the third wave is a little bit more solidified and a little bit more mature, a little bit more settled. In my mind, what we’re seeing is, a lot of these convergent circles starting to overlap, right? You mentioned agile, we mentioned CD, we mentioned things like API, right, which is another big area for CA.

    Schaeffer: Yes.

    Shimel: And, you know, they’re not totally independent of each other, nor are they totally dependent on each other, but you know, they kind of form the ultimate Venn diagram where the overlap is just marvelous, right? I mean, it’s just a wondrous time to be in business if you’re using—you know, you’re leveraging all of these things.

    You know, and you’ve been around, Jeff, as I have—what do you see with that?

    Schaeffer: Yeah, so Alan—exciting things, exciting things. So, a couple of quick comments, one on the Continuous Delivery Neighborhood—really excited for that. Alan, I can tell you that in that context, whenever I meet with peers across the industry, one of the things that comes out very broadly today is, there’s a big gap between conceptualization of things like agile, DevOps, and continuous delivery, and translating those into real world practice.

    Shimel: Mm-hmm.

    Schaeffer: And the opportunity to provide that education, to provide a journey to share examples of how people have adopted these and succeeded is gonna become absolutely instrumental in terms of unlocking the full potential of these methodologies and these concepts and deriving the business benefit.

    So we’re really excited with what devopsy.kinsta.cloud is doing with respect to the educational exercise, and also devopsy.kinsta.cloud and that sponsorship of the DevOps Express Consortium, which is another multi-vendor body that’s focused on this translation of concept of real world practice, and of course, here at CA, we’re happy to be a founding member of DevOps Express as well as a sponsoring member here for devopsy.kinsta.cloud and the CD Neighborhood.

    The second thing is, when we look at the change in the continuous delivery tool chains, what we’re finding is, as companies adopt agile, they start looking to have—okay, what is the prescription of the next generation software factor, software life cycle, and as they look at continuous integration to continuous test, continuous release and deployment and continuous operations, you know, how do you string these building blocks together?

    And the only way to reduce the cycle times is making both a process change but also the tooling change. And the tooling is very different today versus, say, some of the legacy providers of application development and testing tools. It’s all pragmatic, API driven, so that it’s fully automatable. There’s a lot more—as you were describing the intersection and the Venn diagrams, it’s really a function of the feedback loops. So how do I take data, for example, from operations and use that to make a smarter example in continuous testing?

    Let me share an example of what we mean by that. So, if you have a mobile application, you know, mobile application is much more difficult to manage in production than, say, a web app. First, people simply don’t update their smartphones that often, and so you end up with a long tail of versions in production environments.

    Shimel: Mm-hmm.

    Schaeffer: They’re running on different operating systems—iOS or Android and different versions of the operating systems. They’re running on different hardware platforms like an iPhone 4 or an iPhone 7, Galaxy 7. They’re running across different carriers, and there’s over 700 different carriers worldwide. And it becomes a factoral problem, and it’s unlikely that any given testing team has the ability to model that many combinations—because it’s a factoral problem—to model that many combinations in their test matrix.

    But, if you have operating data, and you know that 80 percent of the user base is on these five to seven combinations, then you can provide that data back to the QA team and proactively test those combinations and take your risk in the tail of where people have more infrequently completed combos. But, by the same token, if you can detect failures in operations, you can provide that same data back to dev, and they can focus their investigative research as they work on the current product engineering.

    So when we think about the Venn diagrams and how all of that works together in the future, it’s—not only are the format factors of the tools changing, but the feedback loops become absolutely essential in order to fully automate and to systematically improve the software life cycle process. And so, a really exciting time.

    And we’ll often hear that today, this idea of shift left and shift right, but it’s really a—you know, those things embody, that vocabulary embodies a number of concepts. One is, you know, how do I push activities earlier and earlier into the development process under shift left, so how do I incorporate, say, for example, performance testing early, and then how do I tie performance testing into operational testing, and how do I provide that feedback loop all the way back?

    So just exciting times, lots of transformational changes, and people are definitely looking for prescription and methods as how to reconfigure their software life cycles and incorporate that into their current software development methodologies, and that’s what, I think, DevOpsExpress.com will be so good at is helping provide that center of knowledge and best practices for the betterment of the industry.

    Shimel: Absolutely. Jeff, believe it or not, we’re almost up at time, but I wanted to—and I don’t mean to embarrass you, but I want you not to be shy here. CA has done a masterful job of amassing, developing—both holistically, acquisitions, et cetera—a play in this new third wave, fourth wave economy, if you will.

    Schaeffer: Absolutely.

    Shimel: Give our audience—again, don’t be shy. Why do you think CA is best situated to really leverage what’s happening out there right now?

    Schaeffer: Wow, great question, Alan. So, two, maybe three key points on that. So number one, Clayton Christensen, who is a professor at the Harvard Business School, he’s written extensively on the concept of disruption and then disruptive innovation in the market. And one of the key things that you learn about, or learn from Clayton, is that the incumbents never survive the disruption. And it’s not because they’re—you know, it’s just because of their decision making and how they’re driven by their paradigm.

    And CA, uniquely, is in a position as a company to invest in this next generation of continuous delivery capabilities. And so we’ve been putting together this next gen tool chain through a combination of organic product development as well as acquisition, and so we’re uniquely in that position in the market in terms of being a vendor of sufficient size to provide that consolidated next generation tool chain and to ensure it works together. Per kinda the research of the market and industries over time, you know, we’re in a unique position relative to the traditional incumbents and I’m excited.

    You know, we’ve pulled together the Rally Software, which brings kind of market leading agile management capabilities into the portfolio and we start with the planning process and agile management. We realize that, in the application economy driving the automation, that oftentimes in the app economy, the API is the application, but that’s also the primary means by which we exchange data and are able to integrate or automate all of the functions as well as create the next generation architectures, which are all kind of composite applications built on microservices which work through APIs.

    So we’re connected by the APIs, and so we’ve invested in their seven and brought in a really robust API management capability, and then we are laser focused in the continuous delivery space. So, how do we take and orchestrate release with release automation software and release automation continuous delivery addition, which is basically harvesting the data and providing the analytics so that we can systematically improve and continuously improve the software development life cycle.

    And then, beyond that, we have a number of kind of the next generation continuous testing tools. So, everything in terms of, we just recently acquired BlazeMeter. It’s a fantastic capability and at the heart of continuous testing. You know, it’s a commercialization of open source projects, JMeter and Taurus, which allows us to automate any open source testing tool, whether it’s the JMeter testing, which is the second most widely adopted community developed testing product, or Selenium, which is the most widely adopted testing product. Gatling, Locust, et cetera, so a host of open source testing engines.

    We add value above and beyond that. It’s all hosted in the cloud and deploys both in public and private clouds for the tests themselves, and so it’s highly automated, it’s very scalable, and it allows us to left shift the testing all the way into the integrated testing, the component testing, and the unit testing of the new life cycle processes.

    We also have put together a number of tools that improve testing efficiency around test data management, so how you can’t automate your tests unless you automate the test data, and providing test data with the right sort of attributes in order to drive the tests in a productive way. We have service virtualization software, which allows us to simulate test environments, and to emulate the test environments and abstract away things like mainframes or databases, which allows for both parallelized development. When other components aren’t available, we can simulate those or emulate them, and then in the testing practice itself, we’re able to isolate applications and put them under load testing in an effective way.

    All the way out into our operational tools, where we’re able to shift right, and provide kind of the—you know, what’s done in pre-prod gets used in production, how do we get the integration and the feedback loops back into the testing and the development processes.

    And so we’ve really been focused on putting together that next gen toolset around continuous integration, continuous testing, continuous release and deployment, and continuous operations. And again, we’re in a unique position to do it. We’re unique in the fact that it’s a disruption within the market and we’re able to put together this tool chain, and we’ve made a lot of progress in developing that tool chain up ‘til now. And we’re finding companies like—the people we’re working with across the industry adopting the CA tool chains, you know, we’re finding some significant improvements in not only the velocity but the quality and the cost effectiveness of their software development practices.

    So, for example, companies that were getting one release out every year are now able to do 30,000 deployments per month on 300 applications in both the test, the pre-prod and the prod environments. We’re able to significantly reduce the cost of handling data and increase the automation of testing, up international the 85, 95 percent range, lowering the costs and achieving ROIs, in some cases, of over 300 percent in paybacks on the investment measured in months—you know, two to three months, which is very unusual around what people would normally expect in an enterprise software vendor.

    So we’re really excited with the difference we’re making in the lives of our customers—the operating benefits, the business benefits, and then the overall, you know, the impact that we’re gonna make in the industry as a whole.

    Shimel: Fantastic. Hey, Jeff, we’re way over time. I apologize, here. I apologize to—well, I’m not apologizing to those listening, I think they’ll find it worthwhile. But we do try to keep these at 10 to 15 minutes, and we’ve gone over—but I think it was worthwhile, we had a lot of information to share.

    Jeff, continued success in leading up the CD business at CA Technologies, and we’re looking forward to more exciting news soon, and we’re actually looking forward to the CD Neighborhood on devopsy.kinsta.cloud really becoming a go-to place for people looking for information around it. So thanks very much on the sponsorship for that as well.

    We’ll be in touch again, soon. Until next time, I hope you stay well. Jeff Schaeffer, he runs the CD business at CA Technologies—thanks for being our guest on this episode of DevOps Chat.

    Schaeffer: Thank you, Alan.

    Shimel: Thank you. This is Alan Shimel for devopsy.kinsta.cloud, and we’ll see you again on another DevOps Chat.

    — Alan Shimel

  • Overcoming Objection to DevOps Adoption

    Overcoming Objection to DevOps Adoption

    The advent of the application economy has made software arguably one the most critical and valuable assets of organizations across a broad spectrum of industries—financial, telecommunications, entertainment, and government, just to name a few. In the era of “app store ratings” and an unprecedented ability of the consumer to easily switch suppliers of whatever they’re consuming, delivering application feature updates as quickly and as safely as possible while maintaining high quality is absolutely critical.

    Most of us with a pulse in the IT world are aware that the concepts and practices we know as “DevOps” and “continuous delivery” continue to dominate the software delivery conversation in IT organizations everywhere. Almost every business my company works with has some sort of continuous delivery or DevOps initiative in flight (with, naturally, varying degrees of maturity and success). And yet, we frequently encounter organizations where these ideas are anathema to many within, are considered overhyped buzzwords from consultants and vendors or, most frequently, simply do not apply to their organization in meaningful way. Others maintain that they have tried and failed so it’s back to business as usual. Many are swayed by a number of DevOps “myths” that often stop initiatives before they even get started. So, what is the objection over and some myths about DevOps that keep some organizations from taking the steps to improved software delivery? We’ll take a look at a few that we have seen firsthand and, in subsequent posts, suggest some ideas and strategies for getting past them.

    Objection: “DevOps may work for some greenfield apps or startup but that’s not us.”

    Many of our most reluctant customers acknowledge the benefits of DevOps and continuous delivery but maintain that their systems are too old, too monolithic, mainframe-dependent, etc., to reap any tangible benefits from a transformation. In other words, “it doesn’t apply here.” This point of view is especially frustrating because the benefits to organizations like these can be just as dramatic and transformative to the culture and IT “psyche” as found among the “unicorns.” Maybe even more so. As the 2015 “State of DevOps” study stated, “It doesn’t matter if your apps are greenfield, brownfield or legacy—as long as they are architected with testability and deployability in mind, high performance is achievable.”

    Sometimes these groups will look to hybrid strategies such as bimodal where greenfield projects, innovation labs and other internal IT incubators are chartered to use new technologies and methodologies such as DevOps while the rest continue on as always. Opinions differ here, but these strategies generally are fine as a “way station” within an overall transformation road map with the potential to impede progress if accepted as the status quo. If legacy applications still change with some frequency and if deployments are painful for those involved, then those, too, should be included in the DevOps road map. We’ve done it at my company, a 40-year-old software company, and our mainframe team led the way.

    Objection: “We are doing fine as we are.”

    Another common category we encounter is the sense that, after some measure of improvement, perhaps the successful adoption of a toolset, that we’ve done enough. Things are better than before, our deployment pain has diminished so we have accomplished what we set out to do. A corollary to that is “we’ve implemented [Jenkins/Chef/Puppet/Cloud/etc.]” implying a belief that implementing one or more of these  tools is, in effect, “doing” DevOps.

    Successful DevOps is not about adopting a tool or even making measurable progress in organizational goals. DevOps is actually about embracing a culture of continuous improvement, collaboration and, perhaps most importantly, focusing first on maximizing value for your customers. It’s about adopting patterns such as the Deming cycle—Plan, Do, Study, Act—as a core tenet of the way you approach how you think about what you do. No matter what we do, no matter how well we do what we do, there’s always an opportunity to do better.

    Objection: “Implementing a major change like continuous delivery is simply too large and complex an undertaking.”

    When large, well-established organizations seek to undertake a major change, it’s often a task so daunting, so frequently met with skepticism and cynicism across the spectrum of stakeholders, that the initiative, no matter what it is, appears doomed from the start. Couple that with the culture-shift generally required to affect a successful and genuine DevOps transformation, and it’s no wonder that some senior IT leaders either severely limit the scope of these initiatives or, in some rare instances, veto DevOps outright. Regardless, the belief that their teams are too entrenched in current methodologies to make meaningful progress and the seemingly overwhelming weight organizational inertia stops change cold.

    Transforming organizations that have functioned in, more or less, the same fashion for years, even decades in some cases, is practically incomprehensible for many. Organizational cultures generally evolve over time and changing them is not something that can be accomplished by decree and certainly not overnight. The barrier to even starting is often the sense that “we have too much work to do right now and balancing that against some intangible future state is not something we can take on.” Of course, the problem with that line of thought is that there will always be too much work to do now.

    And, of course, there are many other obstacles. Barriers to entry against meaningful transformation like DevOps frequently emerge when new ideas and thinking collide with the status quo, especially pre-existing processes governing the software development and deployment. These processes generally emerged from the best practices of the recent past coupled with reactions to major problems encountered years ago that linger on as faint echoes of bygone errors. Most of these rules were put in place with good intentions, applicable at the time of implementation but may have outlived their relevance. Others may be regulatory and not optional. Regardless, if there ever was an area where DevOps and continuous delivery can deliver benefits, this is it.

    Many large “traditional” IT shops have, indeed, transformed their culture and fostered environments that continuously improve. So, what do you do? Perhaps the most important step is to decide to take the first step. First, understand why you are seeking to change in the first place. What is the ultimate driver and does everyone, top to bottom, the organization have a clear understanding of that “why”?

    Recognize that transformation is an ongoing process where successes and failures are to be expected in equal measure. Learn from both. Don’t attempt to roll DevOps out as a big bang strategy. Work incrementally.

    In upcoming posts we’ll explore some strategies for moving past objection and making real strides toward meaningful and lasting change. What are some of the challenges you have faced in your company’s transformational journey? How did your teams get past the obstacles that inevitably appear?

    — Jeff Bradley