Welcome!

@DevOpsSummit Authors: Dana Gardner, Yeshim Deniz, Elizabeth White, Zakia Bouachraoui, Pat Romanski

Related Topics: @DevOpsSummit

@DevOpsSummit: Blog Feed Post

Continuous Delivery, Real-Time Test Analysis By @XebiaLabs | @DevOpsSummit [#DevOps]

You have to plan your Continuous Delivery pipeline with quality in mind from the outset

Why Continuous Delivery is Nothing Without Real-Time Test Analysis

By Victor Clerc

TL;DR: There is no point shipping fast if everything is broken!

Pushing frequent releases of high quality software to customers is beneficial for everyone. There’s a great deal of business value in delivering software to the market faster than your competitors. Once realized, ideas can be rejected or pursued quickly. Customers can see their feedback shaping the product. Flaws, defects, and omissions can be addressed without delay.

But, setting up a Continuous Delivery pipeline is about more than speed. How do you ensure that things don’t start breaking all over the place?

It’s an established fact that the later we encounter a defect or a problem in software development, the more expensive and difficult it is to fix. Accurately measuring quality and building it into the pipeline may seem like a lot of upfront effort, but it will pay dividends quickly.

Step 1: Build solid foundations

You have to plan your Continuous Delivery pipeline with quality in mind from the outset. The only way to effectively do that is to design tests before development really begins, to continually collect metrics, and to build a test automation architecture integrated into your Continuous Delivery pipeline. The test automation architecture defines the setup of test tools and tests throughout the pipeline and should support flexibility and adaptability to help you meet your business objectives.

This test automation architecture should facilitate easy selection of just the right tests to be performed to match the flow of your software through your pipeline as it gets closer to release. From unit tests and code level security, through functional and component testing, to integration and performance testing. The further the software progresses along the pipeline, the greater the number of dependencies on other systems, data, and infrastructure components – and, the more difficult it is to harmonize these variables. Making sane selections of tests to run at each moment in the pipeline becomes more and more important in order to focus on the area of interest.

Step 2: Fail fast

If we wait until functionality has been developed to write automated functional tests, we are creating a bottleneck. Designing tests during or at the end of a sprint is delaying feedback that we need right now. Why not apply the same test-driven development mindset we employ for unit tests to functionality? So, design all tests as soon as possible: refining the backlog for subsequent sprints should include discussing and designing tests.

The development team is greatly helped when for each piece of functionality a set of examples of expected system behavior is available. These examples, with some syntactic guidelines and using readily available tools, can serve as automated acceptance tests. Starting with failing tests and working to eliminate them maintains a laser focus on what developers should be doing. For this to work well, all stakeholders must get together at the beginning to design the acceptance tests.

The alternative is a drip-feed of failure as new stakeholders climb on board with fresh concerns as the software gets closer to release. The later a failure occurs, the more disruptive it is, and the more difficult it is to do anything to alleviate the relevant stakeholder’s concerns. Pull everyone in at the start, design the tests together, run the most important tests first, and start collecting the feedback you need about software quality from day one.

Step 3: Automate and optimize the process

A concrete set of acceptance criteria in the form of automated tests gives you a clear signal about the health of your software. The easier it is to run these tests, the better, which is why you should automate where possible. There will be some intangibles that will prove tough to automate, but you may need them for a true measure of quality. Not all acceptance tests can or should be automated, but automating functional tests makes a great deal of sense.

It will be necessary from time to time to add new example test cases in to augment the existing functionality. It will also be necessary to optimize the tests available in the regression set to prevent this set from growing and containing superfluous tests.

You can’t test everything all the time. Be pragmatic when you define which tests to run in any given situation. You need flexibility to select the right tests for inclusion and exclusion according to a variety of quality attributes.

Step 4: Maintain a real-time quality overview

If a test is going to fail, it’s better to know about it now. All the stakeholders should know about failures as soon as possible. If the software is passing your tests and meeting the acceptance criteria then you can feel confident about the overall quality and proceed with the release.

Keeping things specific with examples and creating these acceptance tests as early as possible will increase the efficiency of your software development process. Furthermore, when possible reasons for failing tests can be identified through adequate monitoring, this may help to correct defects as soon as possible. The predictive value of trend analysis can also help you to take adequate measures before quality thresholds, such as a maximum duration for test execution, are breached.

Automated continuous qualification of all relevant test results (across all relevant test tools) is what enables you to provide real-time quality feedback. With this real-time quality feedback built into your Continuous Delivery pipeline, you can ensure that your standards never slip.

Join the XL Test beta programme!

We have built XL Test to allow you to achieve these steps. If you’re interested and would like to join our beta programme, please drop us an email. Start making sense of all your test data and get real-time quality feedback built into your Continuous Delivery pipeline today!

The post Why Continuous Delivery is Nothing Without Real-Time Test Analysis appeared first on XebiaLabs.

Read the original blog entry...

More Stories By XebiaLabs Blog

XebiaLabs is the technology leader for automation software for DevOps and Continuous Delivery. It focuses on helping companies accelerate the delivery of new software in the most efficient manner. Its products are simple to use, quick to implement, and provide robust enterprise technology.

@DevOpsSummit Stories
Here to help unpack insights into the new era of using containers to gain ease with multi-cloud deployments are our panelists: Matt Baldwin, Founder and CEO at StackPointCloud, based in Seattle; Nic Jackson, Developer Advocate at HashiCorp, based in San Francisco, and Reynold Harbin, Director of Product Marketing at DigitalOcean, based in New York. The discussion is moderated by Dana Gardner, principal analyst at Interarbor Solutions.
Atmosera delivers modern cloud services that maximize the advantages of cloud-based infrastructures. Offering private, hybrid, and public cloud solutions, Atmosera works closely with customers to engineer, deploy, and operate cloud architectures with advanced services that deliver strategic business outcomes. Atmosera's expertise simplifies the process of cloud transformation and our 20+ years of experience managing complex IT environments provides our customers with the confidence and trust that they are being taken care of.
Today most companies are adopting or evaluating container technology - Docker in particular - to speed up application deployment, drive down cost, ease management and make application delivery more flexible overall. As with most new architectures, this dream takes significant work to become a reality. Even when you do get your application componentized enough and packaged properly, there are still challenges for DevOps teams to making the shift to continuous delivery and achieving that reduction in cost and increase in speed. Sometimes in order to reduce complexity teams compromise features or change requirements
GCP Marketplace is based on a multi-cloud and hybrid-first philosophy, focused on giving Google Cloud partners and enterprise customers flexibility without lock-in. It also helps customers innovate by easily adopting new technologies from ISV partners, such as commercial Kubernetes applications, and allows companies to oversee the full lifecycle of a solution, from discovery through management.
Skeuomorphism usually means retaining existing design cues in something new that doesn’t actually need them. However, the concept of skeuomorphism can be thought of as relating more broadly to applying existing patterns to new technologies that, in fact, cry out for new approaches. In his session at DevOps Summit, Gordon Haff, Senior Cloud Strategy Marketing and Evangelism Manager at Red Hat, discussed why containers should be paired with new architectural practices such as microservices rather than mimicking legacy server virtualization workflows and architectures.