Over a million developers have joined DZone.

Tell DZ: The Highs & Lows of Your Journey to Continuous Delivery

DZone 's Guide to

Tell DZ: The Highs & Lows of Your Journey to Continuous Delivery

· DevOps Zone ·
Free Resource

Moving toward Continuous Delivery can be a big change. Ideally, releases speed up and smaller, iterative changes allow for quicker bug fixes and less risk of catastrophe. But any team undergoing changes will experience some growing pains, and whether your experience with Continuous Delivery has been a sweeping success, a gradual struggle, or just a few pieces and ideas incorporated here and there, we'd love to hear about it.

Already we've heard from a few DZone MVBs on the topic. Lubos Krnac, for example, recently wrote about his successful approach involving Maven, Jenkins, a Deploy plugin, and GitHub, which allowed him to trigger deployment after each commit.

According to Krnac, Continuous Delivery should be the first thing addressed when beginning a new project, and existing projects should adopt it immediately. Larger teams, however, may not want to deploy on every commit, and care should be taken to ensure adequate roll-back for failure scenarios:

I already saw cases when [all of] QA was paralyzed for a few hours because of failed deployment.

Steve Smith, on the other hand, sums up his Continuous Delivery experience with a motto to live by:

Building a Continuous Delivery pipeline is easy. Building a Continuous Delivery organisation is hard.

So, what has your experience with Continuous Delivery been like? Let us know with a comment: What were the highs and lows? What worked, and what didn't?


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}