Continuous integration (CI) is the practice, in software engineering, of merging all developer working copies with a shared mainline several times a day. It was first named and proposed by Grady Booch in his 1991 method,[1] although practices at this time did not yet support full automation, or the performance of integrations more than a few times a day. It was adopted as part of extreme programming (XP), which did advocate integrating more than once per day, perhaps as many as tens of times per day. The main aim of CI is to prevent integration problems, referred to as "integration hell" in early descriptions of XP. CI isn't universally accepted as an improvement over frequent integration, so it is important to distinguish between the two as there is disagreement about the virtues of each.[citation needed]
CI was originally intended to be used in combination with automated unit tests written through the practices of test-driven development. Initially this was conceived of as running all unit tests in the developer's local environment and verifying they all passed before committing to the mainline. This helps avoid one developer's work-in-progress breaking another developer's copy. If necessary, partially complete features can be disabled before committing using feature toggles.
Later elaborations of the concept introduced build servers, which automatically ran the unit tests periodically or even after every commit and report the results to the developers. The use of build servers (not necessarily running unit tests) had already been practised by some teams outside the XP community. Nowadays, many organisations have adopted CI without adopting all of XP.
In addition to automated unit tests, organisations using CI typically use a build server to implement continuous processes of applying quality control in general — small pieces of effort, applied frequently. In addition to running the unit and integration tests, such processes run additional static and dynamic tests, measure and profile performance, extract and format documentation from the source code and facilitate manual QA processes. This continuous application of quality control aims to improve the quality of software, and to reduce the time taken to deliver it, by replacing the traditional practice of applying quality control after completing all development. This is very similar to the original idea of integrating more frequently to make integration easier, only applied to QA processes.
In the same vein, the practice of continuous delivery further extends CI by making sure the software checked in on the mainline is always in a state that can be deployed to users and makes the actual deployment process very rapid.
Continuous integration (CI) is a software engineering practice in which isolated changes are immediately tested and reported on when they are added to a larger code base. The goal of CI is to provide rapid feedback so that if a defect is introduced into the code base, it can be identified and corrected as soon as possible.
Continuous integration (CI) is a software engineering practice in which isolated changes are immediately tested and reported on when they are added to a larger code base. The goal of CI is to provide rapid feedback so that if a defect is introduced into the code base, it can be identified and corrected as soon as possible. Continuous integration software tools can be used to automate the testing and build a document trail.
Continuous integration has evolved since its conception. Originally, a daily build was the standard. Now, the usual rule is for each team member to submit work on a daily (or more frequent) basis and for a build to be conducted with each significant change. When used properly, continuous integration provides various benefits, such as constant feedback on the status of the software. Because CI detects deficiencies early on in development, defects are typically smaller, less complex and easier to resolve.
According to Paul Duvall, co-author of Continuous Integration: Improving Software Quality and Reducing Risk, best practices of CI include:
- Committing code frequently.
- Categorizing developer tests.
- Using a dedicated integration build machine.
- Using continuous feedback mechanisms.
- Staging builds.
ist of build automation software
From Wikipedia, the free encyclopedia
Build automation involves scripting or automating the process of compiling computer source code into binary code. Below is a list of notable tools associated with automating build processes.
Contents
[hide]Make-based tools[edit]
- distcc
- GNU make, a widely used make implementation with a large set of extensions
- make, a classic Unix build tool
- mk, developed originally for Version 10 Unix and Plan 9, and ported to Unix as part of plan9port
- MPW Make, developed for Mac OS Classic and similar to but not compatible with Unix make; OS X comes with both GNU make and BSD make; available as part of Macintosh Programmer's Workshop as a free, unsupported download from Apple
- nmake
- PVCS-make, basically follows the concept of make but with a noticeable set of unique syntax features[1]
- Rake, a Ruby-based build tool
- ElectricMake, a replacement for make and gmake that implements build parallelization with ElectricAccelerator. Produced by Electric Cloud Inc.
Non-Make-based tools[edit]
- Apache Ant, popular for Java platform development and uses an XML file format
- Apache Buildr, open-source build system, Rake-based, gives full power of scripting in Ruby with integral support for most abilities wanted in a build system
- Apache Maven, a Java platform tool for project management and automated software build
- A-A-P, a Python based build tool
- Boost.Build from Boost C++ libraries
- BitBake, a Python-based tool with the special focus of distributions and packages for embedded Linux cross compilation
- Cabal, common architecture for building applications and libraries in the programming language Haskell
- FinalBuilder, for Windows software developers. FinalBuilder provides a graphical IDE to both create and run your build projects in a single application. Final builder also includes the ability the execute unit test, deploy web projects or install and test your application.
- Flowtracer
- Gradle, an open-source build and automation system with a Groovy Rake domain specific language (DSL), combining the advantages of Ant and Apache Maven with additional features like a reliable incremental build
- Grunt (http://gruntjs.com/), an open-source JavaScript-based build automation framework, which runs on Node.js
- Gulp (http://gulpjs.com/), an open-source JavaScript-based streaming build system, which runs on Node.js
- Leiningen, a tool providing commonly performed tasks in Clojure projects, including build automation
- MSBuild, the Microsoft build engine
- NAnt, a tool similar to Ant for the .NET Framework
- Ninja, created in 2010 as a Make replacement to speedup Google Chrome compilation[2] (can be used by CMake and GYP)
- Perforce Jam, a generally enhanced, ground-up tool which is similar to Make
- Psake, domain-specific language and build automation tool written in PowerShell
- sbt (Simple Build Tool), a build tool built on a Scala-based DSL
- SCons, Python-based, with integrated functionality similar to autoconf/automake
- Tup, Lua based, make-like DSL with a pure focus on speed and scalability
- Tweaker, allowing task definitions to be written in any languages (or intermixed languages) while providing a consistent interface for them all
- Visual Build, a graphical user interface software for software builds
- Waf is a Python-based tool for configuring, compiling and installing applications. It is a replacement for other tools such as Autotools, Scons, CMake or Ant
- Pants is a multi language supporting build tool (Java, Python, Scala) that is primarily aimed at a multiple project with interdependencies development environment. This system is in very early (beta?) release as of September 2014.
- TinyBuilder, a distributed build system designed to provide consistent build results.
Build script generation tools[edit]
- configure
- CMake, a cross-platform tool that generates files for the native build environment, such as makefiles for Unix or Workspace files for Visual Studio
- GNU build system (aka autotools), a collection of tools for portable builds. These in particular include Autoconf and Automake, cross-platform tools that together generate appropriate localized makefiles.
- GYP (Generate Your Projects) - Created for Chromium; it is another tool that generates files for the native build environment
- imake
- Premake, a Lua based tool for making makefiles, Visual Studio files, Xcode projects, and more
- qmake
Continuous integration tools[edit]
- AnthillPro, build automation with pipeline support for deployment automation and testing. Cross-platform, cross-language
- Bamboo, continuous integration software
- Automated BuildStudio, a system for automating and managing software build, test and deploy processes, with build scheduling and continuous integration support
- Apache Continuum
- Buildbot, a Python-based software development continuous integration tool which automates the compile/test cycle
- BuildIT, a free graphical build or task tool for Windows with an emphasis on simplicity and ease of use
- Buildout, a Python-based build system for creating, assembling and deploying applications from multiple parts
- CABIE Continuous Automated Build and Integration Environment, open source, written in Perl
- Cascade, a continuous integration tool that builds and tests software components after each change is committed to the repository. Also provides a "checkpointing" facility by which changes can be built and tested before they are committed
- CruiseControl, for Java and .NET
- DeployBot, a hosted continous integration service
- Hudson, an extensible continuous integration engine
- Jenkins, an extensible continuous integration engine, forked from Hudson
- Team Foundation Server, an extensible continuous integration engine from Microsoft
- TeamCity
- Travis CI, a hosted continuous integration service
