Continuous Integration (CI) System

A Continuous Integration (CI) System is an software integration system that can fascilitate continuous integration task (can perform frequent code builds and code tests).

• Context:
  • It can constantly monitor a Source Code Repository.
  • It can initiate a new Build Cycle when new changes/commits are detected.
  • It can (typically) be supported by a CI Platform, such as: Jenkins platform.
  • …
• Example(s):
  • a Cruise Control Continuous Integration System.
  • …
• See: Integrated Development Environment, Software Engineering, Continuous Integration, Computing Platform, Software License, Software Build, System Integration.

---

---

References

2022

• (Wikipedia, 2022) ⇒ https://en.wikipedia.org/wiki/Comparison_of_continuous_integration_software Retrieved:2022-1-17.
  • This is a compendium of continuous integration software that supports a software engineering practice, continuous integration, in which developers' changes are immediately tested and reported when they are added to the mainline code base. The comparison of various continuous integration tools is done on the basis of platform, license, builders and Integration IDEs.

2009

• (Fowler, 2009) ⇒ Martin Fowler. (2009). “Continuous Integration". http://martinfowler.com/articles/continuousIntegration.html#PracticesOfContinuousIntegration.

• (Kofman, 2009) ⇒ Vlad Kofman. (2009). “The Best Continuous Integration Tools." February 18, 2009
  • QUOTE: The term “continuous integration” refers to a process that builds and tests code on a frequent basis. It was coined by Martin Fowler and Kent Beck, who first wrote about this process near the turn of the millennium.

    The continuous integration servers constantly monitor source code repositories and as soon as new changes/commits are detected, they initiate a new build cycle. The build cycle actually involves code compilation and, in addition, may involve various tests and code analysis. If the process encounters errors, it may notify the build master or the culprit who checked in broken/invalid code.

    The process can be summarized in these four steps:

    • Team members check in code artifacts into the source control repository.
    • The automated build server constantly monitors the repository.
    • New code is continuously checked out [by this server].
    • A new project build is continuously integrated and any issues are reported in real time.

---