The rush is on!  Software development organizations everywhere are rushing to implement Continuous Delivery.   It seems as though being ‘continuous’ is the answer to every company’s success story.  Successful adoption of the continuous movement is synonymous with product development success, but an important distinction is missing.  Continuous Delivery is a solution; not a development process.

I’ve been around long enough to see a few ‘one size fits all’ solutions go too far.  One time in the late 90’s, someone proclaimed to me that object oriented programming would be replacing every bit of procedural code in existence.  COBOL was out, C++ and Java were in.  OO was all the rage.  But last time I checked online, my bank transfers are still not entirely real-time operations.  The debit side happens right away, but the deposit happens during an evening batch processing run.  Some kind of procedural programming run is still in there.

Puppet and Chef are great tools, but what process do you follow when deciding if you need them?  Is it simply a, “follow the herd decision?”  Did the loudest, most passionate developer make the decision for you?  Is continuous deploy the right solution for your build environment?  Did you create a set of requirements, analyze them, and select accordingly?

Of course, it’s not that these continuous solutions are bad.  Quite the opposite; they are great solutions.  It’s the notion of a single solution being right for every problem that doesn’t sit well with me.  Herd mentality appears to have kicked in and everyone, it seems, is on a rampage to pursue this great new silver bullet.

Continuous integration is something many of us have been working toward for the past 15-years of software engineering.  I think of continuous integration, continuous test, continuous deploy and all the others are as nothing more than pieces of a puzzle.  They are great pieces and suitable for many organizations.  CI is an easy way to say, “one requirement of my SCM environment is end-to-end, unattended build automation.”  Are these other continuous solutions anything more than the same principles applied to the rest of the development processes?  Is continuous test the right way to test every software product? Is continuous deploy the right solution for your deploy?

A better choice for is the pursuit of a process to determine the best solution for creating and delivering our software.  If the solution produced by the process is Continuous Delivery, and it just might turn out that way, then awesome.  But if it’s not, you will be well on your way to figuring out the best solution for your situation.

My suggestion is to use an SDLC approach for determining if one or all of the continuous solutions are right for your project.  Start by understanding the stakeholders and defining the requirements instead of rushing to the answer.  Follow the process through implementation and maintenance and listen to the feedback.  Using an SDLC to determine our internal development processes means our stakeholders are internal.  Some are easy to find, but others are quiet and you will have to look for them.

This site will never be a one-stop shopping destination for everything related to the internal SDLC.  It is my intent to start conversations regarding various ways to effectively use and perhaps even formalize an SDLC to manage our internal development processes.  I think it’s prudent to view all of the internal development process together as a single system and evaluate effectiveness using the same tried an proven techniques we use for evaluating how successfully our business products satisfy the needs of our customers.