 I'm Mel and I've been a full stack developer for too long. I've been working with many different CMSs and a bunch of different tech stacks. I'd like to say that I'm a proficient stack overflow copy-pasterer. And I'm currently one of the lead developers. Yeah, so I am one of the lead developers for hide and seek digital. We do many awesome projects that are complex. And this talk is going to cover one of those projects just in depth at a high level. It was a Drupal 7 to Drupal 9 migration. Of many unique websites for a large government agency. And I apologize for the screen coming in and out. There we go. It works so hard on the slide deck too. So hopefully now there'll be some time for some questions at the end of this. However, feeling kind of like not like we're going to get there. I will be around all day if you do come up with a question you want to ask me something later. But without further ado, let's move on. Most of us in the room will be familiar with this kind of diagram. Most projects are run in an agile or waterfall way. It's completely fine to run a single project this way. But it's hardly reality for most of us here. We're more than likely to have not one, not two, but many projects running at the same time at different stages. Even for example, I was watching people on their laptops doing work. And I have a deployment at six o'clock tonight. So really, you never really do rest. The down times are short. And even before we've recovered, from one release, there's already a handful of projects, minor or large, Lumi in the background. And as Web and Drupal are constantly evolving, the door to the ability to work backwards just slams shut. Now, I've got to give you an example here. And I had screenshots for it, but I doubt it's going to show. So it could be a matter of just using your imagination today. So let's say you've been asked to build a navigation with a drop-down sub-navigation in a new website. Pretty much standard for most of our websites. You remember you've actually built this already in website A. It just has essentially different colors and a different font. So, you know, to save yourself some time, you go copy-paste it from A to your new project to give yourself that head start. At this time, you've actually had a moment to add more accessibility features to the menu, such as keyboard focus navigation, which will let the user open the sub-navigation by choice instead of just tapping through endlessly. And that works great. But now, you can just copy-paste that back to the original project. However, how do you do that when you've suddenly got 12 projects that could all use the same update? Do you just copy-paste it again and again and again? So, this issue showed itself at full force at the government agency during their mass migration project. Each Drupal 7 site was getting better than the previous, developers were so under the pump with all their ongoing projects, consistency and improvements could never make it back to those first few starting websites. So, I kind of knew this had to change, not just for my sanity, but for that team and their future as well. So, working together with the team, we decided to break it down and we would eventually come to a project that we would call the collection of assistive mechanisms engaging recent online networks. Cameron, because life is way more fun when your projects have code names. So, for each new Drupal project, a developer would run the classic composer create project and install with a standard profile. Then, they would manually go through each and every setting in the UI to enable and disable modules, set up the basic workflows, set up all of the content types and, yeah, I've fallen victim to this too because it's a really quick and easy way to just get a website up. However, the issue with this method meant that basically every site was being a little bit more different than the last for the developers and a very important user group, your content authors. Each site had a new learning curve and each site had a better editing experience in some areas, but not all. For the most part, we're not going to get it right the first time. But, tech is always changing and we need to be able to keep up to date with those changes and move back. So, we solved this for that team by creating a custom Drupal profile which is incredibly easy to create and you can also host it privately as your own composer package on your GitHub, GitHub, Bitbucket, whatever your poison is at the time. You only really need one file to get a custom Drupal profile working, the profile.info.yaml and a profile can be quite powerful. If a screenshot comes back, we can kind of see that you can declare what contred modules you want to install, what core modules you want to install and if you look closely, you can see that it corresponds to a custom module and a custom theme. We'll come back to that. We can tell it's composer, what modules and themes contred or custom we want it to grab and also you can lock down the versions as well. So, if you have a module that you don't want to just update to every site all the time, you can lock it down to a version you know is stable and you can tell it what configuration you want it to then add in and anyone who's kind of worked with Drupal config but when you've got all those sorts of one sources of truth in that location it's easier to go back, find the bug, fix it and then send back out. We can even tell it to create out some dummy content pages. We can define the content types, the taxonomies, you kind of get the gist. With this piece of the puzzle we've taken what could have been days of work to do the initial setup, finding and defining all the areas of the site to essentially a coffee break for the developer. This Drupal profile does a lot of the heavy lifting for you. And since we've got to make this a private composer package we can now have all our sites pointed to one source of truth meaning any additions to this are then sent out to all the sites. Very importantly our content authors are happy because they can now be sure that each site will have a similar setup to each other making for faster edits and happy clients. And of course not all sites are the same. You can add additional modules or config to the site added individual level. But when the unique pieces make up a smaller portion of the total project developers will now have more time to sink their teeth into those pieces instead of just spending time setting up content types. So with the profile we now have the bones of a project but that really doesn't help our front-end users who would just see a white screen or in our case a black screen with unformatted text. So I went on a journey and reviewed all of their Drupal 7 sites and it became very clear that there was a lot of code that could have been shared between each other. So even when a component looked different on each site the actual backing of the code was the same. So why would I want to as a developer have to write that again and again and again improving or not copy pasting when I could just do that once and send it to everything. So we solved this with a custom parent theme which ensured that developers had a reusable set of code for their starting point. This meant we could give them access to basic styling or templates but also provide a set of helper functions at the theme level such as formatting all of our links with media embeds to give us the file size and correct icon reference or adding a transparent mode to our iframe so they stopped attempting to go over things with a 999Z index. These little things are things that you can miss when you start a new project because sometimes you're in such a rush to get everything done that you forget some of these basic things. This at least solves that by default. We can also add in the consistent javascript libraries that the sites were using and keep the versions the same. Again, this team would write really nice custom javascript things and then copy pasted to the next project, improve it and then not go back. So one site would have very nice we can have accessible buttons and then one site would have an older version of it. We can also use the javascript libraries to make quick component creations such as an accessible toggle expander. You might use it in an accordion, you might use it in the drop down navigation but it's the same function used in multiple places. Once again, because this theme is unique to this agency we use their github to host the theme as a private composer package. You're going to hear this a lot in this talk but this basically means that they were allowed to use it once and have it as a single source of truth adding something new means adding that update across everything. So putting it all together we finally needed a way to not only force the use of this Drupal custom profile and theme but also have any new developers code to a consistent standard because no one wants to have to continue to reject a pull request because you've gone and made it a standard to set all the sizings to M or M and new developers just come on long and set everything to pixels. Most of the time people will let that slide and tell themselves I'll go back and fix it later but it works so we'll get it out today and then later never comes. So we solve this by building a scaffold repository that will contain all the basic setup of a Drupal site automatically including the custom profile and theme but it's a bit more complex with that so let's take a closer look. The team's choice of local development was Lando. So we've included a base Lando config file that spins up the dev servers and instead of just using the default Lando file we take it a step further we include excuse me we include all of our custom scripts to do things like pull down the relevant weird database on the Lando build automatically spin up the browser sync on launch so a developer never really has to worry about running yarn build to compress their sass and JavaScript scripts and because once again we're using this as a single point of truth if at some point they wanted to move to Ddev or any other local development system they really really need to only write that once and send it out decommission the other one. So we've also added some custom ES and silent configuration files that would extend upon the Drupal core versions and because we're all special unique snowflakes we like to have it a little bit different than what's standard so we've provided a additional set of rules that are unique to the team's preferences such as forcing alphabetical property sorting in our sass files and also declaring what declarations are allowed in each property and then we've also of course got our code sniffer in a specific rule set this ensures that code to be developed it sticks to the standards of Drupal but also gives us the heads up when something is about to be deprecated and again since VS code happens to be the IDE of choice for this team we've included a custom workspace file for the code base which is a hybrid of the one that you can find on Drupal.org but again with the teams unique spin on it and again if they decide to change or add other IDE configuration files you add it once send to everyone we also included the basic GitHub action files that would allow for the linters to check during a PR and alert developers to any failures on their end this in turn kind of trains them to be doing these checks before they raise the PR and gives you then time to actually look at what's important in the code the logistics the logic and any bugs you don't want to be spending time pushing it back because they've intended for instead of two spaces finally because the scaffold contains files with dummy content and naming we've created a custom bash script so we'll run through the scaffold files once it is in a U repository to basically do a find and replace on the files and update all the dummy content naming it to the correct relevant ones rather than a developer sitting through and manually editing each file so was it all worth it well with these three pieces we were able to take the development time for the team cut it in half the content authors would guarantee consistency for their editing experience across all the sites meaning less time asking where something was or asking for a feature to be added backwards developers can now train the new team members faster because the rule set is now in code it's not in your head and importantly now when they need to they can make an update because we've essentially built them their own version of Drupal core they only need to update it once and it'll send to everything so where can we go now with this foundation why would you stop here I consider what we've built to basically be Lego blocks for the team which means they can continue to build out great structures before they have but it allows them time to invest back into the creation of new things so some of the suggestions that we're moving forward with at this point testing you know that thing that you should probably should be doing but you never seem to find the time to do or you go yeah that variable exists but good enough because this project has created a consistent set of code we now have the time to apply our unit testing once for these core functions that we've built but what is something you create breaks one of the websites and for this team they had nearly 13 or so websites can you imagine spending an entire day manually reviewing each website and making sure it didn't break this is where a testing framework like Cypress would come in handy so with Cypress you can write out a collection of universal tests and since we've now gone and standardize all of the content type to the team you can go through take a snapshot of each type individually and do a comparison before you push it to the production server so if you broke one of the content types and had a white screen of death it would say oh don't do that additionally as I've mentioned one of the more important clients is your content authors we also want to make sure that an update doesn't go and cause any issues on that process and Cypress again can allow us to create a dummy user that can then be sent through the Drupal backend making sure that you're still able to perform the creation or editing of content as well as send it through the workflow processes okay oh well for those who enjoy a bit of server reading and listening there's a really good talk basically called making the robots do the job for you when the screen comes back up I actually have the title up for you which you can then search on Google this covers the concepts in far more detail than I actually have for you today I'll put down my talks over that way well from the top hold up where am I where's my mouse are you back here please and you can show alright well finally component libraries can get a bit of a bad rap as there's been quite the limitation for some things and sometimes you just need to break out of the force patterns but again when you are a small team paid to take care of with over 13 websites or so those limitations actually kind of become your best friend Drupal as we know is a super powerful CMS and it lends itself quite well to the headless or decoupled world so for this team we started building out a VJS component library called the friendly replicable intelligent design archive yay Friday because as I've mentioned I love a good codame for projects and any Marvel fans out there will get the reference the choice was to use storybook to build out and test each component as individuals and then beat to the build of the package with storybook we've used CSS variables and a customized theme suture to be able to have say a button to be hard coded once with required aria labels that can then change color to match the website themes as it needs to or add a border radius or make it bounce when it's hovered I've lost my mess and additionally this team happens to use more than Drupal and a javascript component library can be sent to many CMSs or applications you might need so again we've opened the door to a more multidisciplinary team on the build we use learner which we can then turn our storybook component library into a collection of mono repos meaning that we only have to pull in the components that we want to use per site and this again gives developers a source of truth at the component level and they can once again build once and share with many so thank you for joining me and for dealing with all the technical issues that basically covers the journey that we took and the plan for the team going forward I hope that gave you guys some ideas of how you can approach your projects moving forward and maybe even save you some time but we should have some time for some questions and answers if anyone has any you're sorry but it's more starting related because it still works ideally you probably want to use something more like Gitflow so you have a development branch, you have your UIT branch, you have a production branch and you should be doing tests on each of those things before it hits production for reasons and goes horribly wrong and you've accidentally pushed out a style that's broken everything because it's now versioned you can go backwards you can say 2.4.1 has broken everything revert it to 2.4.0 and you fix it all again giving you time to sort of revert and go save the day did you not get to see the screen let's go back so that's the video if you guys want to read more about testing and they also go quite in depth with how you can use lines or GitLab as well to set up these tests so a lot of what I ended up doing for this team was kind of based off this video and how I set things up for sharing is caring you go about sharing, you want to share features deploying updates that have lots of on-premise you know company people on the one side are you doing that yeah so when we update config on the profile end of things and we want all the sites to share it we install it as an update hook and it basically will say oh this is like a database update or go through and go oh I've got all this new stuff to do and it'll go through the config that way yeah only when there's a massive config thing but handling like 10 or so files it hasn't seemed to be a problem yet oh yeah how did they still look like this was about three months of work and it was about one month as well to convince the government agency that we should be doing this so you have to sell the idea to actually get the time to work on it and because it was during the whole Drupal 7 to 9 migration we're kind of able to use that as our starting point to say hey we've reviewed all the stuff, we've reviewed all the code and we've noticed a lot of consistencies how much easy and how much time can we save by making this once so do you have time to work before or you wait to go ahead so we originally started with a general idea, we knew we wanted to make a profile we knew we wanted to make a theme for the component library that actually came later when we started going oh actually we can move this out again and have that outside again and also expand the team because sometimes it's really hard to find Drupal developers sometimes it's really easy to find JavaScript developers I understand when you said that I would say the component library would probably still be worth it and then I think it depends on what your microsites are going to end up doing if they're smaller sites, do you need all that config shared do you want consistency that your editors are going to have the same set of baseline content types yeah