Faster Horses - Category Creation is Hard
“If I would have asked people what they wanted, they would have said faster horses.”
Something Henry Ford never said, but it’s fun to pretend he did.
What does it mean?
That prospective users of your product can’t conceive of the innovation you are creating and would just prefer a better version of their current technology.
Why am I talking about it?
Well, let’s begin.
I’ve been working on Brisk, which is a new way of running your test suite. It's an extremely fast way of running your tests from your terminal (what is brisk?).
It makes the computational power of the cloud available to you in your terminal, making your tests run in seconds (don’t believe me, here is a demo).
But, and here is the big but. It’s been very hard to communicate to everyone about this new way of doing things. It’s like nobody cares. And I know people care, because I care. I've been slogging through slow tests for years. But reaching a community of people is difficult.
It seems that the majority of people aren’t out there looking for a faster way to run their tests pre-commit. The current way of running your tests locally just doesn’t work for most medium-to-large projects, and so people have just stopped looking and they stopped looking years ago.
As a one-person operation without a huge megaphone, it’s depressingly hard to make even a ripple let alone a splash.
See, I’m doing that thing that everyone warns you to never do, category creation. One of my favorite marketing guys explicitly says this many times, and maybe I should have listened.
To make matters worse I’m doing it in a field that is famously resistant to advertising, so I can’t just spend money on ads and gain a little traction to grind my way out of it.
Which brings me to faster horses.
The CI Question
The one thing everyone asks me when I explain Brisk to them is, can it do CI? I would always say no, and explain where in the development process Brisk is designed to be. That is, pre-commit, before you commit to git or push. It’s for running your tests in your terminal - remember when you did that?
But then I got to thinking.
If everyone wants a faster horse, I can give them a faster horse.
I added a few ENV vars to my CLI, added some functionality to determine when to rebuild the workers and hooked it up in a Github action and Brisk CI was born.
So, it’s slower than local brisk, because it’s brisk + Github actions. Brisk still runs at the same speed, but the overhead of starting Github actions slows things down. However it’s still blazing fast, 30 seconds for the full React test suite.
For those of you who haven't checked out the demo, the test suite runs in over 3 minutes locally using jest (the old way), but with brisk from your local machine we can run the entire suite in 12 seconds.
Using Brisk CI has the extra benefit of also working locally. So once you have Brisk set up for your CI you can run it locally (and vice versa). Can your current CI solution do that?
This has the advantage of never having to configure your local testing environment. It should make onboarding new developers extremely easy and keep everything consistent from pre-commit tests the whole way up to production.
But mostly what I’m excited about is just how freaking fast CI is with Brisk.
In the past, I’ve spent hours merging up from master to staging, staging to production and deploying, waiting at each stage for the tests to pass in CI before merging and pushing to the next.
You can check out a Github actions run here
https://github.com/brisktest/react/runs/7666892604?check_suite_focus=true
Brisk makes all of that happen in seconds. 30 seconds is fast enough that you’ll just be loading Github to see the result of the test run when it finishes.
It’s fast.
If you want to give it a try, head over to https://brisktest.com/ and download the CLI to get started.
If you need help getting set up, you can email me directly at sean@brisktest.com and I'll get you up and running in no time.