 Okay, this way. Hey guys, welcome. Thank you for coming. This session is on BLT and Lightning, and the subtitle, A Project Template for Enterprise Drupal. All right. My name's James Gollum. I'm Manager of Technical Services for Acquia in APJ. And in particular, I work for a division of Acquia called Professional Services. And so we do a lot of site builds. We work with partners and we see a lot of kind of like large-scale Drupal implementations sort of internationally. So the first thing I wanted to kind of clear up, Enterprise Drupal, there's Enterprise in the title and what does that mean? And honestly, it means a lot of different things and we can do the definition route, but I'm just gonna say what I mean by Enterprise and what kind of things essentially define Enterprise in the context of this talk and BLT and why we're actually taking this approach. So first of all, I think Enterprise, you might be thinking of the actual site that's being launched, okay? So that's sort of like a client focus where they've got a large site which is considered Enterprise for whatever reason. We could also extend that to being a development agency. So there in some ways also show some of the characteristics of Enterprise development. So they're actually working with, they're working with some large projects. So one of the criteria might be the size of the project. It's not necessarily sort of sufficient, but it might be kind of like enough to qualify it as Enterprise. It might be the number of projects. So you may have, particularly in the agency context, but also the client, the client might have a large number of fairly simple small sites, but that may actually sort of qualify it for kind of like this Enterprise idea. The number of developers, so the number of developers working on a project or projects, like that's a really key factor and kind of like, and again, we're moving away from Enterprise, but a key factor in what we're talking about today of BLT and Lightning, when this process is important. Obviously complexity, so you can have maybe a low-trafficked site which is actually very complex. Now we're getting into the sort of like, the more kind of like the nuts and bolts, the cost of failure. So sometimes a defining characteristic of kind of like these kind of enterprise sites, and Enterprise kind of like workflows are around the cost of failure. If a site goes down for an hour, there may be actually a significant dollar value associated with that, and also a marketing kind of like in a branding implication. So essentially what all of these things are doing is they're leading to risk, and enterprises are risk averse typically, and so what we need is a way of actually mitigating the risk that's introduced by all of these factors or combinations of factors. And I think that gets to the key of when I put Enterprise in the title, it was like it probably didn't mean sort of traditional enterprise, it just meant some projects, the risk mitigation is a sufficient value that it requires, sorry, the risk is of significant significance. Gosh, that was terrible. The risk is significant enough, that works, we have to mitigate that through process. So you've probably all been working, many of you have been working with Drupal for a long time, and you've probably had lots of different workflows over that time, and like in your career and in the development of Drupal, like I mean I've probably done most of these things, if not all of them, so an approach to starting a project. So you might just like basically you get the project, and then you download all of the modules, you go to Drupal.org, you may even be getting the tar tables of the modules, and install them and find the next one when you need it. You might sort of like take a slightly more advanced approach where you actually script that through sort of like some bash script wrapping drash, you may have created a make file these days, you might be doing a composer file. You also may have downloaded a sort of contributed distribution to give you that starting point, you may have sort of like encountered some of the pain that that can lead to. And then for some of you have been doing a lot of sites and you've got a sort of like you're starting to work on those internal processes, you may have gone down the route of actually creating your own distribution and maybe a variety of install profiles, and that can be a way of actually setting up your sites. And so these are all sort of like trying to solve that problem of process, and obviously they're getting kind of like more structured as we develop. So, BLT. Roman, would you like to make your... Yeah, vacant lander smarter. It started as Bolt, okay, which is obviously a much more heroic way of referring to this project. And then there was a namespace clash. So who knew? There's an open source CMS called Bolt who didn't want to share that namespace. So we took the O out and we ended up with BLT, which is somewhat less heroic. So internally we still refer to it as Bolt because it makes us feel better about it. But yeah, there we go. But it is actually a project that's evolved. So as I said, like professional services, we're doing a lot of big projects a lot of the time. We're working with a lot of developers internationally, not just internally to Acquire, in fact, like most of the developers we're working with are working for either clients or development partners that we work with. And so over that time, we've essentially, we encounter the same problem time and time again. And as any company would do, when you see the same problem, you start to write process and automation around that problem to solve that problem. So we've been doing that internally for quite a while and it's really sort of like with Drupal 8, it's actually developed quite a lot. And so there was a point where whilst we were doing this internally, we thought that open sourcing this project would be of use to kind of like other development agencies, clients. And actually it was gonna make our job easier because some people may have used Bolt and they may be able to actually contribute back to it. So you can see the sort of like, it's essentially a tool that allows you to set up and share project settings with the development team. Provides consistency through process. It provides, there's five points that I sort of like wanted to look at which were consistent development environments. I am realizing that I have skipped a slide. I have skipped a slide. This is bad. We can go back. Let's go back. BLT intent. So this is actually like how it's presented on the product page. So it's designed to improve efficiency and collaboration across Drupal projects by providing a custom set of tools and standardized structure. And so it was born out of this internal need we had to reduce rework and improve our internal efficiencies. Importantly, it's kind of like a set of tools that wraps around a Drupal project. So it's not sort of like a Drupal module. It's not something you download and install in that way. It's actually something that wraps around a number of technologies and provides a structure and a process. Just on the open sourcing of BLT, one of the things like when you develop something internally and if you've ever contributed a module or something, you would have noticed this. You make a lot of assumptions when you're developing. And then at some point when you think this could be shared you start to think, well, let's abstract that out and what is the sort of like the general use case? And so you try and make something which is actually doesn't meet just your specific use case but it meets other people's use cases as well. And typically despite best efforts, I guess you end up with like your idea of what people's use cases are and they very rarely match what you find in the world. So part of actually releasing BLT as open source like we obviously tried to make those kind of like the generic like try to not make it aqueous specific and try and make it as generic as we could but we're learning. So we're learning what people want. And so what I see happening with BLT is a lot of what we didn't even realize were hard coded assumptions are gonna be removed and it's gonna make it possible to actually provide your own custom configuration. So if Bolt doesn't match the way you work internally or you don't like something it does, over time it's gonna become more and more configurable. Right, aqueous lightning. Okay, so this is actually a relatively, even though it's sort of like equal billing in the title, it's actually a relatively small part of this overall talk. And it's not gonna be a kind of this is how you use lightning talk. Is that something you shouldn't say? Cause people leave, I don't know. Certainly not gonna get people in here for a second. But aqueous lightning is a distribution. And again, they've sort of like on there, it's open source and their intent is around basically taking sort of like core Drupal and providing kind of improving it through sort of like almost curating modules, right? The modules that actually work really well together but can be hard to set up. Like and every project, like pretty much every project we work on requires this setup. And so a huge time saving for us is to be able to actually remove this from a project by project kind of like a workflow and actually get it to a point where we're managing it in one place and using it on all of our projects. And I suppose the great thing about kind of like Drupal and open source is that obviously because this is open sourced, everybody else is available to work with aqueous lightning. We'll talk a little bit more about aqueous lightning and maybe at the end we'll do a quick demo of media handling because it's probably one of the best sort of features at the moment of aqueous lightning. But I just wanted to introduce that. Probably seen this one before. BLT. So as I said, it's a tool that allows you to set up and share project settings with your development team. For the more technical people, really it's just kind of like a wrapper around a whole set of thing tasks. And so thing is kind of like an automated PHP tool. And it basically codifies those processes in these thing tasks. So the five areas I'm going to look at today, five sort of key things I think that this process actually gives you. So first is consistent development environments. Then we're going to look at just a defined development process, accelerated site development, sanitized deployment artifacts. And finally we're going to look at integration with testing frameworks. And so they're the kind of key areas that I see bot providing in terms of process. So consistent development environments. Whenever you sort of like start out a project, this is a problem you're going to face. And when you bring new developers on, it's a problem you're going to face. So this kind of happens prior to sort of like the first line of code really being written, you have to get set up for the project. So the way we do this, and again, you can do it like differently internally, but with the project set up, we'll either provide a technical architect from Acquia, or it'll be a technical, sorry, tech lead from a development partner. So they're kind of like the senior developer there, they're architecting out a solution, and they're doing this sort of like preparation prior to the project actually kicking off. What this actually looks like, the steps that they go through, and I've left, there are a couple of set up steps to get your environment ready to actually install BLT. I've left those out, but they're all very well documented. But once you've got your environment set up once, this is the kind of thing you do at the beginning of a project. So first we write this line, compose a create project. It actually clones this BLT project repository, gives it a project name, and just basically starts a build process. I do have videos of the build process, 20 minutes, shall we fire it up? No. But I might show it at the end and just scrub through so you can see the kind of tasks that it actually completes. That's the first thing that we do. And once you actually run that command, if you have a look at what's been downloaded, this is what your directory will look like. It's not important that you can actually read or see this, but essentially we have a folder which contains these important folders like the vendor folder. We've got a doc root, and doc root is where Drupal will actually, the Drupal files will live, and that's where it's served out of. We have various other kind of like folders. You'll see the config folder, so with Drupal 8 configuration system. That's the assumption that Bolt makes, that you're gonna store your configuration outside of the web root in this folder. And probably significantly, we've got this project.yaml. So the next step for the technical architect will be to set up that project.yaml file. And it's actually, it's got some sensible defaults. There are things that you actually got to change about it. I'm just looking at my next image, and there's just tiny text that we're about to go through. So enjoy. There we go. Some of you may actually be able to read it. I've got it in a text editor, which we can look at later, but I'll just like move through the process and then we can actually look at. But essentially this yaml file provides the shared project settings that will essentially configure BLT. And when I say shared project settings, these are gonna be committed back into the repository so that any developer actually works with this repository on this project, they're gonna be starting off with these default configurations. We also have, like we, I haven't got a tiny little slide for it, but we also have a local configuration file. So the local configuration file allows an individual developer to actually override some of these settings. And so that they can get that kind of like, at their machine level, they can get their own configuration. Typically, if this is set up well, you probably don't need it, right? So the next bit. So we've set up the project and it's essentially downloaded Drupal on a lot of modules using Composer. It's set up a directory structure, which is consistent with the way we manage projects. And the next step is actually choosing how you're gonna run the project out of the doc route, right? So for this presentation, I'm gonna be using the VM command. So that's using a virtual machine. So that's the Drupal VM by Jeff Gealing. And so this single line command is gonna do quite a lot of stuff. It's gonna provision the virtual machine and it's gonna configure that virtual machine based on kind of like a configuration template in the project to run the types of the versions of PHP, et cetera that you expect on your development environment. And then it's gonna set up things like Drush aliases and actually make that machine kind of like essentially use the doc route as the source of its web route. It's slow. You may not be able to see the whole wheel. I assure you that's a hamster running in a wheel. So this can take about 15 or 20 minutes. There are some like, but you only have to do this once on a project. And you can also cache these things. And actually interestingly, there was a talk yesterday from about Beatbox and they were talking about one of their major sort of like motivations was actually to improve the speed of this process. And so we were talking about how could we integrate Beatbox as your choice of VM. So we don't wanna be that opinionated that like this is the only VM it's gonna work with. Yeah. So once the hamster has stopped running, what we end up with is we've got Drupal VM here. And Drupal VM is actually looking at that doc route folder. And the doc route folder is on your local development machine. It's stored there, but it's shared. It's sort of mounted by the Drupal VM as its web route. So essentially what that means is your developer has downloaded a virtual machine, but they don't have to work in the virtual machine to work with Bolt. They're working in their local environment using their IDE of choice in a familiar environment, working in this doc route, but the changes being reflected through the virtual machine. A virtual machine is not the only way you can work with BLT. All we're actually trying to do is provide a web server that will use this as kind of like the doc route. And so other approaches, dev desktop. The dev desktop, it's not all about product, really. But dev desktop is an aquia kind of product where you actually download and it makes it very easy to set up a development environment. And you just essentially point dev desktop to your doc route. And the other approach, which many will use is something like a homebrew setup. So you might have homebrew setup locally. And in that case, you would just have to set up a virtual host using Apache and point it to the doc route. What? No, not yet. Yeah, yeah. It will be on the cards, definitely. Next to like probably six months. So what I'm saying here is it doesn't really matter what's serving the website. The reason we go with Drupal VM is all of that configuration can be captured in the project and then the next time a developer actually spins up the site, they'll be using exactly the same environment. So once that's completed, we run this command BLT local setup. And that actually kicks off the process of creating and installing the Drupal site based on configuration. So at the end of this process, what we expect is actually a working site that you can actually log into and has been installed using the base profile. Now this is all being done by the tech lead, remember. And so once they've actually configured this setup, essentially they take everything that's been created and add it to Git. So add it to the Git repository, commit it and then push it to the repository that's going to be shared with the developers. The Git at all, the project comes with a Git ignore file which obviously isn't going to commit things like, you know, anything that actually is almost an artifact of setting up the local environment. So essentially what we're committing back is all of the files that provide shared settings to ensure that the next person who sets up this project is working in basically an identical environment. So the technical architect, technical lead, set this up, they push this to GitHub. It's time to bring on the development team. That may be one developer, it may be sort of like five developers, however many. Developer setup is actually essentially the same as the tech lead, except they don't have to worry about the project settings files. So the steps quickly, they clone the repo, they run that composer, they run composer install, they run BLT VM, and because the tech lead has already run VM, it's committed the configuration that was controlling that VM and so when the developer comes along, they're not defining their own configuration or creating a new file, they're actually using what was provided initially. And finally, they run BLT local setup and at that point, we should have a happy developer. It's kind of like, I like that bit, yeah. It's one of those ones which you think, because I look at that guy, oh, that's not me, look at this guy. It's like, actually that's me, right? So I don't know about showing it to you guys, if you're like, oh, look at that guy, is that me? So essentially you've got a developer who has actually got set up in the project very quickly. Like, given that they've got their environments set up to run composer, et cetera, this process should take around half an hour. So we've set up the development environments, we've set up the project, we've got everybody set up and it's time to start coding. And so another thing that BLT gives us is this kind of like enforced development process. Enforced sounds a bit strong, but I couldn't think of a better word for it. So this bit actually isn't the enforced bit, but I thought I'd share it with you, because this is how we like to manage our drip late projects. And so it may be a workflow that's of use to you, it may not. It's not required to work with BLT. I think the emphasis though is whatever your process, it's documented and it's kind of like enforced by your tech lead and wherever possible, enforced by technology permissions, those kinds of things. So we will have the tech lead create this project repo. So that was the first step that we looked at before. When the developer comes on board, we sort of like skipped over this bit, but essentially what they do, rather than checking out the actual repo in GitHub, they're going to be creating a fork of the repo. A lot of you will be familiar with this process. When they create the fork of the repo, they now have a copy of that repo in GitHub, and that's where they'll actually be working from. So the developer clones this locally onto their machine. This is the point where we actually run the setup. So we look at the setup, that's where the happy developer is actually working then. Once we've got that all set up, obviously, they start doing some code, hopefully. So they're working locally. I won't go into kind of like where they're working, but it's a pretty familiar workflow for them. So they're working in that doc root essentially, inside sort of like the custom modules directory. So once they've actually finished their code changes and they feel like they've finished their story and it's ready, it's time to actually contribute it back, get the tech lead to have a look at it. They'll actually do a commit. So one of the things that BLT did when it set itself up, it set up some pre-commit hooks inside the project. And what they do is actually give BLT the opportunity to run some tests against the code that they want to commit. We'll talk about that in a second. Assuming they pass those tests on the local machine, the developer will have been able to commit that locally. Then the final parts of the workflow, the developer will push it up normally into a feature branch on their machine, and they'll create a pull request back to the actual source repo. Those pull requests should have sort of like, typically will have the tech lead or the technical architect review those manually to make sure that even though it's passed, these kind of like pre-commit hooks, to make sure that the code is actually best practice, etc. I imagine a few people in this room are actually working with this workflow. So these pre-commit hooks, we just mentioned that BLT will set these up, when you run git commit, the hooks will actually check for PHP syntax and code style. They'll also check to see if any modules that you're actually contributing back into the project have active sort of like security issues. So if they actually fail that, you won't be able to commit them back. And then finally, it checks for commit message format. And so, again, this may seem a little bit rigid, but when you're going through a git history, it's really nice to be able to link things to issue numbers and to have sort of succinct commit messages. And so right at the bottom there, we've got an example of kind of the format it's expecting. The prefix is defined in that project.yaml file. And so it typically might, it could even relate back to kind of like a JIRA prefix or something like that, the way you actually refer to the project internally. Then it's followed by a dash and then a number. So that will be the issue number. And it's followed by a colon and a space. Why don't I just show you the regex here? And then we've got the commit message. So essentially, if any of these things fail, so if the PHP syntax or code style is wrong, if there's an outstanding security advisory around a module or if the commit message is in an incorrect format, the developer locally won't be able to commit to their repo. So they have to fix those things up. If they all pass, then they're free to commit and complete that process. So the next area, the third area that we're going to talk about was accelerated site development. And so this is actually one of the big gains we've got and it's through using lightning. So we mentioned briefly lightning and its intent. So essentially it's a distribution of Drupal designed to provide that great out-of-the-box experience for editors. It's trying to solve common site challenges, as I mentioned before. The three big areas that it addresses at the moment are around media, around workflow, and around layout. Probably, possibly as important or more important, it's great to work with a distribution, but you probably work with a distribution in the past and there's a security update to a module and you need to update that kind of like that distribution. There can be issues with that or the distribution falls into a bit of disrepair, that kind of thing. Lightning actually has a commitment from Acquia to support it and basically publish a roadmap. It's interesting because you've got core and you've got contrived and you can use core and you've got all these certainties and you've got contrived and you've got none of those certainties, really. There's room for something in between that, right? There's room for like, I mean, not as strict as core, maybe, but something which actually you can rely on for projects because if we're asking you guys to start your projects on Lightning or suggesting that you do that and then we don't maintain that, you've got a lot of technical debt there to maintain. So I think one of the most important things about Lightning is not necessarily what it provides you out of the box, but it's actually that it gives you some certainties that you're not going to pick the wrong distribution to base your work on. And finally, this is also important, it's extensible. So distributions generally, like you download them and install them and kind of like that, there's no additional steps, right? You use what's in the distribution, then you maybe modify the site in more normal ways. Lightning has actually introduced this concept of extensibility. It's nothing like, I suppose, sub-theming or extending in that way, but what it does is it kind of like looks for the presence of a YAML file in a site directory and if that exists, it allows you to install additional modules once Lightning has completed its setup. And actually what that means is those additional modules can have their own install hooks and they can actually extend the process. So it's actually extensible in that way and so it means that it's kind of like almost acting like a base theme, it's not like the final distribution, it's a part of the distribution. So in terms of media, essentially, I don't know if... Has anybody been involved in media in Drupal 6, 7, or 8? Yeah, okay, so yeah. I've given a couple of talks on it, like media and the alternative scope and that kind of thing. And like media is still, I'm not sure what the status if it's dev or alpha at the moment, but what Lightning has... The responsibility, I suppose, Lightning has taken on is actually looking kind of like the best of breed modules out there and then brought them together so that they work together out of the box when you install them, which essentially what that means is, like the current best practice is to use, like when you're actually embedding media to generalize that. So it doesn't have to be media specific. What we're really talking about is embedding entities, having an entity browser so that you can actually go through a library of entities, certain text formats. So what media does, if you look in the code, it's actually not got that much. There's some configuration, there's some dependencies on these modules, but essentially what it does is it saves you the time of going through and setting up kind of like and configuring things like text formats and making sure the entity... If anyone's ever tried to configure an entity browser, I mean, that's kind of like... Yeah, so it does that for you. So essentially that's kind of like a great out-of-the-box experience. It obviously adds WYSIWYG and media library support for things like images and video, but it's also external sources. So it's got kind of like the... You can just basically dump in a URL to a number... Like there are more services there, but to a number of kind of like these social media services or distributed media services, and it will actually use the files table and the entity handling within Drupal. So it's actually managed in Drupal, which means you can associate metadata with it. You can see where it's used in your site and that kind of thing, but it doesn't actually store the asset. It stores a pointer to the asset. So that's a pretty powerful concept, and it's really effective. So that just kind of works out of the box. So you can see like that's where a large part of our kind of like, I suppose our quantifiable savings have come from in a project setup. Similarly, workflow. So I'll just go through this quite quickly, but we've got this... It will add default workflow states. So many of you have probably used Workbench Moderation. And like for most larger clients, workflow is actually a requirement. So you're setting it up every time. So again, the workflow is just set up by lightning out of the box. And additionally, scheduling of content, schedule publishing. So it also provides that out of the box. It uses this module, field updates. No. Field updates? Help me. What was that? No, it's field update. It's update field. Something like that. Essentially. So you probably use scheduler. And scheduler on node basis will actually say, okay, well, you can update. You can publish and unpublish, essentially. This module, whatever it may be named, actually provides per field to light level updates. And so that field may be kind of like the Workbench state. And that way you can actually move something to archives at a certain point in time. It also provides, per entity, it provides multiple... The ability to add multiple scheduled states. So you can turn it on, off, on, off. Whatever. So that's, again, all out of the box. Finally, around layout. It adds a landing page content type. God. Terrible IPA. Anyone? Anyone? Thank you. So essentially this gives you a drag and drop interface for panelizing nodes. And so the landing page is configured to actually use the in-place editor. When you actually go and look at this in-page editor, you have a shelf down the bottom where you can actually drag and drop pretty much any ripple content in there. So that's the main gains we get from actually setting up a project. So we're already starting from an advanced point. But one of the really key areas that BLT gives you, it's this sanitized deployment artifact. And so you may have heard of the concept of artifacts rather than the actual code. And probably even if you didn't know it, you're familiar with it because if anybody's used something like SAS, SAS is like the source code and CSS is the artifact. And so you need both in your project to work on it. But actually on the web server you don't need the SAS because it's actually the CSS that's getting served. So that is sort of like an example of what sanitized deployment artifacts are all about. So it's about having a process when you're about to actually deploy your site. We're actually stripping out all the things that aren't necessary. And some of the benefits of actually taking that approach are maintainability. So it's impossible using this process because we're using Composer to actually create these artifacts and then we're stripping out the stuff we don't need. You can't hack Core. Core is always downloaded when you generate these artifacts. If you need to hack Core you need to provide a patch. And so BLT also provides kind of like well it comes with that Composer library which will allow you to apply Drupal patches during your build process. What this means is that whenever we're using shed modules there's no way a developer can actually go in and change code there. Stability and stability because we're building these deployment artifacts automatically. It allows us to test them and we'll talk about testing in a second. It provides performance and this one I mean there's obviously a lot less files on the server but also apparently like the autoloader it doesn't have to actually scan as many files so you're actually getting performance benefits from stripping things away that you don't actually need on your production server. And finally security again through that testing but also through that enforced security alerts and not being able to commit those things. So as I said it only deploys what's needed and the process for actually generating this kind of artifact within BLT is just this command BLT deploy. So as I said BLT deploy BLT is just a wrapper for Fing so it actually calls a Fing target which does a number of things actually it does a bit more than this but it builds out a dock route in a new directory called deploy. So you've still got your old your old dock route with all of the artifacts in there like your SAS etc. But it creates a new folder and this folder the intention of this folder is actually to be tested and then deployed. It compiles front end so it's got like build steps where if you've actually got if you're using SAS and you're using grunt or gulp there are hooks in there that when you actually hit deploy it'll trigger all of those front end build processes and so you don't have to remember to run grunt before you actually deploy because it's actually built into the process and that can be extended to a whole lot of other automation processes. As I said it sanitizes the files that are in that directory and then finally it will push to a remote and that remote again defined in that project.yaml file. This is essentially what it's doing so there are many more file types you've got to find in your dock route but you can see you've got SAS files, gulp files, maybe coffee script, you've got JS and CSS in there as well you've got readme files. So when we actually run the deployment like those files are stripped out and we just leave behind the files that are actually necessary. That readme one is an interesting one that you may or may not know when you download Drupal there's a changelog.txt which basically reveals it's by default in every kind of like Drupal site and it reveals what version of Drupal you're running which is incredibly useful information to about one group of people. So this is around security as well. So essentially we've set up a development environment we've shared that development environment we've started coding and enforcing a workflow we've got a kickstart on our project through lightning we've got a process for deploying just what's required and the final step in this process is integration with testing frameworks. So this is like obviously it's been important for a long time but it's getting more and more recognition now. And so BLT allows you to integrate with kind of like sort of automated testing. So there's a number of ways you can do it but they're all basically the same kind of command. So again it's a BLT command and then it's running CI pipeline so that's an Acquire kind of like testing service in it. Additionally you can run it for Travis or even Tugboat so there are three services there at the moment but like I mean you can actually extend this to work with your service. Behind the scenes really what it's doing is it's a thing task, it's copying across some configuration that is known to work with kind of like the services that are supported. And then it's using the internal BLT build mechanism to actually build and test. So the process here if we were to take the example of Acquire pipelines it's a beta product it's a private beta at the moment if anybody was interested they can actually apply to use it. But essentially the process is the developer has their fork the developer creates a pull request pipelines has GitHub integration and so when the pull request is received it sends a message to pipelines to actually check out the repository and merge the pull request and run the build process and then run all of the automated tests. If those tests actually pass it lets GitHub know they've passed and it also builds it creates the build artifact and it pushes it to a repo if you're using Acquire hosting and with pipelines if you weren't using Acquire hosting pipelines probably isn't available to you. But essentially it will push to a repo that is the repo that your site is deployed from to a branch that you specify and then you can make the cloud environment consume that branch so every time it pushes it automatically deploys to whatever environment it is you want. So that might be the UAT environment for final user testing and that's the final part of it actually deploying. Very briefly another one of those tiny text files that is kind of like a pipeline's configuration file it defines a number of steps you may have to take my word for it but that's pretty much the five kind of things that BLT has given you as I said it's recently been open sourced so there are going to be things that may not work with your workflow it's on GitHub please create issues and pull requests because we actually do want people to use it and we want to remove any impediments and any of our hard coded assumptions so the BLT project is available on github.com there's a read the docs for BLT documentation lightning information there's a site lightning.acquia.com but it's also available on github Acquia pipelines there's more information on the Acquia documentation site and then we've got Drupal VM where there's great documentation on installing and configuring Drupal VM I think we're up to like question time and no questions from Margie I saw him snake in here does that mean we can't ask questions now just quick one on the sanitization of the build artifact do you specifically remove the sass files I guess my question is sort of like what happens if there is disconnect between you know one dev team and the production environment and the next dev team gets access to the build artifact repo and they're like alright let's pull this down let's you know cowboy it go old school oh wait look we've got no sass files so let's just edit css like you know you've got bigger problems yeah I mean I realize that but is it really essential to remove those files and is it is it configurable can you just give yeah look I mean and it may be one of those but because we haven't had that use case it's not configurable if there was a compelling use case we could make it configurable I think the problem though is kind of like it subverts the process in that every no developer should actually and in fact you could enforce no developer had access to the repo on production all they had access to is on github the project which they could fork so you can actually shut that down immediately yeah good talk James we've got a lot of our support guys are working maybe on say five projects in one day and it looks great is there a way maybe that you could sort of have the one say Drupal VM and all these sort of little sub things which sort of slot into the VM when required if that makes sense it makes sense because everyone's nodding except me so I guess rather than if I'm working on five different projects in a day rather than spooling up five separate VM use that one VM and use just different so you'd be mounting different directories within the VM yeah look I yes it is possible and there's ways of extending it depends on where you would actually lie that so it may be through the thing task you can actually override the thing task itself if it wasn't configurable at a kind of like higher level and we actually I talked to Tom after that and like it'd be a great to add beatbox integration to this would be great so we weren't yeah sorry the second to last slide you had there as I understand it you have basically two repositories the project repository that's right and what you call the artifact repository and that one does get everything all of the source code of all of the contribs can edit to it automated so the project the project repository gets all of that the artifact repository it only ever gets kind of like the artifacts okay can everyone please give James a big round of applause