CI is the lifeblood of microservices. Break the pipeline, break the app. But as much as Docker has enabled better CI, there are still problems.

We version-control our app environment with Docker containers and our code with Git, but test data is still the wild west. Even when we have version-controlled scripts to generate test data, they often produce a pale imitation of prod, and transforming and loading this synthetic data into test databases is slow and awkward. Moreover, when tests do fail, debugging locally is often a challenge since we don’t have access to the build environment including any problematic state generated during the test run.

CI also suffers by being slow. Running a test doesn’t just require realistic test data. It requires a grab bag of binaries, plugins, scripts, all of which have to be loaded onto a machine and be in a known good state before a build starts. The setup process for each host can take 15 minutes or more, and unless this environment is refreshed after each build, subsequent builds can fail simply to due the test environment.

Solving these problems is one of the reasons why we created FlockerHub and Fli.

Problems with CI today:

  • Slow data generation & load process
  • Hard to inspect problematic state upon build failure
  • Incremental CI builds introduce error
  • Debugging locally hit-or-miss without state
How frequently do you encounter bugs...
Q3 2016 survey of DevOps users n=137

Catch more bugs in dev, get fewer pages

Bugs in prod are the worst. Literally. A recent survey found that the most expensive bugs to fix happen in production. Furthermore, one of the biggest reasons for bugs slipping through the cracks was due to lack of testing against realistic data. When the pager rings, these preventable bugs are even worse.

With FlockerHub and Fli, you can snapshot your databases and use the fully read-writeable clones as part of your CI or test environment, or even locally.

Common, version-controlled test fixtures reduce room for error

Working with a team of other developers often means that your code is a dependency for someone else. When someone is testing how their code works with yours, you need to make sure they are using the right test data to cover all the integration edge cases.

FlockerHub lets you build and operate a version-controlled test fixture library, so everyone on your team runs tests using the same realistic test data to find more bugs. Faster. Before they hit production.

Common, version-controlled test fixtures reduce room for error
Test fixture library for user account widget

When builds fail, snapshot and debug

Figuring out why a build has failed can be complex. It could be the code. It could be the data. When your build fails, snapshot all your test fixture volumes and pull them into your debug environment. You’ll have the entire environment recreated for you so you can more quickly zero in on the cause of the failure.

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