--- title: "Build Bullet #1 - Use Version Aware Build Scripts" url: "https://osherove.com/blog/2012/11/17/build-bullet-1-use-version-aware-build-scripts.md" canonical: "https://osherove.com/blog/2012/11/17/build-bullet-1-use-version-aware-build-scripts.html" published: "2012-11-17T21:47:54" updated: "2012-11-17T21:47:54" tags: ["Build Bullet", "builds"] author: "Roy Osherove" description: "I am thinking of writing a small booklet about better builds . this blog post might end up as a part of it . Let me know if you’re interested by taking a look here. While I do love to use Continuous Integration Servers…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Build Bullet \#1 - Use Version Aware Build Scripts By Roy Osherove November 17, 2012 In [Build Bullet](https://osherove.com/blog/category/build-bullet) **Historical article** · Originally published November 17, 2012; technical details may be outdated. > I am thinking of writing a small [booklet about better builds](https://leanpub.com/build). this blog post might end up as a part of it[. Let me know if you’re interested by taking a look here.](https://leanpub.com/build) While I do love to use Continuous Integration Servers such as teamcity, Jenkins and more, I try to use them as much as possible as “dumb triggers” to my build actions. They do one thing and one thing only, and that is to trigger the correct build script with the correct resources (source version, artifacts form other builds, etc), and nothing more.  I don’t add any custom build actions such as compilation, source checking etc, because I believe that the build actions themselves have a very strong connection with the correct version of the source. For example, at an earlier version of the source you might need to compile a specific set of projects, and in future source versions, maybe new projects were added, some were removed, or renamed etc.  If you have your build scripts as part of your source control, and versioned along with the source, they will always match the current source version. zZhRk5owEMc/jY/tkICcPJ6ctH3oTGeuM31OJWKmkTgh3ul9+oKJSMxyJxptxxkkGwjZX3Y3fxiF6Wr7RZL18rvIKR/hIN+OwqcRxpMgqI+NYXdiKCTLtQkZw4bltLJMSgiu2No2zkVZ0rmybAvB7cHWpKCO4XlOuGv9xXK1NJPD8dH+lbJieXgMihPdU6ndYYycLsiGq097E9bd20D3hebynWmPk8PApTWBNyFWlkHSir3Zk1wwMwtD7reQOZWWibPyT5dSOBuFqRRC6bPVNqW8WZYDcn1b1tPbwpG0VOfcYJx/IXxjpp5+q9s/pJjTqnLAVa9sxUlZt6aFJDmrn5IKLrRLYZal+HHiTsHM6oVKRbenvtbhR8WKKrlrFsGsQWzomNA7NF+PCx5FxrbsLHZ0oEoM0qId+sigPjEYYCQhjGS6YXWk4iAV5YIVLpklWTenav83XTDOO2TSNJtkmUsGDyWDQpvM2CXTXtIlgwIPZCKHzBNhfOfA2UiimCg/YgREUBxPsRdOiY0JARHU2rxzGruc6JqL3b4u1oeftFKjJlQHBhUALEnqpEt9BBYaW8Ragl1iya2IxQ6xZ7GRc6rRKCmai1/Q52BgRUqjdAbF0+CKFH1YkMLgVgVp0g8nY5wCVdqEzZJuSVHnIYhmFjc/F008FM2DjSYC4gYDaCYeyKDArdWsk1bPc8nWqpdPKdQ7aQXFzWA4J3GDoHo9AejEPuggh85pvb4YUF+hvhYQDgFAD7cC5KofsFB7CSeoSl9Lq605HVoY2v590MJusjkoaJk/Sile9zTqotxXeCtdwLp6SxFZ0HZP0TaaW+8CLpar/HHTw4s/EeAPuoc/bjR78WcM+IPv4Y8rxGFRgBw3zxcFTuoBOPqz0ZZMY3RPVQCocd+y4AM4eoH+R10AKHD/uuA6Ov9SGABy+ybCwCuhuyoD/OASurky8IrrvtLAfUU5b+s52UAu2Yv0UnneepI7+QNoBZ2cfv0JL5VuQ/0BtJxes6v8qZvHL6L7vs4X63D2Fw== So what do those processes trigger? A script that is inside source control, tied directly to the current project\`s source committed version. It might be an xml file (ugh), or a rake file, or a finalbuilder script file (my favorite). Then it becomes easier to revert to an older build version to recreate it, or to test differences between versions, or to build multiple different branches of the same applications in parallel for different clients. See if you can take your current CI build, and have it run on a version of the source from 6 months ago. How many changes will that require of you to make it work? If your build is tied to source version, things should feel much simpler. ### Single Responsibility To me it is also about the single responsibility principle.  A Continuous Integration server should do one thing well – manage builds, their resources, and their scheduling.  It should not also need to worry about what is inside each build. In uncle bob’s [newspaper metaphor](http://www.markhneedham.com/blog/2008/09/15/clean-code-book-review/), the builds would be like different sub headings. Each does one thing, and the caller of those functions would only call them, without caring what they do. Thinking about it the other way around, if you have your whole build script running inside one large set of teamcity custom actions, all managed in the browser, and then you refactored that script to separate script files that are part of the source code, you’d be closer to what I am trying to do. So when I see companies boasting about how many custom tools their CI server can do, and how you can manage it all in the browser easily, I remind myself that the more I use those custom build features without the context of a current source version they are attached to, the more work I will have to do to change them every time I need to go back and forth between versions. ###  Version Aware Artifact Paths Following that line of thinking, I might argue that version aware build script “cubes” in source control should also be internally-deciding on what artifacts the encompassing CI process that is running them will be exposed to, and allowed to share with other builds. Today such things are managed solely at the CI tool level, but it would be good if the tools enabled artifact paths to be tied to the current version of the source. - [#builds](https://osherove.com/blog/tag/builds) ## More in Build Bullet [All posts in Build Bullet](https://osherove.com/blog/category/build-bullet) - Nov 18, 2012 ### [Build Bullet #3– Start Products with an Empty Build and Deploy Pipeline](https://osherove.com/blog/2012/11/18/build-bullet-3ndash-start-products-with-an-empty-build-and-d.html) - Nov 18, 2012 ### [Build Bullets #2–Avoid XML Facing Build Tools](https://osherove.com/blog/2012/11/18/build-bullets-2ndashavoid-xml-facing-build-tools.html) --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/