Today I want to let you know that we’re currently working very hard towards the 1.0 release, which’ll be out Soon&tm;. While that’s coming, I thought I’d write a blog post to let you know what
makes Spree just so great to use for your e-commerce platform.
Our helpful community
With Spree being built on Ruby on Rails, the syntax and organization of the project is exceptionally clean. To compliment this exceptional design, we have freely available guides which explain Spree in an easy-to-understand way, contributed by valuable members in the community.
For 1.0, we’ll be updating these guides and filling them out with even more useful information. If there’s something else you’d like to see documented here, just shoot me an email (firstname.lastname@example.org). Better still, why not follow the steps in the Contributing to the Documentation section of the Contributing to Spree guide?
If you’re looking for more help that isn’t quite guides material, we also have helfpul people on the spree-user mailing list.
One more thing: We’ve also been receiving a lot of code from our users through GitHub. We use GitHub because it provides the community an easy way to provide fixes for Spree and we’re able to
review these extremely efficiently and merge them into our codebase. If you want to submit a fix for Spree yourself, we’ve also got a section for that in the Contributing to Spree guide also.
We’re fanatical about testing
When we’re merging in these changes from other people, we look for code quality and test coverage. If these two things aren’t up to scratch, then we’ll help people in those regards. For
testing, we use the best Ruby testing framework, called RSpec. We also use Capybara and selenium-webdriver. With these tools, we’re able to write end-to-end tests for Spree.
In the unlikely case of a bug, we will write a regression test for it, ensure that the test fails and then write the code to fix the bug and make the test pass. Take for example this commit where a regression test for issue
#774 was written, and then this commit was what fixed it. Without these regression tests, a bug
may re-appear. If we accidentally introduce a regression, there’s a high probability it’ll be caught by one of these tests and not released to the public.
We’re also massive, massive fans of Travis CI. When we push Spree’s code to GitHub, a notification is sent to Travis which triggers a new build to run. This
new build will run all the tests for Spree, ensuring that everything is working properly. When the tests are finished running, we’re notified in our Campfire channel and our IRC server. If
the tests fail, there’s one more notification that goes out: an email to me that says “The build was broken”.
When this happens, it’s my job to bring the build back to green, because a broken
build means a broken product, which is something we, and not you, should have to deal with.
A build listing from Travis
You can see this system in full effect in the above image. I committed broken code and it broke build 316. While I was fixing
this, two other commits came through from other people and their builds failed due to the break that was introduced. The break was then fixed it with the commit that triggered build 319. We will do our best to ensure that this build is always green, because that’ll mean that we are giving you the best
We want to help you
Finally, we want to be the easiest-to-use e-commerce platform out there. If there’s any questions or suggestions you’ve got for it, please don’t hesitate to ask them on the spree-user mailing list. We want you to actually enjoy using Spree and not hate it.
Why? Because we can.