 Well good afternoon everyone, welcome to Ten Reasons to Standardize Your Development on Pantheon. Hello. Hello. Yeah, yeah, yeah. Day two of DrupalCon. This is my second presentation of the day, so very excited to be here. I am Steve Perche, I'm joined by Ryan Sears here. A little bit of background on me, I'm an agency and community engineer at Pantheon. You can find me on the internet as Steve Vector on Twitter, Drupal.org, GitHub. You can also find me as Drupal Haikus on Twitter. So agency and community engineer, I come from a background of building Drupal sites for agencies. Working with agencies, building sites for end clients of all sorts, media clients, nonprofits, university use cases as well. My name is Ryan Sears, I am a partner manager at Pantheon and I have two kind of quick questions just to kind of understand the audience a little bit better. How many of you have actually ever like used Pantheon to launch a site? Like actually touched it, used it, okay, got a handful. And how many of you work at agencies? You're doing this like for other people, third party, okay. So for those willing to raise their hand again, about half, something like that. So just a little bit of background on me, I've been at Pantheon for now just about three years and the first two years I was actually working as one of our enterprise sales reps. So spent a lot of time working at people kind of doing large scale implementations of Drupal on Pantheon. And part of my last year has been working specifically with what we view as really central to our kind of like long term strategies. Working with agencies who are often times doing many different size projects. And so one of the things that's been interesting for me is not only seeing kind of like large scale projects happen on Pantheon, but then specifically like what are the unique use cases that apply to agencies? The business owner, the site owner, the agency owner, folks that are digging in. So Steve obviously as an engineer has a much more technical background, but we'd like to think that when we start engaging in this conversation about standardization that there are a lot of different reasons why someone would be interested in doing this. And in my three years at Pantheon I've definitely seen hundreds and hundreds of different use cases of people that kind of go through and look at that. So that's my background. Just for those who may not know a little bit of the background and story of Pantheon, there are four original founders. All of them have now over a decade of experience in the Drupal world and working on kind of like a lot of the lore of the early stage Drupal projects, the department of defense working on the economist, and really kind of figuring out how to do this Drupal thing that was still new at scale. And so building the tools to allow Drupal to reach that kind of level of sophistication and architectural sophistication, they were doing this hundreds and hundreds of times. And so literally every single time they were going through this process, they were building in architecture and infrastructure and codifying the best practices for going through this. And Pantheon's genesis was really as a way of saying there has to be some way of doing this that actually allows for us to implement these best practices to do it at scale for many, many sites. And that really is what Pantheon has come out of. So at this stage of the game we're now at over 130,000 websites running on the platform, over billions of monthly page views. We like to brag about our kind of ever-increasing percentage of the overall internet. Now at 1 in 1,000 on the web, so just made it onto the marker for there. And we were working with over 1,000 allied agencies. And so specifically when we like to think about what is the reason why not only has Pantheon kind of come out of this genesis of the Drupal community, but what is its standard use case? As opposed to being forced to build these things one off, that on Pantheon VR container infrastructure, we've really kind of cracked the nut on two really difficult problems for people building Drupal websites. One being this concept of elasticity, like how do you actually take a site where you don't necessarily know everything about it from the get go and be able to scale it over time? And how do you run huge websites that require massive amounts of infrastructure, how do you actually do that? And then on the other side, we talk about cloud development tools for teams, which is more than just like, hey, isn't it nice to have all these cool things at your disposal? But it's about time to market. It's about efficiency. It's about making sure that whether you're at a large organization building a huge site or many sites, or whether you're at an agency doing this professionally, you have certain commitments of things that you actually have to accomplish and get done. And anything that stands in your way, either that's billable hours as an agency, that's like your productivity and being able to go get new business. Or if you're within a large organization, it's your ability to actually accomplish the things and get your product out the door on time, iterating quickly as part of an agile environment. So we see Pantheon as really being the way of completing that mission of what people really need in the web space. But this last piece here is really what we're talking about today. It's like, why would you standardize? And what is the benefit of standardization? And if you've talked to Pantheon at all in the last couple of days, it's tip of the tongue for much of what we talk about, because it really is core to our central premise of actually gaining some of these efficiencies for your project. So when we think specifically about what are the impediments that we're trying to solve? So thinking through a standard kind of project life cycle or agency life cycle, what are the things that you're running into? What are the most common problems from getting up and getting started on a project to are you going to launch on time, to the sustainability of continuous integration workflows? We want to dig in into specific examples of common roadblocks for people who are building websites either for their company or for other companies as part of a third-party agency and really how Pantheon is the perfect solution match for a lot of those common problems. Sure. And before we get into these 10 items, we're going to take a look at the Pantheon dashboard. Can I get a show of hands? Who stopped by the Pantheon booth and seen our dashboard demo? So just about everybody, okay, so I will not repeat the demo in its entirety. I want to highlight a couple of key areas that we didn't get to see in that main demo. So first, again, I want to highlight the basic idea of working with Pantheon from a development workflow perspective. So the idea that we have code going up and content coming down, this is a standard idea in the Drupal space, just about really any CMS space, the idea that our content lives canonically in our live environment and we bring it down from the live environment in order to work with it in a testing environment or in a development environment. So I'm going to jump over now to our dashboard and take a look under the hood at some of the kinds of changes we can make. So you've probably seen in our dashboard demo this idea of standardizing what the infrastructure looks like. So on the basic Pantheon plan, that personal plan, you have this essential infrastructure of traffic coming in from the public internet, hitting a varnish cache, bouncing right back out in an extremely performant manner when content is cached. If it's not cached, then Drupal can go ahead and build that page using PHP, using a database container and Drupal performs as you would expect on any infrastructure. Moving up to a bigger plan, say a business plan, yes, you get more resources. What I think is key here is that developers don't have to completely reorient the way they're thinking about it. Even before I worked at Pantheon, just as a developer using Pantheon, for me the part that I loved most was that I didn't have to think about this diagram all the time. We like this diagram, we're proud of the fact that we run on a containerized infrastructure, that these containers allow us to scale to really, really large sites. Moving up to an elite or enterprise site, you get a really large set of containers. What I like about this as a developer is that I don't have to reorient my thinking entirely as I move between large sites and small sites. That I, as a developer, can standardize the way I'm thinking about building a Drupal site. If you're building a Drupal site with best practices, it's going to run just fine on Pantheon. So I do wanna take a look at an alternative way of interacting with that configuration management system that you saw in the dashboard demo. So you saw in our dashboard demo down at the booth that we have this lovely dashboard. It gives you an overview both for yourself as an individual developer. You get to see these are all the sites that I have access to. These are the organizations that I have access to. This might be your agency, this might be your university. I can see my support tickets within any one of these organizations. You get a rollup of those sites. You saw that all at the booth. Going back to the individual site, what I wanna look at is making that same type of configuration change. You saw in our dashboard demo and I'm going to use the Pantheon command line tool if my mouse will respond here to click this button. The joy of live demos, everybody. So what I'm going to do is make that same type of block configuration change that we saw before, moving a block from one region to another and then I'm going to export that change using Terminus, Pantheon's command line tool. Terminus gives you the same ability that you have in the dashboard to interact with Pantheon to make backups, to move content from say your live site to the dev site and a lovely conference wifi is slowing us down here. So over here in our development site, I can see that I've got sidebars on both sides, blocks in both sides. If I want to move a sidebar from one side to the other, I can do so in that same way we saw before. What I'm going to do here is use our Terminus command line tool to give me a one time login link. So I have the ability to run Drush commands directly from this Terminus tool. So I'm going to run Terminus Drush ULI or user login and I want to login link to the development site. So I can just run this command here. It's going to get me a one time login link to the development site provided the wifi is running here. And if we continue to have trouble with wifi we might just skip over this part. I have a wifi if it helps. All right, I think I'm just going to skip over this part. So I can talk through what you're able to do on the command line. So you saw in that dashboard demo being able to export configuration using a button that just says export configuration. A lot of developers are totally comfortable doing that operation with Drush. So if you want you can run Terminus Drush config export export that configuration using Drush. You can commit it right on the command line if you want using Terminus. You also can commit through the dashboard as you saw before deploying forward to that test environment. You can import that configuration. The exact mechanism of import is something we kind of gloss over in that main demo. That's what I want to highlight here and luckily I don't need an internet connection to do that. So pantheon.yaml is the way you specify those platform hooks that you saw downstairs. So if you want to notify Slack, if you want to do things like importing your configuration, you can specify this pantheon.yaml file. This is what's connecting you to those cloud hooks. This is a way to specify, say that in response to the deploy operation, I want to run this config import script. Over at the config import script you can see we're simply calling drush config import. So these are the kinds of things that you can write as a developer, as a team of developers, deciding how do we want to standardize our workflow? What do we expect to happen every single time we deploy to live? These are the kinds of things that you could do manually. You could manually import your configuration every time you deploy to test or live. What I like about this is it allows you to standardize. It allows you to say every single time we deploy, we expect this to happen. Every single time we deploy, we expect to notify Slack. It takes the guesswork out of that day-to-day development work. So we're going to jump back now to those slides. So again, there are, we think, 10 great reasons to standardize on pantheon. And they coincide with the basic outline or arc of a project. So we're going to talk through what the life of a project may look like on pantheon. So we'll start here with a project set up. Great, thanks. So specifically talking about project set up, I don't know the standard process for everyone varies, but very commonly, you have to start spinning up servers. You have to set up an install profile. You have various things that you're going to do as part of any kind of net new project to get up and running. One of the interesting stories to me was working with Ketchum. Oftentimes, the technical team, the developers, they were at the whim of the business team. So the business team is out saying, we're going to do this great, cool project. We're going to do something new. And then what was the tech team left with? Whatever they decided to go with. So that doesn't, you know, it could be, this time we're on Squarespace. This time we're on WordPress. And every single time, there was scrambling, trying to figure out, how do we actually start in a place that's going to be consistent and easy for us? And rather than trying to adapt every single time to what the business side was doing, the technical team said, actually, there's a way that we can do this all in one efficient place, we can spin up these new environments. And rather than spending a long time configuring servers or getting the vagrant box set up, we can just start from jump and install Drupal. And rather than having a discovery meeting where all this great work is being done about audience profiles and the people you're trying to cater to with the website, and then, OK, just wait one week now while we go and set up your servers, immediately you can have time to mark it. And what Pantheon really provides here is a dashboard that's really a central interface for everything that you're going to be doing. Whether it be that individual site dashboard that Steve was showing, which has DevTest and Live baked in, and all the things you would need to interact with the site, or a team dashboard, if you're an agency or an enterprise that has one of those central repositories, you can see all the sites in the list. And what Pantheon then allows you to do is have consistency of practice for all those things. And oftentimes, when it came to catch them in particular, they were able to say, OK, don't just go run off and promise Squarespace or something random for every individual project. We have a way, a way to start that's actually very quickly, get us to being able to be productive for that individual site project. And in particular, one of the things that is a very common problem, especially, is when you have a specific project or even within your organization, you always want to have a custom start state, the standard 20 modules that you're going to add every single time. Or if you're working for an organization like in Resonance where they're building school profiles and they're able to print them out in mass, it's really difficult to do that. In Drupal in particular, the history has been your only choice is Drupal Multisite. How do you have a single code base that allows you to manage multiple different sites? Well, in Pantheon, rather than making you sacrifice between the flexibility of having sites with their own autonomous code bases or the efficiency of Drupal Multisite, we've allowed you to tap into this superpower of custom upstreams. And so for in Resonance, it means that they're allowed to manage one single code base. And then whenever they make that change, they can push that change to all the sites, 70, 100 sites that are all running on that code base. And for those that are different or have had modifications, they can test those before they deploy out. But for those that are identical and exactly the same, they can make that change once and deploy across the board. So not only is this useful if you have a specific product or a custom distribution that you're using for managing sites, but also just for site setup. A lot of agencies have specific ways that they start every new project or templates that help the sales team go out and be able to sell what they're able to do. Like this idea of custom upstreams really allows you to have that flexibility of managing each individual site autonomously and with Pantheon, by threading them together, it also allows for long-term sustainability and updateability of those sites. And in Resonance in particular, we found that as they were standardizing on Pantheon, they had to talk through exactly how are we going to be making updates to that custom upstream. That conversation of exactly how are we going to use these tools, but into, well, how are our developers going to work together as a team? It's common in agencies to have developers stepping on one another's toes. For myself, the first time I had to deal with this, I was using Dreamweaver Check-In Check-Out. Did anyone have that as your first version control system? Yeah, that was not a good system. I mean, I suppose it was better than nothing at all, but we found ways to work around it. Oh, styles.css is checked out. Well, then I'll make styles too.css. That's what happened. So that problem of developers working on top of one another is something that we're solving industry-wide with Git. So Pantheon, of course, is trying to give you those industry best practices. So building on top of Git, we have this tool called Multidev. Basically, for every single Git branch, you can have your own Multidev environment. If we want the Steve Multidev environment and the Ryan Multidev environment, we can do that. If we want a Multidev environment just per bug or per feature, we have that ability as well. I'm particularly excited with CMI for how granular CMI exports those configuration files. I think we're not going to have a ton of merge conflicts, especially compared to those feature files that we were working with in Drupal 7. Those conflicts were the worst to try and merge. With Multidev, I think we're going to be seeing a lot of really efficient Drupal 8 workflows as people are able to make a Multidev environment, make configuration changes, export them, and I think merge them a lot cleaner than they were able to merge configuration changes exported with Drupal 7's features module. So another problem that we're looking to solve at Pantheon, the website is slow. The past couple of months I've been doing this presentation called Why Your Site is Slow. I've done it at a couple of Drupal conferences and part of the answer is often, well, we don't have varnish. A website basically is waiting for requests from the internet and sending out responses. The faster that response can be made, the better. And Drupal, anything running in PHP has a limit to how fast it can run. Varnish can be much faster, basically if you have slash about, if you have your homepage, that's something that's probably getting served the same for basically every site. So in my own work I found that if you aren't using a system like Pantheon, there's probably someone on the team who has as a side task, oh, I've got to set up varnish, or I have to set up solar and it's not my main responsibility but I know I have to do it. That's the kind of thing that can bog down a team. If you're always waiting for that other team member to be able to update varnish or to give you another solar instance to use with your test site, you're going to be waiting a long time and your project as a whole is going to slow down. We also give you access to New Relic. That's a great way to find out what are the bottlenecks in our code. Not only for custom code, I've certainly found problems in my own custom code through New Relic. You can also find configuration problems. Like I had a configuration of token module that I didn't realize was inefficient but using New Relic I could find, oh, way too many calls are going to token module. Have I just do these simple reconfigurations? This site will run a whole lot faster. Often you need to bring in a specialist or an expert or your CTO to diagnose those performance problems. Great, thanks. And one of the things that's really interesting with bringing in people midstream, obviously it's nice from the beginning being able to get everybody set up, get their environments going and have that out of the box but we recently have been working with an agency that's been working during the presidential primary process and sometimes in advance of the Iowa caucuses you need the demand for higher scale is immediate. And so being able to have someone be able to come in, 11th hour, immediately being able to be added to a specific project is highly valuable because not only are you not spending two, three hours pulling your developer off, setting up a separate installation of whatever's going on with your site somewhere else or giving access to your CTO, immediately you can bring in people and bring them up to speed. On Pantheon in particular, it's nice and easy where you can add an email address and they're immediately added to the project. So team management on Pantheon is as simple as adding an email address within that site's dashboard and then that team member immediately has access to everything there. In some use cases for large technical companies, the media publishing or really anywhere where there's kind of secure processes about deployments, sometimes you even wanna be able to lock that down. So within Pantheon, there's team management tools where you can say lock a developer to only be able to touch dev but not actually promote code to the test for a live environment. So that's our change management controls available to agencies and organizations. And this is something that in particular when you think, again kind of putting my like business hat on, I think of time to market the ability to step in and address issues on demand and not essentially having my like development team, the people that are actually producing the goods slowed down by like doing all this putzing around stuff. Like that's a huge value in terms of not having to like mess around with these things every single time. And in particular, when I think of another common problem for those teams working together is the worst common problem is that the site doesn't launch on time. And now there are a lot of things that go into a site potentially not launching on time but we recently worked with an organization called dbrand and they were having problems on the infrastructure that they were working on and realized that we're now two weeks out from Black Friday and we're selling internet or cell phone covers and everything, we're running huge promotions and we're not sure that our site's gonna be able to scale. So this issue of like not launching on time has many problems but moving to Pantheon one of the things that's really cool about the process that you just get out of the box for every single site is you have baked in best practices. So you have DevTest live. You can make sure that when you deploy your site, you're confident that it's going to actually work because you've run it through on an environment that's identical and testable to what you're gonna be running in production. So the team that was able to kind of move the site over to Pantheon then was able to get up to speak quickly and make sure that they were able to launch on time because the QA process and all of that was standardized with like a standard set of best practices and when you kind of even expand the view outside of an individual project to many projects the consistency developed by being able to have a standard approach for deployments is a huge value time saver and making sure that you're actually doing this in a coordinated way and everyone can be on the same page for exactly what those deployments are gonna look like. And it's especially helpful when it comes to core security updates. I don't think anyone particularly enjoys doing core security updates. It's a task that we have to do in some way as Drupal developers. We have to make sure our sites stay up to date, have the latest security releases. And when I was just working as a freelancer I could keep track of all the places I've deployed sites and how I deploy security fixes to all those sites. As I started working with other people well, okay, maybe I just need to ask the guys sitting next to me, how are we supposed to actually deploy these security fixes to that one site? Well, okay, that works. That maybe works with two people talking with one another. As you get to a dozen developers working with one another, working with a large number of sites each deployed in different places. It can be really cumbersome to keep track of how are we supposed to get Drupal 7.46 out on all these different places. And that was especially critical with Drupalgetin. A couple years ago we had a security hole come to Drupal core and within seven hours if you didn't have your site patched you should just assume that you had been hacked. So the company I was at at the time we had a team of people dedicated to making sure that all of our clients got the patch in time and that was just fine. Pantheon we were able to block some attacks and we were able to provide that one click update to any site on Pantheon. When it's mission critical, when it's absolutely critical that you get security updates deployed immediately the more standardized you can be in how you're making those deployments the better off you'll be because seven hours is not a long window to make those kinds of fixes. So we also have people asking us about what to do with continuous integration. Some people like to think of their Drupal sites as the units where they simply put modules in. They push them to Pantheon and that's it. That's pretty much the way we've been developing Drupal sites for years. People are starting to reconceptualize how do we think of the way a Drupal site is being put together. Some people like to think I would just like a slim repository that has a Drushmake file or a composer.json file. The way Pantheon is answering this question right now is we're giving you a clear picture of what we expect Drupal to look like when it is fully assembled. So if your team decides we want to think in terms of Drushmake we want to think of composer.json and we want to have our own processes for building say SaaS or running gulp or grunt. We say please do go ahead and deploy your site by connecting say GitHub, have CircleCI, Jenkins, Travis whatever continuous integration you want to use to get you from that known start state to a place where Drupal is in that shape that it has been for years. What I like about Pantheon is that we have a clear line between the application and the environment. Much of the conversation around continuous integration has to do with how do we know where our line is between our environment and our application. When I got started working with continuous integration processes I would intermix setting up my environment and setting up my application. I would download modules and I would configure Apache and then I would do something else at the application level. What I like about working with Pantheon is that we handle the environment for you. If you want to organize your Drupal project in a certain way, go ahead and do so. We're giving you a clear picture of what our environment looks like and you can send us exactly what we need to deploy it on Pantheon using Terminus. Terminus as you saw before is that command line interface. So you can use Terminus in your day-to-day workflow if you want to just use the command line rather than the dashboard. It's also that bridge to continuous integration platforms. So in my own time right now what I'm doing is building pull requests on GitHub and then sending them over to Pantheon using Terminus. We're also rolling up more and more ways to integrate with third-party services. So you saw at our booth demo the ability to let Slack know what's happening, the ability to let Jira know what's happening. Again, this is a great way to standardize. When you've got a team of developers working on a number of sites, it can be easy to forget. Oh, I'm supposed to tell Ryan that the deployment has been made. If we just have that happening in Slack, if we're just simply updating our Jira tickets, then I don't have to remember to tell Ryan, hey, take a look at that site because I've made the deployment. The robots remember to do it for us. That's what they're good at. Developers can focus on what they are best at as well. So again, Platform Hooks is the way to do that. You simply define with that YAML file the scripts you expect to run in response to which Pantheon level events. Great, so this has all been kind of conceptual from project start to launch to long-term sustainability and really the core problem we're looking to solve with Pantheon aside from everything a site needs to be highly scalable, secure, on a bulletproof infrastructure, but also everything people building Drupal sites need to be successful. And so one of the things we've seen is especially in the agency space is that people who are building sites over and over again or even for organizations that have many sites, every time they start a new project, they have to orient themselves, like I've spent six months on this and now I have to totally switch gears and do this in another way. And we've seen this kind of across the board with agencies whether it be Calamuna, Minecraft, or like any of these agencies that say, hey, we recognize that actually not every single site we're gonna have the choice of where this is gonna live in production, but we know that every single project we can start on Pantheon and that we can start it there and even if the eventual destination is somewhere else, like we believe there's a lot of value wrapped into kind of keeping it on that same platform, but even if you don't have the ability to make that choice on Pantheon by standardizing in that way, there's a consistent project, like a project process that everybody can buy into and that everybody can see. It's transparent, it's scalable, it's something that is immediately available to you. Like this is the power of modern SaaS. Like the only reason why we're able to offer these things is because we have this giant container-based infrastructure and so giving you these pieces to be able to use as part of your development life cycle or any sort of project life cycle is part of our contribution to saying, let's make this simple. We know that if you're doing that on Pantheon, not only are you gonna alleviate a lot of these specific problems, but the thing is that, again, back into the world of site owner or business owner, time to market, ability to make changes quickly, being able to have a scalable dynamic for all of the projects that you're working on is a truly valuable thing when you're building a team or really running any sort of customer project or your own site owner project. So we see that as being kind of like the linchpin for really taking advantage of what Pantheon has to offer. And is there anything else on the standardization front that you wanted to touch in on? I love it. Like the standardization philosophy is something that has really hit home for me because it's especially valuable when you come back to these projects. We've talked through this lifecycle of projects. What happens six months later, a year later, when you're pulled back into a project? I find that when you're setting up your projects in the same way, when you're doing deployments in the same way, when that client does call you back and say, hey, we can now start phase two or we can now start phase three of that project, you're coming back into an environment that's familiar, you're coming back into an environment that's standardized. So those are common problems in ways that Pantheon can help to solve them. Now over to you all, I'll bring this out if folks have specific questions. I'll stop roving around with the microphone. Any questions at all? I will assume we have answered all questions already. And we're also around, like if there's specific things that you're interested, if you've touched Pantheon or had challenges in kind of getting up to speed, we have, here I'll move to the microphone. We have teams that are really designed to help make the process of moving to standardization easier for you. So whether you're at a company and you're kind of like starting off with Pantheon for the first time, you wanna run your site or you're an agency and you're looking to say, like, is Pantheon available to help me kind of like move this life cycle towards more agency standardization? We have people as part of our team that are really focused on being able to make that process easier for you. So both Steve and I kind of work with hundreds and hundreds of different agencies and organizations that are looking to do that. So if you need specific help on that, our information is there in the slides or please feel free to come up and talk to us about it. Great. Well, if there aren't any questions, thanks everyone for coming. Please do review our session. We'll be at the sprints on Friday. Of course you can come find us at the Pantheon booth. The Pantheon party is tonight. So we hope to see you at the rest of the conference. Thanks everyone.