Content deleted Content added
Tag: Reverted |
m Reverted edits by 45.70.53.159 (talk) (HG) (3.4.13) |
||
| (10 intermediate revisions by 8 users not shown) | |||
Line 6:
[[File:Continuous Integration.jpg|thumb|right|Sketch of [[flow diagram]] for continuous integration]]
'''
Typically, developers [[Merge (version control)|merge]] changes to an [[Branching (revision control)|integration branch]], and an automated system [[Software build|builds]] and [[software testing|tests]] the [[software system]].<ref name="martinfowler" />
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 ==
Line 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 60 ⟶ 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 70 ⟶ 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 128 ⟶ 124:
== Benefits ==
{{More citations needed section|date=May 2016}}
Line 152 ⟶ 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 ==
| |||