Will Containerization (Docker) replace Continuous Integration?
<p>Or, in other words, <strong>Do "images" beat "scripts"?</strong></p>

<p>I am new to the Docker story, and unfortunately I am currently working in an environment where CI is not yet a reality ;-P</p>

<p>But, I have the following experience on "image" beating "script":</p>

<p>If I want to distribute, even only for exploration/training purpose, a (desktop) application for some of my colleagues, I have to go through a long and costly process, resulting in an installation <strong>script</strong> for the software to be installed on workstations. The end result being that the <strong>script</strong> takes quite some time to execute and can fail due to doggy context variations.</p>

<p>So, I did not do that. Instead, I have asked to test AWS and Google Cloud Platform ;-) Then, I have installed a virtual machine with the software I wanted to distribute, together with a clientless (HTML5) remote desktop gateway (e.g. <a href="http://guac-dev.org/" rel="nofollow">Guacamole</a>), and I have taken an <strong>image</strong> of it.</p>

<p>THEN, when a colleague needs to try it, I can just create a new VM instance based on the image and it's done! It takes the time for the VM to be created (&lt;30 sec), there is no installation script, no deployment-thingy!</p>

<p>The "image" won over the "script".</p>

<p>NOW, I am imagining doing the same kind of "short-cut" within our DevOps team. The developers might deliver a ready-to-run container, instead of a ready-to-be-built source-code. No?</p>

<p>And, why not going further... Why not testing (systematically) in PRODUCTION with a segmented small group of chosen users? If I have versioned containers that can run in parallel - the stable one together with the brand new one - and if I can "redirect" only a limited (chosen) subset of my users to the new one... Do I still need this internal-testing-phase-which-does-not-really-work?</p>

<p>Does this make sense? Or, am I missing something?</p>