SaaS on Rails

About SaaS

SaaS companies solve existing problems by shipping software solutions.
Shipping software solutions — is SaaS company’s heartbeat.
If SaaS company stopped shipping, it’s dead.

But shipping continuously, doesn’t mean shipping crappy software. 
SaaS needs to ship not just Features, but Quality Features.
Quality Features are the ones, that execute well.
That solve some problem well.

About problems solutions

Any problem have a solution after a number of iterations.
And, ultimately, any problem solution is all about how fast can you iterate: have an idea, give it a try, get feedback, improve on it, then repeat.

And SaaS company also solves problems with iterations.

There are different models of iterations for SaaS, but we are not going to discuss them here. It just should be clear, that the faster SaaS company can iterate, the faster and better it builds a real problem solution.

This is what we call Continuous Delivery.

About release cycles

Fast iterations in other words: small Time to Delivery. 
Small Time to Delivery means short Release Cycles.

This is the same as railway carriages of a very long train running all the time, rather than a big tanker ship arriving once a month.

Have you thought about Release Cycle which lasts minutes, not months?
It’s all about small changes, right?

But small continuous changes can be dangerous. 
How to make them safer?

About safety

It’s some kind of art and trade-off: you need to iterate fast, but at the same time you need to be safe and stable.

How on Earth can we iterate fast and safe?

With intelligent Continuous Integration.
You need to make entire process of Software Development, Testing and Delivery as endless running cargo train.

How to do that?

For example, you may:

• Split your production environment into 3;
• Let all successful CI builds being deployed to “Staff-only” / ”User acceptance” / ”Staging” pretty simple environment where Product Managers, Project Managers, Product Owners can control the Product Quality either in real-time or on weekly-demos basis;
• When ready, push changes to “Beta testers” environment to verify your changes with moderate load and real customers usage and feedback. 
  If something is broken, just Rollback to a previous version or Rollforward with a quick update delivered in minutes;
• When everything is stable, just push these changes to “Everyone” — changes are pretty safe already:

Successful CI builds — are builds, which passed all Autotests. 
This is where autotests coverage matters: the better coverage, the safer delivery process.

And again: if something was missed and anything gotten broken, then you can deliver a fix covered with autotests in minutes or hours, not months.

Let’s admit that: things will go wrong online. Due to any reasons. You can’t protect yourself from it. But you can and should build an environment and a process, where you may let it happen and benefit from it.

About ideas and insights

You need to test your ideas in real world to get real data to analyse and get new ideas and insights.

If we have facts, let’s use them. If all we have are opinions, let’s use mine!
 — Jim Barksdale, CEO of Netscape

Because those, who test — fly, those, who not — die.