devopsy.kinsta.cloud

Tag: continuous delivery

The 2016 State of Software Supply Chain Report is Here
Our State of the Software Supply Chain Report has just been released. Over the past year, we’ve amassed a great deal of data with respect to the staggering volume and variety of open source components flowing through software supply chains into development environments. This year, we assessed behaviors across 3,000 organizations and performed deep analysis on more than 25,000 applications.

The results we discovered ranged from staggering to surprising to sobering. For example, we measured organizations consuming an average of 229,000 components annually. The good news is, these components help companies accelerate their development and innovation. At the same time, we saw 6.8% of components used in applications marked with at least one known security vulnerability — adding high levels of security debt. Not all components are created equal.

Software supply chain infographic from 2016 report. See full image here.

The 2016 State of the Software Supply Chain Report blends public and proprietary data with expert research and analysis to reveal the following:
- Developers are gorging on an ever expanding supply of open source components. Billions of open source components were downloaded in the last year.
- Vast networks of open source component suppliers are growing rapidly. Over 10,000 new versions of open source components are introduced daily.
- Massive variety and volume of software components vary widely in terms of quality. 1 in 16 parts include a known security defect.
- Top performing enterprises, federal regulators and industry associations have embraced the principles of software supply chain automation to improve the safety, quality, and security of software.
We invite you to read the report and leverage the insights to understand how your organization’s practices compare to others. Then, let us know what you think @sonatype.

If you would like to join a live discussion on this year’s report, please join us on Wednesday, July 13th. Save your seat here.
July 11, 2016
Iterative Indicators: Measuring DevOps ROI

It’s well-established that application of ROI measurements to IT investment remains an imperfect science, and the same goes for ongoing adoption of DevOps methodologies.

The fuzzy math of vendor-driven ROI calculators aside, even the most respected industry watchers have long struggled to create concrete parameters for assessment of technology spending. This, in large part, has been related to the fact that the requirement for continued investment has outweighed the value of short-term metrics.

At the same time, it’s hard to put a price on the influence that paradigms including mobility, virtualization and the cloud are having on today’s business world. The scope of the so-called Applications Economy is only truly beginning to be realized.

For in-depth discussion of DevOps ROI, register today for the upcoming webcast “Maturity Metrics – Analyzing the 2016 State of DevOps Report” with noted industry expert Gene Kim.

With DevOps, the challenge of ROI measurement evokes similar characteristics as with these other bellwether movements. The affect that leveraging DevOps to become more agile and respond adeptly to changing customer expectations will have, long-term, ultimately will be realized as much in organizational viability as in any immediate cost-savings or other factors.

That said, the recently published 2016 State of DevOps Report, assembled by the researchers at DevOps Research and Assessment (DORA), goes further down the path toward creating meaningful ROI metrics than any other such previous effort.

For starters, the 2016 report builds on previous year’s conclusions that so-called “high-performing organizations”—those already deeply engaged in DevOps practices—are “decisively outperforming their lower-performing peers in terms of throughput,” and this gap continues to widen.

Moreover, DORA contends that high performers deploy applications code 200 times more frequently than slow performers and achieve 2,555 times faster lead times. Perhaps even more importantly, in particular as it relates to the ability to improve applications performance, the report estimates that leading DevOps practitioners lay claim to 24 times faster recovery times and three times lower change failure rates.

The State of DevOps Survey, completed by roughly 4,600 technology practitioners, also found that high-performing teams spend far less time on so-called “unplanned work and rework”—most often required to address existing problems—allowing them to spend nearly 50 percent more of their time on new work. The latter brand of effort is typically aimed at adding or improving feature functionality—or, in simple terms, innovation.

As increased software velocity and reduction of MTTR represent the most critical differentiators in today’s environment, where an end user may wait only seconds for an app to load before abandoning your brand altogether, these conclusions obviously carry impressive weight.

Finally, based on a framework established by research analysts at IDC which suggests that hourly application downtime costs can range from $1.25 to $2.5 billion for a Fortune 1000 firm, and that the average cost of a critical application failure is $500,000 to $1 million per hour, the State of DevOps Report allows for the conclusion that high-performing organizations save an average of more than $91 million per year.

