CSC/ECE 517 Fall 2014/ch1a 16 av

From Expertiza_Wiki
Jump to navigation Jump to search

Writeup Page Continuous integration pipelines (CIP) are software packages that help groups of developers manage, maintain, merge, build and test software continuously and automatically throughout the day. These packages provide the infrastructure to support the practice of Continuous Integration (CI), a method of continuously combining everyone changes in order to prevent integration issues.

Background

Introduction to the Pactice of Continuous Integration

Before we talk about the pipelines that support it, we must define continuose integration itself. Continuous integration has gained a lot of popularity with agile development, called out specifically in the flavor of agile called Extreme Programming (XP).<ref name="Stahl">D. Ståhl Modeling continuous integration practice differences in industry software development J. Syst. Software 87pp. 48 <last_page> 59. 2014. . DOI: 10.1016/j.jss.2013.08.032.</ref><ref name="Meyer">M. Meyer. Continuous integration and its tools IEEE Software 31(3), pp. 14 <last_page> 16. 2014. . DOI: 10.1109/MS.2014.58.</ref> As agile developers began to shy away from the traditional waterfall development cycle and move towards smaller cycles, the need to limit the global gates that software needed to go through arose.

The core idea is that the longer code sits with a developer, the more bugs they can introduce to the code. The older bugs are, the more they cost to fix. To combat this, continuous integration is a push to test, merge, combine, and package builds every day.

One of the core tenets of agile program that enable continuous integration is the idea of test driven development. Test driven development is the idea that you should design the tests that a piece of code should pass before developing the code, then writing the minimal amount of code required to pass all tests. If there is a function or feature that is not captured by the tests, it should not be coded. These tests were first developed as personal unit tests. Later, this was expanded into automated unit testing with unit testing frameworks, such as CUnit, JUnit, etc. By running the test on each commit, it becomes immediately apparent on which commit the bug was introduced or exposed. This allows for less backtracking when dealing with show-stopping bugs.<ref name="P.Duvall"> P. Duvall, S. Matyas and A. Glover. Continuous Integration: Improving Software Quality and Reducing Risk 2007Available: Table of contents only http://www.loc.gov/catdir/toc/ecip0714/2007012001.html</ref><ref name="Meyer"/>

Later developments in this process adopted the use of a “build server”-a separate, clean development environment that is independent of the developers work environment. By integrating the source control, build server, and unit testing into one interface, the whole process can be managed from one single pipeline.


Continuous Integration History

The idea for continuous integration has been around for a lot longer than there has been a name for it or tools to run it. Nightly or daily builds have been toted as a valued for decades.<ref name="M.Fowler"/> Many institutions began with in-house processes that supported some form continuous development. These systems were primarily put in place to deal with the resource heavy requirements of building and maintaining software. This induced daily cycles of commit, merge, test, and report. As the popularity of this system arose, it created a market for continuous integration pipeline software. These in house tools used build automation tools like build servers to create their software.

One of the oldest of these software packages was CruiseControll. Release in March, 2001, this software has been iterated upon for many years.

Another early riser in the field was Hudson. Created at Sun Micro-systems, it was released under the MIT License, so it was free (as in speech). It became popular as an open source alternative to Cruise Control. When Sun Microsystems was sold to Oracle, the creates forked the project to keep it “free”, creating the Jenkins.

Since that time, the number of products have become widespread, touting such features as cloud integration, integration with different source control, and a myriad of language support

Benefits and Drawbacks

Proponents state that the bugs are caught sooner, following the “Fail faster” paradigm in software engineering. Because it is strongly built on automation, proponents state that continuous integration will reduce repetitive processes that will slow down the code. <ref name="P.Duvall"/> <ref name="M.Fowler">M. Fowler. (01 May 2006). Continuous Integration. Available: http://martinfowler.com/articles/continuousIntegration.html</ref> However, the most powerful result of the process is that it maintains an up-to-date “clean” node of the software. This software can usually be packaged into a release with little additional effort. This provides risk mitigation by having a partially complete product, as well as aids in bug tracking. <ref name="P.Duvall"/><ref name="M.Fowler"/>

Skeptics state that continuous integration requires costly frameworks and framework maintenance, and gives little benefit over frequent integration. There is no unified standard on how to implement CI and thus it is hard to measure its affects. It is such a huge process and time consuming process that it is difficult to tell which parts improve and which parts do nothing to help the software development process.<ref name="Stahl"/>

