Miroirs/cooperative-software-development
1
0
Fork 0
mirror of https://github.com/amyjko/cooperative-software-development synced 2024-12-26 21:58:27 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

Fixed #36, citing Hilton CI work.

Browse source
This commit is contained in:
Andy Ko 2019-04-30 10:58:23 -07:00
parent bf98f39f98
commit ccdc1d7d4b
1 changed files with 12 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

13
evolution.html
View file

@ -47,7 +47,17 @@
<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>). 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>
Perhaps the most modern form of build practice is <strong>continuous integration</strong> (CI).
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 CI is that every major change is quickly built, tested, and ready for deployment, shortening the time between a change and the discovery of failures.
Research shows this is true: CI helps projects release more often and is widely adopted in open source (<a href="#hilton">Hilton et al. 2016</a>).
Of course, these benefits occur only 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>
@ -59,6 +69,7 @@
<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="hilton">Hilton, M., Tunnell, T., Huang, K., Marinov, D., & Dig, D. (2016, August). <a href="https://doi.org/10.1145/2970276.2970358">Usage, costs, and benefits of continuous integration in open-source projects</a>. In Proceedings of the 31st IEEE/ACM International Conference on Automated Software Engineering.</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="nelson">Nelson, N., Brindescu, C., McKee, S., Sarma, A., & Dig, D. (2019). <a href="https://link.springer.com/article/10.1007/s10664-018-9674-x">The life-cycle of merge conflicts: processes, barriers, and strategies</a>. Empirical Software Engineering, 1-44.</a>
<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>