Much of this advantage is found, the researchers note, in the form of lower applications change failure rates, or those updates to software code that result in subsequent performance issues or outages. While high-performing DevOps practitioners experience an average change failure rate of 7.5 percent, medium-performing organizations see that figure rise dramatically, to a whopping 38 percent.

If the undeniable adage that “time is money” applies in today’s Applications Economy as much—if not more than ever—than these ROI calculations would appear to infer substantial meaning.

Later this month, Gene Kim, one of DORA’s founders and a key contributor to the State of DevOps Report, will host a webcast with CA Technologies expert Aruna Ravichandran to discuss DevOps ROI and many other related topics. Register for that event today.

July 8, 2016
On Building Self-Driving IT

More CIOs than ever are moving their data centers to the cloud. Some have decided to maintain their on-premises data centers and move cloud-first with all new deployments, while others are moving more aggressively to all-cloud and are retiring on-premises hardware and software as quickly as possible. Both types of enterprises also are working to automate as much as they can to not only cut costs, but also improve their user satisfaction and the productivity of their organization though higher efficiencies.

Aater Sulemen, co-founder and CEO of Flux7, a DevOps and cloud consulting firm, is an expert in hardware architecture and performance optimization, and has spent more than 10 years working with cloud. He calls that hyper-automation “self-driving IT.” This push-button IT works much the same way many expect self-driving cars to work in the not-so-distant future: Push a button, summon a car, instruct it where you want to go and it takes you there.

In this view, when business users wants an app, a database or even more infrastructure, they reach out and request it. They fill out a form, the system determines the proper security and governance policies that should control such systems and data, they push a button, and it’s delivered.

And rather than IT enforcing these rules manually, developers build the right tools to enable this, enabling developers to be autonomous. As the theory goes, technology gets deployed much more quickly, and when the systems are built properly, compliance and security are improved.

devopsy.kinsta.cloud: What does “self-driving IT” mean to you?

Suleman: It’s about achieving successful DevOps through automation. It’s not about dictating rules, or what should be done, but making the processes associated with DevOps seamless.

Self-driving IT means that the business does not wait for developers or operations to get things done, and they don’t wait for each other. If someone needs something, from an application, to expanded infrastructure, to test and development environments, they should be able to push a button and get it done.

Self-Driving IT is a way of automating the repetitive events and all of the process overhead and the auditing and logging systems, when someone needs a new application or service they can just get it, and it’s ready. They don’t need to wait weeks, or longer, to provision the apps, storage, servers that they need. Just like a self-driving taxi, they call it and use it.

devopsy.kinsta.cloud: What are some of the challenges that organizations face when moving to “self-driving IT?” themselves?

Suleman: There are known hiccups, and there are areas companies know how to smooth very well. Typically, the hiccups within enterprises are in terms of skills necessary to essentially provision infrastructure and make infrastructure provisioning very automated. Then there are the skills needed to create the tests that need to be created, and the automation that can be done around that. We don’t see such a fundamental issue there. Usually the issue that people have is a skill-set issue—They don’t have the skills or the right mindset and place for building self-driving IT themselves.

I think, generally, most organizations run into trouble when they have to make major changes to the infrastructure and how they will support that. There are a lot of changes that need to be made, and they may not be ready.

In most cases, if you’re making such a major change that there is going to be a brand new infrastructure designed and built, organizations are going to need some guidance and support through that.

Another aspect here is that the infrastructure isn’t always the highest priority. So the focus isn’t always there to automate it. But when you need a database, you need a database. There’s no getting around it. So it’s a higher priority and it actually gets done, and the underlying change to the infrastructure that needs to get done to automate doesn’t get done.

devopsy.kinsta.cloud: Where do you see this heading in a year to 18 months? Do you see more companies moving down the path to self-driving IT?

Suleman: That is a very interesting question. We have been having a lot of discussion around this very subject lately. There are actually two kinds of customer perspectives. There’s the, what I call, IT view of automation. So IT cares about, “I can create a server with one click, backups happen automatically and I don’t care what’s run inside the server, because to me, these are just boxes. I have 80 boxes on-premises and now I have 80 boxes in the cloud. And this is self-driven IT because I can press a button and spin up a new server.” That’s a fair definition from an IT perspective.

