Added continuous delivery.

evolution.html

@@ -41,7 +41,7 @@
 
 		<p>When code changes, you need to test it, which often means you need to <strong>build</strong> it, compiling source, data, and other resources into an executable format suitable for testing (and possibly release). Build systems can be as simple as nothing (e.g., loading an HTML file in a web browser interprets the HTML and displays it, requiring no special preparation) and as complex is hundreds and thousands of lines of build script code, compiling, linking, and managing files in a manner that prepares a system for testing, such as those used to build operating systems like Windows or Linux. To write these complex build procedures, developers use build automation tools like <code>make</code>, <code>ant</code>, <code>gulp</code> and dozens of others, each helping to automate builds. In large companies, there are whole teams that maintain build automation scripts to ensure that developers can always quickly build and test. In these teams, most of the challenges are social and not technical: teams need to clarify role ambiguity, knowledge sharing, communication, trust, and conflict in order to be productive, just like other software engineering teams (<a href="#phillips">Phillips et al. 2014</a>).</p>
 
-		<p>Perhaps the most modern form of build practice is <strong>continuous integration</strong>. This is the idea of completely automating not only builds, but also the running of a collection of tests, every time a bundle of changes is pushed to a central version control repository. The claimed benefit of continuous integration is that every major change is quickly built, tested, and ready for deployment, shortening the time between a change and the discovery of failures. This only works if builds are fast. For example, some large projects like Windows can take a whole day to build, making continuous integration of the whole operating system infeasible. When builds and tests are fast, continuous integration can accelerate development, especially in projects with large numbers of contributors (<a href="#vasilescu">Vasilescu et al. 2015</a>).
+		<p>Perhaps the most modern form of build practice is <strong>continuous integration</strong>. This is the idea of completely automating not only builds, but also the running of a collection of tests, every time a bundle of changes is pushed to a central version control repository. The claimed benefit of continuous integration is that every major change is quickly built, tested, and ready for deployment, shortening the time between a change and the discovery of failures. This only works if builds are fast. For example, some large projects like Windows can take a whole day to build, making continuous integration of the whole operating system infeasible. When builds and tests are fast, continuous integration can accelerate development, especially in projects with large numbers of contributors (<a href="#vasilescu">Vasilescu et al. 2015</a>). Some teams even go further than continuous integration, building continuous <em>delivery</em> systems that ensure that complete builds are readily available for release (potentially multiple times per day for software on the web). Having a repeatable, automated deployment process is key for such processes (<a href="#chen">Chen 2015</a>).</p>
 		
 		<p>One last problem with changes in software is managing the <strong>releases</strong> of software. Good release management should archive new versions of software, automatically post the version online, make the version accessible to users, keep a history of who accesses the new version, and provide clear release notes describing changes from the previous version (<a href="#vanderhoek">van der Hoek et al. 1997</a>). By default, all of this is quite manual, but many of these steps can be automated, streamlining how teams release changes to the world. You've probably encountered these most in the form of software updates to applications and operating systems.</p>
 
@@ -52,6 +52,7 @@
 		<small>
 		
 		<p id="brindescu">Caius Brindescu, Mihai Codoban, Sergii Shmarkatiuk, and Danny Dig. 2014. <a href="http://dx.doi.org/10.1145/2568225.2568322">How do centralized and distributed version control systems impact software changes?</a> In Proceedings of the 36th International Conference on Software Engineering (ICSE 2014). ACM, New York, NY, USA, 322-333.</p>
+		<p id="chen">Chen, L. (2015). <a href="https://doi.org/10.1109/MS.2015.27">Continuous delivery: Huge benefits, but challenges too</a>. IEEE Software, 32(2), 50-54.</p>
 		<p id="kim">Miryung Kim, Thomas Zimmermann, and Nachiappan Nagappan. 2012. <a href="http://dx.doi.org/10.1145/2393596.2393655">A field study of refactoring challenges and benefits</a>. In Proceedings of the ACM SIGSOFT 20th International Symposium on the Foundations of Software Engineering (FSE '12).</p>
 		<p id="phillips">Shaun Phillips, Thomas Zimmermann, and Christian Bird. 2014. <a href="http://dx.doi.org/10.1145/2568225.2568274">Understanding and improving software build teams</a>. In Proceedings of the 36th International Conference on Software Engineering (ICSE 2014). ACM, New York, NY, USA, 735-744.</p>
 		<p id="potvin">Potvin, R., & Levenberg, J. (2016). <a href="">Why Google stores billions of lines of code in a single repository</a>. Communications of the ACM, 59(7), 78-87.</p>