Bootstrapping your projects

10 Jan 2014

Bootstrapping a project is a concept that I first seen derived from Ruby on Rails script/server and I was instantly hooked. Fortunately, this concept was beginning to catch on and many open source projects were getting on board with it.

The process of having a single point of contact for everything I needed to do in a project (outside of the actual development of course) was amazeballs. No longer would I need to worry about which environment dependencies I had to use to include for a project or whether I needed have another service running to make it function, it was already done by the maintainers and would only require me to run a single script regardless of the task at hand. This concept was applied to a range of functionality and helped new comers to the project get up and contributing much faster.

Here is an example of a typical script directory looks like:

├── bootstrap
├── console
├── cibuild
├── release
├── server
└── test


A series of tasks or dependency management steps that will run to enable a developer to start working on the project. This includes all required gems, environment variables and local services setup.


A script to load the current application into a console session - often use for debugging without a browser.


The file that will setup the prerequisites for the CI server. Has very similar tasks to the script/bootstrap script often using mock or test information instead.


Tasks that determine how you will build and create a new release of the project. This isn’t used for individual commits for a feature branch, mostly for the project maintainers when a new version of the application is ready.


If your application is web based, you will need a something to serve it and this task would start it. Saves the developer fiddling with their own version of a web server.


A wrapping file for your test suite. Depending on your test suite, there are a number of ways to invoke it and if developer miss a flag or a certain syntax that your suite requires they may not be able to successfully run the test suite and not submit that code patch - leaving a sad developer.

Even though the example above is based on a Ruby workflow, it could just as easily be implemented for any other language. The required files and tasks may be slightly different however the underlying concept will remain the same and hopefully ease that learning curve of a new project.