Content deleted Content added
Stevebroshar (talk | contribs) →See also: use annotated link |
m Reverted edits by 45.70.53.159 (talk) (HG) (3.4.13) |
||
| (19 intermediate revisions by 13 users not shown) | |||
Line 1:
{{short description|Software development practice of building and testing
{{more footnotes|date=July 2016}}
{{Use dmy dates|date=April 2022}}
Line 16:
{{expand section|date=August 2014}}
The earliest known work (1989) on continuous integration was the Infuse environment developed by G. E. Kaiser, D. E. Perry, and W. M. Schell.<ref>{{Cite conference |last1=Kaiser |first1=G. E. |last2=Perry |first2=D. E. |last3=Schell |first3=W. M. |year=1989 |title=Infuse: fusing integration test management with change management |conference=Proceedings of the Thirteenth Annual International Computer Software & Applications Conference |___location=Orlando, Florida |pages=552–558 |doi=10.1109/CMPSAC.1989.65147|citeseerx=10.1.1.101.3770 }}</ref>
In 1994, Grady Booch used the phrase continuous integration in ''Object-Oriented Analysis and Design with Applications'' (2nd edition)<ref>{{Cite book |last=Booch |first=Grady |url=http://www.cvauni.edu.vn/imgupload_dinhkem/file/pttkht/object-oriented-analysis-and-design-with-applications-2nd-edition.pdf |title=Object-Oriented Analysis and Design with applications |date=December 1998 |edition=2nd |access-date=2 December 2014 |archive-date=19 August 2019 |archive-url=https://web.archive.org/web/20190819035559/http://www.cvauni.edu.vn/imgupload_dinhkem/file/pttkht/object-oriented-analysis-and-design-with-applications-2nd-edition.pdf |url-status=dead }}</ref> to explain how, when developing using micro processes, "internal releases represent a sort of continuous integration of the system, and exist to force closure of the micro process".
Line 22:
In 1997, [[Kent Beck]] and [[Ron Jeffries]] invented [[extreme programming]] (XP) while on the [[Chrysler Comprehensive Compensation System]] project, including continuous integration.<ref name="martinfowler">{{Cite web |title=Continuous Integration |url=http://martinfowler.com/articles/continuousIntegration.html |last=Fowler |first=Martin |date=1 May 2006 |access-date=9 January 2014}}</ref>{{self-published source|date=May 2020}} Beck published about continuous integration in 1998, emphasising the importance of face-to-face communication over technological support.<ref>{{Cite conference |last=Beck |first=Kent |date=28 March 1998 |title=Extreme Programming: A Humanistic Discipline of Software Development |url=https://books.google.com/books?id=YBC5xD08NREC&q=%22Extreme+Programming%3A+A+Humanistic+Discipline+of+Software+Development%22&pg=PA4 |___location=Lisbon, Portugal |publisher=[[Springer Science+Business Media|Springer]] |volume=1 |pages=4 |isbn=9783540643036 |book-title=Fundamental Approaches to Software Engineering: First International Conference}}</ref> In 1999, Beck elaborated more in his first full book on Extreme Programming.<ref name="Beck, Extreme Programming Explained">{{Cite book |last=Beck |first=Kent |url=https://archive.org/details/extremeprogrammi00beck |title=Extreme Programming Explained |publisher=Addison-Wesley Professional |year=1999 |isbn=978-0-201-61641-5 |page=[https://archive.org/details/extremeprogrammi00beck/page/97 97] |ref=Beck, Extreme Programming Explained |author-link=Kent Beck |url-access=registration}}</ref> [[CruiseControl]], one of the first open-source CI tools,<ref>{{Cite news |date=1 February 2018 |title=A Brief History of DevOps, Part III: Automated Testing and Continuous Integration |work=CircleCI |url=https://circleci.com/blog/a-brief-history-of-devops-part-iii-automated-testing-and-continuous-integration/ |access-date=19 May 2018}}</ref>{{self-published source|date=May 2020}} was released in 2001.
In 2010, Timothy Fitz published an article detailing how [[IMVU]]'s engineering team had built and been using the first practical
== Practices ==
The core activities of CI are developers co-locate code changes in a shared, integration area frequently and that the resulting integrated codebase is verified for correctness. The first part generally involves merging changes to a common version control branch. The second part generally involves automated processes including: building, testing and many other processes.
== Related practices ==
Line 42 ⟶ 36:
=== Build automation ===
{{Main|Build automation}}▼
[[Build automation]] is a best practice.<ref name="Brauneis, [OSLC] Possible new Working Group - Automation">{{Cite mailing list |
Proponents of CI recommend that a single command should have the capability of building the system. ▼
Automation often includes automating the integration, which often includes [[software deployment|deployment]] into a production-like [[Deployment environment|environment]]. In many cases, the build script not only compiles binaries but also generates documentation, website pages, statistics and distribution media (such as Debian [[Deb (file format)|DEB]], Red Hat [[RPM Package Manager|RPM]] or Windows [[Microsoft Installer|MSI]] files).▼
=== Atomic commits ===
Line 66 ⟶ 65:
=== Continuous delivery and continuous deployment ===
{{See also|CI/CD}}
[[Continuous delivery]] ensures the software checked in on an integration branch is always in a state that can be deployed to users, and [[continuous deployment]] automates the deployment process.
''Continuous delivery'' and ''continuous deployment'' are often performed in conjunction with CI and together form a CI/CD pipeline.
=== Version control ===
Line 76:
Proponents of CI recommend storing all files and information needed for building in [[version control]], (for [[git]] a ''repository''); that the system should be buildable from a fresh checkout and not require additional dependencies.
[[Martin Fowler (software engineer)|Martin Fowler]] recommends that all developers commit to the same integration branch.<ref name="Fowler, Continuous Integration practices">{{Cite web |title=Practices |url=http://martinfowler.com/articles/continuousIntegration.html#PracticesOfContinuousIntegration |last=Fowler |first=Martin |author-link=Martin Fowler (software engineer) |website=Continuous Integration |type=article |access-date=29 November 2015}}</ref>
▲{{Main|Build automation}}
▲Proponents of CI recommend that a single command should have the capability of building the system.
▲Automation often includes automating the integration, which often includes [[software deployment|deployment]] into a production-like [[Deployment environment|environment]]. In many cases, the build script not only compiles binaries but also generates documentation, website pages, statistics and distribution media (such as Debian [[Deb (file format)|DEB]], Red Hat [[RPM Package Manager|RPM]] or Windows [[Microsoft Installer|MSI]] files).
=== Commit frequently ===
Line 97 ⟶ 87:
|publisher=[[Addison-Wesley Professional]]
|date=2007
}}</ref>
Line 135 ⟶ 124:
== Benefits ==
{{More citations needed section|date=May 2016}}
CI benefits include:
* Facilitates detecting [[software bug|bugs]] earlier
* Reduces effort to find cause of bugs; if a CI test fails then changes since last good build contain causing change; if build after each change then exactly one change is the cause<ref name="martinfowler" />
* Avoids the chaos of integrating many changes
* When a test fails or a bug is found, reverting the codebase to a good state results in fewer lost changes
Line 159 ⟶ 147:
* Implies that incomplete code should not be integrated which is counter to some developer's preferred practice<ref name=":1" />
* Safety and mission-critical development assurance (e.g., [[DO-178C]], [[ISO 26262]]) require documentation and review which may be difficult to achieve
== Best practices for cloud systems ==
The following practices can enhance productivity of [[CI/CD|pipelines]], especially in systems hosted in the [[Cloud computing|cloud]]: <ref>{{Cite book |title=Serverless Architectures on AWS |date=29 March 2022 |publisher=Manning |isbn=978-1617295423}}</ref><ref>{{Cite book |title=Pipeline as Code Continuous Delivery with Jenkins, Kubernetes, and Terraform |date=23 November 2021 |publisher=Manning |isbn=9781638350378}}</ref><ref>{{Cite book |title=Continuous Delivery Reliable Software Releases Through Build, Test, and Deployment Automation |isbn=9780321670229 |last1=Humble |first1=Jez |last2=Farley |first2=David |date=27 July 2010 |publisher=Pearson Education }}</ref>
* '''Number of Pipelines''': Small teams can be more productive by having one [[Repository (version control)|repository]] and one pipeline. In contrast, larger organizations may have separate repositories and pipelines for each team or even separate repositories and pipelines for each service within a team.
* '''Permissions''': In the context of [[CI/CD|pipeline-related]] permissions, adhering to the [[principle of least privilege]] can be challenging due to the dynamic nature of [[Software architecture|architecture]]. Administrators may opt for more permissive permissions while implementing compensating [[security controls]] to minimize the blast radius.
== See also ==
| |||