Tag: CD

  • Culture Comes First in Bringing DevOps to the Mainframe

    Culture Comes First in Bringing DevOps to the Mainframe

    One of the most difficult challenges in engineering, oddly enough, isn’t technical: the challenge is culture transition management. In my 20-plus years of managing engineering teams worldwide, I’ve led teams through countless organizational adjustments and process improvements toward high-performance and quality, beginning with QA segregation to CMMI to ITIL, AGILE and SAFe.

    Today, mainframe organizations have emerged as the focal point for enabling DevOps capabilities and practices. Why the mainframe? Well for starters, business critical applications rely on mainframe data and business components. These applications are mission-essential and that sustained innovation requires solution sets that deliver continuous testing, continuous delivery and continuous feedback on the mainframe platform.

    But culture comes first.

    Understanding Your Key Players

    In conversations with our customers we’ve observed an interesting dynamic emerging within mainframe application development teams. Within these teams are experienced developers who were instrumental in creating the applications that helped make their companies so successful. Over time, many have become set in their ways, adopting a motto of, “If it’s not broken, why fix it?” Such developers are not interested in trying out new things, including programming languages and tools used by the modern-day programmer.

    New to the scene are the millennials who have also taken up the mantle of enterprise software engineer. They are a bit more open-minded and bring a different programming language profile, including Java, .NET and C. These developers might be learning how to code APIs with the support of management, and have likely dabbled the basics of how to code iOS apps. Millennial developers are typically much more active online and, as a result, prefer to leverage Twitter and other social channels to stay informed with the development community.

    United We Stand

    Who, then, should be involved in the journey to realizing DevOps? The answer, of course, is both. Because we’ve heard it reinforced among our users we talk with in the CA Communities every day, at user groups and at prominent mainframe community events such as CA World and SHARE.

    You know it, because you probably see it in your organization as well. There are experienced developers: people who have deep knowledge of the applications in place, business intelligence, database tables, cross-application dependencies, batch execution windows and the general experience of how things work on the z/OS platform.

    Most importantly, they also know how to avoid breaking what’s working.

    And there are the millennial developers: people who are curious to learn about new programming languages, platforms, people who, with the advent of Agile development, and open source have played with things, tested them and are using it to enhance their skill sets.

    These people prefer to use modern user interfaces and tools to increase their productivity. Sometimes they might be tentative about making mainframe changes, not willing to risk their careers by breaking poorly documented code.

    Culture – Have it Both Ways

    While the interests of millennial and experienced developers may at times seem conflicting, both have pivotal roles to play in application development and will benefit greatly from the common sense practices of DevOps and agility that are coming to the mainframe platform. To survive and thrive, teams must unify to facilitate the change process. Most importantly:

    • Code must be accessed and modernized at the speed of business. Enterprise developers, testers and architects cannot be afraid to go talk to the “black box” that is the mainframe team.
    • Project managers can’t worry that a six-week turnaround for small changes will kill their hopes of meeting their delivery windows.
    • The delivery team—QA, release management and operations—can’t afford to sit around waiting for simple deployment steps to happen: when we can automate and integrate to increase deployment frequency.

    The promise of DevOps and agility on the mainframe is to fix this, and that’s why our engineering teams are actively building out solution sets that extend DevOps practices to the mainframe, including continuous testing, continuous delivery and continuous feedback.

    Curious about what it will take to bring DevOps to the mainframe? Catch some tips and best practices from Forrester Research principal analyst Rob Stroud, or hear from the leaders driving change in their organization in our CA World 2016 Mainframe DevOps panel.

    — Aline Gerew

  • Automation Killed QA – It’s Time to Deal With It

    Automation Killed QA – It’s Time to Deal With It

    Quality assurance (QA) had a good run.

    From the time it was considered an afterthought by organizations and software vendors alike to the era of massive outsourcing contracts, followed by significant vendor investments in related tooling, and, finally, its recognition as a critical success factor among high-performing organizations, quality has evolved to become even more important than functionality to end users.

    Customer experience, today, is defined by speed and quality above all else. Namely, can I access the information and products that I want in the blink of an eye and get expected feedback based on input? As a result, customer experience has also shifted: It’s all about application experience, not the friendliness of a checkout cashier or sales/service rep.

    With this massive shift toward customer experience platforms (think omni-channel) and increasingly lofty expectations, the operative question becomes, How are we enabling velocity in our testing practices to ensure the highest quality while keeping up?

    We’ve tried everything from outsourcing to insourcing, investing in tooling, investing in people and even building testing architecture teams to oversee the automation, quality and consistency of testing results. Roughly seven years ago, my top priority for testing teams was to automate 30 percent of our tests. Today, if you are not 100 percent automated, or close to it, you are severely lagging in output.

    But what’s next? What if I’ve automated all of my tests and my manual testers have been replaced with automation engineers, but I’m still having quality issues and being perceived as a bottleneck?

    The answer is simple. Automate everything.

    Makes sense, right? Isn’t everyone telling you that? But what are we defining as “everything” from a testing perspective? Therein lies the problem; we are thinking about testing as its own factory within the larger software development life cycle.

    While we believe we are changing this perception by going agile and moving most QA functions into scrum teams, the reality is we still look at testing as a standalone function. Centralized or decentralized, this is the case, and we need to think differently.

    Automating for quality begins with defining requirements. How am I ensuring that I’m covering all cases? How do I ensure I’m translating the business requirements properly? These questions, the time it takes to answer them and the risk of human miscalculation all impact quality and velocity.

    We must start our automation for quality at the beginning, during establishment of business requirements.

    Let me introduce you to next-generation QA. Intelligent “continuous testing” platforms are replacing humans for testing, automating tests, creating data and building test cases. These platforms are able to translate model-based business requirements into complete automation—test cases, test data and test script automation.

    Orchestration across your software development life cycle creates your environments, lays down your test data, deploys your software, runs your test scripts and reports results. No more human error, no costly resources and guaranteed test coverage that ensures quality.

    Integrating your existing automation around continuous integration, portfolio management reporting, and execution reporting to this framework now gives you the ability to report and automate your ideas all the way through to outcomes.

    Early adopters are already doing this. QA as a functional organization is gone. If you aren’t already automating to this end, you are severely behind.

    Questions?  Comments?  Perspective?  Have at it in the comments below.

    — Ron DeCanio

  • Welcome to the Continuous Delivery 101 Podcast

    Welcome to the Continuous Delivery 101 Podcast

    No matter what industry you’re in or how old your business is, your software often determines your success in today’s application economy.

    Applications are the face of your business—both the way it performs and the speed with which you can incorporate new ideas and innovations, driven by the efficiency of your software development life cycle—determines whether your company can survive in this competitive market.

    Software doesn’t just support the business today, it drives the business—and your organization’s livelihood in this application economy comes down to your ability to quickly deliver world-class capabilities. As a result, more organizations than ever are turning to the practice of continuous delivery (CD) to improve their ability to plan, build, test and release applications to market.

    With this increased focus on continuous delivery methodologies and practices, we’ve established a new podcast that highlights the importance of utilizing CD, along with adoption techniques and other best practices.

    Dubbed “Continuous Delivery 101,” the series features some of today’s leading  experts in the field discussing where they’ve seen CD success, across some of the world’s top organizations and across multiple industries.

    The first episode in this series covers CD fundamentals and the software evolution that has made continuous delivery so critically important.

    Beginning in the ‘60s, this first wave of this software evolution saw mainframe systems brought in to automate business tasks. A second wave saw the emergence of ERP/CRM-based processes, so we could improve how we run contact management and transaction processes.  Today we’re in the third wave, which started with the widespread adoption of mobile and web technologies, with all of these paradigms intersecting in perfect convergence.

    Businesses that have mainframe and distributed systems, that have CRM and ERP system, that have web fronts and mobile apps, are utilizing these continuous delivery tools to innovate faster than ever before. These organizations are being forced to reinvent how they communicate with customers and how they deliver goods and services to stay relevant in the market.  This third wave, where business is now driven by IT, is the biggest disruption that we’ve seen.

    To hear a lot more on this topic, check out the  first episode of the Continuous Delivery 101 podcast via YouTube or the iTunes store, where you can find it on the Podcast App by searching for “Continuous Delivery 101 podcast.”

    Software delivery, fueled by CD, is evolving at a furious pace.  Stay tuned for more expertise and best practices.

    — Scott Edwards

  • DevOps by the Book in 2017: Where we Really Stand

    DevOps by the Book in 2017: Where we Really Stand

    Now that the year-end prediction season is over, it’s time to focus squarely on the actual here and now—where the DevOps movement actually stands at the start of 2017.

    As we’ll need to wait another six months or so for the annual State of DevOps Report to emerge from the good folks over at DORA and IT Revolution, which forces us to take stock of the situation using other resources. In this case, I’ll point to the recently released book, “DevOps for Digital Leaders,” authored by my colleague Aruna Ravichandran along with co-authors Kieran Taylor and Peter Waterhouse.

    Register today for the upcoming webcast, “Chart a Winning Course: DevOps for Digital Leaders,” and enter the chance to win a free signed copy of the book [U.S. only].

    Why should you value this book over any of the other DevOps-related titles inundating the technology literature scene, in particular those issued by (gasp!) technology vendors? I’d cite two very specific reasons: real-world metrics and use cases.

    I often preview any comments I make in cross-functional meetings with the phrase “shameless marketing.” That is because I work in marketing. For 12-plus years prior and sometimes in between marketing gigs I’ve served as a journalist, wherein my job was to attempt to be as objective as possible. Today, I work for a vendor that would really like to sell you stuff.

    That said, this current career path does not preclude me from being able to see beyond my own not-so-secret agenda. While many onlookers understandably groan and roll their eyes at the manner in which DevOps has been co-opted by marketers as a means to advance products, this doesn’t mean we’re all full of it.

    Like myself, working at CA—in particular, leading marketing efforts that span a huge array of strategic technologies actively being leveraged by global enterprises to attack various elements of DevOps—has given Aruna and her partners tremendous insight into where many people stand in terms of maturity.

    To that end, this book is written around some fantastic stories about how some of these organizations are refining best practices and measuring real success in domains including continuous testing, release automation and shift-left monitoring. IMHO, these are some of the hottest areas of DevOps being advanced as we speak.

    In addition to these use cases and related practices, the book takes an up-close look at critical aspects of the DevOps build, test, deploy and manage stages, along with key processes related to tuning and continuous improvement. And it even goes so far as to talk about essential DevOps tooling. I hope people are ready to acknowledge that beyond culture and leadership, automation absolutely plays a significant role in all of this.

    Specific to metrics, one of the areas where the State of DevOps peeps attempted to break new ground in the 2016 report, there’s a lot to appreciate. The book takes a close look at how these same organizations are attempting to tie DevOps-driven change directly to ROI, including the all-important customer experience.

    Worth noting, in the coming days we’ll also see the release of a new report from Coleman Parkes that charts numerous KPIs being used to this same end, so stay tuned.

    So there you have it, the marketer has officially hijacked this blog space to do little more than market a book about DevOps written by marketers. But, the truth is that’s not all.

    If you really want to hear the best parts of this story, sign up for the upcoming devopsy.kinsta.cloud webcast, “Chart a Winning Course: DevOps for Digital Leaders,” in which Aruna and Alan Shimel will discuss the high points, with an emphasis on fielding questions from the audience live Q&A style.

    If you don’t have time to read the book—or, better yet, you want a preview to ensure that what I’ve written here is true—post up and ask your own questions. We’ll also be conducting live polls about DevOps maturity, audience use cases and the leading types of DevOps metrics.

    It’s worth noting that all proceeds from the print edition will go to Foundation for Excellence, which provides STEM scholarships to children in India. Order your own copy today (or download it for free).

    — Matt Hines

  • 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

  • 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

  • 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

  • Welcome to the CD Neighborhood

    Welcome to the CD Neighborhood

    Today we opened a new neighborhood or section here on devopsy.kinsta.cloud. It is called the CD neighborhood and it will feature content on CD and related content. The neighborhood is sponsored by CA Technologies, who will also contribute content to the new neighborhood.

    CA authored content will be clearly marked. CA employees have contributed by lined articles to devopsy.kinsta.cloud for a long time and they have some great DevOps thought leaders. Recently they have also acquired Blazemeter and just announced the intent to acquire Automic as well. This should mean even more great content from them.

    But CA is not the only content provider for the new CD neighborhood. The devopsy.kinsta.cloud staff writers will be contributing to the neighborhood on a regular basis. In addition, contributed articles that are on theme will also be posted here on a near daily basis. In fact I encourage you to submit your thoughts on CD to me at editor@devops.com, if you have something to say on the subject.

    In addition to written articles, the CD neighborhood will also host both audio and video content that is on point. Many will come from our DevOpsTV YouTube channel and DevOps Chats hosted on SoundCloud.

    With CD being such an important part of DevOps we think that the CD neighborhood is going to be a favorite destination for many of you. We will do our best to keep it fresh, informative and useful!

    — Alan Shimel

  • DevOps Chat: DevOps & CD with Tim Butel, XebiaLabs

    DevOps Chat: DevOps & CD with Tim Butel, XebiaLabs

    devopsy.kinsta.cloud caught up with Tim Butel, VP of Products at XebiaLabs. Tim discussed some of the latest trends in DevOps & continuous delivery (CD) with us. He also gave us a great update on what XebiaLabs has been up to recently and why organizations including Gartner and others consider XebiaLabs a leader in the category.

    Tim also gave us some great insight into how he has progressed in his own career. How can someone listening to this try to set out on a similar career path? Tim’s journey may prove helpful to you.

    As usual, below is the streaming audio of our conversation and below that is the transcript of our conversation, Enjoy!

    Alan Shimel: Hey, everyone, Alan Shimel, devopsy.kinsta.cloud here, for another DevOps Chat. Today’s DevOps Chat’s guest is Tim Buntel, VP of products at XebiaLabs. Tim, welcome.

    Tim Buntel: Thanks so much, Alan. It’s a pleasure to be joining you today.

    Shimel: Yep. Well, no, it’s our pleasure to have you here. So, Tim, I know you’re fairly new, though not really new new to Xebia, but how long have you been on board there now?

    Buntel: Yeah, so it’s coming up on about six months now, so long enough to have had a couple releases and seen where we’re going as an organization and start to chip in, but can’t take too much credit for all the success of the company yet.

    Shimel: No. Okay, fair enough. And then, Tim, VP of Product. So you’re—give our listeners what exactly does that entail in terms of your responsibilities.

    Buntel: Yeah certainly. So, you know, my team brings together product management, user experience, and all of the folks who are basically bridging the needs of the market to the rest of the organization. So we’re looking strategically at where we want to invest in new features in the products, we’re bringing requirements back to the engineering team, we’re designing the solutions for the features, and then we help bring that back out to the market. So interacting with the analysts and press, interacting, you know, in the support capacity to sales and that sort of thing. So really being that conduit between the market and the customer’s needs and all of the activities that are happening in the organization.

    Shimel: Great. And Tim, you know, we might have some people out there who are a little younger, starting out in their careers, and they hear, wow, this guy is VP of Product at a company like Xebia. Can you give you listeners, give us a little bit of background, so what sort of qualifications, what experience did you bring to this position that kind of, you know, makes you able to succeed at it?

    Buntel: Hmm. Yeah, I mean, product is a great role for folks who really want to help be the advocate for their customers. So in my case, my whole career has been in Dev tools and building businesses that create product that other software engineering companies, you know, sell and use. So I ran the developer tools business at Atlassian, I’ve worked for Microsoft and Adobe, I’ve done a couple of startups that are in the Dev tools space myself.

    But the most important thing was originally I came from a development background myself. So as a developer, I was able to understand the challenges that development organizations faced. So often when I talk to professionals who are in this space, you know, maybe you are a DevOps engineer or you’re a software professional and you like solving problems, and you have a keen sort of interest in the people, right? So talking to people, understanding what their problems are, and then being able to creatively come up with solutions to those problems, that you can turn into a product so that you’re not only solving one person’s problem, but you can turn it into a product that solves that problem at scale for a market. Those are really the qualities that are most important for the job. So understanding the space and the domain—understanding, you know, in my case, what it means to build software—and then wanting to work with other creative people to find solutions to those problems, that can translate into a road map of features in your product portfolio.

    Shimel: Excellent, excellent answer, and I hope our listeners or anyone who might be interested in that topic takes that to heart, Tim. I think there was some great advice and lesson there. So let’s turn a little bit, Tim, though, and talk about Xebia, right, and to kind of lay the groundwork, to you, what is XebiaLabs really all about? What is the secret sauce of XebiaLabs, if you will?

    Buntel: [Laughs] Yeah. I mean, I think for me, the most important thing about us is that we’re really focused 100 percent on continuous delivery. We’re an independent company and that’s all we do. So every day we wake up and we figure how can we help other software organizations, generally they’re enterprise IT teams, how can we help them deliver better software faster, with less risk, right? So we combine many years of experience in that area. We were looking at deployment automation, as much as seven years ago now, I guess, so really before the term DevOps was even broadly adopted, we were solving these problems for large enterprises. And to this day, we continue to do that. So we are able to solve really large-scale enterprise problems because it’s 100 percent of our focus.

    Shimel: Excellent. And so that being said, Tim, now that we know sort of what Xebia is about, I guess fair to say what attracted you to this position? You have a long resume of success with some very, very successful companies, obviously. What was it about Xebia that said, man, this is where I want to be?

    Buntel: Yeah. Well, it’s really the culmination of a lot of the pieces that I’ve been working on in my whole career. So if you look at a software engineering organization today, many of the products that I’ve worked on constitute elements of that technology landscape that they have, right? So everything from issue tracking systems and collaboration tools at the beginning, through source code control and build tools and deployment tools, all the way to the end, to monitoring and user feedback, right? This is a great assortment of individual products, but it also results in a fairly chaotic landscape. So if you’re an organization trying to apply all of that at scale, keeping track and orchestrating all of that together has consistently been a challenge, right?

    So for me, this opportunity to step in and say, okay, the next really important challenge in doing continuous delivery at scale is to orchestrate all of those pieces, and that’s what we’re really focused on at XebiaLabs right now. So XL Release, for example, is release orchestration automation tool that does just that. So we can help organizations automate and manage that process for even the most complex pipelines, and for me, that was a great next step, right? So I had worked on some of these individual pieces that were solving very specific parts of a development team’s challenge, and now I’m able to step back and offer a solution that helps sit above all of that and really make all of those pieces fit together. It’s like a conductor in a symphony, you know, being able to get the most out of each individual musician. That’s kind of what we’re doing for all of these other great parts of the continuous delivery pipeline.

    Shimel: Excellent, excellent, excellent. So, Tim, why don’t we—we’ll continue on the Xebia topic here for a while. What’s new? What’s new, what’s exciting coming out of Xebia these days?

    Buntel: Yeah, there’s some great work that we’re doing. You know, we continue to get great recognition from the analysts and press, we’re getting some great coverage from Gardner and Forrester recently, which is really exciting for us. And what we continue to hear both from them and from our customers themselves is that because we’re focused entirely on the continuous delivery piece, we’re able to offer some insight into our users in a way that, you know, individual point solutions aren’t necessarily able to do that. So a large emphasis for us is on this kind of reporting and insight, being able to analyze the performance of your continuous delivery process and kind of your DevOps organization. That could be through reporting, it could be through analytics, helping organizations find out where bottlenecks might be in their process. So it’s not just managing things, but it’s helping guide you toward ways to improve the efficiency of your program, and even to help folks measure the ROI of that.

    So lots of organizations are trying to adopt DevOps and continuous delivery, and in many cases, it’s difficult for them to know what’s the ROI of that. So a big emphasis on our tools lately is on that aspect. So helping you get insight into your continuous delivery process, and we’re doing that in a way that’s extensible and supports integrations with pretty much any technology that you’re likely to find in the enterprise DevOps stack.

    So that’s one piece, the insight and analysis part. The other piece that I think is a real strength of ours, that’s very exciting for me, is the breadth of participants in the process that are successful with our products. So a lot of solutions that are out there helping organizations with continuous delivery are really focused on the most technical people in the process, right? So they’re very script-focused, they tend to be very technical, and really, in the enterprise, the people who are participating in continuous delivery or DevOps initiatives more broadly, they’re coming from a lot of different backgrounds. You might have, you know, less-technical business owners, you might have risk or compliance professionals, and a host of managers and other stakeholders besides the real technical teams.

    And one approach that’s been really centered to our product development recently is to make sure that the products are approachable, they have a great user experience, they are easy to use, they’re easy to understand, regardless of the degree of technical expertise in the user, while at the same time still satisfying all the needs that the most technical parts of the team have. So you can fully automate and fully script all of our solutions. We’ve got full API access and CLI capabilities as well. But the spirit of DevOps as a social process as much as a technical process can only be successful when the products are appropriate for folks with a range of different experiences. So that’s another really key focus for us now.

    Shimel: Yep. What about the bigger—Tim, what about the bigger DevOps market, and how Xebia is sort of playing in that. We’re starting to see, you know, DevOps Express, for instance, was announced two weeks ago at Jenkins. But, you know, I think that’s a symptom of a bigger—I don’t want to say disease, that’s the wrong word, but a symptom of a bigger thing, which is sort of interoperability, right? No one DevOps tool is gonna do all your DevOps for you, right? So what – you know, what do you think about that kind of trend, if you will?

    Buntel: Sure, certainly. You know, in fact, I can point to something that XebiaLabs has been running for the last couple of years now, probably, that really illustrates that beautifully. That’s our periodic table of DevOps. I don’t know if your listeners are familiar with it, but you can find it on our site, and it’s a, you know, a play on the periodic table of the elements, that’s cataloguing all of the different technologies that are typically present in, you know, a DevOps or continuous delivery stack. Everything from ticketing systems through STMs and builds and provisioning tools and all that.

    And it’s community-sourced, so folks vote on the technologies that they use and the things that are most important to them. And we have a new tool now that’s part of that, that allows you to define the pieces of technology that are part of your enterprise IT environment, and it’ll help display kind of what your DevOps environment might look like, based on the combination of all of those technologies. But my point there was that, yeah, exactly as you said, it’s such a cluttered landscape and it’s growing at such an explosive pace, right? There seems to be a new open-source technology that’s looking at a different piece of the puzzle that comes up almost weekly, right?

    So the challenge that we see for professionals that are in this space, especially in the enterprise, where you might be managing the development initiatives across different geographic locations and teams who are trying to be empowered to select their own technology is how do you centralize that and manage that while still balancing the control that you need as an enterprise, with the autonomy that you want to give your individual development teams to pick and choose the technologies that are best for them. our approach for it in our product is to really focus on integrations. So we have, you know, both of our products really emphasize integrations first, so that we can build integrations as they come to all of these emerging technologies, as well as the established and even older technologies. Everything from mainframe to the most recent sort of container or container management systems, we’re able to integrate with because we’ve built our products in this loosely coupled integration-based way. So that’s certainly something to look for if you’re considering how to construct your own continuous delivery or DevOps, you know, sort of landscape. Make sure that the products put integration at the center of how they’re able to hook together.

    Shimel: Got it. So, Tim, believe it or not, we—I told you we’d do this for 12 minutes, and we’re at 15.

    [Laughter]

    Shimel: It happens. Just one last question, and if you have an answer for it, fine, if not, it’s okay, but I usually always like to ask my guests if you had to recommend a book to our audience to read, a must read, what book would you recommend? It can’t be “The Phoenix Project,” by the way. We’ve already got that one, but go ahead.

    Buntel: [Laughs] Yeah. Well, yeah, well, you know, on my desk right now I’ve got sort of the following on “The Phoenix Project,” right? We have the new “DevOps Handbook,” from Gene Kim and Jez Humble, and we’re getting a lot of interest from our customers in that book, and, you know, we talk to Gene a lot and he has some really great insight. So I’m pretty excited—I’m about halfway through that, and there’s some really terrific case studies and great, practical, you know, kind of illustrations of how this actually works in real world technology and organizations out there. So that’s a great one for me, the latest.

    Shimel: Yeah, yeah. It’s interesting, a very different sort of focus than the first one. But anyway—

    Buntel: I love that—I love that there’s a good focus on metrics in this one as well. That’s something that I’m personally really interested in, is, you know, this ROI of DevOps initiatives, and I think he’s got some great case studies in there that help measure that.

    Shimel: Well, Gene is a metric nut.

    Buntel: That’s right.

    Shimel: So anyway, Tim, we’re at the end of time, really, we’ve got to wrap. Tim Buntel, VP product XebiaLabs. Thank you so much for being this episode’s guest on DevOps Chat. Hope to see you soon, and we’ll catch up again, all right?

    Buntel: Thank you so much, Alan, and look forward to talking to you again sometime soon.

    Shimel: Okay. This is Alan Shimel for devopsy.kinsta.cloud. See you on the next DevOps Chat.

    — Alan Shimel

  • Continuous Integration vs. Continuous Delivery: There’s an Important Difference

    Continuous Integration vs. Continuous Delivery: There’s an Important Difference

    If you read DevOps blogs today, it can be easy to assume that Continuous Integration (CI) and Continuous Delivery (CD) are synonymous terms. People often use them that way. But that’s a mistake.

    As an example of conflation of the terms CI and CD, take this page, which purports to be a “history of CI/CD tools.” The author does provide a truly excellent history of CI platforms.

    But CI tools are the only subject that the page discusses. It’s not a history of CI and CD. It’s just a history of CI platforms. To work the history of CD into the picture would require discussion of how software testing and delivery practices have changed over time, not just an overview of the history of CI software over the past several years.

    I don’t mean to knock the page. It’s a great read, and the mistake the author makes in treating CI and CD as synonymous is hardly rare. He or she is just repeating a common confusion. You see the same lack of distinction between CI and CD on Docker’s discussion of CI/CD, for instance.

    The Difference between CI and CD

    It’s unclear how this conflation of the two terms originated. But it’s easy enough to clear up.

    Simply put, CI is the process of integrating code into a mainline code base. In almost all scenarios today, CI is done using platforms designed specifically for the purpose. Implementing CI is, therefore, as simple as using the right tools.

    CD is more complicated. CD is about the processes that have to happen after code is integrated for app changes to be delivered to users. Those processes involving testing, staging and deploying code. There is no single type of tool that does all these things. These processes take different forms, depending on the culture of the team and the type of app it is creating.

    In actuality, then, CI and CD share little in common. Besides starting with the same word (“continuous”) and being different stages in modern software delivery pipelines, they don’t have much to do with one another.

    Why the Difference Matters

    Why is it important to steer clear of this confusion? The main reason is because, by conflating CI with CD, organizations can end up doing only the former but thinking they have implemented the latter.

    Setting up a CI server such as Jenkins or Bamboo to integrate code changes continuously does not mean you are doing CD. It just means you are using a CI server.

    To get to CD, you also have to organize your software testing, staging and deployment processes in a way that automates them as much as possible and makes them continuous. Doing so requires more than simply turning on a certain type of tool.

    How you actually do CD is fodder for a separate, much longer article (or you could just read the book about it). But recognizing that CI is not CD, and avoiding confusing formulations including CI/CD, is a start.

    — Chris Tozzi