--- title: "Pattern: Script Injection" url: "https://pipelinedriven.org/article/2014/3/2/pattern-script-injection.md" canonical: "https://pipelinedriven.org/article/2014/3/2/pattern-script-injection" published: "2014-03-02T21:22:42.865000+00:00" updated: "2014-03-02T21:22:58.673000+00:00" tags: [] author: "Roy Osherove" description: "I am slowly realizing that perhaps my concepts for the build book could be better serving as reusable patterns for creating builds, solving specific…" 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/" --- # Pattern: Script Injection 2 March 2014 · 2 min read · Roy Osherove I am slowly realizing that perhaps my concepts for [the build book](http://beautifulbuilds.com/) could be better serving as reusable patterns for creating builds, solving specific problems. This is a test to see how well this idea holds up in reality. If you like it, and especially if you do NOT like it, please let me know in the comments why, and how you would change it. I think this is a topic that can be of great use to many people. If we frame it right, it can be more easily distributed and understood. I am not even sure if the sections below are what I would “need” for a pattern of sorts. ## Pattern: Script Injection ## Problem: You have a continuous integration process running nicely, but sometimes you need to be able to build older versions of your product. Unfortunately, in older versions of your product in source control, the structure of files is different than the one that your build actions are set up to use. For example, a set of directories that exists in the latest version in source control, and is used in deployment, does not exist in the source control version from 3 months ago. So your build fails because it expects certain files or directories to be there, which did not exist in that source control version. ## Forces: You want the set of automated actions in your build to match exactly the current version and structure of your product files in source control. ## Solution: Separate your build script actions into two parts: - The CI side script, which lives in the continuous integration system. - The source control side script. ## Source control side script one or more script files that are inside the file structure of your product in source control. These scripts change based on the current product version. It is important that this is the same branch that is used within the CI system to build the product, so that the CI side scripts have access to the source control side scripts. Developers should have full access to the source control side scripts. Source Control side scripts contain the knowledge about the current structure of the files, and which actions are relevant for the current product version. So they get to be changed with every product version. They will usually use relative path because they will be executed by CI side scripts on a remote build server. ## CI Side Scripts/Actions These actions act as very simple “dumb” agents. They get the latest version of the source control scripts (and possibly all other product files if needed), and trigger the build scripts as a command line action. ## Summary By separating the version aware knowledge to a script inside source control, and triggering it via a CI side script that contains only parameters and other “context” data to invoke the source control scripts correctly, we “inject” the version aware knowledge of what the build script should do, into a higher level CI process trigger, that does not care about product file structure, but still gives us the advantages with had before with a CI process. **Thoughts? Comments? Does this make sense to you? is it the stupidest thing ever?** Does the fact that [I now wear glasses](https://twitter.com/RoyOsherove/status/285360033015947264/photo/1) help in any way? --- ## 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/