Work with Environments

Quite some exciting news this week!

Another very important evolution in the product is the “Environment” semantic.

For those who are/have been using the Premium or Enterprise Editions, you started to get used to our “Teams” concept. Basically, it was a way for you to collaborate with coworkers, where the team owner would share his secured access to an app, a server or cluster of servers.

It was actually a very flexible way to configure Blackfire: you could do anything you wanted depending on your workflow. But in the end it was actually too flexible, making it a difficult concept to grasp.

Blackfire.io v2.0 and its load of new features helped us give a stronger semantic to that concept, and thereby made it easier to understand and use. As we added the possibility to define Assertions, Test Scenarios, Triggers and Notifiers, it became clear that each “Team” would need specific configuration, that was actually more related to environment constraints.

What’s an environment?

Generally speaking, an environment is where your code is being stored and/or executed. Generally, development teams have:

• a local development environment per team member (their computer)
• a shared development environment (a git repository, for instance)
• a staging environment (where they usually apply QA processes)
• a production environment (for the live application)

When managing performance for an app, depending on the environment where it is deployed, you may want to be alerted for different reasons, at different times, and via different communication channels.

What can I do in Blackfire.io about it?

So here it is. Now you can:

• give profiling access to a group of people on the same environment.
• configure a set of tests specifically for each environment
• configure test scenarios specifically for each environment
• be notified via the appropriate communication channel depending on the environment

Let’s go through two simple and concrete use cases.

Example use case: Production Environment

You want to make sure that your most visited pages never encounter load times higher than 400ms. You want to monitor this on a regular basis, and that notifications arrive directly in your team’s instant messaging service (most likely a place where someone is always hanging and can spread the alert or do something about it).

1. Create a “Production” Environment in Blackfire, and set-up the corresponding credentials on your production server
2. Write the test that will monitor that `main.wall_time < 400ms`
3. Write a scenario that will trigger profiles on the required pages
4. Schedule scenarios to be triggered every hour
5. Set-up a notifier to warn you whenever the tests fail via your instant messaging service (Slack, Hipchat,…)

Example use case: Staging Environment

You want to make sure that all pages use less than 10 sql queries. You want that to be checked for all new app evolutions, before they reached production, as part of your QA process. And you just need to know if something changes, as part of your daily workload. Otherwise you don’t want to be bothered.

1. Create a “Staging” Environment in Blackfire, and set-up the corresponding credentials on your staging server
2. Write the test that will validate that `metrics.sql.queries.count < 10`
3. Write a scenario that will trigger profiles on all pages
4. Schedule scenarios to be triggered by Jenkins (via a webhook)
5. Set-up a notifier to give you an e-mail notification whenever a test result changes

Conclusion

To wrap-up, we’ve made some changes that shouldn’t affect your current Blackfire workflow. But it should help you get the best out of it. And in the coming weeks, we’ll add more evolutions to the UI (amongst other evolutions), to make it more intuitive.

Happy profiling!