Introduction to Continuous Integration Software (Pipelines)

There are many suggested features for continuous integration software pipeline. These software pipelines could be ad-hoc and built in house, or externally provided. This section will cover best practices and procedures to ensure functional system builds that report no unexpected errors to the developers. Features include version control, build and test automation, as well as developer housekeeping rules that streamline the process into an powerful software development tool. Following Figure 1.1, diagramming the commit and build processes, are the essential principles of continuous integration:

Figure 1.1


Maintain a Source Repository

Source code can become very complex in larger systems. Continuous integration mitigates untracked branching that developers wish to avoid. The entire code for a functional build should be on the central repository, including test cases, configuration files, and database schemas. For proper functionality, the baseline suggestion is to host the information in a source code management system like Subversion, where all developers push towards the current build.<ref name="M.Fowler"/>

Automate the Build

Across the numerous development platforms, there are many build scripts that are used to configure a project and in some cases using very uncommon commands. Sometimes changes to the source code file structure can cause the build scripts to change. Therefore automation can serve to reduce the possibility of incorrect configurations and simplify the entire build process.<ref name="P.Duvall"/> Automated build systems are standard in a number of systems . Java developers created Ant, Unix users configure with make, .NET developers prominently use MSBuild, and Ruby has the rake command that automates configuration, build, and database migration.

It is imperative that these builds include all source code committed to the repository.<ref name="P.Duvall"/> This means that introducing a new machine should only require downloading the project source and instructing a single command to have a fully functional application or executable.

Make Your Build Self-Testing

Extreme Programming(XP) and Test Driven Development(TDD) show that self-testing code is very valuable in catching the bugs that sometimes slip through regression test coverage. In continuous integration pipelines, these development methodologies aren't paramount to an effective system. The significance is in having having the ability to build test code that covers a majority of the project by issuing issuing a single command.<ref name="M.Fowler"/> Since this procedure is called after a clean commit, a resulting failure in the test code build should result in a failed project build as well. Essentially, this automatic testing procedure gives developers confidence in functional project releases.

All Contributors Commit To the Mainline Every Day

Frequent communication is a major facet of continuous integration. Each day developers follow a series of operations to submit successful repository changes:

  • Retrieve and update the trunk or mainline code
  • Fix any conflicts as they merge their commit to the trunk
  • Pass automatic build in testing and release

Once the commit is established on the trunk, other developers can follow the same procedure to validate their contributions while the version control system provided another form of error checking in file inconsistencies. Continuous integration requires this quick and constant communication so that any code conflicts can be found and removed in a fast manner.<ref name="P.Duvall"/> When an error is detected in running code rather than compilation, the system of continuous commits reduces the search time for repository changes that caused the system to break.

Every Commit Should Build the Mainline on an Integration Machine

After every commit from a developer merging changes to the mainline, the system should execute some automated build script or a daemon to automatically configure and run the build process.<ref name="M.Fowler"/> Each commit is only successful if the build of the main source code passes. Of course this does give each developer the responsibility of maintaining source code in good state, as their changes may introduce error to the system.

Keep the Build Fast

Commits to the system should be frequent. The system uses quick iterations as a way to reduce the amount of bugs introduced to the code base. Continuous integration utilizes the deployment pipeline as a two staged process for committing a correct build.<ref name="M.Fowler"/> In the first stage, the build process consists of unit testing and merging with the mainline on a localized copy of the source and a mock or nonexistent database. After the commit build stage, the developer will have a good commit sent to the server for testing on the production database and source filesystem. Building on both the production level and local versions is imperative, as it allows developers more code coverage with the ability to utilize performance testing in the build process.

Test in a Clone of the Production Environment

As previously noted, the mainline should be tested in a local copy before the server automated build test.<ref name="P.Duvall"/> Since developers may operate in varied computing environments, resulting errors from updating to the mainline can be machine dependent, thus only fixable by the developer with that specific code conflict. Setting up an environment cloned as closely to the source environment as possible, promotes the ability to set up a testing environment that can relay performance testing of the build without affecting the production database. Therefore if a test fails in the mock environment, then the commit will not take effect on the mainline of the version control system.

Make it Easy for Anyone to Get the Latest Executable

