Continuous integration: Difference between revisions

Revision as of 00:11, 8 May 2024

Revision as of 04:59, 1 June 2024

Line 87:

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

By committing regularly, every committer can reduce the number of conflicting changes. Checking in a week's worth of work runs the risk of conflicting with other features and can be very difficult to resolve. Early, small conflicts in an area of the system cause team members to communicate about the change they are making.<ref name=":0">{{Cite web |title=Continuous Integration |url=https://www.thoughtworks.com/continuous-integration |website=Thoughtworks}}</ref> Committing all changes at least once a day (once per feature built) is generally considered part of the definition of Continuous Integration. In addition, performing a [[nightly build]] is generally recommended.{{Citation needed|date =April 2012}} These are lower bounds; the typical frequency is expected to be much higher.

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

|author2=Steve Matyas

|author3=[[Andrew Glover]]

|isbn=978-0-321-33638-5

|publisher=[[Addison-Wesley Professional]]

|date=2007

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

}}

</ref>

In addition, performing a [[nightly build]] 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 ===