devopsy.kinsta.cloud

Tag: devops

Continuous Testing: What exactly is it?
***This post is based on themes and ideas from the great e-book, “Continuous Testing,” by our friends at Parasoft.

The aptly named DevOps practice of Continuous Testing synchronizes Testing/QA with Dev and Ops processes optimized to achieve business and development goals.

A few years ago when Agile was all the rage, lightning-fast Dev sprints left the Ops and QA personnel playing catch-up due to inadequate and sluggish testing practices with minimal coverage across frequent builds.

The widespread culture of Agile development has accelerated development while software testing still lags behind, forcing organizations to cut corners in QA or slow down Dev processes entirely.

Instead of speeding up the conveyor belt beyond control or slowing down development to kill efficiencies, Continuous Testing in DevOps encourages a systematic approach toward process improvement.

Continuous Testing goes beyond automation and encompasses all practices — including tooling and cultural change — that help mitigate risks before progressing to subsequent Software Development Lifecycle stages.

Continuous testing and Automation

The approach to Continuous Testing can vary and follow diverse pathways to ensure the best user experience is delivered, free of defects.

It’s barely viable to repeat all tests every time a new feature is added, so the Continuous Testing strategy fosters a company-wide cultural change to achieve four capabilities: Test early, test faster, test often and automate.

End-to-end test automation practices are intended to integrate QA into existing fast-paced Dev and Ops processes as a means to create continuity while maintaining faster development cycles.

It’s important to understand the role of automation in Continuous Testing. Automation alone does not enable continuity in testing, but it helps provide a qualitative assessment of risk and practice actionable tasks to mitigate these risks throughout the SDLC.

In essence, automated testing constitutes the detection process for software issues and defect prevention, whereas Continuous Testing addresses the wider challenge of improving the effectiveness of these detection sensors.

What does Continuous Testing Look Like

This example demonstrates how collaboration, automation and tooling enable end-to-end testing that’s performed faster, more often and better aligned with Agile Dev and Ops practices.

Continuous Testing starts within development processes as Devs use open source tools such as Selenium to test the functionality of their code.

Tools such as GitHub or other internal repositories can then be used to store tests and version together with the software code. DevOps teams can use the same tests to integrate frequent builds of the software with the Load Impact API.

Once the code reaches preproduction, dedicated QA teams can use these tests by modifying dynamic test parameters as appropriate. In the production environment, Ops can reuse these tests for acceptance testing and ongoing post production monitoring.

Once the application goes live, integration with existing APM tools help keep tabs on server-side app metrics.

Continuous Testing in this example is broken up into at least four environments: Development environment, Continuous Integration environment, QA Pre-production and Performance testing environment, and the Staging environment. Additional post-live monitoring further enable end-to-end continuous testing.

Key Elements of Continuous Testing

Parasoft, a global software solutions company, is one of the great thought leaders in DevOps and Continuous Testing. The company has laid out some key elements of the process in a fantastic e-book, and they’re definitely worth sharing here:

Risk Assessment: Covers risk mitigation tasks, technical debt, quality assessment and test coverage optimization to ensure the build is ready to progress toward next SDLC stage.

Policy Analysis: Ensure all processes align with the organization’s evolving business and compliance demands. Primary objectives include:
- Identifying trends associated with injection of dangerous patterns within the code
- Augmenting defect prevention practices for high risk areas
- Isolating risk in target areas
Requirements Traceability: Ensure true requirements are met and rework is not required. An object assessment to identify which requirements are at risk, working as expected or require further validation.

Advanced Analysis: Using automation in areas such as static code analysis, change impact analysis and scope assessment/prioritization to prevent defects in the first place and accomplishing more within each iteration.

Test Optimization: Ensure tests yield accurate outcomes and provide actionable findings. Aspects include Test Data Management, Test Optimization Management and Test Maintenance.

Service Virtualization: Early, frequent and everywhere testing requires access to real-world testing environments. Service visualization enables access to the virtual form of the required testing stages, cutting the waste time to test environment setup and availability.

