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:
script
├── bootstrap
├── console
├── cibuild
├── release
├── server
└── test
bootstrap
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.
console
A script to load the current application into a console session - often use for debugging without a browser.
cibuild
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.
release
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.
server
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.
test
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.