Why continuous Delivery is important

Some software development topics are controversial because they don’t seem to have real benefit or the costs are too high. In my experience, one of those topics is using Continuous Delivery. This concept describes the full automation of the whole build process so a product can be built just by clicking a button. The source code is build, every artifact is created and even the database is updated completely automatic. Please don’t confuse Continuous Delivery (building the product but not deploying it) with continuous Deployment (deploying the product), here is a nice article about this difference.

In my experience, the endeavor of setting up Continuous Delivery is often rejected because

  1. it is supposed to be too expensive both in time and money and
  2. it doesn’t solve problems that couldn’t be solved with a manual build.

I disagree strongly with both arguments. It was always easy to point to existing tools to disprove the first argument. However, I found it difficult to disprove the second argument. Luckily, a few weeks ago a pretty good example kind of flashed into my live.

Have a look at this small Oracle SQL script:

update MY_TABLE set VALUE = 4 where VALUE = 6; -- set some value
update MY_TABLE set VALUE = 3 where VALUE = 5; -- set some other value

Doesn’t look bad, right? It doesn’t, as long as you run this script via Oracle SQL Developer EVERY TIME AND ALSO WHEN DEPLOYING and don’t use another tool EVER. However, if you run it on the Oracle SQL command Line, the second line will be ignored as a comment, see Oracle language reference:

Do not put a single-line comment in a PL/SQL block that will be processed dynamically by an Oracle Precompiler program. The Oracle Precompiler program ignores end-of-line characters, which means that a single-line comment will end at the end of the block.

Oracle Language Reference

This will cause the second line to be ignored. I don’t get into detail what happens if a script works absolutely fine at every developer machine and in test and in quality assurance (because it gets deployed by hand with SQL Developer) and “suddenly” doesn’t work on production. Oh yes and one more thing: There won’t be an error. The second line just gets eaten up by the prince of darkness himself and will get someone in trouble. So, using different tools for deploying a script, even from the same vendor, can lead to very different outcomes. That is the reason why you should use exactly the same tools for building and deploying your software, independent if the build is for development, test, quality assurance or production. In short: use Continuous Delivery !


Use Continuous Delivery !

(Photo: scanrail,