An effective Continuous Testing strategy incorporates all of these elements and forces an organization-wide cultural change to synchronize Dev, Ops and QA/Testing as part of the true DevOps philosophy.
May 27, 2015
DevOps Leadership Series: Security at Velocity

If it does not fit, it does not get done. For many DevOps practices, application security falls into the “does not get done” bucket. That’s because for many DevOps-centric organizations, application security has historically been done somewhere else, by someone else, who is slow.

Go faster. Shift left. Remove complexity. Reduce rework. All mantras of DevOps practices. And while DevOps practices have changed dramatically in recent years, many experts will tell you that application security has not changed enough.

In this installment of the DevOps Leadership Series, you will hear Chris Corriere (DevOps Engineer, Autotrader) and Mitchell Ashley (VP Information Technology, CableLabs) share perspectives on the state of DevOps and security. It is about security at velocity.

But is going faster and automating resulting in better security? There are still security pros who are uncomfortable with that premise. Nevertheless, that is where this is headed. The security community has to come to the mountain, otherwise the mountain is coming to them.

First, listen to Chris’ Corriere of Autotrader tell us his perspective that security can move at DevOps speed, as long as you take a diversified approach:

https://youtu.be/8DdfHkAK1Fk

Then hear from Mitchell Ashley, VP of IT at CableLabs as he remarks on the evolution of security from a validation role (at the right) to an integrated, ingrained role that has shifted left:

https://www.youtube.com/watch?v=pg_m7dYqUPU

This is the third in our series of interviews from this event. Stay tuned as the actual sessions from DevOps Connect will be posted shortly.

NOTE: If you have missed any of the other videos from this series, you can find them here. (We’re up to 15 so far).

May 21, 2015
API Discovery and Search with APIs.JSON

