Staging. It helps us preview our feature branches. It’s an environment for running automated tests. It can be a pain.

The problem with staging is that, often, it is a thing. There is one staging environment and teams compete for staging time to test their changes. Moreover, staging needs to be maintained over time and if you want to expand access to more individuals, teams or machines, you've got more environments to maintain.

Containers start to change this, with a “staging” environment creatable almost instantly from a Docker Compose file, available for the length of the test, and no longer. But without realistic test data, this environment is a poor facsimile of production, and therefore a poor test of the correctness of code before its final push to prod. Who hasn't seen a User table have three fake users named “Test”, “Jane Doe” and “fasdfasdfa”?

Problems with staging today:

  • A single environment means too much coordination
  • Time wasted waiting for access
  • Without realistic data, staging is a poor substitution for production
  • Running multiple environments is complex
Common, version-controlled test fixtures reduce room for error
Test fixture library for user account widget

Staging without realistic data isn’t really staging

Staging serves one purpose. Test your application in an environment with the highest possible fidelity to what that app is going to see when it goes live. But when your staging environment doesn't have realistic data, your testing is incomplete and avoidable bugs can will slip through. With Fli, you can make regular snapshots of your production data and store it as a test fixture in FlockerHub. This fixture can be pulled onto any host, giving you a full read-writable volume for your Dockerized database.

Staging should be plural

Having realistic data in staging is great. But if there is still only ONE staging environment, then we’re only part way to the solution. With Fli you can create as many on-demand staging environments as you need on a single server, complete with realistic data. Because Fli uses space-efficient snapshotting, each new fully independent, read-writeable copy of your database doesn't use any extra storage until you start making changes. Even then, you’re only adding the changes, or diff, since the last snapshot, which means your server is unlikely to fill up any time soon and you'll use a lot less bandwidth.

Staging should be plural

More flexibility, less complexity

Docker Compose lets you deploy your application with a single command $ docker compose up. When you add Fli into the mix, each of these application environments can get its own, fully-independent, read/writable database, giving you as many on-demand staging environments you need for your team, all on a single server if you want. No stepping on toes. No unnecessary storage or network costs.

Signup for FlockerHub today

Learn more about FlockerHub and Fli

Push and pull data snapshots

The basics of how to move data with Fli and FlockerHub.

Creating volumes

Learn how to create a data volume using Fli, the FlockerHub CLI.

Updating object metadata

Learn how tag your data snapshots with user-defined attributes so they are easy to find and manage.

How to setup Fli with your ZPool

Learn how to set up a local storage pool to store and take snapshots.

Got a question?

Thanks for your email, we'll be in touch shortly