View All Videos
Continuous Deployment Really Means Continuous Testing

Continuous Deployment Really Means Continuous Testing

2

Damon Edwards / 

On Twitter and on web operations focused blogs, the concept of Continuous Deployment is a topic that is gaining momentum. Across our consulting clients, we’ve also seen a significant uptick in discussion around the concept of Continuous Deployment (some calling it “Agile Deployment”).

The extreme example of Continuous Deployment that has sparked the most polarizing discussions is from Timothy Fitz’s posts on doing production deployment’s up to fifty times per day.

While it’s a fascinating read, many people for whom the essay is their first exposure to the idea of Continuous Deployment overlook the real value. The value is not how Fitz gets code all the way into production on a sub-daily basis. The value is in achieving a state of continuous automated testing.

If you understand the concept of “the earlier you find a bug, the cheaper it is”, the idea of continuous testing is as good as it gets. Every time a build executes, your full suite of unit, regression, user/functional, and performance tests are automatically run. In a mature operation this could quite literally mean millions of automated tests being executed every day. As your application development makes even the smallest moves forward, the application is being rigorously testing inside and out.

Another common misconception is that Continuous Deployment means that human-powered QA cycles are a thing of the past or are somehow less important. This belief is probably a byproduct of those extreme practitioners of Continuous Deployment who are doing hot deployments to production after every build. In most business scenarios there is not much benefit to continuous production deployment. The value of a human-powered QA team sensing if the look, feel, and functionality match the requirements can’t, and shouldn’t, be overlooked.

Most of our consulting clients just aren’t interested in sub-daily deployments to live production environments. What they want out of Continuous Deployment is to have a constant state of broad automated testing and an always up-to-date QA environment for human-powered testing and business review.

In addition to deploying a broad suite of automated testing tools, Fully Automated Provisioning provides the linchpin that makes Continuous Deployment a reality.

Clouds, Virtualization, and Continuous Deployment all share the same achilles heal

Clouds, Virtualization, and Continuous Deployment all share the same achilles heal

1

Damon Edwards / 

Recently, there are 3 “hot trends” that we regularly get asked about in our day jobs as web operations consultants:

 

  • Cloud Computing (meaning elastic computing resources paid for on-demand)
  • Virtualization in Production (meaning using virtual machines for non-development or QA uses)
  • Continuous Deployment (meaning the ability to automatically deploy and test a full environment automatically after each and every build that comes out of their Continuous Integration driven build process)

There is a common thread that ties all of these together — Fully Automated Provisioning**. You can’t achieve the full benefit of any of these advances without Fully Automated Provisioning.

 

In this previous post, we covered the reasons why efforts to harness the power of cloud or virtualized infrastructure will fail without Fully Automated Provisioning.

Continuous Deployment suffers from a similar weakness. If you don’t have Fully Automated Provisioning in place, the efforts required to provision your applications and sort out the resulting problems will outweigh whatever benefits you set out to gain.

IT automation may not be the sexiest field. However, IT automation (and specifically Fully Automated Provisioning) is the necessary foundation that lets you continually reap the benefits of the latest headline grabbing initiatives.

**To read about what the criteria is for achieving Fully Automated Provisioning, check out this blog post and whitepaper.

The CIO / Ops Perception Gap

The CIO / Ops Perception Gap

1

Alex Honor / 

Every IT manager should read this article: Making Business Service Management a Reality . I think the original title, “BSM Evolution – The CIO / Ops Perception Gap”, more accurately reflects the essence of the issues it draws out.
* CIOs prematurely believing they have a handle around running their software services
* VPs of Ops afraid to admit that they’ve just begun a long journey that assumes continuous improvement approaches and no one time fixes
* No clear visibility from the biz level into the level of quality of service operations delivered by the CIO on down through the tech management ranks
* The need to focus on fundamentals

The article made me think of the strategies put forth in the Visible Ops book. But, even more so, it really indicates the need for true visibility into how ops is conducted at every level (no obfuscation tolerated).

The real reason why enterprises aren’t moving to the clouds

The real reason why enterprises aren’t moving to the clouds

1

Damon Edwards / 

Visit any of the cloud obsessed blogs, discussion forums, or conferences and you’ll hear the same “reasons” as to why cloud computing isn’t catching on within enterprise IT shops. It’s always something about interoperability, service level agreements, security risks, data formats, APIs, or hypothetical legal implications.

Interesting issues, but they are all red herrings.

The inability of enterprises to take advantage of the clouds isn’t due to the shortcomings of the cloud offerings available today. The shortcoming is with the state of today’s enterprise IT shops. The real reason is that those millions of applications currently running within enterprises are hardwired into a particular environment.

I’m not talking about the application code itself. After all, Linux is Linux and Windows is Windows no matter if it’s running on native hardware, a local VM, or somewhere in a cloud. The true problem is with the way today’s applications are configured, deployed, and managed. Very few folks in enterprise IT are willing to admit to the hairballs that decades of shortsighted IT Management techniques have created.

The often offered up excuse of there being “a lack of cloud skills within the enterprise” is really just code for a general abundance of poor to outrageously awful IT Management techniques.

Let’s look at a basic and often quoted use case for cloud computing.

With server utilization rates in the 3-15% range, there is obviously room for significant reduction in capital expenditures by taking advantage of cloud-based elastic computing resources. Why isn’t there a rush of enterprises running to take advantage of this? No, the answer isn’t the often quoted fear of vendor lock-in. The answer is that these enterprises are locked into themselves.

