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: 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
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.
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? Get in touch