On-demand staging: Include realistic test data for each commit
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
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.
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.