 HHVM which stands for Hip Hop VM plus AngularJS and some other things you can only do with platform SH. So in case you want to still run away and get out of this session if it's the wrong thing for you, we're going to use an example application using those technologies to show some of the interesting workflow challenges and development challenges that you might run into as a team and some of the ways that the product that Augustin and I work on helps solve that. So it's very product oriented. This is one of the sponsor sessions. So we get to talk about our product. So if you don't want to hear about our product, get out of here. And that's fine, no offense taken if you want to hear something less product oriented. I just wanted to get that out there up front. Also if you were worried about the word headless and the fact that I brought a French guy with me, don't be worried. We're not going to be doing any physical decoupling today. So who's this guy standing next to me over here? His name's Augustin de la Porte and he is in the platform team. He is in charge of software delivery. Literally not a single byte of code goes deployed without his intense scrutiny. Kind of, yeah. And I'm sure you know Robert Douglas, right? So he's been in the Drupal community for years and he's now the director of support and director of operations in the platform S.H. team. Great guy. If you don't know him, you should really talk to him because thanks Augustin. He's actually a great guy. You want to talk about commerce guys? You talk about commerce guys. OK, so maybe you don't know the story. Commerce guys is behind platform S.H. Platform S.H. That's the solution we are going to talk about today. Commerce guys is the creator of Drupal commerce and the distribution behind that also commerce kickstart. And we're now working on commerce 2.x, which is a next generation for its commerce for Drupal 8 and for any PHP-based application. And yeah, basically commerce guys started to work on a project called Platform S.H. as an R&D project at the beginning. And it grows, it grows, it grows and then the team, yeah. Well, what we wanted initially was to build an ideal hosting environment and development workflow for working with Drupal commerce. When we got done with it, we realized what we'd built was an ideal hosting environment and work development workflow for basically any PHP application. So about a year ago, we took that to market under the product name Platform S.H. which we're going to show you. And in the meantime, we've also realized that the generic benefits that you get from our product are also extensible to other application domains. So we have in the final stages of testing, this week Python and Node.js support as well. So when you think about the product, and we're going to talk about it a little bit more in the focused context of Drupal 8, but it's good to keep in mind that it's a general platform as a service for any PHP application now. And in the very near future, it'll be a general platform as a service for Node.js and Python as well. And we started implementing all the services that you might need for Drupal. And then we extended that with more services that other PHP-based framework might need. So since it's a sponsored application, sponsored session, we're going to go and give you a small tour of the key features of the product. So this video is just to set the base. When we talk about platform, what are we talking about? Because the rest comes in the context of this. So one of the key things that we offer for a development team is that for every Git branch, you get an entire copy of your application with all of the data. And you get that in about two minutes time. So all you have to do is Git branch your application. And then in two minutes, you've got a new URL, a new environment to test on. We kind of killed Dev stage prod, that no longer exists because that's actually a limitation. What you want is for every feature branch in your story, or every story branch in your sprint, a way to test your application. And we provide that. One of the hard things about providing that, if you were to do it yourself, is the data synchronization. If you have 10 gigabytes of data, MySQL export, MySQL import, go Git launch, come back. Hope it's done. With us, you've got that in two minutes in between the environments. And it's quite fast and quite easy to do. It makes the branching and merging of your development workflow at the infrastructure level as cheap as branching and merging at the Git level. And we've got specific starting points for applications like Drupal, Symfony, Vagento, Wordpress that get you going up and running quickly with those stacks. So for example, with Drupal, it makes sure Drush is available as a dependency, knows how to handle your settings PHP file, provides the right private, public, temporary mount points, et cetera. And it's not just for the typical MySQL solar varnish Redis stack. If you want a rather MQ as a message queue, or if you want to use Elasticsearch, or maybe your database is Postgres, we support those and a lot more services. And what you can also get is that we don't bypass your development workflow if you're using Bitbucket or if you're using GitLab or GitHub. Platform will just integrate nicely within their UI. So we have add-on for GitHub, the add-on for Bitbucket. And you see for each pull request that you might push or each branch that you want to test on, you have a specific environment that is deployed on platform automatically. So you just push your code to GitHub or to any Git management hosting solution you're using, and it's going to deploy. And we're hosting the symphony documentation like that. So every pull request that is pushed to symphony documentation is actually automatically built on platform. So every developer can just push his code, test there, and review what's actually been built. And we support something also, which is that you can push multiple applications inside the same Git repository. So basically, you can push your Drupal as a back end and as we're going to see. And Angular as a front end for your application, you push that into one repository, and Platform will be able to build all of those at once. And you can try it for free. So you can see us at the boost later. That was for the basis of the solution, right? So now, we want to. So let's introduce the problem space that we want to talk about. And specifically, I want to make clear, first of all, what the headless Drupal 8 and the AngularJS and HipHopVM, I just want to lay all those out for everybody. It's kind of out of order from the slides, but I think it's important. So what we're going to show you is a Drupal 8 application. It's a movie database. And we're actually taking this from an example that we got from DrupalCon LA. So I think we can just go there and show that to you. Yeah, it feels like the right time to talk about it. So we got this from Travis Tidwell from the DrupalCon LA. Is he in the room? Travis, you're here? You're here? No. Call out to the man who made the application. So we didn't do anything new with this application because it's a great prototype already for the general pattern. And that is to use Drupal as a data store and an API provider. And what it is is it's a movie database. And however you get the movies in there, you can use the Drupal front end or you can import them somehow. The idea is that then Drupal is going to provide an API to applications or other clients who want to use that data to build an application based on movie data. And what Augustin's showing here is some JSON output. Is that JSON? Yeah. JSON output from an API call to list the movies or a specific movie. So the idea is that Drupal no longer is providing the front end application for the actual end user. It's providing the back end management system for the database and the APIs for the front end, which then becomes the AngularJS application. So with AngularJS or any of the other, you probably all saw Dries' keynote yesterday where he talked about this a lot. You can make really rich front end experiences. And all you have to do is call out for the data to the right API that you need. And it uses that and it provides a real time experience. If you add a movie to the database, it'll appear in your list like magic. And we're going to show a little bit of that. So that's the Drupal site? That's the same company application. Oh, that's the Angular application. The Angular, sorry. I'm not sure if you've tried to actually build an API with Drupal 8, but it's really super easy, right? So you have your content type and you can expose that as a restful API. So you don't have anything to do. There is a restful module. For that to work on platform, I just had enabled the course module so that I can do cross origin request, because if you look at the two URLs here, we have master dash project ID US Platform SH. And then you have a different URL, which is Drupal dash dash dash master. So it's the same branch, but it's two different application with two different URLs. So if they need to communicate together, I'll need to enable the course module. And that application is very easy. There is a video, so again, from Travis, from Drupal Con LA. And really, you should watch that video. It really explains all the concept between those two. Yeah, that way of working with Drupal 8 and Angular. And it's like complete decoupling. So Drew yesterday talked about different decoupling, the progressive decoupling, and the complete decoupling. And that's the complete decoupling. All right. And finally, in our source code. Yeah, the source code is available on GitHub. So if you just want to check the URL, you can just fork that repo and push that to platform if you want to try. And you're going to have a headless Drupal working on platform with Drupal 8 and Angular. And you see that I only have like two folders, one for the Angular application, one for the Drupal application. And some images just for the readme and the platform, the dot platform folder, which is specific for platform SH, which is going to list all the services that you actually might want to use. Thank you. Great. So now you know what the application does. And we'll talk about the hip hop VM part a little bit later. I wanted to make sure we understood what the application does before we talk about the problem space that we want to solve. So we want to do that type of application development. What problems are we going to run into? We identified three categories of problems that we're going to run into. And we want to show how we can solve those problems. So the first, and this is a general DevOps problem. This isn't specific to the application that we're showing you, but it's relevant enough to talk about in any case. And that is pushing and managing non-code changes to a runtime environment. And this could be all sorts of stuff. So this could be like the PHP versions that you're using. Obviously, we're talking about hip hop VM. So if you're not using hip hop VM and you want to change to it, you have to change your PHP runtime. That's a non-code change to a runtime environment. Another type of change would be adding new PHP extensions, changing PHP INI. I'm very focused on PHP here, but this could extend to any aspect of your stack configuration. Or going a step higher, adding whole new services, such as maybe you'd want to try out that elastic search that we mentioned. Maybe you do have a message queue. Message queues become particularly relevant when you're working between multiple applications, because a lot of times you have asynchronous requests that need to go between them, or data that needs to be moved between them, and that needs to be coordinated. And a message queue is a perfect solution for those. So having that available to your application is a great advantage in those cases. And since we're already showing an example of an application, the Angular application that takes JSON inputs as its primary input, that's the Angular app, then a lot of people will be interested in using PostgreSQL, because PostgreSQL is doing just a great job these days of providing a JavaScript native document-oriented data store, similar to what you'd expect from a MongoDB, which then makes PostgreSQL an ideal solution for building an Angular front-end application based on data stored in the PostgreSQL. So maybe you want that. These are all changes to a runtime environment that you might make. And how do you coordinate that across an entire development team? And you don't want those changes only to happen on your production server. You want those changes to also apply on your dev environments, your sprints environment, any test environment that you might have, because you want that to be coherent with what you're going to actually deploy on your production site. So you don't want to have to manage those changes on each of them. You just want to change them at one place, and so they get deployed everywhere. That's the problem that people are facing. The next problem that we identified is simply the human workflow aspect of coordinating multiple sub-teams in a project. So we're presenting an application to you where there are at least three roles that you might run into. In a typical Drupal project, you've got this division between Drupal Coder and Drupal Themer, as made famous by the epic battles between the Drupal Coder and Drupal Themer at many Drupal cons. Unfortunately, not this one, but they've got a running session where they try to solve the same problem from the Coder point of view and from the Themer point of view. So those are two roles, but those are within one project. That's already difficult enough to coordinate between coders and themers inside of Drupal. But when you add a complete new domain of expertise to this, the Angular application, and this person might know nothing about Drupal whatsoever, then it becomes a little bit more challenging to coordinate your team's workflow and the deployment workflow and the sprint plannings, et cetera, et cetera. So some of the goals that you have there are to achieve independence amongst the teams so that you never have a case where one team is blocking the other or where you have to have an overly expensive amount of communication between the teams about, what are you doing today? What are you doing today? OK, then let's, you don't really want that. In an ideal case in an application like this, you'd specify an API and the Angular team would go to town. And the Drupal team would fulfill the API and whatever needs they were doing, like the role of the data entry. But deploying this to testing environments, staging environments, making sure the stakeholders can see it, making sure the project managers can sign off on it can be a very complicated process because you're literally deploying two separate applications from two different teams, but they have to be in lockstep with each other. How do you version control that, right? If the Angular team has their own Git repository and the Drupal team, their own Git repository, how do you match the version they want tested with the version they want tested and how do you switch between them really easily and platform solve some of these problems? Then the third problem that we identified is to replicate complex build processes across various areas of expertise. We've very strongly moved to a time in web application development when you write code that builds code. You don't write the code that you run in the application. You write code that builds the code that you run in the application. So what do I mean by that? Let's start with a Drupal example. With Drupal, we often use things like Drushmake to build a Drupal site, which is in essence, writing some code that will build a Drupal site. You might write some custom modules. You might store those in GitHub. You might pull them in during Drushmake or you get submodules. Somehow, you're going to piece together a bunch of code, some of it public, some of it private, some of it specific to that project, some of it maybe specific to your agency, and that's going to become your Drupal site. And this is a common pattern for actually all web applications. If you're doing a symphony application, you're going to use ComposerJSON to do the same thing. If you're doing Node.js, you're going to use NPM. Maybe you're going to use Bower. We've got PIP, we've got RubyGems, and orchestrating all of this build process is now becoming an interesting task. Furthermore, when you deploy a Drupal application, you might have subsequent dependencies on things like Ruby just so you can compile SAS. And you also have a dependency on the developer know-how on how to do that. So what are you using Yeoman locally? So he's using Yeoman so that they change that he makes to his HTML files that he's using for the slides, automatically recompile the CSS and everything. Yeah, this is grunt, grunt. Oh, that's grunt doing that? Okay, so I don't do this stuff. Thanks. I will talk about it. But this is a developer level know-how that then becomes hard to replicate. So I recently did a very small Drupal 8 site where the person I hired to do the theming compiled all the SAS. That meant I couldn't easily go in and change the CSS anymore without also knowing how to compile a SAS, which I didn't at the time, which became a blocking issue for me. I couldn't apply my know-how to the site. I was dependent on him. How do you overcome that? And Platform can address that. And this becomes more complicated when you've got more than one application going on because then the areas of domain expertise are so separate that you can't possibly just cross over. Like he could teach me how to compile SAS for that one case. But if I needed to go and modify the AngularJS app, I'd be completely lost. So I might not be able to even deploy it if I don't have all that domain know-how. And by complex build processes, we also mean like Rob talked about Mac file for Drupal. But if you push your composer.json or package.json, you don't want to push all your vendor folder that you have locally because the version might change. And you want to rebuild that all the time to make sure that the versions still are current with what you have. So you want to keep your git repository as small as possible and listing only the dependencies that you actually want to use with their versions. So a composer.log file, for example, you don't want to push all of the dependencies that you have on your site, right? And that's what we call complex build processes. You want to have everything downloaded when you build your actual environment. And once you've got that process, you want every member of your team to be able to execute it perfectly without having to know every step of the way. Yeah, definitely. So let's talk about each of them a bit now. Well, we introduced this before, but I think there are a couple of details that now that we've gone through the problem space, we could actually highlight. Do you, yeah, no, let's go on, you're right, hip hop VM. So the other buzzword in our session title was hip hop VM. For those of you who might not know about it, hip hop VM was originally released by Facebook as a PHP virtual machine that greatly accelerated the runtime execution of PHP so significantly that that's one of the key ingredients about how Facebook has achieved scale, the scale that they do. And we are happy to announce today that a platform is capable of running your PHP projects in hip hop VM as well. Why would you want that? The chart that you're looking at is the comparison between PHP 5, PHP 7, which is the up and coming version that is not ready for production yet, but is showing a lot of promise. And then the yellow bars are hip hop VM. And in this chart, bigger bars is better. And you can see that for different applications, Drupal 7, Drupal 8, Drupal 8 cache, media wiki and WordPress, in every case, hip hop VM significantly outperforms the others, meaning you can run more sites with more users on less infrastructure, saving everybody money and giving your customers and visitors a better experience, that that's why you would want it. You should really read that blog post. It's really complete and it's really interesting because that chart just by itself doesn't, I mean, one of the yellow is good, but. One of the things that you see in this chart is that the hip hop VM team for the last year at least has been testing explicitly all of these applications and more to make sure that they completely satisfy with no problems the compatibility requirements for, say, Drupal to run inside of it. And they've now achieved 100% compatibility for that, which is why we felt confident deploying it. Yeah, we haven't talked about that yet. We haven't publicly announced with the blog post. What, we haven't actually publicly announced that? No, you guys are the first one to hear about hip hop VM on platform. No, we haven't. But I thought we had a blog post. It should be ready. Yeah. I was going to tell them to go read the blog post. Christian, Christian, do it. Okay, so Christian is the guy that wrote the blog post. Let's deploy that right now, right? That's actually a good feature. Are you sure it's ready? Did somebody proofread it? That's a good feature, good feature to show because it's actually, you can see. I can't believe my team is going to live deploy in front of you all. It's a blog post. So it's the live deployment of a blog post. But if I got internet and it, yeah. So you're going to actually see a live deployment. That's basically my job. I click on the merge button and it gets deployed. So that's... Oh yeah, this is the part where he scrutinizes every byte that gets deployed. Now you can see it in action. Okay, it's called draft. So he's on GitHub right now? So yeah, so you see Christian pushed to that branch and Patrick, oh Patrick, you reviewed that. Awesome, that's even better. So you see here I got a details button and I can access that URL and see actually the website. So it's a hosting on platform. It's the idea of the request. Let's go to the updates and check that. HHVM, yeah, cool. So simply by virtue of having a pull request, there was already a built environment to test that change. Okay, it looks good to me. Yeah, let's merge that. Did I mention reviewing every byte? So if you go to the platform, I say it's blog posts, you'll actually see that it's not there. I wanna, yeah, you see it's not there. Let's merge that. I trust you on that Christian, right? It's a Jekyll-based website. So it's a static website, but we can still build that with platform. This process would have applied to any stack. Merging. Okay, so now it's actually building my, I could go to the platform UI. How long does it take? It takes one minute. It needs to download the different libraries. Let's go to the platform SH project. It wasn't part of the, but it's a cool thing to show, yeah. It's a good feature. Improvising a stack. So you'll see that actually the master environment, the production environment, it's getting rebuilt. So not on that one, I'm just loading the other project, but the internet is like not wanting to have me there. Okay, so I can explain this because it's quite interesting. So when you push to get on platform SH, that triggers the entire build and deploy process. Okay, the entire release mechanism on platform SH is get push. And when you push to get platform does several things. First of all, it looks to see what services you have. And that's in the ML file. And this could be, this will be like PHP, MySQL, Postgres, MongoDB, Elasticsearch, Solar, Redis, RabbitMQ, Riemann, ZooKeeper. Load the page to check that it's there. Just someone can load the page because I'm caching. So it's there. Woo! Let's deployment. So you can choose any of those services and you put that in the ML file and platform finds that. And then it looks for the relationships between those services. And it makes an ordered graph of dependencies between them because not all of the services are serving the same applications. Then it looks for the applications that you have. And in the example that we're showing here, there are two applications. There's the AngularJS application and the Drupal application, but you could have more applications. If we had had more time and I wasn't so busy being a bull yesterday, then we would have had a BHAF application that would have tested both of them concurrently as a separate development stream, but in the same Git repository. And once it finds the applications it finds out from previous Git hashes and build processes which ones it's already built and which ones haven't changed and which ones are changed and it won't touch the ones that haven't changed. So the ones that have changed then it will look through the dependencies, it will install the dependencies, it will look for the scripts that you've put in your build and deploy process and it will start building that. And it will build that and package it into a read-only code slug, which is essentially a Squash FS read-only thing that we then will transport to your application and mount it. And at that point, we at the edge freeze incoming requests for that application, meaning we store them in memory as they're incoming and we turn off all of the services that are in that ordered graph of dependencies. We replace the code slug and the services because the code might have changed the services that you need like you might have introduced RavaMQ, in which case we've got all of those services up and running on that code slug and then as soon as all of the dependencies have reported back that they're fulfilled, then we unfreeze the requests coming in at the edge and they get replayed into that running application as if their internet were just really slow. So the requests don't get lost but your users might wait 30 seconds to return which is in fact better than putting your site in maintenance mode. And so here you see all the branches that we've pushed and automatically that's what I was showing. When you merge a pull request, you don't need the environment of the pull request anymore so platform deletes it automatically and the URL just doesn't work. So you don't consume resources that, I mean you don't need to go to the website and say I don't need this environment I want to delete. It's going to be taken care of automatically. It's pretty cool. Let's go back to the solutions. I give a hand for my deployment manager for spontaneously deploying live. All right, so we presented the problem space. Now let's go through the solutions that we have for those. When you want the solution to managing non-code changes to a runtime environment, we've kind of pieced that together already. All of the non-code changes to your runtime environment that you manage on platform.shr actually encode. They're in the YAML files that are the metadata for your project. So for example, if you want to change from PHP 5.5 or 5.6 to hip-hop VM on platform, you simply update your YAML file as shown and you get pushed that and then that process that I described takes place. It's that easy. If you want to have different PHP extensions, for example, if you want to do some profiling and you want to take advantage of the Sensio Labs Blackfire product, Blackfire is a profiler for PHP. It's really incredibly good, but you need a PHP extension for it. So you would add that to the list of extensions that you need to the runtime. That's not actually a PHP extension. That's a platform extension. Which one? Blackfire. Blackfire is a PHP extension. Oh, okay. Yeah, okay. It's the agent, actually. And those configuration leaves in your code base. So once you push that to a branch to get deployed and then when you merge that, it automatically takes exactly the same configuration. So you don't need to care about configuring the production server. Meaning your developers can, at the branch level, experiment with the infrastructure changes that are needed for their feature and test it there on that branch. And then when you merge that into the sprint, then you can test it against all of the other developers' changes for that sprint. And then you merge it into QA or staging or however you named your branches. And by the time you actually deploy this non-code infrastructure change, you've probably done it 20 times. You know exactly how it's going to work because you also, as I mentioned, have the guarantee that the code, an environment that's built, will be exactly the same for that code every time as long as the code hasn't changed. So your deployment is extremely predictable. And the excuse like it worked on my machine won't appear here. It worked in dev. It worked in my machine and doesn't work on prod. That cannot happen. So this is the services YAML file I was mentioning where you can list the services that you want running. If your developer wanted to use a rabbit MQ, getting that into their project is those three lines. You name it, that's the first key. Then you just say what type it is and how much persistent storage it needs on the hard drive. And for some services, you can also add some key and values. For example, for a solar, you can have your custom XML configuration scheme for a solar, so you'd add the configuration right here. Right, so if you need Cyrillic characters or multi-language support, or if you want to do Ngram. You did that right here. Indexing, then you can actually do that. We don't limit what you do on the platform. Yeah, so that was the first. That was the first solution. So the second problem was coordinating multiple subteams in a project. So what I've got here, I hope that's legible. This is the screen on platform that you use when you add a developer to your project. And the hierarchy that you see there, it's really small. Is it possible to plus, plus, plus that? Yeah, I must go around you. No, that doesn't work. What? It's master staging, testing, and I've got AJS Sprint 17, and then RM numbers, and these are mythical branches in a sprint for the Angular team that's being managed on Redmine. So that will be, I'm just showing how it will look here. Right, exactly. This is essentially a hierarchy of branches. Okay, and then if you go back to the, if you go back to the screenshot, Augustine, the blue bit down there would be the Drupal application. So that's DR Sprint 5 with JIRA tickets. So in the example, they're using different project management systems. And what we're showing is that the Drupal team works there in their own sprint, and they've got their own hierarchy in the branches where they could create new environments, merge new environments, do everything they want because they've got the user permissions to do so on that set of environments. And the Angular team has their own tree, and they can do their own sprint workflow however they want. They're completely independent in terms of their internal workflow. They can use Gitflow, they can do whatever they need. It can be Agile, it can be Waterfall, who cares. But at the point where they meet on the testing branch, no, the testing branch, they'd both be able to merge their stuff there and test it, but when it goes from testing to staging, the way they've got the permission set up in this mythical example would be that for the testing branch to merge into the staging branch, there has to be a release manager. So you have a built-in set governance model where your teams can independently operate to a certain extent, but it's like making a pull request beyond that and somebody else has to review and merge it. And that's really nice because we saw in the agencies that we worked with as commerce guys, we met a lot of development and delivery agencies. Some of the bigger ones, like Cap Gem and I, expressed to us that they had a very often recurring problem where they described a project and won a project at the customer level and then they needed to resource that project to which they returned to outsource teams, a development team in India, maybe somebody in Lithuania and maybe their home team in their home base, and maybe the customer had a team as well, maybe as many four or five development teams on any project and onboarding these development teams to have exact copies of the application to develop on, but making sure that they didn't step on each other's toes was a real serious problem for them. Yet this solves it with one form control. When you add the developer, you simply put them in the right team area and then they've got all the control they need to go to town. They can make as many branches and as many copies of for development or testing as they want and there's a governance when they will go to merge. And it's a feature that is very specific to platform because on Git, if you invite someone to the Git project, he is going to have access to all the branches, no matter what, right? You cannot define per branch the permissions. So with platform, we have implemented that fine-tuned permission system where you can actually per branch give access to someone. So he's not going to mess up with your staging or your master branch, basically. So the third problem that we defined was replicating complex build processes across various areas of expertise. And then we kind of touched on that already in our examples. So... It's a video, I went cold feet here. Oh yeah. You've got a video, right? Yeah, it's not that. We like movies. Yeah. It's not live, I could have done that live too. So here I'm just... You've done enough live already. Yeah. So here I'm just changing a PHP version on the configuration file for the Angular application. This is the configuration file that I have. And for the Drupal application, also I'm upgrading to PHP 5.6. And then I'm going to push those configuration files and platform will just rebuild the two applications at the same time. So I'm adding that to my repo and pushing. It's a bit slow, can you read? Yeah, a bit. So I push and when I push to platform, I don't only see the logs of my Git, I also see all the deployment process that is happening on the platform side. Okay, so here you see that... That's exactly what's happening. So on my Angular application, I'm just downloading some dependencies like Compass for Ruby, Grunt, Bower, and I'm just running npm install, Bower install, Grunt build. So every time I push, platform is going to read my files, my dependencies and download them for my Angular app. So it takes maybe 30 seconds to a minute, depending on how many... But the application is still running at this point. Yeah, yeah. So you don't lose the application. And then once the Angular application is done building, I'm now building the Drupal application, again with PHP 5.6. And for the Drupal application, it's actually not the same dependency. I'm just needing Drush and I'm running Composer Drupal install. And at the end, I'm running the update database and feature revert. So I'm applying all the updates and features that I have on my code base. So basically you see here that I push two different changes on the two different applications and they both get built. But if you only changed one application, that's what I'm showing right here. If you're only changing one application, here I'm changing the Drupal application, you see that platform and that's great concept, right? You see that platform will not rebuild the Angular application because it does a hash of the old tree ID, compares them and if they are the same, that means nothing has changed actually either your configuration or your code base. So it doesn't need to rebuild anything, it just reuse the same package that it already has. And you get the very lovely message, slug already built for this tree ID. It's keeping. So basically it's not going to slow down, it's not going to rebuild all the dependencies if you don't touch the Angular application. If you're working on Drupal, you still have access always to the Angular application. You can still test your code base but it's not going to get rebuilt all the time. So that's how we solved that multi application stuff. Why is that? Yeah. Oh, you want to talk about the TV now? So, no. Okay, I think we're good. That was the three problems that we've identified and the three solutions and we got Doug here who asked me to put a slide for a TV so. After the questions we're going to get, so we're getting basically to the end of the presentation, we're going to open the floor for questions but at the commerce guys platform booth downstairs, we're raffling away, not that TV, but it is a 4K flat screen TV and you can take it home with you. It's not the contractual feature. Or we'll ship it to you if you win and to participate in this once-of-a-lifetime opportunity, all you have to do is see this guy, raise your hand Doug, either now or at the booth later and sign up for a chance to win that. You'll also, as a result of that, get exciting product notifications like when we add new cool stuff to platform SH. It's since we have a one-man marketing team, then we don't actually send out that many emails so we won't spam you to death. Maybe at some point we might. But be warned, if we take off like wildfire then we're going to have the hugest marketing team on earth. You can unsubscribe later no matter what. So then we're going to spam you a lot, so sorry. But that'll take time. Yeah, question time. If you have questions, please walk down the aisle and line up at the microphone. The reason for that is so that the rest of the room can hear you and this is a recorded session so people watching the video later will hear your question if you ask it into the microphone. The first question is always the hardest. Yes, if there are any. And I know Ricardo is going to come up with a zinger. Don't feel too bad. It's about submodules. Have you done any work with referencing submodules in your deployments? It's fully supported and being used in production. Actually, I think for the symphony documentation you can just check the code. And we are using submodules to download the sim. It's a Sphinx extension and it's in the submodule from another repo. So just you push and it's going to pull your submodules. Hi. So my question is related to life environments and how you actually move the data from life to testing and do this continuous flow because life environments have a lot of data, big databases. And then how these things goes to development environments and local development environments. Is this possible, for example, at all? I'll take that. So as long as you're on the cloud and all of those environments on the cloud, the data synchronization is conceived of going down. So from master to all of the other branches. And it's a one button process that you can choose to bring your merge code changes and or to bring new copies of the data from the parent environment. And it's very fast. It's independent of the size of your data, more or less. Like there's a light linear curve that means it'll take a little bit longer for more data. But tens and hundreds of gigabytes of data are no problem to be synchronized in just two to three or four minutes, depending on how much it is. And it's a one button process. So you don't need to manage it. And the way we do that is at the file system level. And we do it in such a way that you get all of the data. So when you do that synchronization of data, you get the MySQL database in the state that it's in at that moment, you get your uploaded files, you get the solar index, you get anything else that's persisting, anything to disk, all in one integral state. And this is a really big problem with applications otherwise. If you think simply about a Drupal application, if I upload, if I write a blog post and it has an image on it, you've got three places that that data is stored. You've got the database, which is the canonical record of the fact that it exists. But you've also got the uploaded file, which is the canonical record of the image itself. And then you've got a solar index on that, which is ancillary data about that stuff. And if those fall out of sync, then you could have a database that thinks it's got a file that's not on the file system, or you could have a solar index that has a post in it that you've actually deleted. And keeping those in synchronicity is guaranteed when you do the synchronization with us. Now for the local development, then you use, for Drupal, you use things like Drush SQL dump, or Drush R-sync to bring the remote files and database into your local environment. We have plans in the future to extend this data synchronization to local, but that's not something we're gonna launch this year even. So it's more of a mid to longer term roadmap item. And I wanna add that you can also, and that's what we use for our clients. Our project, you can also sanitize the database while it's getting from the live to the staging and to the development environment, which means sanitizing a database is just for, you have a comment, for example, for Drupal, with Drush, it's a Drush SQL sanitize. It's going to trim or remove all the passwords from the users, change all their email address with a specific pattern that you can have. So any like sensitive data that you might have live, you don't want them on your development environment. So you can just sanitize the database while you're actually synchronizing the data, so that from the live to the development environment, you're not getting any sensitive data. But you work with exactly the same amount of data, the same structure, the same everything, except there's no sensitive data. Thank you. Welcome. Actually, my question was actually related exactly to that. Since we have pretty strict requirements around privacy and we also need to sanitize the content so that in no way we can actually have access to the actual content that users produce. And so I was wondering, is it possible to hook into the sanitization process? So you have, when you deploy, we expose what are called build hooks and deploy hooks. Build hooks can be any script and it can use any dependency from composer, PIP, Ruby, NPM, Bower, any of those. And you can script against that. You can also provide your own scripts. So this puts your code base together in the way that you want. Then the deploy hook assumes that the application's in place but you just haven't started sending traffic to it yet. So that means you can run Drush commands. If it's a symphony application, you can run, not ascetic, what's the other command that would update the schema? Darn it, don't remember. In any case, you can do things like update DB on other applications as well. And you could do your sanitization script then and by building that into the code base and the project, it would run for every developer every time they push if you want. You can also control if it only does it once like when it goes from master to whatever the next branch is using something what we call environment variables. That's a variable that you control from the platform UI that we store separately from your application that we inject into environments at runtime so that you can store data like connections to payment gateways to marketing tools to email lists and you can configure at the platform level which endpoints and details are used for which environments. That way you don't have to put those in settings PHP or in your code base because then you'd have a problem merging that between different environments. So you could say use an environmental variable that says on all of your development environments use sanitized data. And then that would trigger the sanitization. Thank you. And then another question about the access control you were showing earlier. Actually, you were explaining us that we are able to build an additional layer of access control on top of GitHub's one. On top of our get not on top of GitHub. Oh, sorry. Yeah, that's what I was wondering actually. So if a developer has access to any branch locally to the three in right. The access layer in that case is the ability to merge and push is also visibility for if you're not even a reader on a get branch does that prevent you from checking that branch out? Yes. So it also applies if I'm doing a get poll or I want to check out a branch. If I'm not permission to do that on the platform level then I cannot get to that branch. You cannot fetch your branch if you don't have access to it. Thank you. Okay, so I really enjoyed the graph that you showed on HHVM. And as a contrib author, I'd like to see if my modules run on Drupal 8. So my question is too prone. First, how was your experience in getting Drupal 8 to run on HHVM? Is it straight? No, no issues at all. No issues. It's one line of change on your configuration file. You push and it's faster. Just faster. I saw that you were offering a free trial. How does that work on contrib? Because I don't want to like try it for 30 days and then not see it again. So you'd want to talk to us later. So the official commercial offers that there's a 30 day trial. Okay. That's applicable one time. If you want to, if you're a contrib maintainer and you want to set up a project that is specifically for the sake of guaranteeing HIPHOP VM compatibility or PHP 5.6 compatibility or PHP 5.5, you could set up a project and your different branches would have those different versions on each one. And you could push your code to each one. And that's easy too. You would just in Drupal 7, you'd just use a Drush make line. In Drupal 8, you'd just use Composer and make sure that the module comes in the right way. And if you're doing it on GitHub, it would be automatic. It would push every time you change anything on GitHub, it would test it. So I would offer that to you for free as a module maintainer for that purpose at any time without any question. Just come and talk to me afterwards. Okay. Great. Thanks. Cool. And we are right on time. All right. So thanks everybody. Thank you very much. See you all this morning and see you at the booth. Thanks very much. See Doug for the TV.