If you're using Jenkins , then you may have a job that has an "Execute Shell" step to build your project.
The contents of that step may look like:
bundle exec rspec
Or maybe just this:
bundle exec rake teaspoon
Or maybe a little bit of both:
bundle exec rake teaspoon bundle exec rspec
With a little bit of this:
bundle exec rake teaspoon bundle exec db:setup db:migrate bundle exec rspec
And a little bit of:
bundle exec rake teaspoon bundle exec db:setup db:migrate bundle exec rspec curl -X POST -T failures.json https://my.data.com/failures
Maybe it started with a one-liner, but then eventually grew to be a four-or-more-liner.
Instead of using that "Execute Shell" textbox to pile in everything that's relevant to your build, put all of those commands into one file (say,
ci/build ) and execute that file from the textbox. With this setup, you can check that script in to source control and get all the benefits that come with.
First, because this build script is in source control, all history that goes with it becomes available to you. If the need ever comes up, you can investigate how your project and build script evolved together. Whereas, if your "build script" is just a bunch of text in a box on some Jenkins configuration page, then you don't get any history with that. If someone makes an "improvement" to the build script and ends up breaking everything, you can very easily revert to what you had there previously if it's in source control.
Second, having your entire build process in source control means that the build process is specific to each commit in your repository. With every change to your code you also have the freedom to modify the build script to reflect those changes. What this means is that every developer has the freedom to try different build configurations (i.e. optimizations, experimenation) without affecting anyone else on the project.
Even if your build is very simple right now, and it doesn't do anything more than
bundle exec rspec or
mvn test , just go ahead and throw that into a
ci/build anyway and check that in. There will come a day when you want to change that just a little , and having it in source control will make things just a little simpler.
Taking this a little bit further, it would be ideal if we could throw all of our build details into a source-controlled file. If you're using classic Jenkins jobs then that's not really possible because you still have to manually click through the UI, create a job, and set up a bunch of things by hand.
This can get pretty tedious and cumbersome, and that's where the Pipeline plugin comes in. This plugin allows you to specify a lot more of your build configuration in a
Jenkinsfile , which is also source-controlled. It may not be trivial to migrate your existing traditional job to the pipeline, but it may certainly be worth the effort. Give it a shot!
There are a ton of CI solutions out there. I use Jenkins as an example here, but whatever you end up choosing make sure it allows you to source control your build configuration in some manner.
Happy Continuous Integration!
Dariusz Pasciak likes pizza and burgers, beaches and mountains, music and software.
- How TDD can make your team happier Chris Jordan
- Loosely Coupled Tests Chris Jordan
- The Cumulative Effect of Inefficient Workflows Aaron Lahey
- Test First Uncle Bob
- The Right Tests in the Wrong Order Mike Jansen
- The Frenzied Panic of Rushing Uncle Bob
- The Pragmatics of TDD Uncle Bob
- The Start-Up Trap Uncle Bob
- The Letter Uncle Bob
- Flipping the Bit Uncle Bob