Continuous Integration

The concept of CI was first coined on 1991 by Grady Booch (American software engineer, best known for the development of UML together with Ivar Jacobson and James Rumbaugh). The Extreme Programming (XP) methodology adopted this term, making it very popular. According to Martin Fowler, CI is defined as follows:

Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.

In CI systems, we can identify different parts. First, we need a source code repository, which is a file archive to host the source code of our software project, typically using a version control system. Nowadays, the preferred version control system is Git (originally developed by Linus Torvalds) over older solutions, such as CVS or SVN. At the moment of this writing, the leading version control repository is GitHub (https://github.com/), which as its name indicates it is based on Git. Besides, there are other alternatives, such as GitLab (https://gitlab.com), BitBucket (https://bitbucket.org/), or SourceForge (https://sourceforge.net/). The latter was the leading forge in the past, but is nowadays less used.

A copy of the source code repository is synchronized in the local environment of developers. The coding work is done against this local copy. Developers are supposed to commit new changes (known as patches) to the remote repository in a daily basis. Frequent commits allow to avoid conflict errors due to the mutual modification of the same parts of a given file.

The basic idea of CI is that every commit should execute the build and test the software with the new changes. For that reason, we need a server-side infrastructure which automates this process. This infrastructure is known as build server (or directly CI server). Two of the most important build servers nowadays are Jenkins and Travis CI. Details of both of them are provided in next subsections. As a result of the build process, the build server should notify the result of the process to the origin developer. If tests were successful, the patch is merged in the codebase:

Continuous Integration process

Close to CI, the term DevOps has gained momentum. DevOps comes from development and operations, and it is the name given to a software development process that emphasizes the communication and collaboration different teams in a project software: development (software engineering), QA (quality assurance), and operations (infrastructure). The term DevOps is also referred to a job position, typically in charge of the setup, monitoring an operation of the build servers:

DevOps are in between development, operations and QA

As shown in the next figure, the concept of CI can be extended to:

  • Continuous Delivery: When the CI pipeline finish correctly, at least a release of software will be deployed to a test environment (for instance, deploying an SNAPSHOT artifact to a Maven archiver). In this phase, acceptance tests can also be executed.
  • Continuous Deployment: As the final step in the automation toolchain, the release of the software can be released to a production environment (for example, deploying a web application to the production server for each commit, which achieves to pass the complete pipeline).
Continuous Integration, Continuous Delivery, and Continuous Deployment chain
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.149.29.71