WEBVTT NOTE Created by CaptionSync from Automatic Sync Technologies www.automaticsync.com 00:00:01.086 --> 00:00:03.256 align:middle A long time ago in this tutorial, 00:00:03.496 --> 00:00:07.756 align:middle we talked about Blackfire's truly awesome "comparison" feature. 00:00:07.836 --> 00:00:12.786 align:middle If you profile a page, make a change, then profile it again, 00:00:13.096 --> 00:00:20.256 align:middle you can compare those two profiles to see exactly how that change impacted performance. 00:00:21.046 --> 00:00:25.306 align:middle When you use the build system, you can do the exact same thing... 00:00:25.806 --> 00:00:29.976 align:middle and you can even write "tests" that compare a build to the previous build. 00:00:30.176 --> 00:00:33.286 align:middle For example, you could say: Yo! 00:00:33.616 --> 00:00:38.316 align:middle If the wall time on the homepage is suddenly 30% slower 00:00:38.316 --> 00:00:41.596 align:middle than the previous build, I want this build to fail. 00:00:42.446 --> 00:00:43.916 align:middle How can we do that? 00:00:44.306 --> 00:00:45.556 align:middle It's dead simple. 00:00:46.146 --> 00:00:51.876 align:middle Add a new global metric - how about "Pages are not suddenly much slower" - 00:00:52.336 --> 00:00:54.936 align:middle and set this to run on every page: path: /. 00:00:55.436 --> 00:01:01.956 align:middle *. For the assertion, we can use a special function called percent: 00:01:02.576 --> 00:01:07.086 align:middle percent(main.wall_time) < 30%. 00:01:08.226 --> 00:01:09.286 align:middle That's it! 00:01:09.286 --> 00:01:12.016 align:middle There's also a function called diff(). 00:01:12.096 --> 00:01:21.516 align:middle If you said diff(metrics.sql.queries.count) < 2 it means that the difference between the number 00:01:21.516 --> 00:01:27.236 align:middle of SQL queries on the new profile minus the old profile should be less than 2. 00:01:28.276 --> 00:01:29.416 align:middle Let's see what this looks like! 00:01:29.416 --> 00:01:37.386 align:middle Find your terminal and commit these changes: Now... 00:01:37.746 --> 00:01:43.896 align:middle deploy! But... 00:01:44.226 --> 00:01:48.106 align:middle bad news. If we waited for that to finish deploying... 00:01:48.266 --> 00:01:50.536 align:middle and then triggered a new custom build... 00:01:50.856 --> 00:01:53.476 align:middle that test would not run. 00:01:54.126 --> 00:01:55.876 align:middle In fact, I want you to see that. 00:01:56.736 --> 00:02:05.566 align:middle Wait for the deploy to finish - okay, good - then move back over and start a build. 00:02:07.806 --> 00:02:12.816 align:middle This does what we expect: it executes our scenario and creates 2 profiles. 00:02:13.836 --> 00:02:19.666 align:middle Look at the 3 successful constraints for the homepage: we see the other global test about 00:02:19.666 --> 00:02:22.056 align:middle "HTTP requests should be limited"... 00:02:22.496 --> 00:02:24.476 align:middle but we don't see the new one. 00:02:24.856 --> 00:02:25.446 align:middle What gives? 00:02:26.306 --> 00:02:33.256 align:middle So... when you create a build, you can specify a "previous" build that it should be compared 00:02:33.256 --> 00:02:35.996 align:middle to by using an internal "build id". 00:02:36.826 --> 00:02:43.036 align:middle Our project is too new to see it, but this happens automatically with "periodic" builds: 00:02:43.296 --> 00:02:47.626 align:middle our comparison assertion will execute on periodic builds. 00:02:48.616 --> 00:02:50.686 align:middle But when we create a manual build... 00:02:51.116 --> 00:02:54.426 align:middle there's no way to specify a "previous" build... 00:02:54.626 --> 00:02:57.336 align:middle which is why the comparison stuff doesn't work. 00:02:57.336 --> 00:03:05.146 align:middle Fortunately, since I don't want to wait 12 hours to see if this is working, there is another way 00:03:05.146 --> 00:03:08.496 align:middle to trigger a build: through a webhook. 00:03:09.236 --> 00:03:14.546 align:middle Basically, if you want to create a build from outside the Blackfire UI, 00:03:14.866 --> 00:03:19.066 align:middle you can do that by making a request to a specific URL. 00:03:19.566 --> 00:03:24.616 align:middle And when you do that, you can optionally specify the "previous build" 00:03:24.896 --> 00:03:27.866 align:middle that this new build should be compared to. 00:03:28.956 --> 00:03:33.916 align:middle This webhook-triggered-build is especially useful in one specific situation: 00:03:34.296 --> 00:03:37.266 align:middle creating a build each time you deploy. 00:03:38.046 --> 00:03:43.726 align:middle If you did that correctly, your comparison assertion would compare the latest deploy 00:03:43.956 --> 00:03:45.896 align:middle to the previous deploy... 00:03:46.126 --> 00:03:48.086 align:middle which is pretty awesome. 00:03:49.046 --> 00:03:53.006 align:middle Because we're using SymfonyCloud, this is dead-simple to set up. 00:03:54.176 --> 00:03:57.976 align:middle Find the Blackfire SymfonyCloud documentation and, 00:03:57.976 --> 00:04:01.626 align:middle down here under "Builds", I'll select our environment. 00:04:02.406 --> 00:04:08.206 align:middle Basically, by running this command, we can tell SymfonyCloud to send a webhook 00:04:08.306 --> 00:04:12.186 align:middle to create a Blackfire build each time we deploy. 00:04:13.126 --> 00:04:16.066 align:middle Copy it, move over to your terminal and... 00:04:16.396 --> 00:04:23.956 align:middle paste: Hit enter to report all events and enter again to report all states. 00:04:24.106 --> 00:04:31.146 align:middle For the environments - this is asking which SymfonyCloud environments should trigger builds. 00:04:31.806 --> 00:04:35.376 align:middle Answer with just master - I'll explain why soon. 00:04:35.986 --> 00:04:36.916 align:middle And... done! 00:04:37.896 --> 00:04:39.126 align:middle Let's redeploy our app. 00:04:40.436 --> 00:04:43.996 align:middle Oh, but before we do, refresh our builds page. 00:04:47.736 --> 00:04:50.096 align:middle Ok, we have 5 builds right now. 00:04:52.236 --> 00:05:00.176 align:middle Now run: symfony redeploy -- bypass-checks This should be pretty quick. 00:05:03.936 --> 00:05:06.406 align:middle Then... go refresh the page. 00:05:08.976 --> 00:05:14.416 align:middle Yes! A new build - number 6 - triggered by SymfonyCloud. 00:05:15.086 --> 00:05:16.826 align:middle And it passes. 00:05:17.286 --> 00:05:26.936 align:middle Awesome! Let's redeploy again: When that finishes... 00:05:30.406 --> 00:05:32.366 align:middle there's build 7! 00:05:33.116 --> 00:05:38.096 align:middle But to see the comparison stuff in action, I need to do a real deploy 00:05:38.526 --> 00:05:42.486 align:middle so that the next build is tied to a new git sha. 00:05:43.686 --> 00:05:48.386 align:middle I'll do a meaningless change, commit, then deploy: Actually, 00:05:48.426 --> 00:05:51.986 align:middle I could have skipped changing any files and committed with -- 00:05:52.566 --> 00:05:55.576 align:middle allow-empty to create an empty commit. 00:05:59.786 --> 00:06:01.446 align:middle When this finishes... 00:06:04.506 --> 00:06:05.386 align:middle no surprise! 00:06:05.576 --> 00:06:07.306 align:middle We have build 8! 00:06:08.466 --> 00:06:15.396 align:middle On this build, it's super cool: each profile has a "Show Comparison" link to open the 00:06:15.396 --> 00:06:20.596 align:middle "comparison" view of that profile compared to the same profile on the build 00:06:20.596 --> 00:06:26.736 align:middle from the last deploy - which - if you click "latest successful build" - is build 7. 00:06:28.046 --> 00:06:32.696 align:middle Back on build 8, click the "Show 4 successful constraints" link. 00:06:33.576 --> 00:06:34.446 align:middle There it is! 00:06:34.786 --> 00:06:39.176 align:middle We can see our "Pages are not suddenly much slower" assertion! 00:06:40.006 --> 00:06:44.576 align:middle It's comparing the wall time of this profile to the one from the last build. 00:06:45.786 --> 00:06:47.186 align:middle Click to open up the profile... 00:06:47.436 --> 00:06:49.906 align:middle and make sure you're on the Assertions tab. 00:06:52.306 --> 00:06:59.266 align:middle I love this: 2 page-specific assertions from the scenario, and 2 global assertions: 00:07:00.036 --> 00:07:02.026 align:middle one using the percent() function. 00:07:03.316 --> 00:07:05.386 align:middle The "Recommendations" also got a bit better: 00:07:05.996 --> 00:07:10.496 align:middle Blackfire automatically has some built-in recommendations using diff: 00:07:11.116 --> 00:07:14.626 align:middle this recommends that the new profile should have less 00:07:14.726 --> 00:07:18.046 align:middle than 2 additional queries compared to the last build. 00:07:19.116 --> 00:07:21.026 align:middle It looks like it failed... 00:07:21.136 --> 00:07:24.486 align:middle but that's just because the other part of this recommendation - 00:07:24.676 --> 00:07:27.316 align:middle not making more than 10 total queries - failed. 00:07:28.786 --> 00:07:32.036 align:middle Next: what about running builds on your staging server 00:07:32.166 --> 00:07:36.056 align:middle so you can catch performance issues before going to production? 00:07:36.506 --> 00:07:40.566 align:middle Or what about executing Blackfire builds on each pull request? 00:07:41.436 --> 00:07:44.756 align:middle We can totally do that - with a second environment.