--- title: "Build Pattern: Shipping Skeleton" url: "https://osherove.com/blog/2013/1/7/build-pattern-shipping-skeleton.md" canonical: "https://osherove.com/blog/2013/1/7/build-pattern-shipping-skeleton.html" published: "2013-01-07T21:31:09" updated: "2013-01-07T21:31:09" tags: ["Build Bullet"] 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 problems. Pattern: Shipping Skeleton other names: “Hello World”,…" 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 Pattern: Shipping Skeleton By Roy Osherove January 7, 2013 In [Build Bullet](https://osherove.com/blog/category/build-bullet) **Historical article** · Originally published January 7, 2013; technical details may be outdated. 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. ## Pattern: Shipping Skeleton other names: “Hello World”, Walking Skeleton ([based on XP](http://alistair.cockburn.us/Walking+skeleton)), Tracer Bullet Build, ## Problem: Remember when you had a working product, but you could not ship it, or shipping and deploying it took a long time, or could not be estimated?. By that time, however, your product was too big and your free time was too short to start creating a working automated build and deploy process. As time went on, shipping became even more and more of a nightmarish manual task, and automating it became more and more of a problem. Now you're at the start of a new project, and you want to avoid all that pain in your new project. ## Forces: You want to avoid the pain of automating the build and deploy cycle. But you also don’t want to spend too much time working on it. ## Solution: Before starting development on the new product, **start with a shipping skeleton --** An empty solution with nothing but a “hello world” output, that has the basic automated build and deploy cycle working. You should be able to ship this empty hello world project with the click of a button, in a matter of minutes. once the shipping skeleton is in place, you can start filling out the product with features, and growing the build scripts in small increments alongside the product. Basic Shipping Skeleton: 1) A Build script (in source control) for compiling the current source 2) A Continuous Integration Server that has a “CI” build configuration, triggered by code check-in, that invokes build script from the previous bullet (also see [Build Script injection](https://osherove.com/blog/2012/12/30/build-patterns-script-injection.html) for more on this pattern) 3) Another build configuration on the CI server for “**Deploy**”. This can be either deploy to test, or deploy to production. Usually you want at least a “deploy to test” succeeding before having a “deploy to production” CI build Configuration. This “Deploy to test” gets invoked automatically upon “CI” configuration passing. Later on, as the build process matures, you can change this, but for now, knowing that the product is deployable as soon as possible, while it changes so much, is important for quick feedback cycles. 4) If there isn’t a “Deploy to production”, create it. This deploys the product to a production machine. If it is a web site, it deploys the website to a web server. if it is an installer, it deploys and runs the installer on a machine that will act as a “production” machine. either mimicking a user machine, or or an enterprise machine where the product will be installed. for web servers, make them as real as possible, all the way, even by making them public (although possibly password protected). This gives you the chance to make the web server become real production by the switch of a dns setting. ## Summary By starting with a shipping skeleton, you give yourself several benefits: - You can ship at will - Adding features to the build and deploy cycle is a continuous action that takes a few minutes each day, if at all. - You can receive very quick feedback on features or mockup-features you are building into your product. **Thoughts? Comments? Does this make sense to you? is it the stupidest thing ever?** ## More in Build Bullet [All posts in Build Bullet](https://osherove.com/blog/category/build-bullet) - Jan 19, 2013 ### [Build Pattern: Fill In the Blanks](https://osherove.com/blog/2013/1/19/build-pattern-fill-in-the-blanks.html) - Jan 19, 2013 ### [Build Pattern: Location Agnostic Script](https://osherove.com/blog/2013/1/19/build-pattern-location-agnostic-script.html) - Dec 6, 2012 ### [Build Bullet #5– How to make your builds FAST using DRY and SRP Principles](https://osherove.com/blog/2012/12/6/build-bullet-5ndash-how-to-make-your-builds-fast-using-dry-a.html) - Nov 27, 2012 ### [Build Bullet #4: Rolling Builds and the Plane of Confidence](https://osherove.com/blog/2012/11/27/build-bullet-4-rolling-builds-and-the-plane-of-confidence.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/