This is where the continuous integration/continuous delivery and (CI/CD) becomes interesting. When you wear your DevOps hat is when you see that there’s a whole new world inside those boxes. Well, what IT likes to think as boxes. And self-driving IT now has a whole new meaning: code deploy, configuration management, patch management … the stuff that is inside the virtual machines becomes very different.

A new class of customers has started emerging. This is as recent as early this year. They used to think of virtual machines as boxes. “I don’t know and don’t care what’s in there. What I care about is I have a box in the cloud,” they’d think. And now they have evolved to just wanting to move huge segments of their enterprise to cloud.

We’re actually working with a lot of this right now. It’s not DevOps, because it’s automated Ops. This is a new level of discussion; this isn’t an app team moving to the cloud or modernizing. It’s CIOs calling and saying that they don’t want to build another data center, that they want 5,000 virtual machines migrated.

devopsy.kinsta.cloud: That’s fascinating. This sounds like it’s the natural evolution of cloud and DevOps?

Suleman: Exactly. To us, self-driving IT has been synonymous like cloud, just like DevOps is. In fact, cloud has always been means to achieve DevOps, and CI/CD and configuration management follows. Now it’s a different mindset. They’re looking for a way to not deal with the servers. So, now what is happening is, when it’s time for a refresh, they are either going to call a hardware provider and ask for 5,000 boxes, or they’re going to decide to move to the cloud. And if they have a tight deadline, like under a year or six months, they don’t have enough time to “DevOpsify” 500 applications. They end up wanting a one-to-one migration, so that they don’t have to invest in a new data center or upgrade their current data center.

It’s a very interesting conversation, and it’s front and center with a lot of enterprises now.

July 5, 2016
REP SPOTLIGHT: ITSM Academy

DevOps Institute: Tell us a little about your organization.

ITSM Academy: Since the early DevOps Days in the U.S., ITSM Academy has been involved in the DevOps community. We are proud to be the first DOI REP in The Americas. We offer DOI’s full line of training, in our open-enrollment public (virtual) classrooms as well as on-site. All instructors have completed thorough Train-the-Trainer programs and we are achieving phenomenal pass rates.

DevOps Institute: What other topics do you teach or consult on?

ITSM Academy: For the last 12+ years, ITSM Academy has offered the full ITIL catalog. These courses are all developed in house, and licensed to other organizations. Our groundbreaking Certified Process Design Engineer (CPDE) course is also developed by our in-house team.

DevOps Institute: What type of interest in DevOps are you seeing in your region?

ITSM Academy: Enterprise organizations are embracing DevOps and agile service management and attending our courses to help build sustainable programs.

DevOps Institute: How do you think DevOps contributes to the business’ value stream?

ITSM Academy: At its core, DevOps is about a shift in culture. Organizations have a tendency to focus on tools, or the automation of manual tasks. Taking a big-picture approach, starting with reviewing existing processes and being willing to re-engineer, is where the real value comes in. Organizations that are coupling DevOps training with the Certified Process Design Engineer (CPDE) course are seeing equipping their teams for success.

DevOps Institute: What topic area in DevOps excites you the most?

ITSM Academy: Improvement of the flow of work between software developers and IT operations professionals. Enriched workflows enable IT organizations to deliver greater business value by improving the ability to more quickly design, develop, deploy and operate reliable software and services.

DevOps Institute: Why should enterprises and individuals consider formal DevOps training?

ITSM Academy: DevOps is a philosophy, not a “tool” to be learned. DevOps foundation training helps teams start on the same page, with common vocabulary and goals.

June 27, 2016
State of DevOps Report: Reaping Results

The newly released 2016 State of DevOps Report concludes that DevOps is “no longer a mere fad or buzzword,” but rather an established set of practices and cultural patterns. Yet, a closer look at this year’s findings reveals progress is far more substantial than any matters of perception.

