{"id":5003155,"date":"2015-12-16T21:42:37","date_gmt":"2015-12-17T05:42:37","guid":{"rendered":"https:\/\/aadev22.local\/?post_type=aa_glossary&#038;p=5003155"},"modified":"2023-03-12T12:41:02","modified_gmt":"2023-03-12T19:41:02","slug":"continuous-integration","status":"publish","type":"aa_glossary","link":"https:\/\/agilealliance.org\/glossary\/continuous-integration\/","title":{"rendered":"Continuous Integration"},"content":{"rendered":"<div>\n<div>\n<p>Teams practicing continuous\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/integration\/\">integration<\/a>\u00a0seek two objectives:<\/p>\n<ul>\n<li>minimize the duration and effort required by each integration episode<\/li>\n<li>be able to deliver a product version suitable for release\u00a0at any moment<\/li>\n<\/ul>\n<p>In practice, this dual objective requires an integration procedure that is reproducible at the very least, and largely automated. This is achieved through <a href=\"https:\/\/agilealliance.org\/glossary\/version-control\/\">version control<\/a> tools, team policies and conventions, and tools specifically designed to help achieve continuous integration.<\/p>\n<\/div>\n<\/div>\n<h2>Common Pitfalls<\/h2>\n<div>\n<div>\n<ul>\n<li>As suggested above, the practice of continuous integration should not be confused with the tools that assist it (CI servers such as Cruise Control, Hudson, etc.). Continuous integration is first and foremost a matter of attitude rather than tools, and it relies on more than one kind of tool: tools for testing, tools for automating build processes, and tools for version control.<\/li>\n<li>Continuous integration aims to lessen the pain of integration by increasing its frequency. Therefore, \u201cany\u201d effort related to producing intermediate releases, and which the team experiences as particularly burdensome, is a candidate for inclusion in the team\u2019s continuous integration process. (This is the reasoning that leads teams to\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/continuous-deployment\/\">continuous deployment<\/a>.)<\/li>\n<\/ul>\n<\/div>\n<\/div>\n<h2>Origins<\/h2>\n<div>\n<div>\n<ul>\n<li>1993: the phrase \u201ccontinuous integration\u201d is already in use and thus predates what will later be known as Agile processes, for instance, an article contrasts it with \u201cscheduled\u201d integration, and recommends the latter, citing \u201clack of thorough testing\u201d as one issue with continuous integration; this helps explain why the automated testing favored by Agile teams is an enabler for continuous integration<\/li>\n<li>1996: Steve McConnell\u00a0<a href=\"http:\/\/www.stevemcconnell.com\/ieeesoftware\/bp04.htm\" target=\"_blank\" rel=\"noopener noreferrer\">describes<\/a> the \u201cDaily Build and Smoke Test\u201d technique, used at Microsoft for Windows NT 3.0 during the 1990s; the emphasis is not so much on the automation as on the frequency, the daily cycle being at that time considered \u201cextreme\u201d<\/li>\n<li>1998: continuous integration is listed among the core practices of Extreme Programming<\/li>\n<li>2000: an article by Martin Fowler provides perhaps the\u00a0<a href=\"http:\/\/www.martinfowler.com\/articles\/originalContinuousIntegration.html\" target=\"_blank\" rel=\"noopener noreferrer\">most complete description<\/a>\u00a0of the continuous integration practice available at that time<\/li>\n<li>2001:\u00a0<a href=\"http:\/\/cruisecontrol.sourceforge.net\/\" target=\"_blank\" rel=\"noopener noreferrer\">Cruise Control<\/a>, the first \u201ccontinuous integration server\u201d, is published under an open source license; it automates the monitoring of the source code repository, triggering the build and test process, notifications of the results to the developers, and archival of the test reports; the period 2001-2007 sees a large number of similar tools appear, leading perhaps to an excessive focus on tools over practice<\/li>\n<li>2004: an\u00a0<a href=\"http:\/\/www.developertesting.com\/archives\/month200404\/20040401-eXtremeFeedbackForSoftwareDevelopment.html\" target=\"_blank\" rel=\"noopener noreferrer\">article<\/a>\u00a0by Alberto Savoia proposes \u201cExtreme Feedback Devices\u201d such as lava lamps or dedicated monitors, to display the results of the most recent integration, an important innovation in CI<\/li>\n<\/ul>\n<\/div>\n<\/div>\n<h2>Signs of Use<\/h2>\n<div>\n<div>\n<p>For most teams, continuous integration in practice amounts to the following:<\/p>\n<ul>\n<li>use of a version control tool (CVS, SVN, Git, etc.)<\/li>\n<li>an\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/automated-build\/\">automated build<\/a>\u00a0and product release process<\/li>\n<li>instrumentation of the build process to trigger\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/unit-test\/\">unit<\/a>\u00a0and\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/acceptance\/\">acceptance<\/a>\u00a0tests \u201cevery time any change is published to version control\u201d<\/li>\n<li>in the event of even a single test failing, alerting the team of a \u201cbroken build\u201d so that the team can reach a stable, releasable baseline again soonest<\/li>\n<li>optionally, the use of a tool such as a continuous integration server, which automates the process of integration, testing, and reporting of test results<\/li>\n<\/ul>\n<p>Look for a dedicated display in a prominent spot of the\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/team-room\/\">team room<\/a>: this can be a normal monitor, an LED display, or even a lava lamp, with the sole purpose of reporting on the result of the most recent integration.<\/p>\n<p>Observe also how the team responds to a broken build, suggesting that a defect may have been detected. If the team is aware of defects, but tolerates them or continues working on a product that isn\u2019t in a releasable state, the term continuous integration no longer applies, irrespective of tooling!<\/p>\n<\/div>\n<\/div>\n<h2>Further Reading<\/h2>\n<div>\n<div>\n<ul>\n<li><a href=\"http:\/\/www.martinfowler.com\/articles\/continuousIntegration.html\">Continuous Integration<\/a>, Martin Fowler (2006)<\/li>\n<\/ul>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>Continuous Integration is the practice of merging code changes into a shared repository several times a day in order to release a product version at any moment. This requires an integration procedure which is reproducible and automated.<\/p>\n","protected":false},"author":6000331,"featured_media":8067461,"parent":0,"menu_order":0,"comment_status":"open","ping_status":"closed","template":"","categories":[906],"tags":[838],"class_list":["post-5003155","aa_glossary","type-aa_glossary","status-publish","has-post-thumbnail","hentry","category-technology","tag-version-control"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_glossary\/5003155","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_glossary"}],"about":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/types\/aa_glossary"}],"author":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/users\/6000331"}],"replies":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/comments?post=5003155"}],"version-history":[{"count":0,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_glossary\/5003155\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/media\/8067461"}],"wp:attachment":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/media?parent=5003155"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/categories?post=5003155"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/tags?post=5003155"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}