If that sounds vaguely like UDDI (which dealt with discovery and search of WSDL then you’re on the right track.

Glue is this week, and preceding the conference was the 2015 API Strategy and Practice Tech Un-Workshops. One of the lightning talks (and they were lightning fast, let me tell you) was all about APIs.JSON – a relatively new collaborative effort between Kin Lane, API Evangelist, and Steven Willmott and Nicolas Grenie of 3scale networks,

The effort – which you can dig into at apisjson.org – is an attempt to provide a more formal and standardized definition of APIs designed for “public deployment and consumption by automated software agents (robots)”. In a nutshell, automated agents (and people, too, if you like reading machine-consumable metadata) can access a meta description of the APIs available for an organization at a known (standardized) URI such as http://company.com/apis.json.

It’s not quite a WSDL for JSON, as the metadata is not describing the actual interfaces, but more like UDDI entry that might have once (and maybe still is) hosted in a registry (repository). The current incarnation provides basic information about the APIs and includes basic properties like a name and descriptions and URLs and can also contain more (some might say usable) information such as links to documentation or an actual, real-life readable API definition such as Swagger or API Blueprint formats as well as WADL and WSDL.

The effort is showcased in an open API search engine (http://apis.io) that allows individuals to seek out APIs (over 900 are listed today) based on a variety of criteria, all of which of course is derived from the metadata within an APIs.JSON file.

What does this all have to do with DevOps? Well, as Steve Willmott astutely pointed out in his lightning talk, APIs.JSON is not just about describing APIs in a consumable format, but it’s about being able to have machines discover and bootstrap APIs. That means potentially being able to trigger and signal changes about an API to kickstart a new build and deployment process.

This is a great example of the possibilities for collaboration between Dev and Ops when everything is treated like code and automation moves from simple tasks to workflows – to orchestration.

And I probably don’t have to mention (but I will, because , me) that the same trigger and signaling process could (and probably will) hook into broader network infrastructure (the components that exhibit high application affinity like load balancing and caching and app security) to drive more automated change management.

APIs.JSON is not the first (and won’t be the last) effort of this kind because the mobile and app economy of the future is being built on APIs and thus , as Steve Willmott stated in his talk, “the Web of APIs is the future of the web.”

May 20, 2015
Swim in the DevOps pool or drown in security problems

There has been a significant shift recently in security. Most security vendors and organizations recognize that the traditional model of keeping the bad guys out by detecting malicious exploits is flawed at best. The reality is that the bad guys are already inside the network using authorized credentials to bypass security controls and exfiltrate sensitive data. That sounds ominous but the silver lining is that DevOps changes the game and shifts the advantage back to the good guys.

There was a time when the traditional model made sense. The attack techniques used and the motivations behind the attacks were different. In recent years, however, the line between inside and outside attacks has been blurred beyond recognition. There have been some high-profile insider attacks like Bradley Manning and Edward Snowden, but the reality is that most of the “outside” attacks were perpetrated using stolen or compromised credentials. In other words there is no difference between an inside and an outside threat at the actual point of attack.

Organizations have to guard against both inside and outside attacks. In almost all cases, though, the root problem is credential abuse. Whether it’s an authorized employee accessing systems or data in an unusual way or an outside attacker moving laterally through the network and exfiltrating data using compromised credentials the crucial part for an organization is to have detection methodology in place capable of performing anomaly analysis to identify concerning behavior and activity.

Improving security through DevOps

That’s where DevOps comes in. Organizations need to have continuous monitoring in place. Anomalous activity isn’t something you can just conduct a daily or weekly scan for. If you don’t detect the activity in real-time and do something to stop it immediately the damage will already be done by the time you retroactively review log data and discover the breach.

Things are heading in that direction—but slowly. The good news is that DevOps seems to be picking up steam as more security vendors and organizations face the reality that the traditional security model can’t effectively protect against attacks.

“The DevOps movement is really gaining momentum but unfortunately still small,” agreed TK Keanini, CTO of Lancope. “It is a small but passionate community that can do nothing else but grow and help fill a void as we move from traditional enterprise IT to Internet IT. The tempo of DevOps is its major security feature and—with the principals of John Boyd’s OODA loop—has a winning formula to make it too expensive for adversaries to attack.”

DevOps isn’t just a trendy way of providing or delivering security. The security vendors themselves are also starting to embrace DevOps internally as a means of keeping up with attackers and working to develop new tools and techniques more effectively and efficiently.

Keanini explained that everyone will be moving to DevOps over the next 3 years—just not all at the same time. “Where IT was infrastructure and development was applications, suddenly infrastructure is the application or you could say that applications have become infrastructure but in either case, the business is forced to redraw the org charts and redo the processes.”

Jump in! The water is great

Attacks are relentless and attackers are nothing if not innovative. If you’re using yesterday’s security tools and techniques to defend against last week’s attacks and attackers you’ve already lost. Organizations need to move faster to stay ahead of attacks, and the most effective way to accomplish that goal is to incorporate DevOps tools and principles into the security model.

Keanini summed up with, “It is exciting and I encourage folks to start jumping off the diving board as they are filling up the pool.”

May 15, 2015
4 Ways DevOps Teams Create Value.

Sven Malvik – I’ve written thousand of lines of code based on lies, lies I hoped were the truth. The truth is that we make false assumptions. Assumptions that kill our business. I’ve built software that was too expensive, I’ve built software nobody wanted, and I’ve built software that never saw the light. If you are like any other developer you probably have lied too. But it doesn’t matter. What matters is the application we haven’t built yet and that we will build based on the truth. We need the truth to create value and to survive. This article will show you 4 ways of how DevOps teams create value.

(more…)

May 12, 2015
The Heavy Cost and Burden of Shrink Wrapped DevOps

I’ve worked in the enterprise software game for quite a few decades now and for most part it’s been a good gig. Ok, there’ve been a few road bumps that beset anyone working in this oh so fickle and volatile business, but what really keeps me motoring isn’t the software at all – it’s the joy that comes from helping folks learn and grow – even in the midst of all the crap, chaos and confusion that surrounds us.

Paradoxically and sadly, most of this “triple-C” burden comes from over hyping and sensationalizing the real IT goodness. Goodness in the shape of best practices that can help us grow both at an individual level, and in context of supporting team, departmental and business goals.

DevOps is a classic example.

Here we have a set of principles and guidance to facilitate better communication across an often fractured IT function. All simple goodness you might well say. So why is it that clever folks are waxing on at great lengths to proclaim DevOps is the best IT thing since sliced bread? Why are vendors hurriedly washing just about every product (from servers to thermostats) with the DevOps soap? Why is it that our industry is taking something that’s really common sense and shrink-wrapping it in hyperbole and nonsense?

Well, the short and simple answer is there’s a buck to be made. Hey, nothing wrong with entrepreneurial spirit, except of course when the cost and burden of suspect knowledge and overstated capabilities (all packaged in glossy DevOps wrapping), is passed on to you – and becomes – well, another “box” that sits and gathers dusts on the shelf of good intentions.

So whether you’re a working at the sharp end in development and operations or in the management treadmill how do find and put to work all the DevOps business goodness and not end with another trendy IT white elephant? I have some surprising, but simple advice that starts and ends where it’s most effective – with you.

Garbage in, Garbage out – Go on, Google DevOps — 10,900,000 results in 0.23 seconds– isn’t the Internet just wonderful. But in all the noise, how much is actually useful and applicable in context of your daily grind – Not that much, I’d say. Nuggets are especially hard to find when you’re distracted by all rants and raves – like, ITIL is dead – long live DevOps, or DevOps solves Global Warming. Ok, I jest, but for the sake of your sanity, seek out folks who apply common sense thinking as it applies in your world. Personally, I enjoy (although I don’t always agree with) the work from the likes of Kim, Spafford, Haight, Bloomberg, Edwards Willis and Mann (even Rob England for a good dose of Skepticism), but depending on your own craft, look for solid, meaty, practitioner-baked material that makes sense to you.

Greeks bearing Gifts – or anyone for that matter. The good or bad thing (depending on which way you look at it) about DevOps is that being a collection of principles it lacks a formal framework and isn’t a standard. Unfortunately this provides an opportunity for scurrilous types to fill the void with suspect claims. So if a vendor tells you that they have the best DevOps product, or that their product/service is DevOps compliant, they should probably be selling steak-knives on one of those late night promo TV channels.

Don’t Play the Fool – In slang we often use the word “tool” to depict someone that goes along with something without question and never questions the greater purpose. How often do we see the other form of tools (great software products) used in this manner. All too often the business invests in damn fine open source and smart enterprise software, only to have its true potential diminished because of tribalism, parochialism and plain stupidity. So the next time a tool lands in your eager hands, think beyond your silo and see what automation and integration exists to weave the DevOps collaboration fabric between you and you colleagues. Like for example Ops guys using performance management data to auto-generate realistic virtual services that Dev and Test can use to prevent defects reaching production.

Apply the KISS Principle – it’s easy to get carried away in DevOps folklore with grand tales of continuous deployment, microservice magic, containers and design for failure. But back on your planet, old creaking servers still need to be patched, the help desk sucks, and you’re being asked to deliver mobile apps on the smell of an oily rag. Sure, there are great lessons in the DevOps hall of fame, but think practically about what’s applicable in your organization. Like any best practice, DevOps isn’t an all or nothing approach, so cherry pick what works and think big as you progress. Personally, I think the best place to start is by applying lean thinking – that is, clinically identifying and unashamedly owning up to the waste and technical debt that exists in your own department.

DevOps is great, but it isn’t a perfect package. Your role is to take it, shape it, and apply it in ways that work for you and your organization – which always involves, time, cost and commitment.

Shame on anyone who tries to shrink-wrap DevOps in outrageous claims that just add more burden and cost to an organization.

May 11, 2015
DevOps and Bi-Modal IT
Can a business have two competing approaches to delivery and operations of their information infrastructure and be successful? If you follow Gartner recommendations, it would seem that bi-modal IT is the way to go. Bi-modal IT has been explained many different ways, but, ultimately, comes down a failure in leadership; allowing a subset of IT to continue to operate in an non-optimal way because it’s too expensive and difficult to transform. This results in formation of a secondary subset of IT leveraging emerging trends that have demonstrated results to deliver modern information infrastructure faster with reliability.

If we examine from the 50,000 foot view, bi-modal IT actually makes a lot of sense. Disruptions are happening everywhere and businesses need to respond quickly. For many of these businesses IT can barely keep the core systems afloat let alone bear the burden for handling creative exploitation of massive data growth, enhanced customer experience and transformation to new compute platforms. A nimble team with the right skills can facilitate forward movement in these areas with little disruption to the core business. Moreover, they can establish a framework and approach that enables the core business to adopt when ready.

The issue is when we move down to 5,000 feet, this strategic viewpoint becomes a series of tactical actions that have the potential to spell long term disaster for the business. For example, the data that feeds many of the new digital applications is actually housed in systems being managed by the “traditional IT” group, which means that the “fast” team now is reliant upon the “traditional” team to enable access. Needless to say this is fraught with many hurdles; everything from heel-dragging due to animosity to lack of skills to lack of slack time needed to make the changes to support. While the stick might help with heel-dragging there’s little it can do to fix the lack of skills or slack time issue.

Technical and operational debts are finally coming home to roost for many of these businesses. Lack of attention to automation, documentation, training and staffing are now creating a Sophie’s Choice for many IT and business executives.
- Where do we invest?
- Do we spend time and money making what we have work better before addressing the needs to compete in a digital economy?
- If we do this, how far behind will we fall?
- If we follow a bi-modal IT strategy, do we risk losing critical resources needed to support our existing systems?
For years we’ve been telling the business that downsizing and budget cuts for IT is a mistake. The reduction in headcount and budget continued to squeeze existing resources to take on more responsibilities. As we now know through DevOps research the larger the quantity of work-in-progress being managed the more likely the increase in defects during the build process and the higher the likelihood of outages in production.

If there is a possibility to escape this conundrum, it most certainly is not bi-modal IT. Leveraging a nimble team to meet the needs of digital economy is fine, but they must work cooperatively with the traditional IT teams. Prioritization of backlog and increased transparency with the business is critical for moving forward. The business has to accept they can’t do everything they want that’s new and keep all that’s running today. Specialization must be reduced through standardization to reduce complexity and bottlenecks. Increased automation efforts will reduce time spent on manual operations and afford time to support other key efforts. Visualization and communications of work-in-progress across teams will minimize conflict and foster faster prioritization of critical efforts. Finally, moving to fewer changes with increased number of releases will enable the business greater opportunity to prioritize efforts.

In summary, one could say that the fix for IT isn’t going bi-modal, but adopting continuous delivery and lean IT approaches.
May 8, 2015
The Great Legacy Code Crisis Of 2016

Over the next few years, I believe that legacy software is going to become a key factor which will start impacting organisations in fundamental ways, having a sudden and significant impact on their profitability.

Those constrained by legacy platforms will be operating with a ball and chain, holding back their ability to get new features to market, to iterate, and to innovate with software.

Those unconstrained will be able to fly by taking advantage of modern tooling and approaches, and quickly grab market share from an increasingly fickle consumer base.

These modern approaches to software delivery such as DevOps, Continuous Delivery, cloud, containers, infrastructure automation and polyglot MicroServices are exponentially better approaches than last generation technology. Those who are working on these modern platforms can move so quickly in comparison to more traditional enterprise environments that people working on older platforms don’t stand a chance. It’s at least a 5-10x uplift in speed of delivery.

What is scary is that by legacy I am not even talking about mainframes or Visual Basic desktop applications. I’m talking about last generation .NET and J2EE platforms which are too heavyweight, slow and bulky to change. Change, iteration and experimentation is what’s important in the new world and these platforms are just not optimised for that.

Many enterprises who I speak with through Contino are seriously feeling this pain now, even though they don’t consider their technology legacy or outdated.

Why Now?

Of course, people have wanted better, faster, cheaper since the dawn of time. Disruption is a mature concept and legacy technology has also been an issue for enterprises for a long while.

What is different this time is that there is now a burning platform. Every business is competing on the strength of their technology, and nimble startups can come along with lower barriers to entry and eat their lunch. Likewise, more established players who are much better at software delivery can branch out into new markets and beat incumbents on their own turf. For instance, what would happen if Amazon launched a bank? Their technology capability would allow them to leapfrog established players in a very short space of time. Established businesses are seriously exposed.

Decoupling, modernising and re-platforming legacy code takes a long while. Some of these projects are going to need significant amounts of work and significant budgets to re-platform, but the cost of not doing is huge if the organisation doesn’t survive in the new software centric world. I suggest starting those conversations now in order to swerve what future generations could deem as the great legacy code crisis of 2016!

May 7, 2015
Social Skills for DevOps: Whose responsibility?

In his post “DevOps developers; don´t be a DevGoof” on devopsy.kinsta.cloud Parker Yates pointed out, that developers have to become more social. Devs should better realize that they need to become a normal part of the business social structure. That is really true and extremely necessary to make DevOps more efficient.

But is this the whole truth? And who is responsible for the social structures and the relationships?

First let´s have a look at the devs. For me as a consultant working with people from IT I always get the impression that developers are creating a cult in being a “nerd”. They use being “nerds” as an excuse for not being compatible with the “others”! To be honest, this is a very cheap way of remaining within their own comfort zones! But perhaps we should take some time to ask for the “why?”! Developers are human beings, too. As is the case for all human beings, there is always a reason, why someone acts and behaves the way they do! So what could the “why?” be? Often experiences in our past are the reasons for our behavior and our actions. But perhaps it is a little bit different with the devs. Most of the devs start sitting in front of PC´s and producing code mostly at the age of puberty, at a time when their own personality is being shaped. This time in front of PC´s is not used to improve their own social skills and interaction with other people. So why do they sit in front of the PC at that age? This could be simply because they are really thrilled by the tech stuff or because they like to deal with PC´s much more than interacting with other kids, perhaps because of experience. Additionally, along with the possibility that they do not like to interact with others they also have a lack of time in practicing social skills and communication. But this lack will have the effect that when “contact happens” the result could be disappointing on both sides. And for the later developers a formative experience is made. All that stuff about being the only smart person in the room could be some kind of self-protective mechanism for not being responsible!

And now, what about the “others”? They call themselves “the experts in social skills” in comparison with the “nerds”. One very important part of social skills is empathy. But empathy doesn´t mean to blame other people for a bad relationship. Rather, it means to change the point of view for a better understanding! To point a finger at the developers and make jokes about them is not the way, somebody with good social skills will act! The reason for their ways of acting and behaving would also lay in experiences and preferences. A relationship always depends on both parts!

When people choose their profession they look for jobs, which fit with their interests and personalities. And with bringing different professions together, different types of personalities are brought together, so of course there could be a gap between them. And this gap often is filled up with stereotypical thinking leading to prejudices!

One important requirement to bridge this gap is, that all parts are made to feel responsible for building up that bridge. The attitude of “I am okay – you are okay” is the only useful way! It is a process of a personal change, which has to start!

When I once started my work on IT and DevOps I was awestruck that all people were talking about tools, but nearly no one was speaking about how to train people to improve communication and social skills! When someone has a backlog in such important personal spaces, how can we expect more of this person without giving support? And why do we expect that a team full of different personalities will grow together and will reach its full potential that easily without any support from an expert?

I have made the observation that developers especially are very interested in ways they can improve their social and communication skills and would really enjoy it if their companies would offer them, for example, workshops or team supervisions.

All parts of stakeholders are responsible for their success; and in particular the company which wants to run DevOps! So do not always think about technical tools; think of the human contribution!

May 5, 2015
The Business Value of Continuous Testing

***This post is based on themes and ideas from the great e-book, “Continuous Testing,” by our friends at Parasoft.

Enterprise software development models have presented many innovative solutions for IT to align development efforts with business goals.

Adopting new software development lifecycle methodologies is as much a business decision as an IT decision. From an IT perspective, this means the ability to produce profitable products at lower cost without compromising quality.

Maintaining quality through the code changes to add features and push new releases has been a struggle until the inception of the DevOps-driven Continuous Testing model, which transforms costly, time-consuming IT practices into profit centers.

The DevOps Patch to Agile Pitfall

Having already adopted lean Dev and Ops strategies, Agile enterprise IT seems to have unlocked unprecedented efficiency and productivity by delivering better business value at a rapid pace.

But in all the mayhem and chaos in jumping on the bandwagon of the Agile development, IT teams ended up stockpiling a mass of false assumptions.

Simply implementing Agile processes and iteratively adding functionalities doesn’t necessarily streamline development.

With this approach, teams ultimately ignored the true Agile philosophy of adapting, collaborating and planning, and ended up following an accelerated and reinvented version of Waterfall in hopes to develop fast, deliver early and manage issues effectively.

A change was needed somewhere between design and development, and release and production phases where IT teams were failing to identify software defects and perform fixes fast enough.

The lack of early, adequate, parallel and continuous testing was transforming IT into a cost center by drawing unnecessary expenses and time investments in reworking software to meet desired quality standards.

The DevOps approach aims to address this challenge by facilitating continuous testing as an ongoing effort to identify and fix software defects early and deliver the right quality at the right time at the right cost.

Continuous testing presents the following value propositions to raise business bottom line and open doors to unprecedented revenue opportunities:

Informed Decision Making

Business expectations about the reliability and speed of application delivery vary throughout the SDLC.

Continuous Testing creates a centralized system identifying failures and defects that present business risk to the organization.

Continuous Testing as a consistent effort provides adequate visibility and useful, real-time data. This can be a huge advantage to businesses, especially when it comes to application performance monitoring and testing.

The assessment of stability and validity of software builds enables Ops and business decision-makers to trade off decisions between risk and time of release, cost investments, functionality, scope and quality.

Business Agility and Competitive Differentiation

Enterprises across all industries have development shops delivering software applications as core components of their service offerings.

These departments, often driven by DevOps, must focus on churning out new, stable and high-quality software and race to deliver a stream of features that complement primary service offerings.

For instance, mobile check deposit was a leading driver for bank selection a few years ago and financial institutions offering this online service (while doing it well) early gained valuable competitive differentiation.

In the DevOps world, Continuous Testing creates a safety net for DevOps teams to develop, test and release new features to the market faster without compromising quality. This safety net works as a trusted testing environment, suite and tool to assess the impact of code changes accurately and quickly.

With these capabilities, organizations gain the agility to bring new products to market and compete on innovation and not on the scale of business operations and investments.

All in all, great DevOps levels the playing field between the eight-person startup and the massive enterprise competing in the same space. Who releases faster with a better product is more dependant on the process, not the funding.

Stronger Business Performance

IT performance is business performance. It’s measured in terms of the quality, productivity and functionality of IT solutions delivered for internal business operations or as marketable products.

The primary objective of Continuous Testing is to ensure high quality software products are delivered on time, cost and scope. To achieve these goals, IT teams need capabilities such as automation-driven, self-testing builds in a clone of production environments.

QA is expected to leverage frameworks and automation tools that allow testing early during the lifecycle. That shrinks time spent on test setup and maintenance, using service virtualization to replicate unavailable testing environments and establishing a comprehensive quality validation process with continuous integration systems.

These practices work as core elements of Continuous Testing to test faster, sooner, more often and continuously, thereby boosting IT and business performance.

These business values not only generate unprecedented new revenue streams but also unlock cash trapped within the business IT.

The resulting increase in revenue encourages organizations to change their game entirely and pursue new DevOps-driven business models in improving service delivery, scaling operations immediately and competing on fronts of business innovation.

May 5, 2015