It seems trivial to note, but all contributors, meaning developers and testers, should have access to the current build.<ref name="P.Duvall"/><ref name="M.Fowler"/> Keeping multiple eyes on the development of the code base ultimately mitigates any bugs or defects that could go untracked in the build process. When a contributor sees a issue in the code, they are instinctively prompted to call attention to this mistake. Again, taking us back to the recurring moniker that the earlier conflict is found, the quicker it can be handled.

Everyone can see what's happening

Visibility is truly important in developing projects that have a varied number of developers, each committing numerous times daily towards a complex code base. In some cases, those developing the executable may be operating in distant locations. Continuous integration promotes accountability in version changes. Everyone working on the project should know the state of the current build as well as the author of each commit to the system.<ref name="P.Duvall"/> With a full awareness, contributors know who to contact for relevant issues and get a deeper understanding of the code base.

Automate Deployment

Expounding the principle of automated build, a system operating a continuous integration platform should be structured to configure and build in various environments. Notably, the system needs environments for commit testing, secondary testing, and a production application environment. Constant file transfers and updates relies on the use of simple command scripts to establish the previously denoted build procedure in a single operation. Other than providing this time savings, the automated build process ensures that the code mainline is in a healthy functioning state before any release.<ref name="M.Fowler"/>

Platforms

Name Platform (computing) License Windows Software builders Java Software builders Other Software builders Notification IDE System integration Other System integration
Jenkins Servlet Container Creative Commons and MIT License MSBuild, NAnt Apache Ant, Apache Maven 2, Kundo Cmake, Gant, Gradle, Grails, Phing, Rake, Ruby, SCons, Python, Shell script and Command Line Android, E-mail, Google Calendar, IRC, XMPP, RSS, Twitter Eclipse, IntelliJ IDEA, NetBeans Bugzilla, Google Code, JIRA, Redmine, FindBugs, Checkstyle, PMD and Mantis Bug Tracker, Trac
Bamboo Servlet Container proprietary MSBuild, NAnt, Visual Studio Ant, Apache Maven 1, Apache Maven 2, Apache Maven 3 custom script, command line, Bash XMPP, Google Talk, E-mail, RSS, Remote API IntelliJ IDEA, Eclipse, Visual Studio FishEye, Crowd, JIRA, Clover
Go Cross-platform Apache License 2.0 yes yes Cross-platform command-line E-mail, CCTray no RESTful API
Travis CI Hosted MIT no no C, C++, Clojure, Erlang, Go, Groovy, Haskell, Java, Node.js, Perl, PHP, Python, Ruby, Scala E-Mail, Campfire, HipChat, IRC no GitHub, Heroku

Modified from "Comparison of continuous integration software" at Wikipedia, licensed under CC-BY-SA


Jenkins<ref name="Jenkins">Jenkins CI. (). Welcome to Jenkins CI! | Jenkins CI . Available: http://jenkins-ci.org/.</ref>

Jenkins is an open source project that split from one of the earliest CI pipelines, Hudson, in 2010. As one of the longest running pipelines, it has been continuously extended, supporting many different languages, including C, C++, Java, and Python.

Bamboo<ref name="bamboo">(). Continuous Integration & Build Server - Bamboo https://www.atlassian.com/software/bamboo </ref>

Bamboo is proprietary build server. Built by the same company that made One of its unique feature is that is can expose the service on the cloud rather than having the developers push it themselves. It also professesses being able to be integrated with Jira, an issue tracking software.

ThoughtWorks Go<ref name="thought">(2014, September 18). Continuous Integration | ThoughtWorks [Online]. Available: http://www.thoughtworks.com/continuous-integration.</ref>

Thoughtworks Go highlights continuous integration as a key component of an expanded production mechanism that the creators Go envision as concept called Continuous Delivery. These CD platforms are extremely useful for managing code releases in large organizations. The service of helps promote lean and dynamic low-risk releases that streamline the ability to automate development and test that always ensures completely functional deployments.

Software is available on multiple development operating systems including Windows, Mac OS X, popular Linux distributions, Solaris, and Package OS.

Travis-ci<ref name="travis">(2014, September 17). Travis CI: Getting started [Online]. Available: http://docs.travis-ci.com/user/getting-started/.</ref>

Travis is a hosted and distributed continuous integration service. As it’s mainly suggested for closed projects, the service is integrated with GitHub to utilizes the version control framework for determining builds.

See Also

References to Continuous Integration

References to Specific Pipelines


References

<references/>

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2014/ch1a_16_av&oldid=88579"