devopsy.kinsta.cloud

Tag: enterprise devops

  • 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

  • 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

  • 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

  • Predictable Progress: Tracking DevOps Maturity Metrics

    Predictable Progress: Tracking DevOps Maturity Metrics

    As DevOps methodologies continue to evolve, we’re naturally seeing an increased emphasis on the cultivation of related maturity metrics.

    For instance, in the 2016 State of DevOps Report, researchers with DORA took an initial stab at creating relevant ROI measurements.

    Similarly, a new report issued by researchers Coleman Parkes, sponsored by CA Technologies, offers additional evidence that as agile and DevOps processes continue to expand, today’s practitioners are increasingly employing metrics to optimize their efforts.

    The report, titled, “Accelerating Velocity and Customer Value with Agile and DevOps,” finds some form of adoption among nearly every enterprise, with 87 percent having adopted agile to some degree and 73 percent leveraging DevOps.

    Related to the overall maturity of these practices, those organizations that are moving to embrace the techniques most broadly are predictably seeing greater returns. Yet, despite the widespread adoption, only a third have deployed either practice widely, according to the research.

    Percentage of Advanced Adopters Reporting Improvements in Customer Experience

     

    Based on a survey of 1,770 senior business and IT executives, the study also closely investigates the specific KPIs that organizations are using to gauge how agile and DevOps initiatives are translating into customer interactions.

    Most notably, “advanced” agile and DevOps adopters have observed more than an 87 percent improvement in overall customer experience, compared to “basic” adopters.

    In terms of how those efforts are affecting business drivers, Coleman Parkes finds:

    • Advanced agile practitioners are experiencing a 40 percent improvement in time-to-decision, compared to 33 percent for basic users.
    • Advanced DevOps adopters have noted a 42 percent improvement in speed-to-market, compared to only 24 percent for basic practitioners.

    Key Performance-Invoking Indicators

    To that end, the research highlights specific KPIs that organizations are using to measure the impact the agile and DevOps practices are having on customers. In fact, the study finds that between two thirds and three quarters of all the organizations surveyed have established such measurements.

    At least half of these focus on business or customer-related metrics, reflecting how “critical software has become to businesses’ ability to achieve their core mission,” Coleman Parkes researchers note.

    Among the mostly widely invoked metrics, include:

    • Business growth (specifically revenue): over 73 percent
    • Operational or process efficiency: over 73 percent
    • Employee productivity: over 73 percent
    • Customer experience: over 71 percent
    • IT-related costs: over 71 percent
    • Speed-to-market: over 71 percent
    • Customer satisfaction (via NPS): over 70 percent
    • Time-to-decision: over 70 percent
    • Quality of development: over 70 percent
    • Employee retention: over 64 percent

    If increasing applications delivery speed and overall organizational velocity are, in fact, the primary goals of engaging agile and DevOps, the research bears out that the techniques are having the desired effect. After all, the survey finds that time-to-decision and speed-to-market are being accelerated among approximately a third of the organizations studied.

    Related to other notable KPIs, Coleman Parkes highlights that a full three-quarters of adopters have moved the needle on overall customer experience, along with employee recruitment and retention, a significant benefit that was also highlighted in the State of DevOps Report.

    Along with positively impacting customers, the reality is clearly that agile and DevOps are also making a big difference in allowing companies to improve the atmosphere for their workers—a huge benefit when you consider the shortage of talent in IT today, and how much it typically costs to attract new employees, just as DORA’s researchers noted.

    Other key findings by Coleman Parkes include “before and after” metrics that many organizations are observing related to their continued adoption and advancement of the involved methodologies themselves.

    I encourage you to download the entire report, and leverage it to measure how far you’ve come with Agile and DevOps transformation—and where you may need to re-examine your efforts.

    — Aruna Ravichandran

  • DevOps in 2017: From Building to Executing

    DevOps in 2017: From Building to Executing

    In 2016, DevOps grew in popularity and use, new tools were introduced and enterprises across industries realized the influence and benefits derived from agile development. But there are even more developments to look forward to as enterprises engage DevOps teams further.

    Scaling-out solutions, providing a baseline for a new cultural approach to problems and continuous improvement will continue to be priorities. But there are a few items that we’ll likely see come to the forefront in the new year. In fact, 2017 should be an even more exciting year for DevOps.

    Here are my top four predictions for what we can expect this year:

    The next phase of DevOps will focus on security

    Security was a perennial news event throughout 2016, and we can expect the same in 2017. However, DevOps teams likely will be challenged to build good security practices into code as a part of application development, rather than refining security post-facto. This will lead to DevOps, QA and operations bringing security teams deeper into the DevOps environment, if not outright incorporating them as a part of the team.

    The foundations for this development were put in place in early 2016 as the DevSecOps model gained traction in cybersecurity circles throughout the year. In 2017, we’ll see DevSecOps teams build on these foundations. After all, every company is at risk for a data breach.

    Containerization will go mainstream

    The convenience of containerization makes it one of the most desirable technologies for DevOps teams, and next year we’ll see it gain even greater use. It’s easy to understand why: Containerization solutions, such as Docker, grant teams the ability to provide a consistent environment from development to production. We may even see containerization move to non-production environments over the course of 2017 due to its portability across multicloud platforms. And that portability is critical not just for production purposes but for security as well.

    DevOps will extend into pay-as-you-go

    DevOps will, almost by necessity, develop an on-demand model in 2017. Companies are realizing the stark demand for DevOps skills and they will be meted out according to internal needs and external demands.

    In particular, we’ll likely see a lot of opportunity for DevOps in cloud implementation, since enterprises leverage solutions across cloud providers. With cloud provider “lock-in” still a real concern for many enterprises, any provider capable of operating cross-cloud development—thereby allowing customers to switch to a low-cost cloud provider—will be in high demand. This is good news for customers, as it allows them to finally benefit from the elastic nature of cloud pricing models.

    DevOps will become pervasive across the enterprise

    Finally, enterprises will use DevOps across the enterprise. Thus far, large enterprises have been experimenting with DevOps in discreet projects, but they have started to plan for employing DevOps principles at enterprise-level, and we will see this roll out next year.

    Watching the Shift

    Thus far, DevOps has been focused on adopting and orchestrating technology and tools to build automation pipelines. But moving ahead, we’ll witness DevOps change its focus from building to executing. With this industry development and the shift within DevOps to security and containerization at an enterprise level, we’ll begin the true potential of DevOps.

    About the Author / Tan Moorthy

    Tan Moorthy is Head of Global Services for Application Development and Management at Infosys, a next-generation IT services provider. Connect with him on LinkedIn.

     

  • 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

  • Understanding Mesos and Its Place in DevOps

    Understanding Mesos and Its Place in DevOps

    Finish carpentersWhen building a house, work is done in teams. This work is managed by a foreman, supervisor, or general contractor, but let’s restrict ourselves to the teams doing finish work, and a foreman. Foreman is old fashioned, but general contractor gets long to type over and over. Assume a large enough house to warrant a couple of teams putting in cabinets and trim, hanging doors, etc. A team of two tells the foreman “We’ve finished with the master bedroom”, and he looks at his list and says “Good, go install the trim in the master bathroom.” And the two head off to do just that. About half way through, one of the installers has an unfortunate incident with a nail gun, and nails his hand to the floor. Both inform the foreman that they have to leave – one to go to the hospital, the other to drive.

    When the other finishing team comes free, the foreman says “The master bathroom trim isn’t done, go take care of that for me.” And keeps his checklist up to date.

    Eventually, the entire house has the finish work completed, simply by the foreman sending teams off to do different parts of the job until all parts are complete.

    That’s Mesos, essentially.

    The foreman is, in a nutshell, Mesos in this example.

    Mesos is a scheduler that knows what jobs have to be done, and what resources are available to do them. The details of getting the job done are not Mesos’ concern, but if the job is not completed, Mesos will send other resources so that it can get done.

    There is a lot more involved, of course, but the analogy holds pretty darned well.

    Mesos turns a collection of machines into a cluster, simply by placing agents on each machine that know how to (a) report what resources are available for Mesos to dole out, and (b) execute applications for a given environment (called framework in Mesos-speak for a variety of good reasons). So once Mesos is distributed across your servers, it can effectively treat those servers as one master server, and itself as the scheduling algorithm.

    It’s never simple. Because IT isn’t simple.

    I have an adage for IT though: No good idea is complete until the real world imposes complexity on the simple.

    In order to make Mesos fault tolerant, there can be multiple masters, and zookeeper can be used to make certain that if the current master fails, there is a replacement ready to pick up and keep things moving (processing).

    In order to keep Mesos focused on scheduling, it does not have complex resource scheduling built in. Instead, it relies upon frameworks asking for resources, and then offering them what fits the requirements. So let’s say Hadoop asks for five CPUs. Mesos may say “Here are three”, then a few minutes later say “Two more!” and Hadoop could tell the executors on those servers to start up tasks. Frameworks can also tell Mesos what they don’t want (filtering), and reject offers of compute resources Mesos makes (in which case those resources are offered to any other frameworks out there).

    Of course, those frameworks that know both how to schedule jobs and how to send them to agents are key. Marathon can handle most long running tasks, Hadoop has a framework of its own. So the “subcontractors” are ready to get the job done, for the most part.

    So what is the benefit? Mesos doesn’t much care where you install it. Put it on hardware, put it on VMs, put it in a VPC. Using Marathon, you can deploy your apps in containers, meaning you really don’t have to care what the underlying infrastructure is.

    What’s the downside? Well, there are a whole lot of tools to learn to make a production environment stable and maintainable, and there are other alternatives out there that we’ll be looking at in the coming weeks. Honestly, most of the “other alternatives” are expansions based upon Mesos (and often Marathon), so this was a good place to start in a series exposing what you need to know to consider if Mesos fits your environment. If you want to start running apps and seeing hardware/VMs as a pool of available resources, Mesos is a good place to start, though the packages we’ll talk about in the coming weeks are more interesting, mostly because they take Mesos’ simple scheduler concept and expand upon it to offer a more complete solution.

    If you would like to learn more about Mesos, The Apache Foundation, DigitalOcean, and Mesosphere all have tutorials. I have used the Mesosphere one, and it was pretty good, though on OSX it failed, it worked like a charm on Windows 10.

     

    — Don Macvittie