devopsy.kinsta.cloud

Tag: software development

  • Why Financial Companies Love Continuous Delivery

    Why Financial Companies Love Continuous Delivery

    The other day I was on the American Express website paying bills and browsing around the benefits and services afforded me when I ran across a “who we are” section. It read:

    “We’re a global services company that provides customers with access to products, insights and experiences that enrich lives and build business success.”

    Surprisingly, the term “financial” was missing from the description. This led me to wonder if other financial institutions are evolving how they think about themselves. Here are some other examples:

    • Bank of America: “Here to help connect you to what matters most.”
    • ING: “Empowering people to stay a step ahead in life and in business.”
    • MasterCard: “As a technology company, we connect individuals, businesses and organizations around the world, creating greater opportunities for all.”

    Financial Companies Love Their Customers

    My unscientific assessment of various financial services companies suggests that they are centered on delighting their customers. They are transforming who they are by altering their customer engagement models and essentially becoming better software companies. MasterCard has even reclassified itself as a “technology” company. These companies are transcending the role of transaction engine to offer seamless, intuitive digital experiences for their customers.

    And the proof is in the performance. According to Forrester’s Customer Experience (CX) Index, financial services firms, including retail banks, credit card companies, investment firms and auto and home insurers, are some of the top brands worldwide when it comes to CX.

    You might think that large financial institutions would be digital laggards because of legacy infrastructure, regulatory compliance pressures and overall risk-avoidance. But you’d be wrong.

    In another study, 81 percent of financial services firms said they are embracing digital to redefine their businesses, and 87 percent are on the DevOps bandwagon. Sixty-one percent even said they are disrupting their industry with advanced digital initiatives.

    To stay competitive and improve their customer experience aptitude, financial services firms are undergoing significant digital transformation.

    Getting the Pulse of Fintech Continuous Delivery Adoption

    But how progressive are these firms in terms of their application delivery practices? Working with CA, Gatepoint Research recently surveyed more than 100 IT executives from financial services companies to take the pulse of where they are in continuous delivery adoption. Results can be found in this report and infographic.

    First off, to see if these companies might be considered unicorns or stragglers, they were asked the total volume of monthly deployments in all environments. Forty percent fell at the low end with fewer than 50 deployments per month. Now, lower deployment numbers could mean that these are less agile organizations or that they have fewer applications in general. Somewhat correlative to lower deployment numbers, the survey found that 48 percent currently are not using an application release automation (ARA) solution. Without automation, it’s tough to scale release processes—particularly to keep up with agile development.

    Moving up the spectrum, 41 percent are moderately prolific at 50-500 deployments per month, and then 15 percent are what I would consider rock stars with more than 500 (7 percent of those over 1,000). Those doing hundreds of deployments a month often have agile development teams and more modular applications. They likely have continuous delivery practices in place that push more frequent, iterative deployments left, helping higher-quality applications to move through the pipeline to production.

    The primary application delivery goals for financial services firms for the next 12 months are to get better control of release processes, tools and environments; to reduce risk and failures; and to release applications more frequently. All of these needs typically stem from companies undergoing digital transformation—it feels more chaotic and disconnected, manual processes are breaking under the weight and there’s intense pressure to move faster.

    Compliance was not a top goal, and the majority (83 percent) claim that their current release process is adequate to meet regulatory requirements. However, they did acknowledge that they could improve in terms of knowledge safekeeping and auditability of the release process.

    The data certainly shows that financial services companies are adopting continuous delivery practices in some form and exploring solutions, including many open-source tools, to help them get the job done. They currently are focusing continuous delivery practices on tracking and reporting releases, planning and scheduling releases and automating test deployments. These practices ultimately help financial services companies to release high-quality applications anywhere at any time.

    How Continuous Delivery Helps Fintech Win

    Continuous delivery sits at the heart of many digital initiatives because of what it enables these companies to achieve for their customers:

    • Delivering features and updates that customers need when they need them
    • Delivering applications that meet performance and quality expectations of customers
    • Delivering secure, compliant applications (for external and internal customers)

    Continuous delivery enables continuous devotion to the customer experience.

    Continuous Release: Fast Customer Response

    With continuous delivery, you establish an application release workflow that automatically connects a developer’s update to parallel testing to staging and ultimately to production release. Because of the underlying end-to-end automation technology, these steps can happen quickly, seamlessly and with little to no manual intervention. Some might call it “push button release” or “zero-touch release.”

    It’s a controlled, tracked, governed, collaborative process. Application stakeholders stay aligned as application changes traverse the pipeline. Your customers can have access to fixes, updates and new innovations in days instead of weeks or months.

    Continuous Testing: Building in Quality

    In contrast to the significant time penalties and shortfalls that can happen with manual testing, in the continuous delivery pipeline, testing is shifting left and happening in parallel. Hand-offs and feedback loops are automated and efficient.

    Testing can happen earlier and without delay with the help of test environment simulation. Testing is on target through automatic test case creation, even from requirements. Testing is real-world with on-demand test data generation. And testing is rigorous with developers able to performance test apps at their end. The continuous testing that occurs as part of the process helps to build in quality and ensure top performance before reaching the customer.

    Continuous Compliance: Audit-Ready Processes

    Ensuring applications are compliant and secure is critical for your customers. It’s making sure customer information is safe and that application changes are tracked sufficiently for SOX or other reporting. It’s also about helping out those internal “customers” like auditors to prove compliancy and easily build reports.

    An automated continuous delivery pipeline can track releases, apply role-based governance, orchestrate proper data masking, deploy security policy updates and provide an audit trail for application releases—who did what, when and why. All this data can be collected and reported easily, which saves time and effort for auditors. You essentially stay compliant and secure all the time.

    Customer Satisfaction Through Automation

    Financial services companies are laser focused on using technology to delight and retain customers. And continuous delivery is the application delivery practice that’s underpinning these efforts. The companies that are exceptional at this, with thousands of deployments per month, are using automation tools such as Application Release Automation (ARA). These tools are the backbone of continuous delivery, providing the automated orchestration, governance, tracking and reporting for your pipeline—development through production.

    That’s why I’m not surprised that leading financial services companies make up a large portion of CA’s release automation customers, including Euroclear, GM Financial, ING, Jewelers Mutual and Western Union. Our customers put high value on delivering excellent customer experiences and are implementing modern software delivery methodologies, practices and associated tools to support their efforts. GM Financial recently said it is “the software company that does auto finance.”

    If you are serious about customer satisfaction and staying ahead of nimble competitive threats in the market, you must get serious about end-to-end automation. It’s time to truly embrace the practice of continuous delivery to be able to consistently release applications that are progressive, always compliant and completely customer-satisfying.

    — Patricia Johnson

  • Boosting Time-to-Market by Improving Software Development

    Boosting Time-to-Market by Improving Software Development

    Today’s business environments require “agility” in terms of being able to quickly understand and adapt to information, trends and new developments. For example, a company might employ a business intelligence suite that provides them with real-time information on product sales, which allows them to dynamically adjust content or strategy.

    Set a Baseline

    You can’t measure improvement in a business process without first establishing a baseline. The first step in reducing the time-to-market for software development is to look closely at the current development process. Review the steps involved in turning an idea into a live product or product feature and identify any bottlenecks, inefficiencies and constraints. Once this review is complete, set realistic goals that reflect the current situation and the improvements you want to see within a certain time period.

    Eliminate and Optimize

    During the review and baseline phase, you might come across activities that do not add value and do not speed up the process. Perhaps there are some unnecessary meetings during the mid-phase of the development process that typically do not uncover any problems and hold no real value. Or, there’s a documentation step that is a drain on human capital and takes away valuable time from testing and innovation.

    Identifying problems and bottlenecks is vital, but the efforts will be wasted if there aren’t open lines of communication. Poor communication causes software release delays, so establish efficient processes, set up the right team structure and adopt tools and technologies that allow transparent and fast communication between cross-functional teams. When it comes to teams, you want to find the right balance of staff. Generally, a winning team includes the right analysts, marketing managers and DevOps resources who can work together towards a common goal.

    Streamlining and Developing Incrementally

    As the team moves into development, there are steps you can take to increase efficiency. Independent tasks should be performed in tandem; for example, test scenarios built while various features are defined. Do not wait until development is completed before creating test environments; encourage the team to split parallel tasks that best match with their individual talents.

    When it comes to enhancements for business apps, there’s an inclination to go for the “home run” by greatly changing the application and including many new features with every update. For reliability and speed to reaching the market, you instead want an incremental approach, by which you develop controllable enhancements and bug fixes that provide immediate value to the users. Prioritize the “wish list” of feature sets so you can better manage and plan the updates that will go into future releases. Get buy-in from other departments and then build and create an enhancements schedule.

    Test Often and Embrace Automation

    In addition to having testers test the application, you should actively engage with clients and select users early in the development process so they can provide input on the overall functionality and user interface as well as help discover bugs. Your time-to-market can be greatly impacted if bugs aren’t caught early on, and you might even need to pull a newly launched application if the glitches impact users adversely.

    Improving this process requires defined and repeatable testing procedures and, to reduce time-to-market, these procedures must be automated at least partially.

    Consider these other benefits of software testing that will improve your DevOps:

    • Discovering bugs and software errors can improve the system’s capacity
    • Testing can improve the security of your applications
    • Improve customer engagement and satisfaction through a high QoE score
    • Reduce the total cost of ownership
    • Better meet industry standards and compliance regulations

    Other automated processes should be introduced into the development cycle, including environment provisioning, data or API mocking; builds management; and standards enforcement. For instance, automated deployment solutions give DevOps a repeatable process so engineers have more time to focus on crafting new features. Another example is release automation tools that manage workflow as software moves between development, production and testing. These tools not only speed up the process, they also eliminate potential for human errors.

    The modern business relies heavily on applications to communicate, complete sales and operate more efficiently. Companies strive to bring these apps to the market quickly so they don’t miss opportunities and can adjust to market conditions. To accomplish these goals, companies must adopt the right software development processes and tools to improve their time-to-market speed and capture a competitive advantage.

    About the Author / Ajay Kaul

    Ajay Kaul is managing partner at AgreeYa, bringing more than 27 years of experience in sales, consulting and managing small to large IT projects worldwide. Kaul has led AgreeYa through 16+ years of success, leading the company in highly competitive and complex markets and driving significant profitable growth with global workforce of more than 1,500. Prior to founding AgreeYa, he was responsible for managing engagements for Deloitte serving private and public sector clients across United States. Connect with him on LinkedIn.

  • Be Here Now – Agile and DevOps in the Current State of Synergy

    Be Here Now – Agile and DevOps in the Current State of Synergy

    If there’s one thing that our culture does not lack, it’s a litany of pithy catch-quotes meant to remind us to focus on the task at hand; yet, this often runs counter to our tendency to fixate on matters of the past and future.

    While we are so often encouraged to “live in the moment” and “seize the day”, this is hardly an easy task, especially as related to any sort of emerging phenomenon that compels us to improve on historical missteps, and predict how things should change for the better.

    Register today for the 3rd Annual DevOps Virtual Summit.

    With the methodologies of agile and DevOps the tendency is, of course, to do the same, harping on the inefficiencies of previous software delivery models and painting an elaborate portrait of how related workflows are being transformed overnight.

    The simple truth is that it’s easy to get excited about concepts that hold such tremendous potential in recasting an increasingly critical vital set of processes, and lose track of where things actually stand.

    To note, while a recent research project published by Coleman Parkes found that over 80 percent of organizations have adopted some manner of agile and DevOps practices, and see them as critical in transforming their internal software factories, only a third have adopted the methods on a broad scale.

    Point being, we’re still pretty early.

    That said, we in the business of helping organizations adopt related culture and tooling have gone to great lengths to encourage everyone that this change should be pursued with dogged intensity. We have sliced and diced the data to illustrate how those organizations at the forefront of so-called digital transformation, enabled by agile and DevOps, are realizing the results in the form of increased velocity.

    The same research finds that “advanced” adopters of the two concepts are, in fact, seeing significant improvement in time-to-market, customer satisfaction and new business growth.

    But research is just that, and often not completely aligned with real-world scenarios. Someone who takes the time to answer a survey about such matters, one could reasonably expect, is the type of person far more likely to be involved in agile and DevOps activities.

    My personal conversations with everyday practitioners [aka other parents on the sidelines at my kids’ sports and social events, many of whom work in IT] tell me that we’re much more oriented to the “pockets of innovation” phase at present, than any sense of pervasive adoption.

    So this begs the two-part question – where do we really stand, and what do I really need to care about?

    The only reliable source of record in my mind is the perspective of people already doing the work, beyond what I can discern amid basketball games and middle school theater. Real-world practitioners are the voices of reason that allow us to “be here now” and address the specifics of practical agile and DevOps implementation.

    Over the past several years, I’ve found one of the best sources of such input to be the customer panels available at industry conferences and on webcasts. When it’s time for me to sit down and crank out some related content, I often go back to these recordings to remind myself where the rubber actually hits the road.

    On Tuesday Mar. 7, we’ll host just such an event, the 3rd Annual DevOps Virtual Summit, where agile and DevOps leaders from organizations including CNN, GM Financial and United Airlines will share their thoughts on how this ongoing transformation is playing out, and where the remaining challenges lie.

    Along with those experts, we’ll also hear from Dr. Nicole Forsgren, one of the leading researchers in the space who is in seemingly constant contact with people leading the charge and working in the trenches putting agile and DevOps into practice.

    As a marketer, and previously as a journalist, everything that I know comes from direct interaction with those colleagues willing to share their hands-on experience garnered via doing this work every day.

    Register for the event and join us to find out where agile and DevOps actually stand today.

    — Matt Hines

  • CD 101 Podcast Episode 2: The Agile Enterprise

    CD 101 Podcast Episode 2: The Agile Enterprise

    And we’re back with another episode of the “Continuous Delivery 101 Podcast.”

    In Episode 1, we covered the three waves of IT disruption—and how these disruptions, combined with the move toward digital transformation, are drastically changing every industry.

    This, of course, underlined how accelerating speed-to-market is clearly more important than ever before.

    In this second episode, we talk about Agile methodologies with expert Dan Rice, who addresses how these practices can enable business strategies to be implemented at greater speed.

    Listen closely and you’ll learn more about what Agile actually means across various teams, roles, product owners and scrum masters, along with related points on DevOps and CD tooling.

    All of these topics are great food for thought as you think about how you can move to build software faster and with increased quality. Yet, if enterprises only focus on these issues, they aren’t tackling or talking about the real problem in their organization that Agile can solve.

    It’s time to take the conversation beyond the team level and talk about how work flows to every involved team, enterprise-wide—specifically, about how initiatives can expand across multiple teams, how to manage shared resources and how to pull in other dependent teams.

    For Agile to work, it has to expand universally and be ingrained further at program level, to understand precisely how work is coordinated and flows across every domain.

    You can listen to Episode 2 of the “Continuous Delivery 101 Podcast” via:

    • YouTube
    • iTunes store
    • Or by searching for it in the iTunes Podcast App under “Continuous Delivery 101 Podcast”

    Thanks for tuning in to the “Continuous Delivery 101 Podcast.” We hope you’ll continue the conversation by posting your comments below or in the comments section on YouTube or iTunes.

    Meanwhile, keep tuning in: We’ll be back soon with another episode!

    — Scott Edwards

  • 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

  • Keep Applications Running by Testing Early, Continuously

    Keep Applications Running by Testing Early, Continuously

    Almost every product we buy or use today goes through some form of extensive testing before it’s released on the market; typically, these tests are designed to replicate the worst-case scenarios that a product may encounter under real-world conditions.

    Automobiles, for example, go through extensive hot and cold weather testing in remote locations, and are driven over obstacle-laden tracks designed to push the limits of their durability. Even seemingly mundane objects such as children’s toys are exposed to abusive simulations to ensure that they don’t harbor any potentially hidden and harmful effects.

    On the current landscape, applications are the face of your business, often serving as the battleground where consumer loyalty is won or lost. Given this reality, it seems crazy to think that any applications are released having only been exposed to a minimum of tests. Yet, in the name of getting to market quickly, that’s far too often the case.

    As disciplines including agile and continuous delivery continue to increase the speed at which development teams can release software, it’s easy to put the crunch on testing in the rush to get an update released. But that’s a costly mistake in the long run, as research has shown that it is 50 percent less expensive to find an error in testing than to address the same error once it has reached production, and more than 90 percent cheaper  when addressed in the development/coding phase.

    Given the dramatic cost savings of addressing errors in development, clearly the goal of any organization focused on continuous delivery should be to shift testing left so a greater number of defects are found early in the development process. This is what we refer to as continuous testing, and it’s a huge part of the reason why I am so excited about CA’s acquisition of BlazeMeter.

    Performance load testing should be a core element of any continuous testing strategy because it is a critical factor in determining system reliability. Similar to the worst-case scenario testing that consumer products undergo, performance testing can quickly uncover applications defects that might otherwise go unnoticed. After all, the manner in which a system operates with a few hundred concurrent users may be very different than how it runs with thousands of users.

    BlazeMeter enables today’s development, operations and DevOps teams to conduct this critical performance testing earlier in the development process, saving countless hours and resources. The company is also competing—and winning—in a highly competitive marketplace where it has been pitted against much larger, more entrenched competitors.

    Part of the reason BlazeMeter is winning is its focus on offering a SaaS-based solution that is highly cost-effective and easy to engage. Using this model, customers can try  out the testing software with a few clicks, and then quickly move forward to broadly adopt the system. Another catalyst to its success: BlazeMeter was built using open source tools, such as Apache JMeter, used widely in the development community for performance and load testing. As a result, BlazeMeter can easily run and analyze JMeter and other open source-based load tests—such as Selenium, Gatling and Locust—within a commercial-grade performance testing system.

    This combination of a SaaS delivery model and incorporation of open-source tools, augmenting strong performance testing functionality, make BlazeMeter very complementary to CA’s existing continuous delivery solutions, including its CA Service Virtualization, CA Test Data Manager, CA Agile Requirements Designer and CA Release Automation products.

    At CA, we’re committed to providing the most comprehensive, integrated and open continuous delivery ecosystem, allowing our customers to release swiftly, test agilely and constantly increase reliably. The addition of BlazeMeter will further enable customers test continuously, thereby increasing agility and the overall quality of their software, to ensure that applications don’t break down on the side of the virtual road.

    — Aruna Ravichandran

  • DevOps: Using Games to Make it Practical

    DevOps: Using Games to Make it Practical

    This blog stems from my experience of being one of the earliest DevOps Foundation trainers of DOI and successfully completing 19 batches of DOI Foundation course in the last year.

    In retrospect of the year starting when TaUB Solutions signed up as a registered education partner (REP) of DOI, my opinion is this has been the best service portfolio offering for our customers and partners.

    There are few things that appeal best when it comes to DOI Foundation course and I can summarize them with the collective feedback I’ve received so far:

    “Challenges the preconceived myths and practices around DevOps with practitioner stories.”

    “Gives a holistic overview of philosophy behind DevOps. Philosophy should precede science and science should precede engineering.”

    “This course maintains the discipline to be truly advisory in nature by illustrating tool chain without recommending vendor-specific tools.”

    “The group exercises during the class and the facilitator practical insights helped us to put the aspects in to our organizational context of delivering products and services.”

    “We have never seen a course such beautifully designed that could be the first basic building block to know ‘Do’s’ and ‘Don’t’s’ of DevOps across application developers, infrastructure operations, project managers, infosec professionals and business leaders.”

    To enhance the overall learning curve of the audience, we put them in to the third day of experiential learning using the Phoenix Project Business simulation. The simulation was divided into four rounds and played with maximum of 12 people per batch. The Team was entrusted to achieve a target of $300,000 within four rounds and take the share value from $21 to $45.

    While the target milestones were clearly laid down at the beginning of game it was difficult for the teams to get hold of the situation due to various unknown parameters. It took them quite sometime to understand the different moving parts of flow, dependencies, business impact of projects, issues and features that came up in every round and make  appropriate choices and decisions.

    The teams experienced significant learning, sharing and collaboration over the four rounds and had loads of fun. One common feedback from the teams was for the game to be mandatory after every two-day DevOps Foundation course.

    The consolidated feedback after playing the DevOps business simulation after the two-day course:

    “It demonstrated that it is not easy to build collaboration, communication and integration. It takes time and there is a lot of patience and team work needed to make this a reality. The DevOps culture had to be nurtured through self-organizing teams with mutual respect, sense of pride and collective ownership to work toward a common goal.”

    “It gave a working knowledge on how ITSM and DevOps are complementing each other [Ex. Change Management and Improved Flow].”

    “The Principles of DevOps, namely the First Way (Improve Flow from left to Right), Second Way (Shorten Feedback Loops) and Third Way (Repetition through Mastery) was visibly evident over the course of four rounds.”

    “The speed of execution improved over the rounds using short feedback loops, continual improvement and applying lessons learned from previous rounds.”

    “It gave a good understanding of how different roles and responsibilities in the organization contribute to the overall success of the project.”

    Finally, the teams made over and above the required target of revenue and stock price. The winning moment was enhanced by the significant learning opportunity and ability to bond with diversified cross functional teams.

    The experience of playing the business simulation reinforced practical understanding of DevOps and also transferred skills that they could implement immediately at their workplace.

    About the Author / Suresh GP

    sureshSuresh GP is the Managing Director of TaUB solutions and Regional leader of BRMI (APAC). He has more than 15 years of experience in IT Service Management, IT Governance, Program Management and Organizational Change Management. He is regular blogger and International speaker at itSMF UK, itSMF Australia, itSMF USA, itSMF Finland and itSMF Norway. He is a Certified DevOps, Agile Service Manager, Business Relationship Management Professional, PMP, CGEIT, ITIL V2 Service Manager, ITIL V3 Expert,  ISO 20000 practitioner. He was awarded the ITSM contributor of the year by itSMF Singapore in 2013.