{"id":5003369,"date":"2015-12-17T00:28:34","date_gmt":"2015-12-17T08:28:34","guid":{"rendered":"https:\/\/aadev22.local\/?post_type=aa_glossary&#038;p=5003369"},"modified":"2023-03-12T12:41:01","modified_gmt":"2023-03-12T19:41:01","slug":"automated-build","status":"publish","type":"aa_glossary","link":"https:\/\/agilealliance.org\/glossary\/automated-build\/","title":{"rendered":"Automated Build"},"content":{"rendered":"<div>\n<div>\n<p>In the context of software development,\u00a0build refers to the\u00a0process that converts\u00a0files and other assets under the developers\u2019 responsibility into a software product in its final or consumable form. The build\u00a0may include:<\/p>\n<ul>\n<li>compiling source files<\/li>\n<li>packaging compiled\u00a0files into compressed formats (such as jar, zip)<\/li>\n<li>producing installers<\/li>\n<li>creating or updating of database schema or data<\/li>\n<\/ul>\n<p>The build is automated when\u00a0these steps are repeatable, require no direct human intervention, and can be performed at any time with no information other than what is stored in the source code control repository.<\/p>\n<\/div>\n<\/div>\n<h2>Expected Benefits<\/h2>\n<div>\n<div>\n<p>Build automation is a prerequisite to the effective use of <a href=\"https:\/\/agilealliance.org\/glossary\/continuous-integration\/\">continuous integration<\/a>. However, it brings benefits of its own:<\/p>\n<ul>\n<li>eliminating a source of variation, and thus of defects; a manual build process containing a large number of necessary steps offers as many opportunities to make mistakes<\/li>\n<li>requiring thorough documentation of assumptions about the target environment, and of dependencies on third-party products<\/li>\n<\/ul>\n<\/div>\n<\/div>\n<h2>Common Pitfalls<\/h2>\n<div>\n<div>\n<ul>\n<li>the practice of build automation should not be confused with continuous integration: the latter consists of \u201cexecuting\u201d the build process as frequently as possible (ideally whenever a code change is checked into the source code control repository) and \u201cverifying\u201d the correctness of the resulting product, in particular by\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/unit-test\/\">unit tests<\/a><\/li>\n<li>in particular, continuous integration tools (CruiseControl, Hudson, etc.) are a category distinct from build automation tools (make, Ant, Maven, rake, etc.)<\/li>\n<li>being able to trigger some build operations from within a development environment (IDE) is usually not sufficient: as it is often the case that some build operations are not supported within the IDE, it must be possible to perform a build outside of the IDE<\/li>\n<li>the duration of a build process should be under ten minutes, including the execution of automated tests; beyond this order of magnitude it will generally be difficult for the team to achieve continuous integration<\/li>\n<\/ul>\n<\/div>\n<\/div>\n<h2>Origins<\/h2>\n<div>\n<div>\n<ul>\n<li>1977: creation of the \u201cmake\u201d tool for Unix systems \u2013 the principle of automating software builds is not a new idea<\/li>\n<li>1990s: owing to the rise in popularity of RAD tools and IDEs, \u201cmake\u201d type tools acquire a mixed reputation<\/li>\n<li>2000s: even though the practice is far from new, nor limited to Agile teams, it is partly due to Agile practices that a revival of \u201cmake\u201d type build automation takes place<\/li>\n<\/ul>\n<\/div>\n<\/div>\n<h2>Signs of Use<\/h2>\n<div>\n<div>\n<p>The best way to ascertain whether a team practices build automation is a surprise test: ask the team to provide an installable version of the product. Measure how much time is necessary to obtain a release, then attempt to install or deploy to an off-the-shelf PC or environment \u2013 one which has not been previously set up by the development team. Any \u201csurprise\u201d during this process will suggest ways to improve the automated build process.<\/p>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>In the context of software development, build refers to the process that converts files and other assets under the developers&#8217; responsibility into a software product in its final or consumable form. The build is automated when these steps are repeatable, require no direct human intervention, and can be performed at any time with no information other than what is stored in the source code control repository.<\/p>\n","protected":false},"author":6000331,"featured_media":8067461,"parent":0,"menu_order":0,"comment_status":"open","ping_status":"closed","template":"","categories":[906],"tags":[],"class_list":["post-5003369","aa_glossary","type-aa_glossary","status-publish","has-post-thumbnail","hentry","category-technology"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_glossary\/5003369","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=5003369"}],"version-history":[{"count":0,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_glossary\/5003369\/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=5003369"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/categories?post=5003369"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/tags?post=5003369"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}