The report was conducted and analyzed by the experts of DevOps Research and Assessment (DORA) and sponsored by CA Technologies. Among its findings is proof that high-performing organizations that have embraced agile and DevOps methodologies deeply are outperforming massively those that have not. And the gap is widening.

The State of DevOps Report also shows leading DevOps practitioners are appreciating benefits that span nearly every area of their business. If I know my colleague Gene Kim, he will assert this point exuberantly on our upcoming State of DevOps Report Webcast.

It’s noteworthy that high performers are surpassing incredible milestones related to core elements of the applications life cycle. Examples include deploying code 200 times more frequently than low performers, driving 2,555 times faster lead times, 24 times faster recovery times and producing three times lower change failure rates. This is evidence that DevOps is having the desired outcome on applications delivery, software quality and organizational velocity. It also shows organizations truly committed to wholesale transformation of culture and process are actively succeeding.

At the same time, the State of DevOps Report shows employees working at organizations enjoying this success are more satisfied with their jobs and more closely engaged with their companies. Chalk this up to the halo effect of operating in a fundamentally more sensible, innovative fashion. Cultural change is undoubtedly the greatest hurdle to DevOps advancement. Here’s proof that if you can navigate the process, your workers will be happier and more productive.

Using Employee Net Promoter Score (eNPS) as a barometer, the report finds that employees in high-performing organizations were 2.2 times more likely to recommend their organization as a great place to work. They also were 1.8 times more likely to recommend their team as a great working environment. Previous studies have found that such an air of positivity can be directly correlated with improved business outcomes, researchers noted.

Shifting the manner in which you build applications to better adapt to changing customer expectations is a necessity. That’s what began driving this movement years ago. That said, proof it also makes it easier to keep valued software engineering and IT operations employees should not be overlooked.

In addition to positive conclusions on the impact of continuous delivery and improvement of test data management, the report offers some important metrics related to return on investment. This is nothing short of landmark, as for decades we have struggled to make a hard case for IT investment beyond implied competitive advantage. It actually was impressive that last year’s report highlighted such a “predictive relationship between IT performance and organizational performance.”

One such new measurement of note is that high-performing teams occupy the least amount of time responding to unplanned work and rework—efforts widely recognized to be results of flawed processes. On a related note, DevOps leaders spend 49 percent of their time on new work‚ surely, in many cases, the next “must-have” feature which impacts competitive standing and, ultimately, the bottom line.

This report is fantastic. It reaffirms powerfully that so many of the promises made about DevOps over the last few years are neither hype, nor overstated. The gap between the leaders and laggards is growing. Industry landscapes and business models are being redefined.

This is critical transformational work that every organization must adopt to survive.

Are you on board? Download the full State of DevOps Report here.

June 23, 2016
DevOps Matchmaking: APM + CI = A Perfect Marriage

As anyone who has ever been set up on blind dates by friends can attest, finding the right match in today’s world is a tricky feat.

There’s a lot of evidence suggesting that the frantic pace of life makes such matchmaking more difficult than ever. That said, when the right set of complimentary traits exist and there’s a willingness to find common ground, things can work out.

Spike Jonzian-notions of artificial intelligence aside, certain technological partnerships are increasingly being perceived as “a perfect marriage” within the context of DevOps automation.

Register today for the upcoming webcast: “Using APM to Turbocharge Continuous Integration”

These technological matrimonies closely support the underlying tenets of DevOps methodology—collaboration, experimentation and increased velocity. In fact, it’s easy to wonder why no one ever conjoined them before. But we were using traditional waterfall development and operations and so couldn’t conceive of such a thing. On the other hand, emerging availability of tooling supporting new integrated workflows represents a significant catalyst.

Finding the Perfect Fit

One such DevOps confederation getting a lot of attention is the matchmaking of continuous integration (CI) and application performance management (APM) technologies. Tying together these once-disparate systems makes a lot of sense, despite the fact that few tools would seemingly appeal to more (traditionally) polarized constituencies.

Continuous integration has been a staple of the development community for many years. It emerged as teams evolved the practice of long build times into more frequent check-ins to deliver code and look for potential errors more quickly. Today, with the rise of CI tools such as the Cloudbees Jenkins platform, some development teams are touting tens of thousands of builds per day.

