At FrozenRidge, LLC, we strongly believe that well-tested software is better than poorly-tested software, and that frequently-deployed software is superior to infrequently-deployed software.
Continuous Deployment and Dashboards
Any serious software project should have a test suite, and that test suite should be run on every commit (Continuous Integration). Code should be pushed live (to staging, at least) on every successful test run (Continuous Deployment).
Real-time and historical feedback from builds, test runs and deployments should be available via active notifcations (e.g. email, mobile push) and passive, ambient dashboards.
Continuous Integration (CI) and Continuous Deployment (CD) are the current state of the art in Software Engineering best practices.
While CI and CD are highly regarded as software processes, the existing software tools to implement them are not.
CI and Deployment Needs Customization
Most tools work great for the specific piece of the process they've been designed to solve, but are often extremely difficult and clunky to use outside of that.
It is our direct experience that CI and deployment processes vary greatly across organizations and software projects. There is almost always a large amount of time spent customizing and integrating any CI solution (Jenkins, BuildBot, TravisCI) with the particular build, test and deployment environment.
Example: Client-side JavaScript Testing
For example one project might be a client-side JavaScript library which needs to run QUnit tests on 5 different browsers in parallel via a cloud provider like Sauce Labs.
Example: Server-side Python Testing
Another project might be a server-side Python web application server which has integration tests requiring a fresh MySQL database and a deployment to Heroku with an automated SQL database migration.
Visual Status Display Matters
Not only that, but the way to communicate build and test status varies greatly: The dashboard for a client-side JavaScript library might naturally fit to a visual matrix of success/failure across different browsers. For a server-side component it might display a time-series graph of production response times overlaid with markers for each version of code deployed.
Existing Tools Have Limitations
While we offer customization and integration services for systems like Jenkins and TravisCI, we also actively develop and support our own Open Source platform called Strider. Based on our experience with other systems, we have designed Strider from the start to support the kinds of customization we see demand for: Front-end and back-end.
Strider is BSD licensed and written entirely in JavaScript, using MongoDB (a JavaScript database) for storage. If you know JavaScript, you can customize Strider.
Know JavaScript? You Can Customize Strider
JavaScript is a natural choice because it is the language of the web, and it supports event driven programming so well.
If your desire is to build beautiful, idiomatic web-based displays for your build, test and deployment data you will be using JavaScript to do so. Having the entire system implemented in JavaScript makes all aspects accessible to developers. You are not limited to hacking on the front-end but can jump into the server-side code, too.
Furthermore, CI and CD are inherently event-driven processes: You execute code in response to events being fired (new commit -> new build -> new test -> new deployment). It is typical for a test or prepare step to involve running many processes in parallel, capturing output and status. Server-side JS running on Node makes this very easy and natural to do.
Strider's Just a Big Bunch of Modules
As a Node.js program, Strider tries to follow the philosophy of being composed of many tiny modules. Strider plugins are NPM modules. This means you can benefit from the existing tooling and ecosystem around the excellent npmjs.org. Installing a Strider plugin is simple a matter of npm install
. Sharing a plugin you've written is just a npm publish
or distributing a URL.
We're very excited about the interest from individuals and businesses in Strider we see so far, and we look forward to writing more about it in future blog posts.
Need help with your test/build/deployment systems? Want nice dashboards?