Life on the cutting edge can be treacherous. At any moment, your web browser may dramatically update its user interface. Your e-reader might take your books away. Your favorite snack cake could disappear from store shelves. For many, the uncertainty of this lifestyle just isn’t worth it.
Fortunately, when it comes to Node.js development, you can have your fluffy creme-filled pastry and eat it, too.
In this post, I’ll discuss how you can use your own project and a continuous integration setup to keep an eye on the development of your programming platform. The basic principles apply to any CI solution and any open platform, but in order to keep things grounded, I’ll focus on Node.js projects and Travis CI. This practice won’t replace more active involvement, but it will help you monitor how upcoming changes affect your project.
Many thanks to Henrik Hodne from Travis CI for discussing this functionality and lightning-quick support. Excellent service like that make it easy to forget Travis CI helps open source projects free-of-charge.
It Pays to be Proactive
Each stable release offers new features and bug fixes. For example, here’s a listing of the changes under development in version 0.11 of Node.js. While it’s always possible to experiment with an unstable release, many developers are (understandably) reluctant to use unstable code in production environments. When the next stable version of Node.js is released, many people are going to want to use it as soon as possible. Without proper preparation, you may find yourself under the gun to update your library on release day.
Remember that contributors to Node.js core make mistakes, too. It’s always possible that some upcoming change has an unintentional side effect which breaks your project. Referred to as “regressions,” these bugs only get more difficult to fix as time goes on. By reporting them early, you not only save yourself the headache on release day, but you also spare the project maintainers much of the time and energy they would have to spend debugging and hot-fixing later on.
Some problems may originate from another library that your project depends on. In fact (depending on how many dependencies your project has), you may find most problems outside of your control. This does not make the information any less useful because no matter where the platform issues originate, they will still block your adoption on release day. By alerting module owners early, you prepare your own project and increase awareness in the package ecosystem at large.
Sign Me Up!
Travis CI offers free continuous integration services to any open source project. They will run your project’s tests whenever anyone makes a change (or proposes a change). They issue a report on the result of the tests to aid the review process; a failure report is a red flag for any proposal.
Many Node.js developers are well aware of this and have been enjoying the service for over two years now. Some lesser-known options allow you to schedule additional jobs where failures are considered acceptable. If you use these options to run your project’s tests in the unstable version of Node.js, the generated report will describe any upcoming problems (providing you the awareness you wanted) without labeling the build a “failure” (allowing you to judge changes based on stable environments).
These settings, just like all Travis CI configuration, should be set in the
.travis.yml file in the root of your project. Here’s an example for how you
might update your Node.js project:
language: node_js
node_js:
- 0.6
- 0.8
- "0.10"
+ - 0.11
+matrix:
+ fast_finish: true
+ allow_failures:
+ - node_js: 0.11
(For a detailed description of these options, refer to the official documentation on build configuration.) In this example report for Cheerio, the “error” status of the job for Node.js v0.11 has not effected the entire build:
It bears mentioning that these builds aren’t magic; they require real CPU time and real electricity. From the above docs:
Please take into account that Travis CI is an open source service and we rely on worker boxes provided by the community. So please only specify an as big matrix as you actually need.
Rest assured: I’ve talked this over with Henrik at Travis CI, and they consider this to be a valid use case. Indeed, it’s something they have actively promoted for Ruby developers in the past.
I’ve already implemented this recommendation in a few of my favorite projects. This experience has helped me craft a succinct commit message that describes the change and the motivation; you can use it for your project, too:
Run CI with unstable Node.js as an allowed failure
Building against the latest unstable release of Node.js will help the project maintain awareness of any regressions or breaking changes in the platform. Specifying that build as an allowed failure guarantees that unforeseen errors do not block ongoing work.
…and if you wanted to link back to this blog post in your pull request, well, that’d be just fine by me.
Safe and Sound
Like all our favorite technologies, the Node.js project operates completely in public. Every change to the platform is made in a public setting, and anyone can review and provide feedback long before it is made official.
However, it’s one thing to laud the openness of a process and another thing to participate. Between mailing lists, bug trackers, IRC rooms, and blog posts, just staying abreast of a project can be an onerous proposition. The open web abounds with projects like this, so you have to pick your battles.
This technique can automate your exposure to the development of open platforms. To be sure, nothing will replace the contribution you make through active participation. Think of the steps outlined here as a sort of baseline for good citizenship. It’s also a rare opportunity to live on the edge without fear of getting cut.