On the other end of the spectrum, squarely on the turf of IT operations, APM has been evolving rapidly over the past few years as organizations have sought to improve use experience and applications reliability via dedicated monitoring. Enabling this ability to identify and address emerging issues has resulted in APM becoming the fastest-growing segment in the IT ops management market, according to Gartner.

DevOps matchmaking factors in when you bring these tools together to create an automated workflow that spans their respective use cases. A cross-functional team can leverage APM-level monitoring and KPIs within the domain of CI and testing to identify potential performance obstacles introduced in new code. Doing so then rather than waiting to respond later in the applications life cycle benefits everyone.

Reaping the Benefits

For example, say an e-commerce applications developer has implemented a new inventory search functionality—something considered a key differentiator by business management. The developer knows this feature could rely heavily on some back-end database system and wants to ensure it’s tested properly, even as the code is being introduced.

Integrating APM and CI allows the entire team to monitor the process and test various conditions related to the update, tracking multiple builds and looking out for related performance issues. Such integration also allows for centralized tracking of other key attributes such as build number, status and build date, to further ease management.

Most importantly, by tying these two critical aspects of the applications delivery life cycle together, the collaboration and feedback loops required to truly embrace DevOps methodology become ever more valuable as these core Dev and Ops functions become intrinsically linked.

If this type of DevOps advancement gets your heart pumping, you’re not alone. Later this month, we’ll host a webcast here on devopsy.kinsta.cloud featuring experts from CA Technologies and Cloudbees. They’ll be discussing the benefits of matchmaking with APM + CI integration. They’ll also detail real-world benefits organizations leveraging integration of our respective technologies (CA APM and Cloudbees Jenkins) enjoy.

We obviously feel that this is a DevOps tooling marriage that will mature, change and stand the test of time. We’d love to garner your questions and feedback on the topic.

Which is all good, because thankfully there’s no such thing as Tinder for DevOps … yet.

June 21, 2016
Continuous Delivery Dependent on Who, What, Where
Without the right people, positions and talents, it is difficult for a business to engender a DevOps culture. It is even more frustrating to facilitate a continuous delivery pipeline successfully producing quick bursts of innovative genius, without a full complement of qualified souls harmonizing on the same DevOps theme song as they toil away on the company’s next release.

Some enterprises have a handle on the go-to people or hired guns they need to help spread a DevOps mindset—and exactly where to plug them into the organizational hierarchy. Other organizations have progressed to cloning these folks across Dev, Ops and the rest of the business. Some of those have laid some pipe as they extend a conduit from build to production. Those that are, by now, the “old guard” of DevOps have well-run pipelines brimming with fresh, robust software goodness.

No one company has a “secret sauce” that works across all industries and organizations. How your company should connect the dots depends on who you ask. This time devopsy.kinsta.cloud has asked Renato Quedas, vice president of Solutions and Enablement at Micro Focus.

Wrong People, Wrong Result

The right people will produce significant changes to code, creating new value that is worthy of promotion to production. The right people will ensure that the release is ready, reliable and fit to go live anytime the business wants to give its blessing.

“If a continuous feedback loop doesn’t exist between everyone involved in defining, building, testing, releasing and operating an application, the right people will not understand or feel enabled to pull the trigger in a release. Essentially that ‘any time’ will turn into ‘sometimes,’” says Quedas.

The company must maintain business continuity/disaster recovery (BC/DR) while accelerating continuous delivery; if continuous delivery moves too fast, it will push BC/DR off the rails and into disaster. Testing is an important ingredient in ensuring BC/DR remains once the software reaches the end of the development pipeline. “Customers will not care if applications are delivered faster if they don’t perform or function properly on their platform and devices of choice. Not having the right people involved will turn continuous delivery into an unreliable minefield and create an uncertain application delivery pipeline, which businesses will never accept as part of any improvement initiative,” he says.

The Right Stuff

