Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.
See all our reports

Pragmatic Continuous Delivery with Jenkins, Nexus and LiveRebel

Manual or Automatic?

In a recent study on Production Deployment processes, results showed that the vast majority of organizations’ deployment pipelines still heavily rely on manual operations, which tend to be prone to human error, inconsistencies and generally move things out the door slower.

Out of 1100+ responses ranging from large to small organizations, here is the level of process automation for different roll-out-to-production activities:

production deployment processes automated deployment pipeline

What I really hate about today’s deployments is that frequently no one knows a) which version was deployed, b) if all the tests passed c) how was it packaged or deployed. It’s not automated, transparent or predictable, and this is what we like to see.
     – Toomas Römer, Director of Engineering at ZeroTurnaround.

Is it hard to believe that ~75% and more of organizations surveyed still rely on unpredictable, error-prone manual processes for making production application, production database and production environ- ment updates. There are good reasons why the industry is where it is, and we can start by reviewing those reasons.

Why is deploying software so hard?

In recent years, we have conducted dozens of interviews and ran two surveys trying to figure out why deploying software to production, something we’ve been doing for years over and over again, is so darn hard to get fast, automated and painless. We learned that two key problems are responsible for defining the complexity:

Whenever you need to change user sessions, databases & other data stores, or third-party dependencies (e.g. APIs) and cannot take the application offline, it becomes a complicated dance that is comparable to changing out the members of an orchestra without missing a single beat.

Software is almost unique in this world by having both a high probability of failure (more or less any kind of change can cause it) and a high impact resulting from failure (it is really hard to isolate the repercussions). This means that a lot of software organizations are built to prevent failure and as a side effect will resist making any changes to their existing infrastructure.

Despite these and many other technological and organizational issues, most firms want to roll out their software as quickly as possible to their users and customer base. The goal of this paper is to review how to simultaneously increase the velocity of delivering production-ready software, while noticeably decreasing the risk and impact of failure.

Grab the PDF and move this to the couch :-)