 Alright, so we're going to talk about 10 reasons to standardize web development on Pantheon. I am Drew Gordon. I am Matt Cheney. And we'll move through these things. We might have, likewise, be able to return everyone to the regularly scheduled lives here in less time. So Pantheon is an excellent platform. We're also in the hall downstairs, combined with a demo and such. We have built a platform that does an incredible job of delivering websites in a highly performant way. But there's a lot of things that we also do that are far beyond hosting. So we like to think of ourselves as a website manager platform. So I'm going to talk through these 10 sort of reasons, issues that we saw that are pretty common to web development. So, oh yeah, that's a good idea. Alright, so project setup. Is this yours? Rachel, whose actually use Pantheon is familiar with Pantheon? Alright, let me just do a little orientation around this, because I think we got a little time, and I think this could be really sort of cool for everyone in the room. So Pantheon is a company that we've been doing for about five years, basically building in our view, the best web management platform for Drupal. So we're really focused on providing a developer experience and a set of tools that you all as developers, project managers and site owners can really take advantage of. It leverages a lot of the containers spoken about in the last presentation. We're really big fans of container architecture. We think that's also the future of how the web will work. And we've been playing around to really build a really great platform that uses those containers. To do really awesome Drupal stuff. Such as hostdocker.com which I think is super cool. And the basic idea here is that also a lot of the tools, a lot of stuff will show you is free for developers. That if you're a developer doing, you know, making a site, you can use our platform, you can spin up our stuff, and really play with it all you want to see how good it is and see if it works for you. That the only point would you have to pay us is if you actually went live with your site. Which in our view is like adding a custom domain and putting it on the public internet. But what you get sort of as a developer is a sort of opportunity to really have a lot of tooling that you would want. So you can sign up for an account on our website pantheon.io under create free account. And then you'll log into something that looks a little bit like this. Where you'll have sort of your own account. Where you can do things like, you know, have your password or upload your SSH keys and this kind of stuff. You can have a list of all the different sites that you're working on. Here's a bunch of stuff I have. Some of which are cool like, you know, my bicycle company's website is on there. A bunch of these are test sites. You can basically have as many of these development sites as you want to play around with actually doing various things. It's also really easy to create sort of new sites that we offer this really cool opportunity to say, you know, this is a wonderful website. And by just naming it, with our particular agency account if you want, and then you'll create a web address dev dash. This is a wonderful website that pantheon.io. And sort of when we kick this off, our sort of back end is starting a process of actually spinning up a number of different containers to actually put your website on the internet. So we'll go grab Drupal 7 right here. And then we're going to go through a process that will take about a minute and a minute and a half. But what's happening here is we're actually provisioning a bunch of different containers to build your website. So we're like setting up some Nginx containers to actually run your web server. We're setting up some PHP containers to actually do the processing of your Drupal code. We're setting up some containers of a file system we made back in Cassandra to host your files on your website. We're setting up some containers from the MariaDB database that will run your Drupal site. We're setting up some containers to do Apache Solar Search, some containers to do Redis for data structure caching. And this all ties into a pretty custom architecture that we've been working on to route all of your traffic through Varnish and really create a great sort of performant environment for Drupal. So there's a longer demo around all this if you want to come by our booth. But just the idea here is that we want to use containers to make it easy to set up Drupal sites and get them on the internet. And what's that happens, we want to allow people to have a lot of other opportunities and flexibilities to do stuff with those websites as developers like move from dev to tests live, like run automatic tests on the site, like easily create backups, easily invite your team members to collaborate. You can see here and use it all with a really, we hope developer friendly kind of system. You want to go in and connect to start editing files on the site right away. Here's some connection information just for this particular dev instance. If you want to do a get check out, we can get you the get information right here. You can pull that down. You want to connect to the database right here. You want to grab your log files, your files we give you information right there. And these are all things that as sort of a developer you're very interested in wanting to have access to, we make it really easy. But also if we want to invite our team members to go ahead and be involved, I can invite my colleague Dwayne who's downstairs and with a simple like email address, it actually will go take his account also on Pantheon, add it to our team and he'll now have access to push code and check it out at work on the site. And the idea here sort of getting into our thesis around agency work is that if you're an individual developer working on a single site, like this is still valuable to you. You get all these container performance advantages. You get all this developer tooling. But what really becomes powerful is if you're working with other people on your project and you're doing more than one website, you're going to run into a series of problems that Drew and I will talk about that actually sometimes it can be a real pain to have ten different customers that all are running on different kinds of platforms where you're like sharing credentials over email and having new people have to turn a new system to start each project. That one of the things that's really awesome on Pantheon is that beyond just the individual site, the environment, we offer the ability to actually have sort of organizations or groups of sites. So that if you're, for example, interested in, I say you've got 20 or so sites on the platform, we'll actually show you a sort of dashboard of all of those things so that you can actually see, hey, here's all of the people that are sort of developers of my organization. These are actually just all me, but you can add other people to your organization, again by email address, and that having the option to actually have different roles and permissions. So you can have some people that are just developers, some people that are straight admins, some people that are just unprivileged and just to view. You also get this really awesome sort of dashboard where you actually can see all of your different stuff. You can say, oh, these are the sites that I'm working on and on a friendly basis. Here's my sites that are really cool Drupal projects. Here's some sites that are in development. Here's some sites that are live and this kind of thing. This can be really helpful because if you're sort of involved in the agency, especially if you're managing a lot of projects on a support basis, and you're working with them over the long run, it's really easy to say, okay, what sites need updates and we can go in and click on a specific site from our dashboard. It'll then just go do a quick check to see, hey, is there a new version of this thing and there's some new code to do. We can just go ahead and apply that if we want. That's sort of a nice little process just for managing our sites. You can also sort of do really cool tagging system where you're actually providing organizational information to the site and you can start to sort of build up this kind of tool set. You also have the cool option if I went and actually added someone to my organization and I want them to work on this Palestinian site, this law firm site, and this web form test, I can just go ahead and add a single team member to all of those sites and then I'll now have access to those sites. I just show all this because this is the kind of thing that when we're sort of purpose to talk, talking about standardization, that I just want all of you who do web development to think of how many hours and how much restress you're doing, setting up servers, building deployment scripts, maintaining those scripts, sharing passwords with your clients, figuring out how to set up a test environment, you have to figure out how to reference all the support tickets are all aggregated together, finding those support tickets and being just really on top of all of your sites. These are hours in our view that are better spent on more advanced and interesting projects. If you're a sysadmin, you shouldn't have to just get a ticket to create yet another Drupal 7 site and then you go out and spend two hours to do that. You should have a script that does that once that someone else writes and maintains and then you write a bunch of cool custom tasks or other kinds of DevOps stuff on top of the platform that we really are trying to encourage people to move up the stack and go beyond the bare bones. Because problems like dev to test alive and performance and Drupal, these are problems that are better solved with very smart robots, not with people's time. Part of what we do at Pantheon is create a product that has an agency dashboard that has individual sites that you can manage and have it all in a standardized way. In terms of our presentation, what we want to do is just talk through 10 problems that we see people who not even necessarily that they solve using Pantheon, but problems that they have if you're using a lot of different environments, if you're not standardized on it. Things we think we solve of course at Pantheon, but these are 10 problems that we see you have. It's sort of what we're up to. I don't think it will take super long, but I think it's sort of fun. We'll alternate. I'll go first, then Drew will go, and we can go back and forth. It's focused on Drupal websites. You can have the websites be behind some sort of authentication if you want. You can have them be logged in through Drupal or basic off. It's designed for Drupal development, however you end up making your Drupal website. Do you have a follow on from there? Is there like a, for instance, something you're thinking of? I was thinking about the Internet section. Yeah, sure. Yeah. Previous presentation? Yeah, sure. I mean, I would just say that what we've done is we do have our own sort of private connections between all of our different servers. We run about 200 different servers that all run different containers on them for the various operations. And when I spun up that site from before I created that new site, it took a little sliver of PHP off a few servers, a little sliver of database off one, a little sliver of files, and put them all together. And all of those connections are private. It's inside our network. They're all authenticated using certificates. And that piece, we all believe, is very secure. In terms of then sort of building an Internet site, a lot of folks will use us to build Internet sites, especially ones that are pretty large. You end up needing a lot of different resources. So one of the cool things that we can do is that we can start out with maybe only having two or three containers running PHP for your site, but we can expand that out to 20 containers if that would be helpful for you. But yeah, it's very sort of general purpose for Drupal, though. If you can do a cool, secure Internet in Drupal, we'll do that. If you want to build a public-facing brochure marketing site for your company, we'll do that, too. You can sort of run any kind of Drupal 6, 7, or 8 code that you want. All right, so 10 common problems, things that you'll run into as sort of developers if you're working in a team and you're using different solutions. So number one is that you do end up wasting a lot of time doing DevOps setup over and over again. That say you have a customer, they're like, hey, cool, we want to work with you. They sign a contract, now you have to start the project. Well, that process now is going to involve some setup. You're going to have to go out and get the latest version of Drupal. You're going to have to set up a web server or at least a VHOS file on an existing server to have your dev instance. You're then going to need to figure out how to get a verging control setup put in. So it's in verging control. You're going to need to have a search solution which could be a Apache Solar setup. You're going to have to then create a test environment to actually review those changes before you go into a live environment which you also need to create. That live environment will need things like varnish and Redis and APC and tuning of all the different components to work. You're going to need to set up scripts so that you can actually go from dev to test to live. You'll need a way to back up the database and the files. You'll need a way to move the databases from live back to dev for work. Choosing feature branches will need a way to actually have each individual developer have their own kind of dev information. You're going to need access control for the people that are supposed to be on the project or the people that aren't. They're going to need monitoring solutions like New Relic to keep that together. And you're going to want to have that for every single project. But this is something that takes time. And it either takes a person's time to build scripts to do this in the first place or maintain those scripts over the long run. Or it takes someone's time at the beginning of a project to actually do project setup. And our view is that this is wasted time. It's either time you can't build for or it's time that maybe you do build for but you'd rather be spending that time doing more interesting stuff on the platform. So our solution here is that developer dashboard I just showed that you can actually have our system and our robots and our scripts spin up your next Drupal site. We've done it 100,000 times. We can do it one more for you. And that you can actually use our stuff to get up and running for free so that you can get going with your actual development and actual value as your service instead of working on sort of rebuilding the wheel for every project. All right. And another thing that we do that, again, this is like our mindset and actually we came from an agency background. So Matt ran chapter three for many years and I used to run a company called Gordon Studios. And so we understand these problems quite deeply. And so again, what our focus is as a platform is to try and deliver as much possible value as we can to agencies. And so again, we bring that mindset to everything and we're showing 10 reasons today but we keep getting better as well. So another thing that often happens is you get developers on top of each other's work, right? So you're all working on some different kind of aspect of the client's website and someone's doing a hot fix over here and someone's doing like a new large feature development and such. The ability to give everyone a, like, their own separate environment which is in fact a duplicate of the live environment that is completely, there's very safe, totally resource isolated yet a mirror of the live environment is an incredibly powerful thing. We call that multi dev. And it's very similar to get branching. And in fact, there's like, we can talk about that if anybody has questions but the ability to do that kind of get branching with the mirror of the live site is a really powerful feature. Yeah. A third problem that we see is that if you have multiple sites that need to use the same kind of common code base this can be difficult to do and a little bit insecure. That you may be working with a university who wants 40 websites that will all be sort of the same. They'll have the same themes, same modules, same thing you'll find on. But like managing all those things at once gets really tricky. You don't necessarily want to create 20 or 40 sites and then have to go individually to each one to do updates. But you also may not want to use Drupal's multi site to do this as well. Drupal's multi site has a lot of security problems in that if you've got 40 sites on the single platform if one gets hacked all the others get hacked. You also have performance problems where if you have 40 sites on a multi site and one has a really great traffic day it'll be the worst day for all the other sites because they'll suffer under heavy load. And that if you do do an update to one of the sites it could break the other 39 and this gets really dangerous. So our solution is that we offer you when you actually create the site I showed that before we picked Drupal 7 as our upstream we actually allow you to create custom starting points for your site so you can have a version of Drupal 7 for your agency which is maybe the 10 modules that you always use on every Drupal site or you could create like a university version of Drupal 7 that has that theme and single sign on and such and that we're going to create individual containers for each of the different sites they'll be independent of one another for security and they'll have their own resources for performance but they'll all be connected together using Git so if you do have to make an update to all the sites you make it once to a master repository and then push it out to all the sites and this is we call this custom upstreams and we think this will save a lot of time because there's some really cool projects you can do if you have to do 30 or 40 sites but you want to do it in a secure way and we feel using Git to make the code common and containers to make the sites distinct is the right way to do it. So one of the things that Pantheon offers is we offer two different kinds of operations to do development. One option is that you can actually do a Git checkout and put that into a local solution that you might be running a vagrant image or a MAMP stack or some other solution. We make it really easy on top of that to actually get the database you can just do a quick export of the database and pull that down. We also offer an ability to do something called SFTP mode which is that you can use like a local SFTP client like Transmit or FileZilla or something to connect to our server and then mount the actual code directory for the dev site on your local computer as like a share and then you can edit that directory. Those changes will then become synced to the server and then you can actually do a sort of live Git commit on the site which is pretty nice. And then those are two pretty interesting options. If you're very interested in containers sort of as per this session, there is a cool tool that's currently still in development called Calibox that actually will create individual containers on your local machine. That'll be for Linux, Windows and Mac that actually will let you do local development and they have an integration with Pantheon option. So you just type your username and password and Pantheon, pick a list from your sites and then you can start with local development. Yeah, Calibox in particular. If you're wondering about the next generation setup like if you want something a little bit more modern than MAP, so containers and such, something that was invented not 10 years ago because the stack has evolved, Calibox is an excellent option so I highly encourage everyone to check that out. Another common problem in working with client websites is the production databases is tricky to sync against. So sometimes you'll have just massive databases or restricted ability to actually get to the database and syncing against that so you can actually know that your development, whatever it is that you're working on, will actually do what you think it will do, can be an unexpected challenge at some points in time. It's an opportunity to learn, as I used to call it. And so the workflow that we provide really does solve this. When you build things, so we have a dev test, every single site comes with a dev, test and live environment. So we were all looking at the dev environment and we saw some updates that Matt showed there on one of the sites and such. But once you get your dev work done, pushing that up to test and bringing back the production workflow or the production database to test is a one-click operation. The checkbox is there, checked by default. Just click it and all of a sudden all of that content and configuration comes down from live and your latest code goes up. So you see it working in tests. That is exactly how it will work in live. It's just the way it should work. That's the way we do it. Another problem that we see, and this happens probably more than you think, is that people will build websites in development and they'll work fine if it's just them and a few people looking at it. But when those websites actually go to the public internet and get a little bit of attention, the problem is that the websites are slow. They get a media event and they go down. This happens a great deal with websites. It's unfortunate it does. But it can be a real problem for your agency. If you've built a site for someone and it's really cool and it doesn't have that much traffic and it can go down. Our solution to that is that we've sort of, as Drew mentioned, prior to doing Pantheon, we both worked in agencies building websites for customers and we spent a lot of time in those roles making sure that customer websites were extremely well tuned for high performance. That we know a lot about how varnish works to do reverse proxy caching. We know a lot about how Redis works and how Blackwool and for PHP. We know that a container architecture is going to be the most efficient way to spin up and down resources and route different traffic to different kinds of PHP workers. We built Pantheon as a solution to be the fastest, to have the fastest run time for Drupal websites in the industry. There's other people that are also fast but I think we have one of the fastest platforms, if not the fastest. It's because every website that's set up goes through the same performance tuning process that we had previously done a big consulting contract with someone to build, but because we do it automatically it becomes something that just happens every time. So if you have issues with your sites having some performance problems and you have to pull off one of your senior people to try to fix it and that you're sort of just ending up reinventing your own sort of performance solutions, going to a standard approach with a platform that stands performance can be really effective because we've done this a hundred thousand times. We know how to make the websites fast and we can give you a really good best practice environment more or less out of the box. On that actually, so it's hard to measure so actually just going to mention one more thing on this. People are always going out and saying who's the fastest host. One of those studies comes out every other day and studies probably is a fancy word for them but we linked to a couple from our site but we're consistently either the top or the top three or something like that and that again comes down to methodologies and all those other things being used but we also serve something like one in every back of envelope one in every thousand page views on the web is coming off of Pantheon at this point in time and that's the same architecture that handles all of our sites. So you cannot have a big day on Pantheon that would somehow make us sweat at all so the best day you could possibly ever have for one of your websites is going to be just hey, just some more traffic. So another issue super common so you have a new person joining the project so either a contractor or maybe the opposite side of that is the CTO something needs to get involved and in order to actually get there and be able to do a little bit of work spend hours and hours and hours getting the keys for this or making sure they're clear for this kind of access from this person over here and this kind of access over here and the many hours of work that go into just even being able to join a project so you can either review code or do some work can be non-trivial and sometimes even be more time than the actual time that you would spend doing the work and so for Pantheon we just saw that Matt showed a little bit earlier someone needs to join the project type in the email address boom, done Another problem or just sort of more like time suck that we see is that actually when security updates come out for Drupal Core these are things you obviously want to apply to your site and that kind of process can in fact be a little bit tricky to do that you're going to need somebody who understands how to use Git in some cases use Drush to actually do the update that if you have core patches that you've applied you're going to have to figure out how to re-apply them after the update and that if you have on a support contract like you have a lot of these things to do so for every on a Wednesday if a Drupal security release comes out you end up having to take up valuable developer time to just apply the same patch or same update over and over and over again and this isn't crazy hard but it can take a bunch of time they'd probably rather be spending doing other stuff in worst case you can make a mistake and sort of mess up the update and then the site itself will go down which is obviously no good so our solution to this is sort of twofold one is that for every Drupal Core update we offer a one click button on our dashboard to actually do the update I showed that a little bit ago yellow box if you actually have a site that needs an update you'll get an email from us saying hey need an update you'll jump into your site there'll be a button that you push to update it and then right in the development environment it'll apply that update and what's awesome is that because it uses get to apply the update so if you've made other core patches to the system it's going to do a get merge operation to apply the new update usually it's no problem it does have a merge conflict it'll tell you and you can resolve that but it's something that makes core updating easy and not something that needs a really technical resource that anyone can basically do the update by pushing the button and then you move it from the development site to the testing infrastructure and actually review it before ultimately going live and our hope here is that this just saves people a lot of time in terms of doing the updates especially if they have a lot to do for security reasons yeah yep absolutely yep so the question was would that work with multi-dev as well so you can apply that patch to multi-dev environments specifically yep alright so sometimes you build something really complex and there's an issue with it right I mean I know that I always wrote perfect code, Matt likewise even perfect error but someone else on the team might have written something that's a little bit not quite as clear as it could be and you have to try and understand where the bottleneck is and that can be a real pain and if you haven't built this already into all of your workflows going back and retroactively saying how am I going to possibly diagnose what's going on is a really big challenge and our solution to that actually is to use New Relic it's an excellent tool and we just build that into the platform so anytime you have a site on Pantheon you're also having New Relic there available to scrutinize what's going on and you can just dig right in why is this particular query slower we're getting weird page loads here dig right in, see there it is alright something going on with image resizing better go check out that function boom, figure it out without tools like New Relic around something that takes minutes with a tool like that it could be hours or even days just sort of like wandering around hoping you find the right needle in the haystack you do know so we have an agreement with New Relic so that all of the sites on Pantheon will be able to use the basic tier of New Relic which actually offers a lot of options for monitoring and for diagnosis you can go, there are some more advanced features like custom reporting and some event driven kind of stuff that you can upgrade and pay more but all sites can use New Relic with the standard package another problem that we found we did a survey of web agencies and web developers and asked them think of your last four or five projects how many of them launched on time and we found that about 60% of the projects did not in fact launch on time they were delayed in some cases days in some cases weeks and in a few cases months or a year or so my sequels at 19 years for 5.7 so things can go late and we're not going to solve all these problems but one of the things that we make we help to make your site launch on time is that we have this workflow where you can go from dev test to live with just a click of a button and then as Drew mentioned the live environment is also the same in terms of the containers and the configuration as the test environment is the same as the dev environment so that the kinds of problems that we saw that like block launches like oh it doesn't work on live but it worked on my local machine or in my dev environment you don't have those kind of problems and it's running the same as the dev environment likewise if you have a sort of last minute change that you have to put up it's not like you have to go out and redo your whole deployment big launch procedure to do it you can just push the change into dev and to test into live and so our hope is that more sites can launch on time when they use this kind of best practice kind of workflow tool that you can go dev and that within each of these environments you can see here so I just a sort of a demo I had gone to this site when we started and it had a yellow box to upgrade to the latest version this is running a Drupal distribution called Panopoli which is fabulous by the way and that new version 1.27 it has a git commit this is actually all the code that was there but I want to test it before it goes live so I actually have an option to deploy that commit it will bring the commit from dev to test it also will go and take the database and the files from the live environment and move them into the test environment then it will run update.php and clear the Drupal caches and what's really great is that like this isn't going to take more than like about 45 seconds but it's going to give us this really awesome test environment that is in fact basically exactly what it's going to look like when it goes live because it's running the exact same configuration all the containers it has the up to date most latest code that you want and it has the exact copy of the database and the files from the live environment and this is something that you can script and you can do you can do a MySQL dump from live and move it to your test you can do a git tag and then deploy it to a new environment this is all stuff you can do but it's stuff that can be a little bit a little bit daunting this is just one button to push and then if you actually want to go live it's no more than just clicking deploy and if you've reviewed it in tests you have a pretty good chance that it will work in live so our hope is that it will make more sites launch on time yeah so we have a feature as Drew mentioned multi-dev which basically means any git branch that you have we can instantiate an environment based on that so we can set up a web server and a URL and stuff you can have as many of those as you want we only have one formal test environment but we see a lot of folks using multi-dev to spin up other environments that then has become test environments that you can use so we have people like that have acceptance testing and QA and stuff that use it that way yeah and we again provide the tools so our hope is and we see this from our agency partners our hope is that each individual agency can use these to personalize it to their own workflows their own paces and their own procedures for doing things like QA testing and such so another thing that happens often in web development is you know like we've got this project over here, this project over here this one's using these set of servers, these things over here and the time to orient yourself to all of the things in that each of those individual environments is non-trivial you have too many things to learn on each individual project and again we're all smart people we can learn them but project modules are fixed whatever amount of time you spend in that sort of overhead stage comes away from your overhaul your budget for the project so whether it's 5 hours or 15 hours or 2 hours I know people who work on projects that are complex enough that the actual setup time to even just get you know able to do the first actual things, they ballpark 2 weeks this is astoundingly terrible statistic you should not have to spend that much time in order to start being productive and so again if you standardize on Pantheon all of these great tools all the time it's super simple just have it be taken care of this is all robot business like let the robots take care of it use the best tools all the time and we'd love to have you do that on Pantheon and we have a booth downstairs if you want to see a larger demo of what we showed or have questions about how we set up the container architecture or other stuff come visit us but we thank you for your attention there are 10 common problems and how standardization can help solve them thank you everyone and we're happy to answer questions now as well if anyone has do we handle those? no we do not handle that automatically for you so if there's a new version of use or something like that that's not the case if you have one possible way of handling that is to use what we call custom upstreams which Matt talked about we have used these 38 models if you make that update to your base distribution that can flow through all of the sites automatically thanks we do work for a federal government in the US I think you're not FedRAMP certified the platform but in terms of security and compliance for government maybe that's a question for the European context I don't know what that is here but in the States FedRAMP where's Pantheon? we do government work what kind of security stuff do you have so I'd say we take security very seriously on pantheon.io we'll show you a lot of techniques that we use to do intrusion detection and auditing we do a lot with PCI we have a lot of those features we don't have FedRAMP specifically I think Blackmesh is the only one in at least the US that does that work but we have a number of government sites that will host us that they don't have those requirements it just sort of depends on what you have and I would also say just a lot of those certifications are also changing a lot but the container architecture is very new and we've filled out some security we've done some security reviews of people that will ask like a lot of questions where in your office are the servers who has keys to them which is not what we do obviously and so I think a lot of that stuff is being updated but we like government stuff government is a huge group that does Drupal stuff there's like 27 or 28% of all government sites are Drupal so it's cool you're working on some maybe one day we'll be FedRAMP that could be sort of cool but we can't be on very secure it's sort of a follow up question for the way, I don't know if this mic is working but just about the multi-dev and the databases is there a way to do database sanitization so that your developers don't have an actual copy of the live site in case for a security barrier that maybe your developers ought not to have the actual live database so let's say we have developers that need to have more restrictive access and sanitize stuff how do we do with that so first thing is we have a technology called change management on the platform that allows you to add people to your projects that are just developers which means they can't access the test database or the live database or that code base or that that's sort of piece one that's pretty helpful and then the second thing we have which we didn't show off here is the standard interface for all of the different functions on the platform so everything we showed you with the button pushing and talked about, that's all scriptable so in terms of sanitization we don't have anything sort of super built into the product where you can have a UI to do it but we offer the ability with our command line interface to when you're moving databases you can download a database, change it and then push it back up and so people who do sanitization what do they write that basically calls our thing to get the database runs any sanitization that they think appropriate and then pushes it that way and that'll work, no problem yes this is probably more of a clarification than a question but can the upstream, the custom upstream work with an installation profile yes, so the question is will the custom upstream work with an installation profile and the answer is yes the way that we do it is that every site has a specific upstream value these actually all correspond to a specific repository on GitHub, so this is the Panopoli one this is a Drupal distribution it basically it's a fork from our version of Drupal drop 7 which just is Drupal 7 but we actually put in all the different code there and we support a number of popular Drupal distributions like Drupal commerce and Panopoli and Open Atrium and stuff like that but if you're an agency and you have a custom distribution that you want to run just for your agency we'll let you set that up as well all you need to do is make a GitHub or Bitbucket version you can be private give us the repo and we'll set it up on our platform great, thanks cool, other than that thanks again for everyone for your attention and come down to our booth if you want to chat more thanks everyone