According to Quedas, the following positions or profiles are examples of people who would have the communications skills, ruthless negotiation tactics, sound decision-making processes and customer-first mentality—with little tolerance for poor quality—that are necessary to make a DevOps culture and continuous delivery work:
- Product Managers who own responsibility for product quality can keep software product focus and development on track. They can communicate the business needs for the software, the capabilities it must have, and mediate the sometimes chaotic process that comes with continuous delivery. “Product Managers are used to prioritizing the work based on market trends, competitive landscape, customer requests and other internal/external pressures. Product Managers are accustomed to making decisions based on trade-offs, which helps CD focus in delivering the right outcomes to the business faster,” says Quedas.
- QA Managers who readily communicate to test, development and operations teams as well as nontechnical folks about what is necessary to maintain software reliability. They also can bring development to a halt and send innovations back to the drawing board when validity and reliability are at risk.
Creating the DevOps Culture

A thriving DevOps culture will build a software delivery pipeline that can duplicate quality results—as any truly repeatable business endeavor should be able to do. To bring this culture to life, the company must demolish team and departmental silos to get everyone on the same page regarding what the organization must do and when it should do it. “Companies will need to streamline production via automation in order to make decisions faster,” says Quedas.

A working, vibrant DevOps culture should give everyone a voice and ownership of a certain amount of control of their part of the process. “There is always pressure on information technology but there needs to be an understanding that it should be acceptable to put pressure back on the business,” says Quedas. “The business expectations need to be realistic or it won’t work. All sides need to be responsive.”

A healthy DevOps culture and mindset includes a shared understanding that scope with value must be achievable in a reasonable amount of time. “The faster you demonstrate value, the easier it becomes to earn the right to continue in the journey and on to the next phase of development,” he says.

Right People + Right Careers + Right Culture = Continuous Delivery

Having the right people in positions such as the aforementioned product manager and QA Manager gives an organization the ability to hone its continuous delivery pipeline. The right culture ensures that everyone will follow these and other leaders and stakeholders so that each new innovation comes as quickly and smoothly as it can.
June 20, 2016
XebiaLabs Opens Sold-Out DevOps Leadership Summit

