 Hey everybody, my name is Scott Massie and I'm the Managing Director of International Regions for Pantheon. Pantheon is a web operations platform for Drupal. And we've been around for about 10 years. Maybe you've heard of us or tried us. And I wanted to take a few minutes to first off welcome everyone to the Drupal South Shorts in 2021. I'm here in Tokyo, but I very much miss being down there in person for these events. And so I'm hoping that in the near future we'll all be able to hang out again, especially in Australia and see each other face to face. But in the short term, this has been an awesome event so far. The user interfaces and things like that have definitely improved and it's a pretty smooth fun experience. So yeah, let's get started today. I wanted to kind of talk about something that's relatively new for Pantheon, a new feature, and it is called Autopilot. So having run a couple hundred thousand websites on our platform for a long time, I would often spend time working with customers together on a video chat or something like that. And we go to look at their dashboard and there's a string of updates waiting to be pushed, you know, core updates, contrived updates, that sort of thing. And the same thing, even when we work with our agency partners, we see the same thing. There's just not enough time in the day to update your site. There's a lot of other things going on. There's also sort of the doubt of what happens when updates get pushed. And so that's something that Pantheon has wrestled with for a while because we want to create this really agile pipeline for not just code, but also for ideas to get pushed to production and into the world. And so we developed, we thought about it and we came up with a couple solutions. We have a very manual solution that our professional services team offers to do it, but we wanted to offer something for everyone. And we have spent the last couple of years developing this product because we know that both things are true, that agencies and website owners are very busy. But also CMS updates are very important in terms of new features, definitely in terms of security. And there needs to be a better way to do it. So this is what Autopilot is and so what it is, it takes best practices of the development pipeline and best practices of DevOps and best practices of Drupal and combines them with automation that has existed on our platform for a while with being a container-based system that incorporates dev infrastructure as well as hosting infrastructure. And we added some magic in the form of visual regression testing and some other kind of common sense tools and bundled them into this product called Autopilot. And what it does, basically it scans your site, it scans your site's code base, it runs some commands that looks for updates in your upstream, it looks for updates in your theme, it looks for updates in contrib, and if it sees them on a regular basis it checks and if it sees them, it will attempt to test them using visual regression testing and if it passes based on a threshold that you set, it will push them to either the dev environment on our platform or to the live environment on our platform if you wish. If the tests fail then it keeps them in a separate multi-dev environment for you to review and determine if it was a false positive or if indeed something has gone wrong and you need to test it. It's pretty simple visual regression testing so it's meant to sort of track the most impactful changes that could affect a site. You know, you make a change and it breaks the theme on a page you didn't expect it to or an error shows up on the page or the page gets rendered in a way that's not really permissible or usable for the user and this helps reduce that. It's not really a replacement for really in-depth unit testing or CICD but what it does allow you to do is it allows, say, an agency to offer this as a service and do it in a way that, especially a lot of our agencies that do mainly work on projects, it allows them to offer updates as a service in a more sustainable, scalable way because you're moving from actually running all these tasks to basically just handling exceptions and so we've been able to work with our partners as we've rolled this out to help them sort of bundle this as a service and include it and have it be sort of more of a fixed fee service that benefits the user because their site is up to date. It benefits the developers on the team because they're more able to push changes without updates blocking or without updates being dependent on features that are waiting to be pushed upstream and it makes it easier for the agency to offer a service that provides monthly recurring revenue which is also really nice. So we've rolled it out to a bunch of agencies all over the world. They're big fans of it. They like it. We've been making improvements and fixing bugs and things like that and it's about to roll out in general release and we've rolled it out to some of our power users who are able to maintain hundreds of sites and save dozens of hours that they would normally spend blocking off time to update sites to test them, that sort of thing. So what it does, I'll run through this and then I'll show you a brief example. We have these container-based multi-dev and you can spin up these ephemeral instances of your site at will and we have robots do this. So it finds an update. It creates a multi-dev. It applies the updates. You have already plugged in URLs that you think are important, the home page and what other pages you think are important. It runs visual regression testing. If that passes, then it can push it to dev. It deploys them to updates. If you have additional tests, more in-depth tests, you can run them then and then it deploys it to our test environment. If it passes there and then if it makes it through user testing or any other final release management process that you have, it pushes them. It runs a backup, which is always a nice thing to do, and then it pushes them to live. So it's hopefully a pretty dependable way to push the core updates, which hopefully shouldn't break your site if you're following best practices and the basic updates that you want to run to keep your site going live. So this is an example. This is my dashboard here. Let me just go full screen with this and maybe take myself off the screen so you can see that. So here's my dashboard for my site. I've got a little bit bigger there. And so, yeah, here's my dashboard. I have sites. Here's all my sites here. I go to the autopilot and here's all the sites that it's running on. And so, like, I'll see that some are up to date and some are errors and some have failed. And so rather than freak out that I have sites failing updates and I didn't know about them, I can actually just go and review the test results in a safe environment. And I could see, like, with this example, oh, there was this change and maybe I didn't intend for this to happen. But even if it's fine, even if, like, that module which renders this block was intended, I can just approve it and the cycle will continue and push it to the dev environment. I can dive into the instance and see what actually happened if it was an error that I didn't intend. I can kill it or I can accept it with all of those just to show you, like, what the configuration looks like. Like, right now I have updates being checked for my upstream, which is my core. It could be a custom upstream if you're running custom upstreams on our platform. It could be a module. It could be a theme. This tells me, this tells the robots where to push changes after a successful test where they get deployed. And this tells me how often I do it. I can run them ad hoc or I can schedule them on a regular basis. And then, yeah, just plug in my URLs. I can plug in a framework there that, you know, a threshold there that says, you know, as long as the change is less than a couple percentages, then let it, then it's fine. And I can exclude divs and other sort of things. So it's pretty straightforward. It's something, you know, I'm a fairly non-technical user can set up and run successfully. So yeah, it's about to go into GA. So every customer that either is on a contract that has a gold tier or above will have this built in. You may already have it built in. If you don't, it'll be coming soon and it'll be available in the dashboard. And agencies, any agency that's a registered partner will have this free to use or included with your normal partner. So yeah, check it out. We have a bunch of stuff coming soon. We have some cool stuff that we're testing with machine learning to sort of better pick out errors and better resolve issues that pop up a lot more editing and integration with other CICD platforms and that sort of thing. But yeah, try it out and ping me if you have any questions or want to see a more in-depth demo. Yeah, thanks. All right, cool. Hi. Hi. My name is Stephen Robredo. And today I'll be showcasing the Aurora Beverages website. We delivered a few months ago. And this site has been selected for Acqua Boards finalists under the manufacturing category. And the highlight of my talk today is the build speed. Drupal has many strengths as we all know. But for me, the build speed is probably a key factor for choosing Drupal to deliver successful projects within the budget. Because when we talk about the build speed, it's always alarming the budget because less time means less resources, less resources mean less budget. But what we need to understand here is even though it's low budget and a tight build, which means the quality and the performance and everything has to be in a very stable level and very acceptable level. So I'm going to go through all the things that we have done to achieve this. We have delivered the Aurora Beverages project in two active spins. Active spins mean two development spins. Yeah. So let's get into the overview. So during this project, we have actually separated this into four different stages. So lucky we had a spin zero. And then we had spin one and spin two, which is the actual the development spins. And then we also had another extra two weeks extra spin for you at the end but fixes. Right. Let's get into spin zero. So planning stage discovering phase and some people call this spin zero. So we had two weeks of discovering phase phase for this project. So we already knew the high level of requirements for this project, but you need to have this. So the aim of this phase is to identify and refine the requirements. So we had so much of meetings in spring zero, I think it's pretty normal for all the projects. So this is where you had all the like car sorting personas all the meetings and and in and the aim of this phase is also to identify and refinement your issues are in the tickets. And this phase is very critical for any for the solution. You also need to create the story breakdowns with the epics getting your G-rated and get your wiki, put your documentations together and putting architectural diagrams. So, and maybe like very critical factor is you need to sign off your solution before you start your first print. By, by this period, spring zero, you have a good idea of what sort of a Drupal core and base modules you need. So I would recommend you to select the modules by this stage. So the best thing about Drupal is you already have number of modules that you choose to accelerate your solution. For example, if you need like forms, you can install it forms for SEO requirements, you can install meta tags. And if you need extra security, you can go for like a second yet and for revision management, the moderation. So Drupal has all these in-built modules. So what you need to do at this stage is pick your modules and sex election and install your co and base model module and get the base installed ready in spring zero because you don't have time to do that in your sprint one and two because you straight away get into the development phase. And the other thing is the base team. So it's good to select your base team wisely because you don't need to create your components all over again and you don't have time for that. And there are heaps of base modules you can use. But in this case, we have, I have actually selected the UI kit for the first time. And the reason I went with UI kit because opposed to bootstrap and other stuff because UI kit is pretty lean. So I thought of to give it a try and it's actually really worth for us. Right. And finally, the most important thing you need to sort out before you start the build is the pipeline. And a solid pipeline is a key factor deliver a successful project on time. So in our case, we've used Acura as a platform and BLT as tooling deep lab as the source code management. And also continuous integration because it has a nice way to build your the branches and testing out and also land over some continuous development. Yeah, I know most digital agencies has their own stack that works. So yeah, whatever works is good. But the main thing is we need to have something solid and not interrupting your work during the development phase. Okay, let's get into sprint one. So because we did this, this in two spins. So spring one is all about setting the stage. So let's, let's, let's get a little more detail about that. So normally when I, when I start any, any development, I normally concentrate about the global components to set up first, like for example, the header. So the log with the main menu search bar, and also the footer section, which is pretty key global component, which is footer menu social links copyright nodes. In our case we had phone numbers, things like that. So set all this up first the headers footers and then get back into, if you need breadcrumbs set that up and the page layouts, and also the typography. So make sure you install your fonts and the typography is being skin properly. And then also the rich text editor. So set up your pictures edit editor and make sure you're the style guide has been integrated to your CSS. And then once you create a basic page, for example, like copyright notes or something. So that's probably one of the basics page you can ever see this just text. So make sure that page is working with the header and footer so that that's where you normally start. And as soon as you figure all these your global components, then my first step is to go through the home pages, because I am anticipating by sprint one. The home page. Home page is signed off the signs. Yeah lucky in order project as well we had the home page is signed off by this time. So that's, that's why we started with the homepage. And then yeah create your paragraphs. Think about your overall design and what sort of paragraph it's about to come and try to be reusable as much as possible. We did the news content type and news pages news listing content type in the spring one as well, as well as the content contact us page. And then as with the contact us page I just forgot to mention that previously, we had to do some sort of integration here with us that there's a requirement for sales a bit to lead integration needs to happen for the contact us page. But the good thing about Rupert is like this sort of challenges has been already resolved before. So as a consequence we already had a module ready for us. So all we need to pick up that module and then put the, you know, in the API keys or things like that and then you know it's it's pretty easy. So that's, that's one advantage of doing group of things because that this ecosystem is pretty solid. And most of the challenges has been resolved before. So we can, we can get out everything without much writing extra codes. Right. So let's get back to the, okay, sorry, this is this is our spin trip or I just wanted to show the how the burn down charts things like that. Okay, so the spring to this is the nature of our project we had to deliver everything to spring. So this is achieving the milestone. So we set up the stage in the previous spring. And this print is all about you, you are your main area because this, this company has various products and they they voted the comprehensive filtering system with their product catalog. So think about some other system if you want to, if you want to implement something like that, this is comprehensive filtering system it might take at least, you know, two, two to three to four weeks to create something like that in a any other platform but thanks to you, we have a search API and I quite supporting aqua search API and facet search and you're creating content type and you have taxonomy systems and display modes. So if you put all everything's together, you can come up with something like this within three to four days, I think, including teaming. Yeah, in our case we had some sort of landing pages, and then it's all about teaming and creating these components and there's nothing fancy here. It's a pretty, you know, basic information site. The integration is only there to lead, which is the contact us page. So we able to manage to deliver these in two screens, which is we completed here. And with it. Okay, so now I'll go back to the tips and stuff. So before we start, I want to acknowledge that the team. So for this, I asked the group lead and and the lead developer here, and I had a mid level developer who's work along with me. And he's pretty good. He's full stack. So he understand that he understood that back and then front end. And also we had another resource and she's a she's a junior front end developer. She had zero knowledge about Drupal previously. So that's the only only like myself and that's the other two develops the only resource we had to deliver this in two weeks. So what we what we done is like. So me and the other mid developer, try to finish most of the components to some extent like 80% to 90% we didn't spend too much time to finish it off. So what we done was, we left whatever the 10% or whatever left overs to be picked up by the mid developer, because when the things come to her is almost finished, she has to finish the final touch ups and if this bugs and fine tuning, and then she picks up all the leftovers and finish it off along the way so that that that model actually was very beneficial for us. But it depends like case to case but in this case because she had zero Drupal knowledge so we didn't want to put her like to put like entire components. So that's why we went through some components and just half finish and then leave the leave the junior developer to touch up and finish it off and create the I mean bug fixing sort of pick us for her. Right. So my tips for this is actually the platform like the CD CI, which is the pipeline that I was talking about has to be really solid. So I know that most agencies has their own pipelines actually working. So that has to be really reliable. So that's pretty key things if you need to deal with something really fast, and also a team, if you have a good base team, then you can actually, actually. Yeah, heavily for most of the stuff and manage your resources wisely I already talked about this and planning your reusable components also is pretty common sense but and also the very important factor here is the product on as well. So you need to have a very good relationship with the product on and and luckily we had a great product on it because because along this exercise. So much dependencies you need to call out early and you need a lot of answers, love questions and a lot of things you need to resolve quickly so very proactive product owner can can deliver you this in a very quick manner. Then you don't slow down and and we actually benefit the that sort of luxury in this project so that's what that's what we managed to deliver this and if I have time I would quickly like to show the website that we did. So this is the homepage that the product we had, and then their filtering system that I talked about that comprehensive filtering system and then the whole of items as well. And they have like about 100 200 products and filtering system is using facets, which is pretty. Yeah, and we can manage up to five filter the drill down pages and this has a product catalog slides and the inquiry back is forward back to the contact cost page and then move and then forward back to their sales to lead. And then these are entity references, and we had so much of we got four to five landing pages per this is the product landing page. And these are the categories each categories have had his own landing page. And these images are like selected by the client and they create all the content. And, and we are pretty happy to finish this in a very record time and we enter into the, the aqua finals and yeah, so that's, that's my quick presentation about my quick delivery. Yeah, is there any questions or anything that would like to, I'd like to share my knowledge.