 Arjmai Drupal Kharthi Bharamai Bhat Karunga. Thanks. Unfortunately, that's the extent of my Hindi. For the English speakers, I'm Dave Hull and today I'll be speaking about deploying Drupal 8. So, who am I? I'm an IT consultant. I've been running my own business for over 15 years. I've been playing around with Drupal since the days of 4.6 and I've been heavily focused on deployment and managing Drupal at scale since the days of Drupal 6 where I deployed over 2,000 sites for a single client in 51 to 52 hours. That was a crazy project. I enjoy hacking on web apps not only with Drupal or PHP but other languages and I also do sysadmin work. I get bored doing the same thing for too long so that's why I do all kinds of different things. So, I'll start by running through some of the things I like. Obviously, I'm here so I like Drupal. I also like automation. If I can get a person out of a process then it makes me happy. I also love DrupalCon. This event has been amazing. I've really enjoyed it so far. I also love cricket and I love the Mumbai Indians. I've actually been lucky enough to go see two games. I've actually seen Harbhajan Singh Baal and Sachin Tendulkar bat on Gwankhidi. So, I'm pretty happy about that. But what makes me even happier about cricket is when Australia wins the World Cup and that's going to happen again next month. So, let's look at deploying Drupal 8. So, here we go. This is just a very simple deployment. We've downloaded it from Drupal.org. We're FTP-ing it to Dreamhost. And I've sped it up just a little bit. And here we go. We start going through doing the basic configuration, putting database credentials and so on. And then the installer runs. And then we put in the site name and all of that stuff. And we even struggled to find our own time zone. And then we save it. There we go. That's Drupal 8 deployed. Thank you everyone for coming. That's the end of my presentation. Now, that's what most people think deployment is with Drupal. But what I'm going to talk to you about today is everything else that goes around deployment so you can have successful, repeatable deployments for your sites and your client's sites. And I'm going to do that by telling you a story. Actually, not quite that story. So, once upon a time there was a company. My clicker is not working too well. All right. Let's skip the clicker. There was a company called Acme Corporation. I don't know if any of you have heard of Acme Corporation. They had a very loyal customer, Mr. Wiley Coyote. And he used to buy all kinds of stuff from them. Very successful business, very innovative with their products. But they had a few problems with their existing content management system. So they started looking at how they could improve their web presence. And this is Larry. I mean, sorry, not Larry, Gary. They look very similar, but this is actually Gary. And Gary is a developer at Acme Corporation. And he likes playing around with new things. So, Gary installed Drupal locally. Here he is setting up ZAMP. Now, you're probably going, yeah, we've all set up ZAMP. I did not my first day at my new job. It's so boring. Yes, it is boring, but it's how most people get a local development environment set up. ZAMP is really good for when you get started, but as we progress through things today, you'll learn that there are alternatives to give you a more consistent environment. Actually, I should turn firewall off. I can't do that. Hopefully it doesn't trigger again. All right. So here we are. We're just running through doing the deployment, doing the configuration. It's all very exciting. Once again, I've sped the video up and downloading from drip.org again, putting in all of our details. Now, the problem with ZAMP is a lot of people use ZAMP on a Windows environment. How many people here actually deploy on to Windows servers? Anyone deploy on to Windows servers? Okay. You have my sympathies. But the thing is that the Windows environment and Linux server environment are completely different. You need consistency between your environment. So that's why ZAMP isn't such a good idea. We'll just wait for this to run through. Well, actually, we know what's going to happen. Let's skip the rest of the video. It's a bit dull. Okay. So Gary goes to his boss, Ada, and says to Ada, hey, check out Drupal. And she's like, that looks great. Let's go with it. So they build their first site and they launch it. And the launch goes like this. It was amazing. They were very happy with it. Then Amy, not Angie, but Amy from Marketing came along and she said, how many people are visiting site? And Gary's like, I don't know. So then they had to work out, like Gary had to sit down and do some research and figure out how they would get some traffic data. And Gary had to poke around on the server and went, here, we've got Apache logs. You can go through that and figure out how many visitors we're having. You might guess Amy wasn't too happy with that. So they decided to use an analytics package. And there's lots of analytics packages around. Google Analytics is the most popular. Piwick is an open source equivalent. If you've got heaps of money and love throwing it away, you can give it to Adobe and get on the tour. And then you've got tools like ChartBeat, which allow you to do real time user tracking. One of the good things that your analytics will show you is all kinds of data, but also page load times. And we can see here that in this one particular week, the average page load time almost doubled. Now, you need to be watching your data. It's not just, I will do the analytics and we'll send off to marketing and they're like, oh, wow, our latest social media campaign was great. We increased traffic by 10%. As developers, you should be trying to get access to the analytics data and understanding the traffic patterns, the page load times, all of that stuff so you have some idea what that looks like. And Ada had a look at the logs and went to Gary and said, why are the gaps in the logs? And at first Gary was like, I don't know. And then he had a look at the traffic logs and there was gaps there as well. And then they realized that because they were using cheap hosting, that the site kept on going down. And how they found that out was by using uptime monitoring. So by using a tool like Pingdom or Wyrmly or New Relic has real-time user tracking as well, that allows you to actually identify if the server's up and down and it'll send you alerts, which is kind of useful, especially if the site is, like if it's your personal blog, you might think it's not really worth it. But if the site's generating revenue either through e-commerce or by generating foot traffic in stores and stuff, you'll want to fix that. So Ada said we need better hosting. And Gary's a bit old school. He thought GoDaddy was still pretty cool. I kind of think Gary may not have a job for much longer. But they decided to go for a platform as a service option. So platform as a service, rather than just giving you the hardware, they give you a bunch of tooling around the system as well. So you get version control. Ideally, it's Git. How many people here have to use Subversion? Okay, you're also people I feel sorry for. I noticed some overlap between the we deploy to Windows and the we use Subversion. But at least using Subversion is better than using no version control. So the past services, they should give you multiple environments. So you can actually have a dev, a stage and a prod, rather than deploying all changes directly to production. That's a great way to break sites. And they should also offer automated deployment. So when you commit your code that the changes actually go live on an environment for you, rather than you having to FTP it or kick off manual processes. And generally they'll give you a service level agreement. So if it does go down, you've got someone to choke. And hopefully if you're losing money, they're losing money because you don't have to pay them. Now, Ada was really impressed with the new hosting platform. And Gary started thinking, what else can we improve? So they decided to adopt a composer based workflow. How many people here have used Composer? Oh, that's great. I'm not going to give you people any sympathy. Any sympathy. Symphony, symphony. All right. So yeah, you can have lots of symphony, just no sympathy. So yeah, the composer based workflow makes it so you actually contain, you put a lot less stuff in your Git repo. So what we've got here is a simple composer.json file that specifies all of our dependencies. So we've got Drupal core, we've got Drash, and we've got Drupal console. If you've got a composer.json file and it doesn't have Drupal console in there, then you're doing it wrong. For Drupal 8, you really want to have console in there as well as Drash. Now, this stops you, like when you've got one big Git repo, you've got a tight deadline and it's like all the code is in there and one thing isn't working. So we'll just hack core today and next week we won't be so busy and we'll fix it. Six months later, that hack is still in production. You do an upgrade and then the functionality breaks. Whereas if you've got a composer file, you're specifying all of your dependencies there and your changes should be properly tested and you know exactly what you're running. So it makes the separation of the dependencies and your custom code a lot cleaner. So this is a little video of using a composer-based workflow for those of you who aren't familiar. Sorry, that text, this is a pre-recorded video unfortunately and the text is probably more than a little bit blurry for the people up the back. So I'll talk through it. What we're doing is we're adding the develop module as a dependency to the composer.json which I'll add in here and we'll put in the branch that we're using. Now I would love to show you this in real time but you'll see when we get to the composer update step that it would be a quarter of my talk just sitting here waiting for composer to finish updating all the dependencies which does slow things down a little bit with using composer but you do have the benefit of having that separation. So I've made the change. I'm now running composer update to update all my dependencies and I cheated here, I sped the video up a bit. So then this will run and it's pulling down all the different dependencies. So we've got PHP unit coming in, we've got the develop module coming in here and so on. So we'll give this a sec. If any of you want to have a nap I'll let you know when it's time to wake up. Come on. So that's finished and then we can have a look and see our changes. The other thing because this is done, I'm actually using platform.sh for my demo here. It gives me a lot of integration here so once I'm done all I do is run platform local build and it will actually go and deploy that all into my Drupal VM local environment so I can continue to work with this code if I want to. The platform.sh guys are here. If you have a chance go talk to them, check out their stuff. I'm very impressed with their stuff at the moment. So now this is, well hang on, I've got to, so I chose the two files that have changed. We're pretending that I've tested this locally just for doing it a bit quicker and then I'll add the files, actually I'll diff them first so we can see our change has gone into the composer file and these are all the dependencies that have been updated as well. Super exciting reading diff files for hashes that have updated. So now we'll do the git commit. Now for some reason it stopped echoing the command output but we'll do the git commit and okay so we've committed the files now we'll push them and then we'll go have a look at what shows up. So if we have a look, you can see here in progress it's already happened on platform.sh and here it's actually rebuilding my environment on platform.sh for me. So we'll switch back over there in a sec. Come on personally record the video, switch. That was a bad edit. Okay so now I've switched and here's the site as it stands at the moment. We'll just use a drush ULI link because I always forget my credentials so we'll log in and now we'll jump to our modules page and we'll scroll down and we'll scroll down, thank you and scroll back up so we can find it. There we go, there's our develop module. So that's been all handled by Composer and the automation has gone and deployed that for us. So that's how quick and easy when you've got a platform that actually supports Composer based workflows you just commit the Composer files and it goes and deploys it for you. So the next thing is performance metrics. One of the things that, once you've got a site that's live you should be regularly looking at how your site performs because the thing is you want to know where the bottlenecks are in the site. You shouldn't be waiting for the site to go down before you realize where the bottlenecks are and there's a bunch of really good tools for this stuff. There's Blackfire, the guys are next to the platform SH guys here downstairs if you want to talk to them. There's also New Relic, New Relic I use for quite a few sites and New Relic gives us nice little graphs like this. So this is showing me that the average response time for the server is like 250 milliseconds but I don't know what happened yesterday but something wasn't too good. And we can see that the user experience wasn't so good either. You really want it in the blue with it dipping down into the green occasionally. If you're dipping down below this orange line that shows that your customers are going to get frustrated. And this is also showing how many requests per minute the site's not doing many, it's only doing 10 per minute. But one of the things that I tell people about using tools like New Relic is don't just wait until you've got a problem and go in there and start clicking around going can I find where the problem is. You need to be in here regularly understanding what your individual sites look like because you might have a nightly cron job that causes a spike in database load but if you know that that happens every night at 3am and no one's really on the site at that time then that's not going to be a big problem but if you're noticing that a particular page is causing five or six second page load times then that's something that you should dig into. But understanding what your graphs normally look like helps you recognize where the problems are. If you're just going in when there's a problem then you're going to miss the key problems in these graphs. Another thing that you should look at doing is visit Drupal VM and I actually didn't put the domain in there. So DrupalVM.com it's a vagrant. How many people here use vagrant for local development? That's awesome. I wasn't expecting there to be so many. That's great. Now this time for all of you who didn't put your hands up, you have my sympathies. So Vagrant allows you to run a virtual machine that gets provisioned with consistent configuration and DrupalVM allows you to set up an environment that you can take the stuff that Jeff Girling has already built and you can use it as is or customize it so it closely replicates your environment. If you're deploying onto Acquia hosting he actually has a configuration that replicates the Acquia hosting environment. So this allows you to debug things locally and have it as close as possible to your production environments which is a lot better than running XAMP. So all the people before who had their hands up for XAMP you should check out DrupalVM. Another thing they did was go for a regular release schedule. Initially they decided once a month and it was the second Tuesday of every month and that worked well. It gave them some consistency with their deployments. But then Amy from Marketing came along and said have a nice stage content changes because the code stuff is all working pretty well with the new platform but content changes, it wasn't so good. All that Gary could suggest was manual copying and that was causing all kinds of problems for them. Pages were being missed, links were breaking because the title wasn't copied exactly and all kinds of stuff. It was out. But then Gary found the deploy module. How many people here have used deploy? Yes, good work. I'd like seeing those hands go up. Now for those of you who haven't used the deploy module or if you haven't heard of the deploy module today 4 p.m. Hall 31, go check out using deploy in Drupal8 with Dick Olson, Tim Millwood and I've forgotten Abyshek's last name. Are any of those guys here? Yeah, that's him. Any of the guys doing that presentation here? Okay good, I don't need to go to their presentation today then. Alright, so then another thing we need to deal with is configuration. Configuration has changed in Drupal8. I think most of us who have been dealing with configuration in Drupal7 have been working with the features module, which features is great but there's a lot of problems with features at the same time. It's only great because we didn't have an alternative, whereas Drupal8 we've got CMI. Now CMI, it means we don't have to pass around database with our configuration code and all of that, not code, content and configuration all kind of mashed up together. Now we can do UI imports for configuration. The problem with doing a UI import is that we can't have a fully automated deployment. Say you're doing a deployment in, well you shouldn't deploy Friday afternoon unless you've got an automated delivery pipeline. So say you're deploying first thing Monday morning, the developer had a big weekend, they kick off the content and code deployment but they forget to do the config import, then you've got wrong configuration on your site and you'll have trouble. So I strongly recommend that you use Drush and I'll take you through a workflow that I'm advocating people use for Drupal8. Again, I'm sorry for the people up the back. I should have made the console bigger. But what I'm doing here is, so I'm going to export the configuration. So I run config export and provide a destination path if I don't make typos. So we'll give this a sec because I do keep on making typos. And so this is exporting it to a directory in my Git repo. And so I've got two directories here, base and dev. Now base is my base site configuration. That applies across all of my environments. And then I also have, so if we do, if we have a look, here's all the YAML files with all of the configuration for my site. Now I'll commit that change and so that's gone and added all of those files. Now I'll update the slogan. Now what I did here was export the configuration when I shouldn't have. I redid the video this morning and I should have done it yesterday. But now if we do a git status, we say that this file here has updated. We do a diff and it'll show our configuration changes if you can read that. But you can see there's red and green that indicates that it's changed. Now ignore me trying to import the configuration that I've written to disk that matches here. That of course won't make any change. We'll just wait for this bit. Also if anyone here knows how to put proper video controls in a revealed JS presentation, come see me after this. I'd love to know. So what we see here is we've got our configuration where we're providing the source directory. This isn't going to work because I'm being an idiot. Just pretend this is like a real live demo where the presenter always makes mistakes. Just include that so the video seemed real. You don't want an overpolished video. So now we're back to the site. We can see that we've got the slogan and we've got the site name. What I'm going to do here is I'm going to set the site name to dev site, save the configuration. Now what I'm going to do is do a configuration get to select just one piece of configuration. So I do Drush C Get. Then I need the name which is system.site and that actually exports the YAML. Now I redirect that output to a directory. I've got a blog post about this on my blog with the actual details for those of you up at the back who can't read what's on the screen. So this will actually export just that single piece of configuration. So if we do a get status, we say that it's just dev. I'll add that and we'll commit it. You'll see when the commit happens it's just one file whereas before there was a mountain of files. So I've added the dev, I'll do the commit. So now I've got stuff in base and I've got stuff in dev. So now we'll actually revert the name change that was here before. So now we've got our repo back the way we want it. And what we'll do is we'll actually do an import because at the moment this is our config. We've got dev.site and the slogan. And so now we'll import our base config which we'll go back and have a look at once it finishes importing. Sometimes I feel like Drupal H should be called Drupal Wait because you've got a wait for compiler, wait for configuration import. It's like wait, wait, wait. So now we will refresh this page and here we go. So that was a bit fast but we've got the stuff the way we wanted it. And now we'll do, we're importing from dev but we're specifying partial which tells it that it's a partial thing of configuration and it's back to reading dev site. So that's how we can have a multiple environment configuration. So when you're automating stuff because you might want something different in your configuration from one environment to another. So no, no, I don't want that. Shut up. I actually killed Chrome so you wouldn't see how many tabs I had open. Then I clicked the wrong thing. All right. So now, oh no. Okay, cool. Now we're back on track. All right. So I should disable rescue time next time I present too. I thought I killed everything. Okay. Actually, side plug. Rescue time is really good for seeing where you waste time during your day. So now Aida is asking, can we make faster releases? And Gary's like, I don't know, like, you know, releases are a bit problematic for us. Every time we do a new release, there's new bugs. How many times has people heard that from like managers and stuff that you can't release more often because every time there's a release, there's more bugs? Yeah, yeah. I know a couple of managers who push that line. Not looking at anyone. Okay. One of the issues with long release cycles is long fix times. It actually takes quite a while to get your fix through smaller releases and actually have less risk because you're making less changes. It also means that you can make, you can get your fixes in faster. So, you know, Gary thought, well, what's it going to take to be able to do more frequent releases? So a really key thing is automated testing using PHP unit for your backend stuff and Bahat for checking that the behavior of the site is as expected. Excuse me. One of the good things about using Bahat over like Selenium, like Selenium is great, but trying to get a business person to understand Selenium is hard. You can't go, here's our Git repo with all of our Selenium tests. It's going to verify stuff that'll be like, oh yeah, that's great. But how do I know that? Whereas if they can actually read through the Bahat tests, it gives them a clear idea of what you're testing for and what to expect. So continuous integration is a really key part of this. So having automated stuff that does your mergers, does your testing, all of that stuff. Jenkins is really good. I've used Jenkins for six years, maybe longer, back when it was still Hudson. Travis is one of the new cool kids on the block. There's quite a few Drupal projects using Travis. There's also a paid private version if you want to use that. CircleCI has also got some traction in the Drupal community. I need to play with it. Co-chips pretty good, not so suited for Drupal, but still a great product. And there's a bunch of others out there. I'm plugging products today that I'm familiar with, and I would happily consider using on my own projects. But there's a bunch of other stuff out there I've never tried, so it still could be good. Just because I don't have it up here doesn't mean you shouldn't use it. Now this is, I thought I'd use one of Dick Olson's projects to show off Travis to win some brownie points. But it didn't turn up, so I shouldn't have used his. Okay, still no excuse. So what this is showing is that it's run the tests and it can actually run it against multiple versions of PHP and multiple versions of Drupal. So this is running PHP 55 with Drupal 8.0.x and then PHP 5.5 with Drupal 8.1.x and the same with PHP 5.6. So if you're in a situation where your hosting vendor is changing from one PHP version to another, you can start running tests in parallel with the two different versions to make it easier. To transition. It'd be really nice to have PHP 7 as a target and have that up on there as well. Now I really think that your absolute maximum release cycle for doing code changes should be once a week for a site that's under active development. Now some of you, your project managers will just have nightmares if you go back and say, hey, we should do weekly releases. It's not going to be like go from we're doing releases every six weeks to doing a release every week overnight. You need to get these things in place. But once you get into the habit of doing weekly releases, people get more confidence around the release. And yeah, sure, you're going to have bugs. Things may break occasionally, but if you're in the practice of releasing once a week, once a day, once an hour, then you can make those changes. You can fix things quicker and it'll actually make your team go faster. And also people from marketing and management and they can see what you're producing and they can say, we don't like this bit or that bit. And you can make those adjustments quicker. So it actually makes your team able to deliver to meet the business needs a lot faster. Another really key thing is communication. Now one thing I don't have up here is a recommendation on a ticketing system because I tolerate JIRA and hate just about everything else. So the communication stuff, you should have a wiki if you're using GitHub. Who here uses the wiki feature on GitHub for project documentation? Okay, good. If I come back and do this talk again, I hope to see a lot more hands go up. I really like the GitHub wiki system for project docs. Google docs is also good, but it doesn't support markdown so it's not so easy to work with, but it is easier to put pictures in. Another really important communication thing is real-time chat. These days I could not do my job properly without Slack. It does make such a difference. You can have notifications coming in from different systems. You can have all kinds of stuff being centralized into chat which helps give a lot more visibility not only to your team, but to other people as well. So if you get the chance, have a play with Slack. Hip chat is good. It doesn't have quite the interest and the integrations these days as Slack does. Slack pretty much came from nowhere and now dominates chat. If you really get stuck, start burning the furniture in the office and do smoke signals to communicate with other people. Actually, I think the lawyers won't be happy if you start burning the furniture, so please don't do that and don't sue me if you do. Another thing you should look at, building is dashboards to expose data to management. What's the team's velocity look like? What's coming up? What's been dealt with? How's the site performing? Provide all this data to people, expose it and allow people to see what's actually happening with the site rather than all they see is go to the website, it feels slow or I don't like this or can you make the logo 20% bigger because the logo is always too small. Also status pages, you can build those for internal consumption only if you want to track how things are running. Really importantly, the real message from today is embrace change. This needs to be an iterative process. You can't just go okay, we're going to do this tomorrow and have it all work perfectly. You're going to have to iterate just like you do with code. It's also why I didn't come in and go this is the one perfect way to do deployments. I hope I've given you all some idea of some of the things you can integrate into your workflows to make it so you can deploy Drupal more successfully. I hope that I can use one of my friends to actually help give you some idea of what this stuff's like. You won't get it right the first time. When you first start off, you're going to be like the guys in this jeep. Hang on, we need audio. Once you get this stuff right, you too can be seen. That is my favourite Bollywood scene. I love that clip. Danyvald and the English speakers, thank you. I've had a bit of fun doing today's presentation. I hope there's a few questions or else we're going to finish a bit early. While we're going through this, feel free to follow me on Twitter. Things on Twitter get a bit crazy with me sometimes, but that's where it goes. If you wanted a bit more serious, you can find me on LinkedIn as well. Any questions? Which are like a couple of points or a border. Do you really recommend doing this even in those projects? There is some overhead for setting this stuff up, but I don't know. Do you work for an agency or do you work freelance? Agency. Agency, yeah, sorry. One of the things that I think a lot of clients can benefit from is agencies actually investing in these processes. Now some clients are lucky enough to be big enough that they can go to the agency and say you're going to follow our way of working, but it's my understanding that most clients go to the agency and they're like, we just want a site and you guys build it. Whereas if you've got these processes in place that you use for all of your projects or 90% of your projects, even though there is some set up cost, you can actually spread that set up cost across a year's worth of clients. Just take a bit extra on the bill and the client will actually see a higher quality outcome each time because of that investment. I think it is because what you can do, one of the things I didn't cover today is I actually think that with your deployment stuff, you should be planning that when you're planning your content types when you're getting the wireframes done. Deployment is just another thing that needs to be planned and built out across the project, and that means you can be testing that deployment system and tweaking it across the two months as you're building it out for the client. So you can still do a fair bit of it. The issue with not having automated testing is you're probably going to miss stuff, but if you've got an automated deployment system so you can release more quickly, every time you break something, you can get the fix wide faster. It's worth using this? Have you been using automatic testing? I think it's still worth using without automated testing, but your velocity will be faster with automated testing. I know there's a few other people who've got questions. I'm more than happy to talk to you more about this afterwards. So there's this guy here. I was just wondering, I just had a question about the Composer workflow aspect of it. So does the Composer workflow aspect replace the Drush Opsi process? No, it doesn't. Well, I don't advocate using Drush Update Code. It replaces the Makefile workflow. Makefiles are great, but they're a real Drupalism, and you can't include non-Drupal dependencies through... Well, you kind of can, but it's a hack. Whereas Composer, you can include all of your code dependencies. I think it's a better option. Yeah, there's a guy up there. The question was, can you specify the PHP version in Composer.json? You can define a PHP dependency version in your Composer.json. I'd recommend only specifying a minimum PHP version. If you know that something's completely busted with seven, then specify a range. But I would be recommending specify a minimum version, and then use your test suite to run with whichever target version or versions you want to use. You want to use Composer.json file with a Drupal module? Yes. Everyone here who's working on Drupal modules, you should have a Composer.json in the root directory of your module, putting in the basic information about the module, but also specifying any third-party dependencies. Don't go putting libraries in your modules and also don't use the libraries module. It was great for Drupal 6. That was many years ago. We're now doing Drupal 7. I mean Drupal 8. Some of us still get stuck doing Drupal 7 sometimes. The issue is about if you must have one, but there's no discussion about can you have one. I say the decision is still to be made if they're going to be mandatory. In the meantime, put one in there so if they do decide that it is going to be mandatory, you're not going to have to go back and do it. I've read through that issue. Any night I'm struggling to fall off to sleep, I go find the big long discussions on Drupal.org and you get about 60 comments in and then it's just like, I've had enough of that. Any more questions? Yes. Docker is really good. The reason why I didn't go into Docker today is I could have done a whole presentation on Docker and one of the other issues with Docker that you get into is, do you want it for local? Do you want it for production? Do you want it for both? How do you do orchestration? There's just so many possibilities with Docker. I've been really excited about Docker for about three years now and I think Docker is awesome, but I can't do a 45-minute presentation on how to do Docker with Drupal at the moment. There's just too many options. Any more questions? Can you elaborate a little bit on the PlatformSH workshop? I saw that you were running Composer somewhere outside the VM and then somehow you got deployed into the VM. Platform.sh isn't a VM. It actually deployed it to the remote environment for me. I updated my Composer.json file locally and I could have been running a VM locally as well. I just skipped that step for time, but I could have updated my Composer.json, run the PlatformClient build locally. That would have run the build and then I could have checked that locally, commit my changes and then that gets deployed onto PlatformSH. No worries. The guys on the booth will be able to give you a lot more info about how it works. Talk to that guy there if you want to know about Platform. Cool. Thanks everyone and if you've got more questions I'll be here today and I'll be around for a part of tomorrow so just grab me and we can chat. Actually no, one more thing. I'll get in trouble from the DA and there's a board member here so I need to tell you. Go rake my session.