Configuring Environments
Environments let developers finely tune assertions via variables and depending on whether the environment is optimized for development or production.
By Fabien Potencier, on Feb 17, 2016 As our customers are busy writing performance tests with Blackfire, we are working on the next step towards a fully automated performance testing solution.
Performance management with Blackfire is centered around the notion of environments; An environment can represent physical environments of a project: a project generally has one for development, one for staging, and one for production.
An environment is more than that; it is a collaborative workspace where developers can collaborate on profiles and builds; where they all receive notifications when something goes wrong.
And your development environment is probably different from the production one: servers, data, and traffic are not the same of course, but configuration might be different as well. You want to enable debugging on your laptop and configure aggressive caching for production. But as Blackfire tests are stored along side your code, how can you write different tests for staging and production?
The key is environments configuration. When creating a new environment, you can tell Blackfire if you want to create a development one and give the hostname for production ones:
The is_dev() function available in assertions let you write test targeted specifically at development or production environments. For instance, here is how you can express that you want no YAML parsing in production:
is_dev() or metrics.symfony.yaml.reads.count == 0
Find more useful examples in Day 12 of 24 days of Blackfire. https://blackfire.io/docs/24-days/12-tests-best-pratices
Besides the is_dev() development test function, you can also use variables in assertions and define different values depending on the environment. You probably want to assert that the number of SQL queries for any HTTP request is limited, but what if your development environment makes several of them to store debugging information?
You can reuse the is_dev() function:
metrics.sql.queries.count < is_dev() ? 15 : 10
But there is a better way with environment variables. Create a max_sql_queries variable in each environment with different values (10 for production and 15 for development):
Then, use the variable in your assertions:
metrics.sql.queries.count < vars.max_sql_queries
This is a much cleaner solution that scales better when you add more environments.
Happy performance testing!
