WEBVTT NOTE Created by CaptionSync from Automatic Sync Technologies www.automaticsync.com 00:00:01.096 --> 00:00:04.966 align:middle For your site, you hopefully have a staging environment - 00:00:05.176 --> 00:00:10.026 align:middle or maybe multiple staging environments where you can deploy new features and test them. 00:00:10.716 --> 00:00:12.236 align:middle What about those machines? 00:00:12.566 --> 00:00:15.316 align:middle Should we also run Blackfire builds on them? 00:00:16.026 --> 00:00:18.506 align:middle At first, that might not seem important. 00:00:19.066 --> 00:00:22.836 align:middle After all, if a staging machine is a bit slow, who cares? 00:00:23.236 --> 00:00:28.656 align:middle But thanks to the assertions we've been writing, if we executed our Blackfire scenarios 00:00:28.656 --> 00:00:34.556 align:middle on a staging machine, we could identify performance failures before deploying them 00:00:34.556 --> 00:00:35.256 align:middle to production. 00:00:35.766 --> 00:00:37.786 align:middle And if you have a really cool setup, 00:00:38.146 --> 00:00:42.626 align:middle you can even have build results posted automatically to your pull request. 00:00:43.076 --> 00:00:49.026 align:middle OooOOoo. Getting Blackfire set up on a staging server seems simple enough: 00:00:49.446 --> 00:00:52.236 align:middle just repeat the Blackfire installation process... 00:00:52.446 --> 00:00:53.756 align:middle on a different server! 00:00:54.836 --> 00:00:58.746 align:middle But stop! I don't want you to quite do that. 00:00:59.476 --> 00:01:04.416 align:middle Why? I want your Blackfire production environment to only contains builds 00:01:04.416 --> 00:01:07.146 align:middle from your actual production servers. 00:01:07.796 --> 00:01:13.076 align:middle I want this to be a perfect history and representation of production only. 00:01:14.136 --> 00:01:17.636 align:middle If we suddenly start adding builds from a staging server - 00:01:17.856 --> 00:01:20.486 align:middle which maybe has different hardware specs... 00:01:20.696 --> 00:01:25.526 align:middle or is running a buggy new feature - some of those builds will fail... 00:01:25.996 --> 00:01:29.086 align:middle and we'll get extra noise in our notifications. 00:01:30.066 --> 00:01:36.006 align:middle Instead, I like to create a second Blackfire environment and send profiles to it. 00:01:36.866 --> 00:01:43.086 align:middle If I have multiple staging servers, I make them all use this same new environment. 00:01:44.206 --> 00:01:48.366 align:middle But... before we create that second Blackfire environment... 00:01:48.856 --> 00:01:55.386 align:middle I need you to - once again - pretend like Blackfire doesn't exist at all... 00:01:55.506 --> 00:01:57.186 align:middle for a few minutes. 00:01:57.366 --> 00:02:01.206 align:middle Because before we talk about how we profile a staging server, 00:02:01.696 --> 00:02:04.726 align:middle we need to create a staging server and deploy to it. 00:02:05.386 --> 00:02:08.986 align:middle SymfonyCloud has an incredible way to do this. 00:02:09.576 --> 00:02:15.106 align:middle Unfortunately, the feature in Symfony cloud that does this is called... 00:02:15.576 --> 00:02:16.796 align:middle environments. 00:02:17.176 --> 00:02:22.206 align:middle And it has absolutely nothing to do with Blackfire environments. 00:02:23.146 --> 00:02:28.746 align:middle Here's how it works: in addition to your master branch, which is your production server, 00:02:29.116 --> 00:02:33.746 align:middle SymfonyCloud allows you to deploy different git branches. 00:02:34.286 --> 00:02:37.396 align:middle Each deploy will get its own unique URL. 00:02:38.116 --> 00:02:41.026 align:middle Each branch deployment is called an "environment". 00:02:43.966 --> 00:02:48.046 align:middle If you run: symfony envs Yep! 00:02:48.246 --> 00:02:51.026 align:middle We currently have one environment: master. 00:02:51.646 --> 00:02:56.726 align:middle It's the "current" environment because we're checked out to the master git branch locally. 00:02:57.876 --> 00:03:00.356 align:middle Ok, pretend that we're working on a new feature. 00:03:00.686 --> 00:03:03.796 align:middle And so, we want to create a new local branch for it. 00:03:04.736 --> 00:03:13.846 align:middle Instead of doing that manually, run: symfony env:create some_feature This does two things. 00:03:14.326 --> 00:03:19.006 align:middle First, it created a new local branch called some_feature. 00:03:19.546 --> 00:03:22.616 align:middle That's no big deal: we could have done that by hand. 00:03:23.606 --> 00:03:26.396 align:middle Second, it deploys that branch! 00:03:26.846 --> 00:03:30.746 align:middle It does this by creating a "clone" of the master environment: - 00:03:30.956 --> 00:03:33.816 align:middle even creating a copy of the production database! 00:03:34.466 --> 00:03:36.276 align:middle I'll fast-forward through the deploy. 00:03:38.606 --> 00:03:42.146 align:middle When it finishes, it gives us a URL to the deploy. 00:03:43.076 --> 00:03:50.136 align:middle This is a different URL than on production: it's a totally separate, isolated deployment. 00:03:50.886 --> 00:04:00.526 align:middle Let's open this the lazy way: symfony open:remote Say hello to our staging server 00:04:00.686 --> 00:04:07.256 align:middle for the some_feature branch, which you can see contains a copy of the production database! 00:04:07.516 --> 00:04:08.666 align:middle How cool is that? 00:04:09.406 --> 00:04:13.926 align:middle Back on Blackfire, refresh to see the builds for the production environment. 00:04:15.176 --> 00:04:19.256 align:middle When we deployed to that environment, it did not create a new build. 00:04:19.886 --> 00:04:21.066 align:middle We expected that. 00:04:21.976 --> 00:04:26.816 align:middle When we added the integration to SymfonyCloud - we told it to trigger a build 00:04:26.816 --> 00:04:32.526 align:middle on this Blackfire environment whenever we deploy the master branch only. 00:04:33.236 --> 00:04:38.586 align:middle We did that because we don't want these staging servers to create builds here. 00:04:39.456 --> 00:04:45.286 align:middle Next, let's create a second environment and configure our staging servers to use it.