 Welcome to closing, you know, a few sessions of the Drupal North. Hopefully everyone's having a good time at the event, learning some good things, getting it going. This is excellent. I've been... It's my second Drupal North. I was here in Toronto a number of years ago. Had a great time and an honor to present some learnings and information for you today. My name is Matthew Cheney. I work at Pantheon, which is a web hosting platform. Some of which I'll show off parts of it today, but I'm not really here to try to like pitch my service. I'm more trying to talk to you all about things that I think every web developer should be doing, which is using a strong industrial-grade workflow and then doing a lot of testing and automation of the work that you and your team is doing. That I think, you know, as someone who's like done web development in Drupal for a long time, I think there's been an emerging set of best practices that have come about and there's a lot of time savings and sort of risk de-risking that can happen if you use what I'm calling an industrial-grade workflow, mostly because I think this thing looks super cool and I wish more website development projects were of that kind. To sort of lay out, you know, the next like 45 minutes or so, I really want to talk about sort of verge control and like some more advanced uses of Git using branching. I think these are sort of ground stakes for doing anything particularly interesting on a workflow basis and I want to also talk specifically about Drupal 8's configuration management system and how using configuration and code and using update hooks and things can allow you to do dry deployments and get yourself set up for testing. And then sort of the, you know, in the middle, I really want to talk about all the different kinds of testing services that I've used or seen people use. At Pantheon, we work with like hundreds of web agencies and so I see a lot of different development practices and a lot of what I'm sort of trying to distill down are just things that I see in the industry and things that I think are really excellent. And so I'll talk about a few of these services. We can do a little Q&A. I've used all of them pretty extensively. You can definitely answer questions or get into more specifics on them. But then I wanted to then sort of, you know, put it together at the end, show a couple. Let's knock on with live demos and just talk about sort of a couple options for maybe improving your workflow or leveling up your game, I think. My hope is folks to come to this session, we'll sort of learn a little bit about, we'll get in workflow and then get some really good ideas and practical things to go back and say, I want to add a B-hat test to my project and get some flavor for that. So this is what's going on. And here's me in Columbia for the DrupalCon. But okay, let's start. Before we had workflow, before we had sort of the idea of a dev and a production site, like workflow processes ended up working very, very basic and very much like this. And this has certainly been my experience before getting into workflows, presumably some of yours. Maybe some people still do this kind of stuff for projects. And these really basic kind of cases is this sort of cowboy coding kind of work where you're like literally just editing production code, which of course is probably not the best idea. Don't necessarily need to sell that that hard. But even a sort of idea of a local development where I have a sort of version of the site and I'm making changes and I push them up and I sort of hope that that's a sufficient change. And then these are ways that you can build a lot of websites. Like maybe most websites on the internet were built with some version of this in mind. But I think as you start to talk more advanced projects, you can start to talk working in teams like you absolutely have to have some kind of workflow solution. And I'm going to guess that like a lot of people's room, like just quick show of hands. Who's using some version of this workflow? Like a dev to test. And okay. So this is definitely a like standard way that Drupal websites get built. And I think that's awesome. Like I also do a lot of work in WordPress. Like plenty of WordPress people do this kind of development as well, but I feel Drupal people early on were very interested in how do we make this process work? How do we build tools like features, configuration management to make this work? Because in the Drupal world, you can fiddle something over here and something over here pops up and that's super magic when it's intentional and it's super annoying when it's not. And there's a lot of ways you can break Drupal sites. And so having that really sort of obvious testing element in the middle is a really big deal. The sort of value to this though is that like when you have as you've probably seen when you have specific development environments you obviously have that safe place to experiment that you're able to try new updates and modules and code patterns and you can throw those changes away if they're unsatisfactory as well as you can make sure that if you do have problems you can fix that before deploying out. And this is something I'll talk about. I think ideally you want to provide every developer on the team with her his own development environments then these should be more personalized sandbox kind of elements and there's a lot of ways and get you can do this. Having a test element in the sort of middle of this allows you to get what I think is really sort of a holy grail kind of element which is I want a test environment to be the same kind of specification the same kind of runtime the exact same basically in all ways possible to the live site but also of course have the latest copy of code and that being able to set up a test environment with those properties is not actually that easy to do but when you do do it it's awesome because you can say I'm looking at the latest code with an identical server configuration live environment whatever happens when I push my code to test will probably be what happens when I push my code to live and then this is how this is how this can work. And of course having a workflow and especially enforcing a workflow so at my company we have a hosting company we force people to use a DevTest live workflow you literally can't edit code in the live environment as part of the process and that can be a little annoying especially if it's an emergency but there's a discipline here that I think is really important for teams and I think well it might be a little annoying you can't also to always have to put something in a virtual control to get it even in a test environment I think that overall this pays off because a lot of workflow and we'll see with a lot of examples it's about discipline and it's about making sure you're doing things in a consistent way because those are ways that can be tested in an automatic kind of fashion and I think sort of DevTest live works as a workflow especially if you have a few people on a project that you end up maybe sharing a Dev Sandbox this isn't the worst kind of thing but when you sort of flesh out this like workflow to like what I think is really the right way to do it what you're functionally doing is you're actually not just having one Dev environment but you're actually having end number of Dev environments based on how many people are on the project everyone should have their own Sandbox luckily because we're using Git it can live in its own branch and then your process of sort of moving stuff to test in live is about integrating work that's already done testing that in a holistic way and then pushing it out and so in this diagram code's always flowing from the left in Dev through test to live the other part of a workflow that's not related to code but is also very important is of course your database and your files are elements that also need to be added to live site a new blog post when it comes in goes to your live environment but you also need as part of a workflow the ability to sync that database content back because you're building out a new theme or you're checking even just making a small change on the site it's important to have the latest like database dump of the site to work from and so having a sort of you know process to clone back the database is really important and this is the kind of process you can sort of rinse and repeat and like most major like web software projects are done with some version of this plenty of awesome like you know hosting services that give you out this box open Dev shop that's outside has an open source version of this kind of thing you can run in your own servers and you know there's a bunch of other ways to get this kind of stuff going but it's a once you get it going a lot of this other stuff becomes possible and that's why I was sort of want to introduce that this is like a core concept beyond that of course what powers dev test live is of is that you have code in version control that you're doing you know committing stuff to a repository you're tagging to things when you want to do a release and you're merging stuff appropriately through the process and get it something I think offers a lot of flexibility to web projects in practice I think ends up people they don't use get to its fullest which I think is someone unfortunate Drupal for people are familiar you before it was running on get it was running on CVS which was an older style source control repository and that repository had like less functionality so it was a lot of sort of like commit and then pull and then commit and pull it was sort of like a save mode for your site as opposed to like a fully distributed system and so I think there was a lot of patterns that got developed that aren't as sophisticated because the tools aren't sophisticated now that we have things like get we can start to do this kind of branching element which I think is one of the most powerful elements of get that idea with this and this diagrams a bit a bit extensive but the idea is that you have your sort of like dev branch that you're working on but you're able to at like points of time of your choosing decide to fork that branch and then have a separate branch that has like some version of that code base that can be worked on and tested and when things are in a good place they can be merged back together and the idea in sort of a workflow standpoint is that each of these different branches is its own sort of consistent part of of work that's happening they should those branches should in fact be their own sites with their own URLs their own database copy their own code check out because you want to address and work with them in that way and that's part of what I think doing good workflows and good testing is about so about making each of these branches an environment and making sure they go through the same kind of testing as everything else and some of the stuff I'll show you in the demo of course takes advantage of this branching so please use get for your projects very helpful like graphics will scary so apologies okay but like wait a second like we're talking about code what about the configuration and this is something that's like a real challenge and I've worked a lot on trying to like do a deal with this this on my own projects because when you're doing Drupal development honestly configuration of views or like the content type setups or setting up paragraphs is honestly more complicated and often more work than maybe some of the code that you put in another part of your project but code is easy to put in version control you just save it and deploy it how do you deal with this configuration well of course I mean for folks who have been playing with Drupal 8 Drupal 8 has a really advanced content now our configuration management system it's built on the Drupal 7 feature system which hopefully we all know and love but the idea basically for those that aren't haven't got too deep into it's just you can take settings things that are put in the database like this is the site information page and you can like reduce this down into like machine readable formats so we've got the title of the site being Drupal 8 CMI demo and then the name element of the site configuration is you know has some addresses and the idea is that within side of Drupal you can at any point in time export out literally all of the settings that got entered into the database via views or content types or display modes or or other kinds of variable options and that's a sort of like full export where you just take these YAML files and you push them to disk and once they're on disk you can put them in version control and this is the whole ball game that you know if you're able to take your site your database changes along with your code you could put it into a a Git commit and you can deploy and test that along with everything else and that sort of is also ground stakes for doing any kind of automatic testing because I want to automatically test like each commit of my site if part of what you have to do to just test the site is like take a legal pad of like change this view or add this thing or import this thing then you can't test it until you've gone through those human processes and this just takes a lot of time so one of the great things that we have this sort of interface for exporting configuration and then we have a GUI as well as command line tools where you can export and then import in again so you can say on my dev site export out these three new views that I did and then I'll move that code to my live site and then in the live site I'll import that and now I'll have those views which I think very cool and something I would encourage y'all to do easy to script of course so if you're writing your own tools you can just sort of drush config export and drush config import and you're off to the races and this is stuff I think as part of your industrial workflow also very helpful to automate that you're able to say look whenever I do a deployment from dev to test or test to live I immediately then also want to do a configuration import right after and I want to run an update PHP hook right after because the ideas of the robot could be the testing for you and you don't have any human interaction and this whole thing just you know cycles all around and this is sort of what I think if you can get to this point with your deploys where literally your go live moment is hit a button to go live be it you know do a get pro thing or hit a button on a platform that's the place you want to be to do testing because if you have any human interaction as part of your deployment then that's just going to slow the testing and it's going to be less interesting being able to do it automatically is excellent that we feel the film that people agree any strong directions all right so that's and that's when I talk industrial workflow like that's basically what I'm talking about all of your site code and configuration inversion control use branches for different features as appropriate and make sure all that's used you know deployed with with scripts that run configuration imports afterwards once you got that let's start talking about the testing and in this part of my happy to people of other ideas or done testing of their own with different tools I think that's really important because overall like us as web developers like are trying to make websites that are interesting that meet business goals that like do new cool technology and like are awesome and when we start to like ask we but there's stuff in our jobs where to make websites that are not that awesome like doing cross browser testing is not awesome like trying to like go through the checklist of features to make sure that work is not awesome now these are real important things to do like not having working code is awesome but like you just end up in a lot of ways like you burn time you feel bad you don't like you're working on repetitive stuff and this is how you make people like not so happy and that's one of the reasons why why we have robots right like we robots like can like clean our house with vacuums the robots can like give an iPad to a child and like raise the kid the Facebook robots tell you how to vote like we can get the robots to help us web development too you know got a the robots will rise up so at least having to be on Facebook and having to test IE are like valid reasons to go after us but the idea is that you could have automation help this and that makes a lot of sense hopefully the people do Drupal development like we're not rebuilding the same kind of stuff over and over again in Drupal we're just using open source components so why not like reuse the same kind of testing stuff if like I think the good rule of thumb is if you've like done a process three or four times manually that can be like easily automated it's usually worth your time to go ahead and automate that and that's a lot of what sort of testing is trying to do because there's tooling and sort of to get into some of the testing stuff we use probably the one that most people are the most familiar with is this concept of cross browser testing where you know depending on the browsers you're supporting as a business and the users of your site like you have like a lot of different opportunities make sure things look right this becomes obviously a huge issue in the context of like I need to test on different kinds of computers I need to test on different mobile devices and tablets before like I would say doing web development 10 years ago you're sort of like cross browser situations like install the browsers that you had and then like get a VM to like run an older version of IE and stuff looked okay clicking around like we're you know in an okay place for the project now I think the world is like much more advanced in that you want to be able to test across five different cell phones four of which five of which maybe you don't actually have and you want to do all of this without having to like boot up a thousand VMs and that's why I think you know we get into a little more like you know instead of doing this like DIY kind of style like like have all my browsers I can instead use the sort of platform kind of testing services to do the same kind of testing and this is where a lot I just see a lot of advantage overall with testing where if you're able to integrate with other services that themselves or professionals and experts at testing you could like get a lot of value out of this like places like Apple tools and browser stacks have like used like mobile and tablet and like testing things they have this dialed like literally hit an API and it'll test your whole site and give you great reports back and a lot of what I see when I'm like hey let's build a website like testing workflow well one of the requirements is cross browser testing that does require presumably human to review stuff but like let's make it easy like on them like let's basically say whenever I do a deployment to test let's go have it run kick off like 50 different browsers to review five pages each on the site and then give me a report back and I can compare them and that saves a lot of time so it's automated in a sense you can automatically initiate the test a human reviews later but like that's such a small percent of time it's extremely helpful and I think if you're looking to sort of you're already doing some kind of browser testing a key thing you can do to improve that is to go from like a manual browser testing to something that's more of a hosted solution and many of these have free MIA or free entirely versions to do your testing and that can be really awesome and I think one thing to mix in to what you're up to and full-on services they're just about do this and they basically find a service you like and see if it has an API and if it does Ace you're in a good place and you can get stuff like this where it's like oh here's a little site that we did and here's the different browsers and what they look like and you can click in this is very helpful the other piece of testing that I think is also really essential for many sites not all but I think more than people probably think is making sure that performance is properly tested in Drupal there's a lot of things you can do on the back end that look might be small changes but could be extremely like damaging to performance if you break a varnish cache cookie or something like that you could overwhelm your site if you install a module it's a little bit sketchy like that could overwhelm your site any kind of weird like views interaction and these are things of course you don't want a website to go down or get slow there's like obvious business and social costs to doing that but being able to test a site to make sure that it's fast is hard and testing a site to make sure it can scale under like 10,000 or a million users is like extremely hard so having external services to help you is good and this can be really simple so Josh Koenig he's works at Pantheon as well he's got this really awesome like W get spider we just like go to the site quick and dirty it gives a little like how long did it take to return the page very, very fast but it gets you some data back bigger tools offer even more options and that performance testing is one of these things where like having an external service performance test is almost necessary because if you want to simulate like 5,000 users going to a site in an hour you need like 5,000 computers worth of users which is something most of us probably don't have or don't want to like you know set up services like this already do this you can buy credits with them or in some cases get free tests entirely and then a really good idea is as part of your workflow again every time you do a test like deploy to test go kick off a quick performance test do a quick five minute test see just how things actually perform under load individually and then you can optimize your site not that that's like a totally perfect example of how your site could get you know traffic in the future but it's a nice baseline it gives you a consistent number and then you can look back every single deploy how much performance was it and you can make it part of your PR workflow you can make part of what you're doing and easy services to integrate with load impacts really great loader IEL is really great you can sort of sign up with the API keys add a little script in your workflow to say kick off a performance test when we do a deploy and then look at the results and this is really awesome because you can get this kind of really fun kind of data and one place I really like to do performance testing it's also free to do is using this tool Lighthouse that Google provides which is sort of a performance plus other stuff test that will Google run you can sort of see it if you want to see an example of it by looking at sort of a Google Chrome here's I ran this a little earlier on this site where Lighthouse is actually going to go up here and it's going to give us some numbers for like how the performance number 24 which is not actually that good but we have a lot of images on this site and then they'll tell you sort of why and what's going on with with everything that's happening and the idea with this is that these are useful numbers just to check out but what's even more awesome is if we can have this just as part of what we're doing so check this out this is a we recently we did our Pantheon IO website and we're working with an agency who's very good and so they've got some automatic testing so we have this issue which is look we want to try to improve performance on the site so there's this scroll magic JS library that's like not loaded on each page so in the pull request like Mr. Herschel commits this thing that says this isn't being used we can remove it and then immediately our automatic test run and it actually kicks us out a set of numbers around performance and around accessibility and now there's a full report you could get like the one I just showed but the idea is that in every pull request on this project it literally gives you that performance number that says 29 well that may not mean anything right now but it's a referential number to where it was before so if I'm working on a project and I'm at a performance like 55 the whole time that I commit something that drops that number down to like 29 that I'm like oh wait this could be a real problem and the idea is that a lot of errors and a lot of things that testing brings up it's easier to catch the errors earlier than later right so like having once you once you realize this commit is the one that slowed the site down you can narrow down why that is and fix it as opposed to doing it and so performance test is good on that basis it's not something you want to do like from the get go of the project but once you're going especially once you're live having a quick test for performance before you deploy important changes super good plan doing it manually super annoying so have the robots do it for you and they'll just put it in and like there's great information on Google's lighthouse side to integrate with GitHub so it literally will just do this every time you have a poor request which is excellent another type of testing that I think is really ace is visual regression testing has anyone used this testing before it's so this is sort of cool and has interesting applications so what visual regression is is it's basically a machine test that looks at two versions of a picture and is able to do comparative analysis to see which areas are actually visually different between the two images so this was made the BBC did this for some of their websites and a lot of game developers really like it because if you have like an adventure game you change something it'll like go through the whole game take pictures of all the pieces of the game and tell you like oh you changed something now it broke this door or something look or the door looks different in this version do you mean that well this is really helpful for website development because if I have a new change I can compare my live site to my dev site and then I can see visually what pixels are different and this can help me to identify stuff that's going on so like here's an example here's two Drupal pages there's a change that was made to it visually we added some green text to the right but if you actually go in and like do the visual comparison it'll show you with where the arrows are which I added but like the red overlay that's where the change is actually technically different most of our job as web developers are to in fact move pixels right so it's not like an air if stuff's changed like we wanted to change the title from blue to green that was like intentional but we may have not wanted to change that little read more link down there that happens to have an a tag on that page but is something that we don't actually want to have be a different color visual aggression is really quick because it can spot these errors really fast so if you're if you're like a project leader and you're reviewing and you want to say okay this poll requests like what what actually is changed what should I like pay attention to the review visual aggression will actually go in it can look at literally it can crawl your site map of your site and like take the top 50 pages compare those for each different change and then give you a report that says of the top 50 pages these five changed these 10 didn't and this is really easy to implement there's a lot of race is pretty straightforward to set up if you want to use the you know the the sort of original version of this I'm a big fan of some hosted services these are people that will like literally do the visual aggressions for you you just like say here's my dev site here's my live site it'll go through and and do all the different visual aggression pieces and this service backtrack is actually based on is written in Drupal so it's sort of a fun interface and it can like really help what you're doing right you can like say oh I move stuff around I get to see where the change is or I can figure out there's differences I'm a huge fan of this testing specifically for testing security updates that come out so one thing that like in almost all cases is going to be true is if you just have a security patch like Drupal get-ins patches that in order to improve the security of your website you don't need to change any of the pixels on the site like applying the Drupal get-in patch should make your site look exactly the same afterwards so there's this process you can go through you're like look for every individual security update I'm going to do visual aggression testing across like all the pages I care about and if zero pixels change which means there's no white screens of death it means there's no air messages which are pixels where all the elements are still there I can actually use that as part of my update review process and I've got we've gone so far at Pantheon we're like literally just updating live updating sites that are running because we do enough testing as part of the process that we're pretty comfortable the Drupal core update isn't breaking the site and we'd rather get the update out visual aggression is a key component to that and it can also help your work sort of figuring out so here's another example of using visual regression to workflow so we were upgrading on our Pantheon site this font awesome package to version number five so again Mike Mike does a commit he updates the font package now what can change if you update the font package like how little fonts and icons work right well luckily we have the automatic visual text and run and it's going to say a visual regression report at the bottom and clicking on that literally will say what changed so the project lead can go in and say oh I looked at the report and guess what this font update package causes this new check mark to actually move and now these are visually different like this might not be bad but this is something we need to flag so let's talk about the issue queue okay let's fix it great now we did some commits to fix it and then we run the report again and we can see that the changes are different and that this is the kind of thing we're like these are the kind of review things like project leads and project managers would have to like manually go in and look at the different pages and try to see what's different see if they can break stuff this just makes it all a lot easier and puts it into GitHub which just makes the whole thing really excellent and I think that's something that from a sort of standpoint if the more of this stuff that you're doing as part of your workflow you're using automatic testing to get information but you're also able to be able to like have conversation around that information because this person can make a visual change the project lead can see what the change is the dev can fix it and then we can you know test again to make sure things are good saves a lot of time which is excellent because we get more website then which is what we're sort of up to and this isn't on the extent of the so there and there's a lot of other testing stuff you can do things that are sort of like tests I think are really good to include in your workflow is like Drupal code standard adherence so there's a set of standards for how Drupal code should be written most of which are pretty good and reasonable not every dev knows those standards and after a while on projects with different standards like the code can look a little bit like messy and that's not that's like best for readability but having like someone's job it is to like clean up the code for Drupal coding standards is like sort of annoying because it's like fixing other people's stuff and like going to take a whole day and if you've it's been up for months you've got a lot of cleanup one thing that can be helpful as part of a workflow is that you can either notify or even block users from committing code that doesn't hear the coding standards that you can run Drupal's coder module on every commit and see does this commit break the coding standards or doesn't not and then you can respond to that it's just a way that like you can subtly have the robots you know do the parenting work to tell people to not do this and then apply it so you get a little more energy and this is a nice way to sort of level up your project as well as the quality of what you're producing because you get really good code standards like you can't commit a function without a comment in it which is like a pretty good thing for developers to have to do this can enforce it in code which is can be really helpful but you can even do there's a ton of scans on the internet for stuff that can be anything can be mixed bags in terms of what's possible but like doing a security scan of your site is pretty awesome like there's some common security vulnerabilities that are out there and being able to sort of like make sure that like common adword passwords aren't used on your site or that like cross-site request forgery items aren't possible or like different other common things that are testable you can actually use third-party services this one does a security scan and this is a site improve it does like accessibility among other things scanning and the idea is that these are people who like know about accessibility. They know what it takes to be like WCAG compliant then people who know about security like they know what tests you can use to try to hack a site and what you can do is right before you go live deploy for like often for free or like relatively small money to get accounts of these people to scan you can literally have your site or your code base be reviewed for a sequel injections every time and that's the kind of thing we're like you know hey I want to make sure my sites always accessible like this is really important for my users important for my you know situation let's just like make sure we always an accessibility check before things are deployed it can save a lot of problems and headaches earlier and something the more of this you do as party of workflow I think the better and the last test I think all sort of introduced before we start showing off some stuff is is this behavioral test called be hat which honestly of all the testing I talk about I think be hat might be the strongest and easiest and most helpful test Drupal projects because what be hat is is it's really for those who haven't used it it's basically a test framework that simulates a sort of user using a Drupal website to the point that the user will actually logs into the Drupal website they click some buttons in the Drupal website and then they expect to see some results from that and be hat sort of does that kind of process to test a behavior on the site so it's a bicycle sites called Mission Bicycle which is excellent and it's a website we do updates to it and one of the things that like is important for the bikes is like it doesn't actually matter for the business as much if like some of this design is a little funky like that's not good right but what we really don't want to have happen is have like our online store get broken because if someone wants to buy you know you lock like we want to sell them this good security lock we want people's bikes getting stolen but so what we actually need to make sure works on this we want to for maybe make sure the lock is seen but we're really really interested to make sure that this word shows up on the page when I hit this button it goes to a page that says cart when I hit this button it goes to a page that says give me your credit card and then if I fill out a credit card thing that X button says order complete and that's really the business value of what's going on so when we do updates to the site like the one task we always run is to make sure the shopping cart still works because that's sort of part of the website and I think you can find similar examples from the site that you have around what I'm what's the most valuable and the be a test are all showing off a couple examples this but the BS tests are really nice because they um they sort of are very human-readable like this is one of the test down there it's a test for like the Unix LS command but the idea is basically given that there's some files and a directory and I like run this command LS bar and foo as to like named elements and they can base basically there's a be hat implementation of for Drupal that can do the same thing like you can write in like literal English language you know if I have a node called this with this like author field then I should see on that node page like the name of the author and that you can sort of and it'll actually go in and like add an element to the database with that with that information if it gets rendered properly and that's nice to build into your workflow and I'll show that in just a second so those are some of the tests that I like I would say there are a bunch of other tests I don't know if anyone has like glaring admissions of stuff they've used successfully for testing I think it all depends on the project right like what are you looking what are you looking to do why is that important but the main idea is that you only have so many hours robots more reliable than humans get them to do all the testing for things like accessibility and security and performance that might not be things you're testing regularly but are actually things you could do so here's I want to show you off how this can sort of work I've got this website we've got our hosting platform Pantheon has our DevTestLive workflow and then part of like how at least a lot of these kind of platform hook kind of things work this is sort of way Pantheon implements it but like a lot of like GitLab and other kinds of services offer a similar option which is you can basically when certain deployment elements happen you can do other stuff so like for example when you like this is example of one of the things that we're running like when you do a deploy before the deploy you can like tell people in Slack that that's happening which is a cool part of the workflow integration and then afterwards you can like import some configuration you can run this regression you can do a performance test and you're basically just kicking off these scripts after and those can happen during deployments or during code commits and then you of course take some third-party testing tools there's a backstop JS so just like my favorite visual regression tool loader which is a performance thing with security scan site improve these pieces and you put it all together and make your site so so yeah so let me show you off what's up with this so I guess for not to like demo my thing that much but this is so this is this is the pantheon dashboard for the site and I made it for the Nashville and it looks like this is the site but the actual sort of workflow is this which we have this is our we have a dev instance we have a test instance and we have a live instance and then in our like development space we have like several working off of so different people have their own items I think there's one if you have a security update you have an item and each of those is his own separate separate environment so when we go to sprint number one because let's start off development and we can go visit the site and now we're going to go just to like that development site and we could do some development so we can commit some code we could do that kind of stuff the piece I want to show off is actually the configuration management so I can go ahead and edit this view actually powers the the front page and right now it's got the buy ticket on the right so I could like change the sort order here to make that so sort of show in a different order get save and then you'll see that it actually reverse the order of the of the site which doesn't look like a lot but like this is a change that is only in the database like if I was to go to the live version of this or even I'd go the site so I've changed you were all of the live version you'll see the the item is not on the left but it is in fact on the right well that's because we changed a view well the cool thing with views and droop late is that you can in fact export out that configuration to disk which I can do up here at the top using my configuration development tools and I'll say oh you just exported your site configuration to disk so now if I go back to my actual site now we're again we're like in a get branch Sprint one we'll see though that we actually have a code change where we're like visually changing that yaml file and I can go in and then say you know order change and I can go ahead and commit that to my project so all I've done is commit this yaml file to to the repository but because I've wired up my industrial workflow we'll start to see over here that we've actually integrated some different stuff here so you'll see here that now suddenly our workflow starting to like be a little chatty about what it's doing now some of this stuff is like not like you know it's just information right like there's a commit that happened with get it happened by me here was the name etc then there is this important step right here which is oh we actually can imported any new configuration that was possible there there wasn't any new configuration to the database but this will be important the future but then it's really cool as we're actually running a B hat test on every code commit so this is a really simple B hat test it just says a user should be able to see like this literal text string the pantheon theater on the home page of the site which is slash so that given you're on slash then you should see this text and then it did a little quick check and it gave us a green because that was the the kind of thing where you could run 50 of these tests if you want you don't necessarily put them all in slack of course you could do a summation in slack or you could put the ones that like fail in slack and everything else was just assumed to be good but the idea is that this is part of that workflow we could keep making code changes eventually we're going to decide that we want to like merge that stuff in so we can actually go ahead and let's do a get merge one of things you end up doing a lot in sort of workflow operations you have a lot of different branches that have different pieces like slide shows over here a bug fixes over here a new features over here and you merge them all together typically as part of your workflow so we'll merge that and it'll go update our dev environment but what it's then going to do and the idea is you might do this a few different times different kinds of tests where it gets really cool is what I think is like sort of this you know awesome part of the testing is that once you've got a good sort of stuff in your dev environment you can actually go ahead and do like a full featured test of the whole deploy so we've got some stuff we have like a new version of Drupal that I did day last week we just made an order change and I can go into this test site and I can see like it with one button I can do really powerful thing so I just click them as button and what it's doing is it's it's literally going out to live site right now and it's copying the database it's copying the files and it's pushing it to the test environment then it's going the dev environment and it's taking all that new code that we just did and it's tagging the code base and deploying that out to the test environment and then it's going ahead and telling us over here in slack that we're doing a deployment as well and then it's going to go ahead and actually like you know push all that stuff together in the test environment it's going to run update dot PHP case there's any updates need to need to have a check to see if we have any configuration and if you remember from the beginning of the presentation like it's important to make sure all the configuration is there before you do any testing so you'll see that it's trying to do the configuration that says importing the configuration to test and then it says oh views views location was the was the test in play that we know that like there's new configuration and it's on the site we also went ahead and like because we're like doing deployments in this case we have New Relic as a technology that's added to our workflow New Relic is a application monitoring tool but the idea is you can look back at your site history and see how good your performance was well that's helpful but like it's really helpful if you know when you actually change the codebase when you look at the performance so we have a little element just make a line says hey we deployed so you can see at like three fifth three 16 p.m on Saturday we deployed you know some code so anything that comes after what kind of traffic comes after well we're actually like straight up running a performance test like every single time we do a deployment to test we actually run 50 virtual users for 60 seconds if you want to see what that looks like but we click on the loader link and oh yeah and it'll give us something looks like this the other one may take a second to finish but it gives us this baseline and the idea is that like 70 millisecond response time like that's pretty good like let's keep that going and you've got a good baseline and the idea is that this is exactly what it should look like in tests like you know test alive or mostly identical like tech live has a few I have a couple other app containers that can be a little bit inconsistent sometimes but as close to possible you want your test of your live environment because when you actually do a deployment right like you hopefully have tested everything up to this point where you can literally say deploy code into the live environment and you don't have to do anything like you know that it's going to automatically push the code because you have presumed some faith in the hosting situation but you also know that is automatically going to tell slack that it's doing that you know that it's going to automatically import the configuration because we just did a dry run of that a minute ago and you know that it's automatically going to be like at least as performant as the test suggests because this is what it's reality was and that as you sort of do workflows and especially like to either push out to a slack channel where you're working or add that information the pull requests both are really good options that these are then places where like your team who's working on projects together doing you know an industrial workflow can really reap the benefits of that kind of automation that a lot of what I think makes these kind of workflows awesome or not that the robots are doing tons of work for you but that you can like review those as humans and build on them and become better developers so I think you know overall I've seen some projects that literally have every single functionality as with a test and they have like high confidence in what they're doing and that's awesome if you get to that point but I think for most projects like identifying like the two or three things that are like the most important to you on the project be it be it visual fidelity via performance be it accessibility and spend some time to like build in that into your workflow as part of what you're doing like I think that could be a really helpful piece of what you're up to and something I'd hundred percent recommend for people doing Drupal development so with that I think I'll pause there because that was sort of you know some awesomeness hopefully but I'm also curious what you all think and maybe take some questions about workflows what do people think of the workflow and what kind of stuff are you curious about a question in the back maybe can you share accessibility yeah so there's there's two tools that I would recommend for accessibility one is site improve which is more of a paid service but it's a very like industry leading kind of option and it'll allow you to actually do a scan of your site and you can see some some testing pieces there's also that Google Lighthouse tool that I was showing before and that Lighthouse tool also has an accessibility element to it as well there's a couple other scans are out there on the universe depends on your specific requirements yeah yeah it's what yes yes the site improve so the question is the site improve I'll make give you a score yes it gives you a score actually a few different scores that you get to pick and you can access them by API Lighthouse by Google will also give you a score Lighthouse is free and open source which is a pretty nice advantage and it'll give you another another accessibility score I don't know actually so inside approve you absolutely can configure the level on the API on the Google the Google side I haven't played that much with with the accessibility aspect but I would say having done a little more research before there are three or four other accessibility scanners that are out there and one sort of rule of thumb I have and I'm looking for like stuff to add to my workflow I see is typically a version I can use to try it to see if I like it and put it make it work and then be does it have like an API that I can call automatically so I'm off of accessibility scan API access and if I can get that then I can build it in my workflow very easily but I think especially if accessibility is not something you're doing a lot but you still want to have a good accessible sites having these kind of scores become really helpful because they surface these issues quickly as familiar with like the all the work the technical work that's changing the underlying aren't like Dom for the site might be but they may be able to look at somebody's scores and say hi team like the accessibility numbers are really low can we add some tasks the next next sprint to improve those and then you have a really clear like number to improve which is a pretty nice goal to work towards so other questions or vibes yeah some decoration like developers would get the up to the database on the live site to the demachine yep so doesn't but even though we get the database from upstream to downstream we still have to run we still have to do the trust yes and see yeah correct so questions about like configuration management when you're like dealing with a live site and you have to copy the live site back one thing that so one problem that that happens is that the live site can be edited and changed by people with the appropriate permissions so you might like be like as developers like awesome like I've like got all my views and code and they work exactly right and I've got it automated and it's automatically importing and then you turn over the client like they go in there and they're like awesome I am Drupal I'm going to add like some more views settings like they make it the way they want and then literally the next thing you push and code because you haven't pulled something back it'll go in and override their changes which is no fun two ways I've seen people handle that one way is is keeping a discipline where before you start new development you actually copy the live database to the dev and then export the configuration that works decently well especially if it's a short development cycle obviously you know someone makes a change five minutes for you deploy there's some issues the other piece if you want to be like if you want to be like sort of aggressive there's this module for Drupal 8 configuration management called configuration read-only mode so this is sort of analogous of like turning off the views module our views UI module excuse me on the live site so like you can't edit views on live this basically says you can't change any of the configuration elements on live it literally will say you must make these changes on death now some of those changes but it is something that can sort of like make the workflow work because realistically given the complexity of views and some of these Drupal tools like you sort of don't necessarily want to do these in live like you can break a lot of stuff if you don't do it right so to some extent you may want to force even some of your your endures do it but when you don't have configuration totally to your point you have to watch out for change surveyed on live site and you can handle that by just blocking them or by dumping them down and importing them I would also say there is a configuration management 2.0 initiative that's currently underway for Drupal for Drupal future versions of Drupal that are trying to address more of these kind of use cases including like having live stuff merge having multiple elements be reused have like questions like letting the user in some cases if they decide what to do so this stuff will get updated but it's currently this is the reality I'm just I'm just I'm just I'm just I'm just I'm just I'm just I'm just I'm just I'm just there. Oh yeah the yeah here's so this is the example that I use for actually importing the configuration which which does like do the computer import the drush CR maybe run one of those at the beginning but like this is all I'm doing in my workflow and actually do that importing right it's just like let's actually run that import command with dash yes and let's like rebuild the cash as part of the process and like run these each time and if there's an error that surface it if not it just sort of goes for it. So yeah yeah so the question about visual aggression like what are the limits that you might hit I would say in my experience like there's regression testing for large projects like helps you identify where changes are made but especially when you're making a lot of changes like there's just so much noise that it's not actually that helpful during an active development stage where I see it the most helpful is in questions where you're doing a small income like a bug fix or something small because it can help reduce your area of Q a and I think it's obviously ace for the automatic updates but it also depends on the kind of how the kind of work and the changes you're doing you know this if anything I see the backstop JS test I see it less as a test that you pass or fail and more of like an indicator of what has changed so I see it sort of like get status but for like the pixels and you know that's sort of get diff but for the pixels and like it's sort of look at that and if it works but but you run into a lot of weird edge cases with visual aggression right so it's trying to like see if pixels have changed but if you have like an ad region on your site that randomly loans an ad or you have like a geographic you have something for Canada and something for us and it's different where you are like those can change depending on like what time a day you look at the site or like sometimes just randomly they'll pick a number put a inspirational quote on the front anything that changes some pixels dynamically will caught will cause issues with a test so the more advanced projects people end up having to write a lot of exclusionary rules like they'll say anything it's like an ad region we don't look at or care about or we don't want to like the bottom always going to be changing at the bottom so like ignore that something like this but I would say if you're into visual aggression backstop js is I think a really great place to start because it's a quick JavaScript framework for doing it you can run it with chrome headless browsers which is totally the right way to do it in my view and it's very fast and it has this cool like crawl capabilities you can just point it at a site into like either take the site map or will just follow the links and like identify the pages that thinks are most important and it's like to then and it's now it's a third version so it's like pretty mature platform piece and open source of course so well excellent well with that I'd like to and thank everyone for like hanging out for an hour learning a little bit about with them also one piece I totally didn't talk about with the workflow is anything related to local development which is like obviously a part of it so if you are a certain that there's a talk right about five minutes downstairs on land about that so feel free to keep it going but I have a great Drupal North and you know enjoy