Improved CI: Integrate realistic data, reduce build times, accelerate your pipeline

Problem

You’ve automated your application development pipeline and thanks to Docker are now doing CI. But too many bugs are getting through to production.

You want to increase your test coverage and practice test driven development, but getting data into your CI environment is slow (you have to ask ops for access to test data) and expensive (all those copies of GBs of data add to your infrastructure costs).

Moreover, this test data changes regularly and you need a way to make sure you are using the right test data for the right test.

ClusterHQ solution & benefits

Use Fli to connect your CI environment to FlockerHub, a data volume repository that enables all of your CI machines to quickly access your version- and access-controlled test data, whether it is a snapshot of production or a carefully crafted test fixture.

You'll catch more bugs before they make it to production and spend less time provisioning your CI environment.

Time spent debugging errors in production
Q3 2016 survey of DevOps users n=137

Build an on-demand staging environment, including realistic test data, for each commit

Problem

You are a part of a team of developers, each of whom is working on feature branches of the same application and you all want to preview your changes on a staging environment before deploying.

You can use Docker Compose to spin up the QA environment, but without realistic data in the database, you can’t find enough bugs or get sense of how the app really functions.

ClusterHQ solution & benefits

For every Docker Compose file you deploy to preview a feature branch, use realistic test data stored in FlockerHub.

Using Fli to clone data volumes without increasing the storage consumed, you and each of your colleagues can have your own private staging environment, all on a single server if desired. That means more complete testing, without having to wait for access to a single shared staging environment.

People pushing to their own staging environment

Operate a scalable, distributed test fixture library for all your applications

Problem

You are the QA lead for a team of fast-moving software developers. You’ve successfully created a test-driven development culture in the team and now everyone is working toward 100 percent test coverage for their code. Yay!

The downside is that there are now a lot of synthetic data sets floating around the team. And requests to Ops for snapshots of databases for use in testing are sending up red flags to management about uncontrolled data flying around the org. On top of that, development teams are inconsistently installing binaries, images, and configuration files in your CI environments, causing your builds to fail. You just want to be able to publish the right fixtures for your team to use, and have every developer use the fixtures every single time a test gets run, whether manually or by automation.

ClusterHQ solution & benefits

Use FlockerHub and Fli to manage a changing, growing test fixture library that can be used by any properly authenticated user or machine in your cloud or data center.

Now, instead of testing with fake data, your developers can pull down realistic data that you’ve created and published into their Docker environment. And QA managers gain the ability to create and share test databases with software developers to help them identify and resolve bugs earlier in the development process.

VolumeSets

Commit and share error state for simplified debugging

Problem

You work for a fast-growing mobile gaming company, and are responsible for triaging user bug reports so, if confirmed, they can be sent to engineering to be fixed. Usually when you get a report, you spend hours trying to reproduce it in your device lab. But even though you are using a Dockerized mobile backend to ensure you are running in the same environment as the user and GitHub to make sure you are running the correct version of the code, you often can't.

In order to have a completely consistent environment, you need to be able to capture the application’s state and share this with the engineering team so they can get to the root of the problem.

ClusterHQ solution & benefits

Regularly capture and commit your database state to FlockerHub using Fli so that when debugging, you can include that data as part of your debug environment. Once you’ve identified the bug, you can provide a link to the problematic state in the issue in your ticketing system so the developer can immediately recreate the full environment and debug as efficiently as possible.

By finding bugs faster, you'll spend less time debugging and more time building features your users want.

Woman on computer

Bootstrap an on-demand development environment

Problem

As a development team, you need to provision development environments for new team members, pair-programming and other exercises. Containers make it easy to package dependencies for development environments like Ruby, Ruby on Rails, and MySQL into an image, but often you need to bootstrap that environment with some initial state.

And sometimes you just want to share your development environment, including its state, with a mentor or colleague so they can help you debug it.

ClusterHQ solution & benefits

With FlockerHub and Fli, you can provide all the state dependencies of your environment to another person using the same Docker Compose file you are already using. Just store your volumes on FlockerHub and provide your colleague with the volume reference, or use FlockerHub search to find it by tag. They'll be up and running with your environment in minutes.

Instant development environments complete with their state mean more time to focus on the task at hand: writing software.

compose and fli-docker yml file

Sign Up Free!

Sign up for the FlockerHub beta and receive 5GB of container volume storage free for 6 months.

Sign up now

Got a question?

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