devopsy.kinsta.cloud

Tag: continuous integration

  • How Developers Can Spend More Time Coding, Less Time Fixing

    How Developers Can Spend More Time Coding, Less Time Fixing

    I don’t think anyone became a developer because they loved to spend their time debugging. As frustrating as it may be, making sure your build works is critical—and this burden is now falling on developers. If your organization wants to deliver highly rated apps faster, building quality into the development cycle is imperative. Even though agile development has become a popular approach, it’s execution has a ways to go.

    A recent trends report in mobile and web development shows 25 percent of time is spent addressing a bug fix backlog. This can slow time-to-market and limit the amount of new features your company can roll out—not ideal when your top priority is to draw in new users and boost engagement to stay competitive. The good news is, the time spent debugging throughout the development cycle can be minimized. How? By shifting QA into the development process, you can spend more time coding and less time fixing.

    Mastering Agility in Practice

    The question for devs today isn’t whether they test, but when and how to do it best. We’ve all heard the vague, top-line answers before: “Adopt Agile development,” or, “Shift left.” The problem is, these terms and strategies can be challenging to execute in practice, especially without proper tools to make it happen.

    When we talk about “shifting left,” there’s still an important balance to be found as to which stage is right for dev teams to test—it can’t be too early, when there is nothing meaningful to test, and it can’t be too late, when the test batch pile is too big. Once your coding and testing processes are harmonized, you can effectively maximize your time and resources and get the job done faster and better.

    For development teams, if testing is done in bulk at the end, identifying the specific point in the build that needs to be corrected is like finding a needle in a haystack. When we shift quality left, defects are found earlier among a much smaller set of changes, and are therefore easier to fix. That’s why continuous integration (CI) calls for building, integrating and testing the system you’re developing upon delivery of even the smallest change.

    By testing continuously, uncertainty is reduced and feedback loops are made smaller, ensuring you’re building in the correct direction. The “shift left” trend is ultimately going to condense the dev cycle by getting quality back into the ingredient list. The earlier we deal with quality issues, the less focus is taken from our primary goal: building valuable, innovative technology.

    Find Tools that Mesh with Your Workflow

    Whether you use Selenium, Appium or Android Studio, new products need to integrate seamlessly into existing developer environments. Having to switch between building tools and testing tools is a big waste of time, and it’s unrealistic to expect a high adoption rate if the product is disrupting, rather than enhancing, your workflow. If you’re expected to shift testing into your development cycle, look for testing tools that seamlessly support the continuous integration of testing.

    Once your testing and building processes is aligned, the testing feedback and analysis becomes a new bottleneck. To minimize inefficiencies and feedback gaps, you need to carefully select tools that will improve visibility into build health, and help avoid batching up issues.

    Empower Developers to Satisfy Users

    At the end of the day, smaller batch sizes are only half the battle. No matter the batch size, quality only can be built in if it includes full test coverage, and if all the defects can be fixed in a way that actually meets user standards of quality.

    With tons of potential end user environments, injecting reality into the development process is crucial if you want to meet the high expectations of today’s consumers. With different phones, operating systems, levels of connectivity and apps running in the background, you never know what your apps will be put through once released. Leveraging stable test environments capable of recreating all potential user conditions throughout the developments cycle will maximize efficiency in development and accelerate the speed of innovation at your organization.

    Through a better delivery pipeline, mobile app and web developers are simply more effective. Once your test process is automated, aligned and maximized, writing better code can become your main focus. By taking a strategic, practical approach to shifting quality left—and giving developers the opportunity to focus on what matters most—you’ll see happier developers, and in turn, more successful businesses.

    About the Author / Paul Bruce

    Paul Bruce is Developer Evangelist at Perfecto, focusing on the value of quality and velocity throughout the software life cycle. He previously worked as an advocate for API development and testing practices and a full stack developer before that. He now writes, speaks, listens and teaches about software delivery patterns in modern enterprises and key industries around the world. Connect with him on LinkedIn and Twitter.

  • 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

  • The Right Automation Tool for the Job

    The Right Automation Tool for the Job

    My father was an antique dealer, and we did a lot of furniture repair in the workshop. All of us kids took turns working for the business as we grew up, and we learned some solid lessons in the process.

    One day, when I was still pretty young and very new at working on things, he pointed out a set of screws someone had set into an otherwise beautiful oak chair and told me to remove them while he worked on another piece for the same customer. I grabbed a screwdriver from the workbench and went to work, but it was tough going: The screwdriver kept slipping, and I was new at it, but I knew enough that gouging the wood was certainly not on the list of things one wants to do with antique furniture. I took my time, got all four out, but the screw heads were pretty mangled—close to stripped—and the end of my screwdriver was also showing marks. Being new at it, I thought nothing of it, and was proud of how few scratches I’d put into the wood.

    My father was a patient man for the most part, and I was proud of having done my part. So it was a complete surprise to me when he could barely contain rage as I showed off my handiwork.

    After he pulled himself back under control, he took the time to teach me that there was a difference between a screwdriver and a wood chisel, and that I should have seen it didn’t look like a screwdriver. It turns out I had ruined his best chisel, and the “few marks” I had left in the chair were gouges that we would have to carefully repair.

    Are You Using a Chisel?

    I learned an important lesson from that day. Always be certain, despite what you think you know, that you have the right tool for the job.

    I’ve certainly said that enough in my career—in development, in ops and in my blog. It is easy to see the tool in your hand as good enough to get the job done, but it is worth stepping back for a second and making certain it is.

    Not too long ago, I worked with an automation company whose largest competitor was not any competitor; it was, “We can do that by hand.” Evidence over time showed that the company could get partway there, and then would find itself with issues that kept it from getting the features/reporting it wanted and a metric ton of code to maintain. Unsurprisingly, some called to have the tool brought in three to six months after embarking on a build project.

    Using bash scripts, Maven/Gradle/Cmake and a dose of Python to do release automation is a good example of that syndrome in action. So is cobbling an application provisioning tool into a release automation system. Like a chisel, these are all astounding tools that rock in their given area of expertise, but are far from optimal—and can even cause problems—when used to automate software releases.

    Familiar Questions

    There is almost always someone willing to say that building is better than buying. These people thrive on the creation aspects of IT and are valuable assets. But the equation has to make sense. In software development, we’ve come to the point of “core business function” as the differentiator in the build/buy equation, and it has cut down the number of systems for which we have to maintain source. But DevOps is new, and a lot of DevOps is scripting, be it command line (bash scripts/batch files/ps) or Python/Ruby/php, straight commands built in-house or scripts for use through tools such as Jenkins. We’re generating a lot of artifacts, and those artifacts will require maintenance. It’s the technical debt of the near future, because environments are not static things, and those scripts will need to change over time.

    So the questions to ask will be familiar if you went through previous build/buy cycles and include:

    • We can build it here, but should we? What long-term costs and risks are we taking on by doing so?
    • If we build it here, what are the tradeoffs? What functionality could we have today that will go missing? What functionality will we likely never have in a home-brew solution?
    • If we build it here, what flexibility will we have, and how does that compare to available tools?
    • What are the timelines? Generally speaking, CI/CD tools can be up and building in a week or less, be truly productive in six weeks or less, and be a standard part of the build/deploy process within six months, even at cautious companies. What would building it have for a timeline, and are the resources required to complete the implementation constrained?
    • DevOps is growing and changing. A dedicated product will incorporate those changes through the upgrade process. Will time be available to staff to do the same on a home-built system?

    There is a Right Tool

    My experience is that IT shops who allow someone who claims, “We can do CI/CD/ARA with the tools we have today, it’ll just take a little work” to run with that sentiment end up feeling more like my father than happy that they made the choices they did. The complexity of the process, combined with the growing functionality and integration of toolsets from different vendors (via plugins or APIs), have made the purpose-built toolsets more effective than cobbled together is likely to be. And when the home-built tools fall short or needs change, the cost in IT staff resources is not something to be dismissed lightly. While blocking off a chunk of time to make IT more effective is important, it is also important to make the most efficient use of that time possible. Having a toolset dedicated to CI/CD and even release automation means less time maintaining source that just manages builds and application deployment. Save that time for things that improve efficiency even more, not keeping the status quo. There will certainly be scripts for your server and application provisioning tools to maintain, because that’s how those tools are designed. And if you are using a tool such as Jenkins as part of your toolchain, it generally has scripts as part of the process too. Increasing beyond that just to avoid implementing the rest of the CI/CD/ARA ecosystem would be a poor investment of time.

    As I told a friend recently: Yes you can implement a full-blown end-to-end ARA system in an application provisioning tool. By the same token, you can implement a fully functional responsive web app in assembler, too.

    — Don Macvittie

  • Security @ the Speed of DevOps Survey: Efforts Still Lag

    Security @ the Speed of DevOps Survey: Efforts Still Lag

    Enterprises today are in a relentless race to digitize or die. If they don’t digitize business processes, services or internal workflows and their competitors do, they will be at a steep disadvantage—and perhaps soon an irrecoverable one.

    In more and more companies these efforts are being driven by DevOps. According to IDC, the vast majority of businesses today think—and rightly so—that it is essential for them to put into place the right resources and IT processes to support a digital business model. Unfortunately, about 75 percent of organizations don’t think that their IT organization is actually scalable enough to deliver and support a comprehensive digital business model.

    There are many reasons why so many organizations have a challenging time with their digital transformation efforts. Many of these are cultural: IT commands tightfisted control over all information technologies used throughout the organization, yet being unable to deliver the infrastructure and digital services enterprises need to succeed, for example. Or, others within the organization still are unable to see how rapidly the world is being changed by digital technologies and so aren’t taking the necessary steps.

    Another reason is security. That’s because this rapid digitization of business processes can have a profound impact on how enterprises secure their data, applications and software development and delivery. In devopsy.kinsta.cloud’s inaugural annual “Security @ the Speed of DevOps” survey, we queried 255 security IT decision makers within organizations currently practicing DevOps or that are on a path to DevOps adoption. The survey found that enterprises of all sizes are embracing DevOps, cloud, continuous integration and deployment. But in securing these processes, however, we found vast differences in maturity.

    When it comes to DevOps practices, larger companies are outperforming. For organizations with 5,000 to 9,999 employees, a full 90 percent have either adopted or started DevOps practices. However, only 38 percent of organizations with 500 or fewer employees have started DevOps or widely adopted such practices.

    As I wrote in our report on the survey, smaller organizations also have a way to go with automated security testing. Only 6.5 percent of those with fewer than 100 employees have automated large parts of their application security testing, while 29 percent have automated some of their application security testing. For firms with 5,000 to 10,000 employees, 38 percent have automated large parts of their testing, and nearly 50 percent some of their testing. For those with more than 10,000 employees, these figures are 20 percent and 48 percent, respectively.

    The challenge here, for many organizations, is the same with enterprise security in general: the view that security slows things down. For the business, it’s about getting more digital capabilities out as quickly as is possible. It’s the same for developers. Security too often is seen as standing in the way of this.

    When this conflict is experienced at DevOps speed, there is the risk not only of development slowing down but also security processes breaking. To succeed, enterprises can’t take the same approaches to security as they did in the past. They must find tools and processes that are designed for the highly automated and continuous world of DevOps.

    Have a look at our survey and report to see how enterprises are tackling this challenge today.

    — George V. Hulme

  • 4 Top Tips for Developing a New Feature

    4 Top Tips for Developing a New Feature

    As a backend developer at CA BlazeMeter, I recently had the chance to work on a big feature for our web app. The feature required a massive change on our backend code, a big change on our frontend and multiple migrations. You know what I’m talking about—it was one of those projects that developers fear.

    But, I gained a lot of valuable experience from the project. Not only did we deliver a kick-ass feature, I also learned the importance of teamwork and patience when developing something new. Armed with those two values, and the right tools and technologies, you can deliver a new feature quickly and efficiently.

    Here are a few more things that I learned that should prove helpful whether you’re developing a major feature or one that only requires a minor code change.

    Tip 1: Plan to understand the development requirements

    The process of development starts way before you start coding, with planning. After the product manager decides what needs to be developed, R&D needs to understand the cost: how many days (or weeks) of development the feature will take, how many people will be needed and which APIs are required.

    To do that, the product manager needs to conduct at least three “grooming” sessions with backend, frontend and QA leaders. The grooming sessions start with the product manager presenting the product flow and requirements.

    Since no one wants to read a lot of text (except perhaps the awesome readers of this article), the product manager should prepare mockups. They don’t have to be designed or colorful, but they do need to show the team what the feature looks like in his or her vision. During our grooming sessions, we used Balsamiq, which lets you create screen sketches for how the product is supposed to look, feel and work.

    Editing screen sketches using Balsamiq

    After the initial presentation, the sessions should include a lot of open discussion—asking questions, checking for answers and examining compliance, etc. —until everyone is satisfied and understands what the feature requires from them and from others.

    This is the time and place for frontend, backend and QA to give their opinion about the schedule and to alert and flag any potential problems in development or extreme use cases. It’s the role of the product team to answer questions and change the flow and requirements until there are no R&D rejections.

    Afterward, the frontend and backend leaders need to create a feature development plan, sitting down to determine what data they need to transform the product vision into a real thing. Or in other words, which APIs are required for each flow or button, how long each step is supposed to take, including buffers, and the order of development. APIs are the agreed “contract” between the development teams. After determining the contract terms, each team can proceed individually.

    I recommend you write your APIs in Swagger, which turns YAML files into detailed HTML pages with all the APIs.

    Swagger Editor

    This plan needs to be transparent to everyone working on the project. In fact, it’s even better if each project participant can add and describe scenarios. Tools such as TestLink and Atlassian do just that. Then, when the code is ready, developers can go over the list and see everything is covered.

    We will need to stick to this schedule later on, especially when new demands unrelated to the feature come in, such as fixing bugs. Sticking to this plan is the best way to distinguish the wheat from the chaff of the development process.

    Start writing automation ASAP

    After planning, we want everyone to start working, and not only the backend. To do that, the backend can prepare mocks, either through outsourcing services such as JSON servers, which show inputs and outputs, or by writing dummy code.

    I mentioned earlier that we used Swagger to write APIs. We also used it to generate a server in NodeJS/Python, like this:

    Generating a JSON Server through Swagger

    From this moment on, frontend can begin writing and building screens and QA can start writing API automated testing, by using tools suh as JMeter. At this point, frontend and QA have the response codes and response bodies; they know which features to put where; and which APIs they need and how to use them.

    QA also know which data they’re missing, such as field names and field data. Sure, the backend code isn’t ready yet and all of the automated exams will return “red” instead of “green,” but the main issue is making sure everyone is as prepared as possible.

    This includes load and performance testing. You can use open-source tools such as JMeter, which is enhanced by CA BlazeMeter. By uploading our test script into, configuring the number of virtual users and ramp-up time, determining geo-locations to test from and analyzing KPIs to determine trends and the health of our system, we can ensure our product is delivered to our customers without crashing.

    This is also true about sending code to QA: Developers should test their code themselves and ensure that when they commit their code, it works 99.9 percent of the time.

    By starting automation as soon as possible, you can minimize future bottlenecks in the development process.

    Ensure the team communicates and works together

    Like I said before, teamwork is the most basic requirement when creating a new feature. This is because new questions arise during development and because requirements change. Therefore, everyone in the team needs to be in sync all the time, from the product manager and the designer to the developers and QA.

    Open communication lines are crucial because everyone is working on the same product at the same time, but each developer or QA should be working on a different part of the product and on different functionalities. Communication ensures each person’s work is compatible with the rest of the team’s work. This saves time, prevents frustration and redundancy and ensures maximum professionalism.

    To make sure everyone knew what was happening, we used Slack and opened a dedicated channel for the creation of this feature. We also had daily (short!) standups where we discussed what we have and what is missing.

    Opening a Slack channel

    Communication also includes team and assignment management. JIRA, our primary issue tracking tool, offers Kanban-style, Scrum and fully customizable boards, which show the progress of each development task, including the developer assigned to it, and his or her exact status or phase.

    This helps you understand what other people are working on, and just as importantly, where people are stuck. If you can, get everyone to work in an open space and put a large screen in the middle of it. This lets you stay in sync at all times.

    We used JIRA to open and manage bugs as well. This was helpful when multiple QAs found the same bug. It’s important to carefully choose which tickets are opened and put them under one epic, so everyone stays focused.

     

    JIRA Dashboard

    Another important aspect of communication is ensuring everyone uses the same terminology, as sometimes people might use the same term to describe different things or different terms to describe the same things. To prevent mixups that could waste your time, make sure everyone is on the same page. For example, do you say “system admin” or “<name (ex. BlazeMeter)> admin”?

    Work on the same development environments

    It’s important that everyone works on identical development environments and even on the same version of the tools and libraries. Otherwise, it could cause an (in)compatibility mess, including a lot of unnecessary back and forth and even might cause bugs to pop up. This environment needs to be as similar as possible to production, but only on a smaller scale.

    Conclusion

    Now look at the feature that came out of all that work here. I’m so grateful that I had the opportunity to work on it with an awesome team.

    I hope these best practices help you the next time you develop a new feature. Don’t forget to keep going agile after development and delivery by running tests in a continuous environment such as Jenkins for every commit.

    CA BlazeMeter works with Jenkins, ensuring you can load test in the cloud and analyze your data while shifting left. You can also use different APM tools, such as New Relic, AppDynamics and CA APM to alert you about errors before QA, which saves time.

    — Dor Atias

  • 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

  • The Code Doesn’t Lie, and Other Operations Mantras

    The Code Doesn’t Lie, and Other Operations Mantras

    As engineers, we spend a lot of time talking about things such as release processes, QA environments and deployments. But at the end of the day, most software systems fail because the software itself is faulty. The code doesn’t lie—you can almost always find the solution to your problem within the code itself. Of course, looking to the code for answers is a time-consuming process if you’ve deployed too much in one batch. After all, sometimes the tiniest mistake can derail a whole string of code, and having to sort through a haystack of code looking for a tiny needle is not fun.

    There are a few corollaries to this mantra that “the code doesn’t lie”:

    • “Know your data like you know yourself.” Sometimes the quality of the data itself can cause a system to behave differently.
    • “A feature is a bug in a tuxedo,” which is largely for you product folks out there.
    • “Where there is one bug, there are many.” When you find a problem and it leads to a systemic set of problems, it may seem terrible at first, but the reality is, you have the opportunity to fix a lot in a short amount of time.

    I had a chemistry teacher who used to say, “A mole is a mole is a mole,” referring to Avogadro’s number. My version is: “A bug is a bug is a bug.” A feature that behaves incorrectly (even if built to spec) is a bug. A badly performing system is a bug. A transient failure is a bug. A race condition is a bug. No matter what they look like, it’s our job to squash the bugs.

    Branch Readiness is a Joke

    A very talented engineering director once made the comment, “Branch readiness is a joke,” about the branch/development model. As 23 different teams were preparing their branches for integration onto the main trunk, code changes were flying around with very little testing/certification. We even had code that would not compile.

    When all 23 branches hit the main release branch, all hell broke loose. And this is where the actual functional, integration and performance testing began. The key problem with this model is that integration and certification happened late in the game. The other problem was that we did not abide by our own criteria of what constituted branch readiness; instead, we were constantly softening the restrictions until bad code made its way into the system.

    We moved to a trunk-based model of development where check-ins are made directly to the trunk, and all code must compile and be pretested. Continuous integration and testing are run against the trunk all day and all night. We can ship from the trunk at any moment.

    Now you may be asking yourself, What does this have to do with operations? The answer is: everything. We can control what changes get to the site. We can certify what changes get to the site. We are assured at every moment of a minimum quality in the changes that do get to the site. These smaller changes give us the ability to move bits onto the site more frequently. We are not forced into large-scale, monolithic deployments, which inherently create more risk to the site itself, often with little ability to roll back.

    Learning from ‘Branch Readiness is a Joke’

    Just because the code doesn’t lie does not mean that you can always understand all of its implications. The key is limiting the amount of code being changed in any individual release to an amount an engineer or automated system can understand. By avoiding large, monolithic releases containing thousands of changes and instead testing, verifying and considering each change individually, we can understand what the code is telling us. We can release to the trunk with confidence that what we build and deploy is going to work.

    The One-Character Change

    We live in a world of bits and bytes (eight bits per byte). One byte is the equivalent of one character. In some cases, a one-character change is benign. For example, changing the number of members of a site on an informational page from 134M to 135M (4 to 5) will not cause any harm to the site.

    But sometimes, a one-character change can be disastrous. Consider a DNS change that has a one-character mistake for www.yourcompany.com. Get it wrong and you are off the air. It is very important to understand the impact of a change going awry. If it can cause a large impact, then we need to ensure we understand the change and have a clear plan to roll it back if we need to.

    Here’s a great example of a very small change going sideways very fast: We once scheduled a maintenance to test routing traffic through a European point-of-presence. Unfortunately, the time-to-live parameter was set to a large number (hours instead of minutes) on the DNS entry. The result was that the change, once implemented, couldn’t be fully undone for hours. It was a one-character change with a bad outcome.

    Learning from the One-Character Change

    The code doesn’t lie, but that only matters if we are paying attention. Put simply, not all changes are equal. By taking the time to think about what a change is intended to accomplish and the various ways it could go wrong, we will always be better off than if we didn’t do due diligence. The one-character change can be benign, or it can be catastrophic. It’s important to figure out the possible ramifications of any changes (no matter how small they may seem) before proceeding.

    Operations tends to be the first group to get called after hours when something goes wrong. As a result, we have a vested interest in quality of code shipping to our site. By working to improve the code quality before it hits production, you can significantly reduce the number of problems you encounter.

    Start with where the code gets committed into source control. For each change made ask the simple questions: Does the code still compile? Does your application still build correctly? Does it still work as intended? By automating the process of asking these questions for every change, we gain the ability to deploy new versions of our application based on any commit.

    Once we have good code quality making it into source control, we can begin making further improvements through the use of a canary process and start focusing on things such as performance. Remember, the code doesn’t lie. If we can understand each change, then we can start preventing problems before they begin.

    This post is part of the series “Every Day Is Monday in Operations.” Throughout this series we discuss our challenges, share our war stories and walk through the learning we’ve gained as Operations leaders. You can read the introduction and find links to the rest of the series here.

    About the Author / David Henke

    David Henke has more than 35 years of experience working in technology, including senior engineering leadership positions at LinkedIn, Yahoo!, and AltaVista Company. He’s also been a founder at two different software companies, both of which were acquired. Currently, David serves in a variety of board and advisory positions with organizations like NerdWallet and UC Santa Barbara.

  • 15 DevOps Expert Opinions on Continuous Integration and Delivery

    15 DevOps Expert Opinions on Continuous Integration and Delivery

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

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

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

    1. Chris Nwamba

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

    2. David Bernstein

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

    3. Tomohiro Iizuka

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

    4. Anubhava Srivastava

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

    5. Erik Dietrich

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

    6. Tom Zorde

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

    7. Ian Robertson

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

    8. The Folks at Browser Up

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

    9. Georg von Sperling

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

    10. Endi Sukaj

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

    11. Jordi Mozcode

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

    12. Dave Kerr

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

    13. Matt Kurleto

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

    14. Sean Handley

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

    15. Manisha Sahasrabudhe

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

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

    — TeamShippable

  • 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