Continuous integration: Difference between revisions

Revision as of 06:37, 1 June 2024

Revision as of 12:08, 1 June 2024

Line 85:

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 ===

=== Everyone commits to the baseline every day ===

By committing regularly, every committerDevelopers can reduce the numbereffort of resolving conflicting changes by synchronizing changes with each other frequently; at least daily. Checking in a week's worth of work runsrisks theconflict riskboth ofin conflictinglikelihood withof other featuresoccurrence and can be very difficultcomplexity to resolve. Early,Relatively small conflicts inare ansignificantly areaeasier ofto theresolve systemthan causelarger teamones. membersIntegrating to(committing) communicatechanges aboutat theleast changeonce theya areday makingis considered good practice, and more often better.<ref>{{cite book

Committing all changes "at least once a day" (once per feature built) is generally considered part of the definition of Continuous Integration.<ref>{{cite book

|title=Continuous Integration: Improving Software Quality and Reducing Risk

|author1=Paul M. Duvall

Line 97 ⟶ 96:

|date=2007

|url=https://www.amazon.com/Continuous-Integration-Improving-Software-Reducing/dp/0321336380

}}</ref>

</ref>

===Daily build===

In addition, performing a [[nightly build]] is generally

[[daily build|Building daily]], if not more often, is generally recommended.{{Citation needed|date =April 2012}}

These are lower bounds; the typical frequency is expected to be much higher.

=== Every commit should be built ===