BOSTON, MA–(Marketwired – Jun 16, 2016) – XebiaLabs (http://www.xebialabs.com), a recognized leader in DevOps and Continuous Delivery software tools, today announced the opening of its DevOps Leadership Summit at the iconic EYE Film Museum in Amsterdam, The Netherlands.

The DevOps Leadership Summit is a full day event bringing together some of the most advanced DevOps experts sharing best practices and enterprise case studies. The event features industry thought leaders and authors Dave Farley and Andrew Phillips, along with DevOps experts from companies such as ING, KPN, NJM Insurance Group, Rabobank, DUO, Stater and Wirecard.

“We are excited to bring together such an exceptional group of industry experts and welcome our customers from around the world,” said Derek Langone, CEO of XebiaLabs. “Attendees will have the opportunity to learn from some of the most experienced Continuous Delivery experts, discuss complex enterprise DevOps use cases and network with their peers throughout the event.”

The event opens today, June 16^th 2016 at 9am. To view the full agenda and learn more about the DevOps Leadership Summit, please visit www.xebialabs.com/devops-leadership-summit/.

About XebiaLabs
XebiaLabs develops enterprise-scale Continuous Delivery and DevOps software, providing companies with the visibility, automation and control they need to deliver software faster and with less risk. Global market leaders rely on XebiaLabs to meet the increasing demand for accelerated and more reliable software releases. For more information, please visit http://www.xebialabs.com.

Media Contact:

Victor Cruz
Principal
MediaPR
vcruz@mediapr.net

June 16, 2016
How DevOps is Killing QA
If you work in software quality assurance (QA), it’s time to find a new job.

The overall software development process has always consisted of the following core activities:
- Creating a requirements analysis;
- Producing a specification of the software artifact;
- Constructing the software;
- Investigating the quality of the product or service;
- Finding and fixing defects; then
- Deploying to production.
In most organizations, this process generally has occurred within one or more methodologies such as waterfall or agile. In waterfall, the testing process occurs relatively late. The software is produced, bugs are found by the QA team and then the software is fixed. These last two practices repeat in a cycle until management is comfortable that it can be released to the public.

In agile, individuals and teams—including QA—work closely together to release and then update software on an ongoing basis rather than deploy an entire platform all together and all at once. DevOps, as we have written in our “What is DevOps?” guide, is the next generation of agile development. Agile is a way of thinking in software development; DevOps goes one step further and is a concrete cultural change that implements the philosophy within an organization.

And that implementation eliminates the need for QA as a separate entity in the organization and disperses the responsibility for quality across different teams, even though many have argued that the discipline is still needed in one form or another.

Past Interpretations of QA in DevOps

One common argument is that DevOps sits at the center of a Venn diagram of dev, ops, and QA:

On one side, QA works together with development in trying to push more of their tests into the continuous integration system. Tests must have zero human intervention and generate their own test data.

On the other side, QA works with operations to collaborate on monitoring tools; perhaps to continuously run smoke tests in production. Chances are that operations is developing scripts for backup and restore of production systems, rollback of deploy, or scripts for disaster recovery.

Tim Hinds at NeoTYS looks at the issue differently and says that “DevOps QA” is meant to prevent defects rather than find them:

QA takes a critical role in this organizational structure because they have the visibility and the directive to push code out when it is working, and roll it back when it is not. This is a very different mindset from QA organizations of 10 years ago, whose primary responsibilities involved finding bugs. Today QA groups are charged with preventing defects from reaching the public site.

With all due respect, both are wrong.

Why DevOps Does Not Need QA

DevOps often uses continuous integration (CI) and continuous delivery (CD). In CI, developers use various continuous integration tools to integrate code into a shared repository multiple times each day, and DevOps relies on automation to determine the quality of the version. You cannot have any human interaction if you want to run CD, which ensures that any version of a batch of code in the repository can be released at any given time.

Essentially, the traditional QA cannot work in a full CI/CD environment. In older structures, the responsibility for software quality was in the hands of QA. Today, it’s part of the DevOps culture and methodology—the developers now own the responsibility rather than a separate entity within the organization.

Specifically, DevOps entails the use of vendors and tools such as BUGtrack, JIRA and GitHub to aggregate and report software bugs and defects. Test automation tools including Selenium, Cucumber, JUnit, TestNG and JMeter manage, execute and measure functional tests and cycles.

In the end, if there is a layer of people in the middle between development and operations, then you cannot perform CI and CD seamlessly and, therefore, cannot do DevOps. To run a proper DevOps operation, you cannot have QA at all.

The Future of QA

So, what will happen to all of the people who work in QA? One of the happiest jobs in the United States might not be happy for long as more and more organizations move to DevOps and they become more and more redundant.

According to the U.S. Bureau of Labor Statistics (BLS), software quality engineering is one of the high-tech professions whose growth rate is projected to be slower than average:

However, the BLS numbers are likely too generous because the bureau does not yet recognize “DevOps” as a separate profession at all:

As evidence, just look at how the relative number of Google searches in Google Trends for “sqa jobs” is slowly declining while the number for “devops jobs” is rapidly increasing:

For QA, the trend definitely does not look good.
June 7, 2016
Q&A: CircleCI’s Kevin Bell on Continuous Delivery

There’s been a lot of talk and momentum lately when it comes to continuous delivery. And it seems every enterprise has moved part, or all, of its development efforts to continuous delivery—or is at least talking about doing so. But there are many challenges such as security, dealing with legacy systems and internal politics associated with the move. With that in mind, we wanted to get a sense of where continuous delivery stands in the market today. And for that we turned to Kevin Bell of continuous integration and delivery platform maker CircleCI.

Kevin Bell has been a both developer and product manager of cloud-based software products, and is currently developer evangelist at CircleCI, where he gets to play with almost every deployment-related technology out there, hack a little Clojure and absorb the wisdom of very smart colleagues and customers. We thought it’d be a good idea to get his perspective on continuous delivery in the marketplace.

devopsy.kinsta.cloud: I wanted to get a sense from you where your customers are in the range of continuous integration and continuous delivery? What are you observing in the market?

Bell: I would say continuous integration is a hard prerequisite to continuous delivery. You need to have continuous integration first, and once you have that down, you can expand from that into continuous delivery. Maybe there are people that automate deployments with a minimum of testing in the middle, but you really want to have continuous integration set up.

Generally, I would say of our customers, on the order of half of the active customers, are deep into continuous delivery. There are certainly people that just use us to test and then do something else to deploy, and then there are those who aggressively, many times a day, deploy to production directly from CircleCI in a totally automated fashion. So we definitely have both extremes and then people that are experimenting in the middle on trying to figure out how to make that jump.

devopsy.kinsta.cloud: Have you seen many of these changes in the past year? And are many of the changes to continuous integration and deployment happening outside of Internet and SaaS (software-as-a-service) companies?

Bell: Lots of companies want to do it. So one change I’ve seen in the past year is that, not necessarily a change in the market, but a change in CircleCI’s world is that we have rolled out an enterprise version, which basically means a version of CircleCI that you can deploy behind your firewall. We are seeing a lot of interest in this among bigger companies. And we’re talking to a lot of different types of companies that are not SaaS companies, but are just any kind of company from apparel to finance institutions—just all manner of companies that take their internal software development practice very seriously, and very much want to do continuous delivery and have a modern software delivery methodology.

It’s kind of just becoming table stakes that you’re going to follow these kinds of practices today, even if you’re not a SaaS startup. It’s not just about software deployment, either. It’s also necessary to attract talent.

devopsy.kinsta.cloud: I would imagine, because we’re starting to see pilots and success stories, enterprises are seeing that it’s not just speed when it comes to feature release, but once the continuous delivery pipeline is up and running, it’s a more effective way to create and maintain software.

Bell: That’s definitely a big part of the promise of continuous delivery, and I think it delivers. Pardon the pun. It does let you get software features out faster. If you do end up releasing a bug, it lets you fix it faster. But I think some of the most emotional stories of success that I hear from people talking about the dark old days when they deployed at once every two weeks, or once every month, is just how risky that felt. And when they clicked the big deployment button in those days, how much was at stake and how many things could go wrong because it was such a big blob of software being deployed all at once. A big part of the idea of continuous delivery is that you don’t do those big bang software deployments. You’re always just putting out a little bit at a time, and keep everything in an equilibrium throughout the process.

devopsy.kinsta.cloud: These enterprises that you were talking to, what are some of the challenges or hurdles they have moving from legacy development to continuous deployment? What are the barriers they need to overcome to get to where they want to be?

Bell: There’s certainly various barriers, and it depends on the organization. Some organizations have a momentum built around a certain process. Maybe there’s political issues in an organization, maybe they have a new CIO that wants to change how they do things, but they have a lot of legacy software and processes that still operate in the old-mold paradigm that they need to update. So there are a lot of systematic challenges organizations run into. But there are definitely technical challenges, too. And I think just broadly to compare, for example, continuous integration and continuous delivery, I would say that continuous integration has been around longer now and has kind of matured a bit.

And a lot of the challenges have been uncovered within continuous integration when it relates to complicated and offbeat projects, whether that’s using things like mobile emulators like you can use on CircleCI to do iOS testing, or mobile device clouds, or browser testing, or all these things to kind of fill in the gaps, and test suites for big complicated software has sort of been explored and addressed to a large extent. But in continuous delivery there remain complicated, nontrivial systems that they’re deploying, not just little apps that go to Heroku or something. There’s this whole world of different policies and structures of software and systems that need to be continuously delivered. I think the industry and toolset makers are still exploring how to provide that.

devopsy.kinsta.cloud: Earlier you mentioned that if an organization wants to attract talent, they need to have these modern development processes in place. So I would imagine developers don’t want to get bogged down, in their view, in old methodologies and want to get aligned with companies that have these more modern practices as part of their career development?

Bell: That’s come up often at big companies. I would say that category of Fortune 500 companies, and not just software companies, they need to assure potential hires that they have modern software practices, and that even though they’re not a software company per se, that they value developers, and that they’re going to be a good place to work.

June 7, 2016