WEBVTT NOTE Created by CaptionSync from Automatic Sync Technologies www.automaticsync.com 00:00:01.256 --> 00:00:07.196 align:middle We now have two versions of our site deployed: our production deploy and a, sort of, 00:00:07.196 --> 00:00:10.746 align:middle "staging" deploy of a pretend feature we're working on. 00:00:11.616 --> 00:00:17.026 align:middle Blackfire is all set up on the production server, but not on the staging server. 00:00:17.456 --> 00:00:18.426 align:middle Let's fix that! 00:00:19.336 --> 00:00:24.906 align:middle Back on the install page, select "SymfonyCloud" as our host to get to its docs. 00:00:24.906 --> 00:00:28.136 align:middle To set up Blackfire on production, we did 3 things. 00:00:28.526 --> 00:00:30.426 align:middle One, added the extension. 00:00:30.926 --> 00:00:36.796 align:middle Two, ran this var:set command to configure our Blackfire Server id and token. 00:00:37.346 --> 00:00:41.786 align:middle And three, ran integration:add so that every deploy 00:00:41.786 --> 00:00:45.786 align:middle to master would trigger a Blackfire build in our environment. 00:00:46.726 --> 00:00:51.846 align:middle Technically, on the staging server, the Blackfire extension is already enabled 00:00:52.286 --> 00:01:00.116 align:middle and it's set up to use the Server Id and token from our production Blackfire environment. 00:01:00.406 --> 00:01:06.096 align:middle But, as we talked about in the last chapter, I don't want to mix my production builds 00:01:06.176 --> 00:01:08.536 align:middle with builds from staging servers. 00:01:08.536 --> 00:01:14.446 align:middle Instead, go back to our Blackfire organization and create a second environment. 00:01:15.426 --> 00:01:18.786 align:middle Let's call it "Sasquatch Sightings Non-master". 00:01:20.296 --> 00:01:23.836 align:middle For the endpoint, use the production environment URL. 00:01:23.836 --> 00:01:28.786 align:middle But don't worry, that URL won't actually be used. 00:01:28.786 --> 00:01:29.256 align:middle You'll see. 00:01:30.176 --> 00:01:31.156 align:middle Hit "Create environment"... 00:01:31.426 --> 00:01:34.196 align:middle then remove the build notifications and save. 00:01:37.756 --> 00:01:41.236 align:middle View the new environment - I'll get the credentials in a minute. 00:01:44.156 --> 00:01:47.296 align:middle Now, stop the periodic builds. 00:01:47.896 --> 00:01:56.736 align:middle Why? Well in our setup, at any point, we may have zero or many different "staging" servers. 00:01:57.536 --> 00:02:00.236 align:middle There's not just one server to build... 00:02:00.236 --> 00:02:02.816 align:middle so if we did a periodic build... 00:02:03.086 --> 00:02:05.266 align:middle which "staging" server would it use? 00:02:06.126 --> 00:02:07.986 align:middle It just doesn't make sense in our case. 00:02:08.526 --> 00:02:14.646 align:middle What does make sense is to trigger a new build each time we deploy to a staging server. 00:02:15.866 --> 00:02:20.446 align:middle Ok, let's think about this: we now have two Blackfire environments. 00:02:20.956 --> 00:02:25.966 align:middle We want the production server to use the Blackfire server id and token 00:02:26.096 --> 00:02:28.146 align:middle for the production environment... 00:02:28.426 --> 00:02:33.056 align:middle and we want every other deploy to use the Blackfire id and token 00:02:33.176 --> 00:02:35.786 align:middle from the new "Non-master" environment. 00:02:36.626 --> 00:02:39.506 align:middle How you do that depends on how you deploy. 00:02:39.506 --> 00:02:44.146 align:middle For us, we can use a SymfonyCloud config trick. 00:02:44.796 --> 00:02:52.026 align:middle First, list which variables we have set with: symfony vars We have the two that were set 00:02:52.026 --> 00:02:54.566 align:middle by the var:set command we ran earlier. 00:02:54.996 --> 00:03:03.386 align:middle Delete both of them: symfony var:delete BLACKFIRE_SERVER_ID BLACKFIRE_SERVER_TOKEN We're 00:03:03.386 --> 00:03:05.846 align:middle going to re-add these in a minute... 00:03:05.906 --> 00:03:08.026 align:middle but with some different options. 00:03:09.976 --> 00:03:11.886 align:middle Now, go back to the installation page... 00:03:12.276 --> 00:03:13.636 align:middle and refresh... 00:03:13.766 --> 00:03:15.506 align:middle so this shows our new environment. 00:03:16.306 --> 00:03:20.396 align:middle For the var:set command, select the Non-master environment. 00:03:21.996 --> 00:03:29.246 align:middle Copy the command, move over and paste: If we stopped now, 00:03:29.526 --> 00:03:36.326 align:middle it would mean that every server would send its profiles to the new Non-Master environment... 00:03:36.866 --> 00:03:39.316 align:middle which is not exactly what we want. 00:03:39.886 --> 00:03:42.646 align:middle But here's the trick: on the install page, 00:03:42.866 --> 00:03:47.536 align:middle change to the "Production" Blackfire environment, and copy its command. 00:03:48.236 --> 00:03:53.856 align:middle We're going to override these variables, but just on the SymfonyCloud master environment. 00:03:54.726 --> 00:04:00.086 align:middle Paste the command, then add -- env=master -- 00:04:00.086 --> 00:04:07.866 align:middle env-level so that the variables are used as "overrides" for only that environment. 00:04:09.256 --> 00:04:16.506 align:middle Finish with -- inheritable=false so that when we create new SymfonyCloud environments, 00:04:16.766 --> 00:04:23.726 align:middle they don't inherit these variables from master: we want them to use the original values. 00:04:24.396 --> 00:04:28.406 align:middle This is a long way of saying that the master environment 00:04:28.406 --> 00:04:32.676 align:middle on SymfonyCloud will now use the server id and token for the 00:04:32.676 --> 00:04:36.476 align:middle "Sasquatch Sightings Production" Blackfire environment. 00:04:37.126 --> 00:04:42.166 align:middle And every other deploy will use the credentials for the "Non-Master" environment. 00:04:43.726 --> 00:04:48.026 align:middle To be sure, run: symfony vars -- env=master Yep! 00:04:50.806 --> 00:04:54.986 align:middle 6900 is the server id for Production. 00:04:55.036 --> 00:05:04.276 align:middle Now try: symfony vars -- env=some_feature Perfect: 00:05:04.726 --> 00:05:07.286 align:middle that uses the other Server id and token. 00:05:07.836 --> 00:05:08.466 align:middle We're good! 00:05:09.546 --> 00:05:15.036 align:middle The last thing I want to do is run this integration:add command again. 00:05:15.546 --> 00:05:19.996 align:middle We ran this earlier to tell SymfonyCloud that it should notify our 00:05:19.996 --> 00:05:24.836 align:middle "Production" Blackfire environment whenever we deploy to master. 00:05:26.256 --> 00:05:29.646 align:middle Now copy the "Non-Master" environment command... 00:05:30.296 --> 00:05:39.236 align:middle and run it: Say yes to all events, all states and all environments. 00:05:40.176 --> 00:05:42.896 align:middle Actually, what we really want to say is: 00:05:43.156 --> 00:05:49.186 align:middle create a build on the "Non-Master" environment every time any branch except 00:05:49.296 --> 00:05:50.626 align:middle for master is deployed... 00:05:50.926 --> 00:05:52.446 align:middle but I don't think that's possible. 00:05:52.446 --> 00:05:58.906 align:middle Phew! Let's redeploy both SymfonyCloud environments to see all of this in action: 00:05:59.406 --> 00:06:06.006 align:middle symfony redeploy -- bypass-checks Because we're currently checked 00:06:06.006 --> 00:06:10.556 align:middle out to the some_feature branch, this deploys that branch. 00:06:12.026 --> 00:06:19.846 align:middle When it finishes, run the same command but with -- env=master to redeploy production: 00:06:20.726 --> 00:06:26.896 align:middle We also could have switched to that branch - git checkout master - and then ran symfony redeploy. 00:06:27.346 --> 00:06:29.026 align:middle That's the more traditional way. 00:06:30.416 --> 00:06:32.596 align:middle Done! Let's go see what that did! 00:06:32.656 --> 00:06:37.386 align:middle First check out the Blackfire production environment. 00:06:39.626 --> 00:06:44.206 align:middle Yes! The redeploy to master created one new build. 00:06:44.586 --> 00:06:48.726 align:middle Perfect. Now check out the Non-master environment. 00:06:50.596 --> 00:06:54.806 align:middle Oh, this has two new builds: one for the some_feature deploy 00:06:55.106 --> 00:06:57.496 align:middle and another for the master deploy. 00:06:57.496 --> 00:07:01.746 align:middle We don't really want or care about that second one... 00:07:01.746 --> 00:07:02.606 align:middle but it's fine. 00:07:03.126 --> 00:07:08.056 align:middle What we do care about is that now, every time we deploy 00:07:08.056 --> 00:07:12.526 align:middle to a non-production server, we get a new build here. 00:07:12.566 --> 00:07:19.386 align:middle If you use GitHub or Gitlab, you can take this one step further by doing 2 things. 00:07:19.476 --> 00:07:25.456 align:middle First, SymfonyCloud has a feature where it can automatically deploy the code you have 00:07:25.456 --> 00:07:26.886 align:middle on a pull request. 00:07:27.546 --> 00:07:32.886 align:middle And because that would trigger a new build, second, you can configure Blackfire 00:07:32.886 --> 00:07:40.476 align:middle to notify GitHub or Gitlab of your build results so that they show up on the pull request itself. 00:07:41.026 --> 00:07:42.046 align:middle Pretty awesome. 00:07:43.366 --> 00:07:44.966 align:middle I love our setup. 00:07:45.406 --> 00:07:48.856 align:middle But there's one more environment feature that we haven't checked out yet: 00:07:49.336 --> 00:07:53.226 align:middle the ability to set variables that you use in your scenarios. 00:07:53.996 --> 00:07:55.236 align:middle Let's check that out next.