Think of how difficult it is for an enterprise to switch datacenters. Months of effort go into planning and executing the move, but have you ever heard of one going smoothly? If it takes months to move between your own datacenters and you still can’t get it right, what hope do you have for making it into the clouds?

It’s no coincidence that the local virtualization vendors like VMware and Parallels are facing this same denial of such an obvious business case as they attempt to push their offerings out of development and testing environments and into production environments.

Rob England (TheITSkeptic) is one of the few pundits to point out the fundamental disconnect between enterprise IT and the clouds. He attributes the largest hurdle to migration costs. I would take it a couple of steps further. Migration is just a symptom of the problem. If migration was the only problem, using cloud infrastructure would be a slam dunk for new application projects. But, of course, the same old broken management techniques ingrained in an enterprise plague new and old projects alike.

The bottom line is that what passes for the status quo in IT Management is crippling enterprises. Enterprise IT can’t take full advantage of such fundamental advances as virtualization and elastic computing until an “abstracted administration” paradigm becomes standard operating procedure.

Abstracted administration means the ability to work from a point of view that is independent of any particular server instances or specific software deployments. Within the abstracted administration paradigm, an administrator manages deployment and ongoing operations from a higher level and lets the underlying framework coordinate operations across the actual physical environment. Once you’ve achieved abstracted administration, moving datacenters or re-deploying an application to virtualized servers in the cloud is as simple as updating one part of the specification that drives the abstraction. Your tools will then handle the rest.

Of course, achieving abstracted administration means that the provisioning and management of your entire application stack — from OS install to running integrated application services — must be fully automated using tools that support this specification-driven, abstracted administration paradigm.

If you look at what passes for state of the art in many IT shops, it might seem like the ability to achieve abstracted administration and fully automated provisioning is a long ways off.

That is simply not the case. The tools to get this done are already here, they work well, and they are all open source. Below is a diagram of an open source toolchain that can provide fully automated provisioning.

Still not convinced it can be done? Check out this whitepaper. The paper lays out how fully automated provisioning can be (and has been) achieved using these standard open source tools.

If you are interested in more detailed explanation of the abstracted administration paradigm, check out this detailed post by Alex on the ControlTier Blog.

Web Operations: the canary in the IT Management coal mine

Web Operations: the canary in the IT Management coal mine

Damon Edwards / 

Rob England (The IT Skeptic), recently wrote some very nice things about this blog.

After I got over the fact that one of my favorite bloggers is writing about this blog, I realized that his post does raise a good question: If good IT Management is good IT Management not matter what business you are in, why does this blog focus so much on the Web Operations perspective?

Part of the reason is that Web Operations is the world that Alex and I live in on a daily basis (via ControlTier… helping e-commerce and SaaS companies improve the efficiency and reliability of their operations).

The other part of the reason is that we see Web Operations as the canary in the coal mine for IT Operations. When a company’s entire business is operating software as revenue producing service, the shortcomings and the successes of your IT Operations goes right to your bottom line. The tolerance for the status quo dissipates a lot quicker and there is stronger political will to think outside of the box.

Put it this way, pretend you’re the CEO of a Fortune 100 size company that makes aircraft engines or automobiles. Where is improving the efficiency and reliability of your IT Operations going to fall on the list of things you worry about every day? 32 on a top 50 list might be generous.

Now pretend you are the CEO of an online company whose sole source of revenue comes from what you can generate through your website. Suddenly the efficiency and reliability of your IT Operations jumps to near the top of the list.

Update: While people point out to me that I’m stretching the “canary in a coal mine” metaphor a bit far… I’m loading The Police’s Zenyatta Mondatta album into my iTunes.

Web Operations: Are you developing an asset or a liability?

Web Operations: Are you developing an asset or a liability?

Damon Edwards / 

“Buy vs. Build”. It’s a term you hear repeatedly with it comes to businesses weighing their options for application and systems management solutions. But as anyone who spends time in the web operations trenches knows, the reality is always something closer to “build vs. build”. Buy something from a software vendor, use open source tools, develop something from scratch – in each situation there just isn’t a one size fits all option and there is always going to be custom integration involved. This reality was previously covered in Alex’s “Stone Axes” post.

So being resigned to the fact that there is a “build” aspect to any solution, the next critical choice then becomes what guidelines you impose on your organization to steer their design choices. The most pervasive design criteria seems to be technical completeness or elegance. From a technical architect’s purist point of view this makes sense; but what this often fails to take into account is the business impact of those technical decisions.

While many technical design options might seem to have identical business impact on day 1 (they cost roughly x to develop and provide feature y), what are the true cost of those decisions down the road? Have those decisions put the company in a position to continuously leverage those design choices into increasingly greater returns? Or have those decisions placed an anchor around the company’s neck that they will be weighted down by, and paying for, well into the future? To put it into loose economic terms: have you developed an asset or a liability for your company?

What would be an example of building asset? Using off the shelf open source tools and only developing thin layers of integration where they need to plug into your existing systems.

What would be an example of building a liability? Writing a custom system that mirrors the available functionality of existing off the shelf tools, thereby saddling your company with the sole responsibility for the forward progress of the design and maintenance of that tooling.

The asset vs. liability concept is one that obviously needs to be flushed out quite a bit more. In any case, it’s shocking how infrequently companies actually analyze the long-term business impact of the technical design decisions made about their tooling.

(Note: Thanks to Lee Thompson for framing this as an asset vs liability debate)

Page 18 of 26First1617181920Last