 So let's kick things off. Come on in, have a seat, welcome. Today, I'm talking about the evolution of deployments. We're going to be talking about how to choose the right workflow for your team. Before I jump into that, here's just a little bit about myself. I'm John Richards. I head up developer relations at a company called Paladin Cloud. We do cloud security, AWS, Azure, GCP. Before that, I worked at Pantheon and in the Drupal hosting and platform business. So I spent three years there. Before that, I had spent about a decade developing web applications. And then the last five years have really been about contributing, being a part of open source community, as I really got to grow and love the value that comes from that. And a little fact, a random fact about me. I was born in Pennsylvania, very the central south part of Pennsylvania. And somehow I never made it to Pittsburgh or Philadelphia. So here I am many years later, first time back in Pittsburgh. So really glad to be back here in my home state and actually visit one of the major cities here. It's been amazing. I love the city. So any of you, anybody here from Pittsburgh? Do we got any local folks in here? All right, we got a few. So thanks for having us here. You guys have a great city and we appreciate inviting all of us here. All right. So let's get to the topic at hand, the evolution of deployments. Picture here of one of my favorite video games called Ancestors. It's about the evolution and learning. So I put that here and maybe it'll tie in a little bit later. But we're going to talk about why, talk about the past. So like, why do we care about how this has evolved? Why does the history of this matter? Then we'll talk into what that actual history looks like. I'll talk about some of the complexities that have come about over time as we build out modern tooling and as we've adopted new workflows and techniques. Then we'll talk a little bit about what to consider as you're prioritizing building your workflow. And then we've got some time at the end. I've got some different scenarios and we can explore what it's like to build out workflows for maybe different environments, what you're prioritizing, what you're working on. And then ending with some general tips to keep in mind as you think about the workflow for where you're at. Alright, so why talk about the history of deployments? Well, if, you know, you're here in this talk, why does this history matter? Well, I saw this quote recently, if you want to predict the future, start by explaining the past, then work up to describing the present. And this came from a former coworker of mine, Steve Perch. He posted this on LinkedIn. I knew I was prepping for this talk and I was like, I'm still in this! That's so great! But I do believe this is very true as we think about what we want to do with our workflows, as we think about how we want to predict what we're going to do in the future, what we're planning for that. It is so important to start by understanding the past, understanding the reasonings and the choices we made so we can make informed decisions now and we're not just blindly copying. And part of why that matters is even more for deployments because deployment workflows are complex. As we go through this, we'll be understanding some of the complexities that come into building a workflow. They also take a lot of time to rebuild. I've been through a few of these at different organizations and it's always taken a huge amount of effort from the team to come up with to build out these processes. And once you've done all that effort up front, you really don't want to have to change this down the line. And so it's very rare to go back. You might only do this once every two, three, five years. It depends on where you're at. You may only change this occasionally. So it's important to understand why you're doing it or you can get locked into really bad workflows that don't mess things up. So it's worth taking the time to do it right. So with that, let's talk about the evolution of web deployments. Now, it may not come to any surprise to any of you, but early on people were shocked when they said, hey, people are really using this worldwide web. We're trying to put a website out there, and people are coming to this. We need to do something about the amount of traffic we're getting. And early on we started using specialized machines. We moved away from... I was just talking to somebody who was working at a university and they still had some old machines sitting under a professor's desk that they were using to run websites. And they came in and like, hey, we got to clean this up. So there was people doing that, but very quickly we moved on to some specialized machines. These servers, no surprise. And hey, how do we change the stuff on there? We need a way to work with this. And that brought us to our good old friend, FTP, the File Transfer Protocol. And this was cool stuff back in the day. I remember in college the first time I played around this, and it was magical to me. It's when I decided to be a web developer. I was learning programming, and all of a sudden I was able to take my CSS, my HTML, and it's a PHP and send that up onto a server. And when I did change something and there was a visual output. I had been working with C++ before that and it was just everything was kind of in the terminal. And all of a sudden I was like, this is incredible. People can see it. I want to do web development. Now, there were a lot of problems inherent in this workflow. We really quickly ran into these problems. Like, oh no, I was working on a project and Frank came in and he overwrote my file. Or my co-worker Sarah, she just pushed up a change. Oh, I put the wrong break. So ignore that. Putting the breaks on the project. Made a change and all of a sudden now the site doesn't work and was it Sarah's problem? Maybe it was mine. We're not sure. And maybe I need to work on a project that's Jose's project but now I'm suddenly been assigned it and I don't know what's there. So we suddenly were like, hey, we need to do something about all this code of writing. How do we track this? And along came version control. I've got this image here I found from 2015 because I love it. It's got a plethora of open source version control options on here. And back in the day, I started out on subversion. If you know WordPress community is still hanging on really hard to subversion. So I'll poll all of you. Is anybody here using version control that is not Git? All right. We have nobody in the room who was doing something and that seems to be the case. We've really as a community back in 2015, whatever that was, eight years ago, it was like, hey, maybe somebody will run it. Well, we'll pull away here. But really it's become Git as the standard for pretty much everyone. And it's amazing. So that's why we're using it. Now, the next thing was happening is all of a sudden, these sites, they were becoming really important parts of our workflow, important parts of our business. And we say, hey, I've got a release coming up and it's Friday. I don't want to have to deal with if something breaks. I'd push out something. It would break. I'd have to work on it. I hated Friday coming around because maybe if we deployed something, I would be stuck working over the weekend to solve that. Some of you may have dealt with that same thing as well. And so this idea of having multiple environments came along. Maybe we can have a development environment. Maybe we can test this before it goes live. And I remember talking to somebody who talked about this workflow and being like, that's a lot of extra work. I don't know if this is going to catch on. And then it would only be a year or so before I was like, how did I live without this? How did I think it was OK to cowboy code right on top of the server and break things? So we moved into this world of, hey, we'll have multiple environments as we work on this. We can be confident on what's going to go out. Then we started having challenges around the idea of, you know, I'm tired of waiting for my code to be deployed. I worked where I was working. There started to be concerns about, OK, who controls the server? What's on there? I think it may be a little bit about compliance. And the IT team was like, well, we're not sure we want developers to have direct access to our production environment. Now that we've got multiple environments, it's OK if you have access to these other ones, but not to production. Well, then I wrote code and I needed that code to go up. And it was starting to bottleneck there. Or we might work on a project. I remember I would get a new project and I would go in and I would pull up the FTP program and I would download all of the code to try and get what the latest version was. Because just because something was in the repo, I didn't know if that's what was matching up on top of the server. And I had to be sure about this. And at the one place I was working where they had this bottleneck, we found a workaround which was at the time we were using a WordPress. And we had a module in the back end that was a file uploader. We would take all of our Git code. We would compress it. I should stay on the mic. We would compress that down and we would upload it through this file uploader. Now, I don't even want to talk about security implications of running this and executing it on there. But there was the problem that if I missed the semicolon, if there was a problem in my code, it would break the site. And because the site was the only method for me to get code onto it, the moment it broke, it meant I now had to call up the system admin and say, hey, somebody with actual access has to get on there. So there was ways to try and work around this, but it was really bad. And so thankfully, part of why there's kind of this universal adoption of get in here is people started to get into the GitOps or Git-based deployments. Well, if we are tracking all of our code in one spot, and that's kind of the source of truth, this is the place where everything's at, then maybe it makes sense that that drives what's on our website as well. Why do we need to have these as separate things? And so this was a beautiful step for us. And we see this growing even now. So you've got some kind of deployment process that's going to happen here. You see like GitHub's adding in GitHub actions. The providers are becoming full on kind of DevOps platforms. We've got GitLab building out their own things. You can have in some automations. Maybe you're using Jenkins to take care of this, but you need some step here as you get to this Git-based deployment to be able to push your code up. And then you can deploy that across these different production environments. And we'll talk a little bit more about the hooks and actions on why they matter here. And our next steps, as we start to think about, hey, I've got all this code now. These sites, these applications are getting so big. And now I kind of, so if you're a developer, there's two core skills you need to have. One is being really good at Google, and the other is copying and pasting. And skill one's about to go away, and instead of being good at Googling, it's going to be how well you can write AI prompts, but we're still going to be copying and pasting what we got from the app. That skill is still fundamental to us. And as we think about this idea of copying and pasting, there's something about it. What if the code I copy and pasted has a vulnerability or bug in it? Well, maybe it would be great if I could then pull in a fix for that vulnerability or bug into my code, because my actual code is kind of dependent on that original code. And it would be great if I could do this at scale. So I'm going to copy and pasted code in that automatically a copy and pasted in code from all the places they wanted it. Okay, I'm getting a little abstract with copy and paste here, but what I'm talking about is we needed a way to manage all of these dependencies. We were starting to have this struggle of I have dependencies, and I want to be able to pull them in and manage them. And we also started to want to write code that would write itself, so we're getting into CSS preprocessors, and maybe you're using certain JavaScript frameworks, things like that. This brought us into the world of needing a build process. We started, you know, maybe you're using gulp and grunt on this side to handle your assas file, something like that. And Composer became such a key part of managing dependencies that it is now baked right into Drupal, because it's accepted that we're copying and pasting from everybody. These are our dependencies out there, and being able to manage them is an incredibly important part of this process to make sure our site doesn't break. And then we ran into this challenge around quality. You've got a developer out there, they're working on code, and we know now, hey, we've got multiple environments. We can catch if something's going to break in that pipeline whenever we're testing it. It doesn't have to make it to production, but what if something does break there? It starts to slow down our process, because we've got code that's sitting there, or maybe the code goes through, it doesn't technically break, but it's written terribly. It's not following our standards, our best practices. And so we started to say, well, what if we could fix this? I once had to work alongside a developer, he was really smart, but he hated testing his own code, and the moment he worked on the code, he'd just push it right up and say, I'm done, and the moment you looked at it, you're like, this doesn't even run. You never even tested this on your own. And so the manual way you can do this is you can say, hey, listen, we're going to pull your access to the main branch of the repo, and until it's tested, we're not going to let you have access to that. But there's a better way. We're starting to add in this build process, we're starting to add in some automation. What if we started to automate things inside of that pipeline? After we've got this GitHub repo now, and we've got some hooks, we've got some actions, or GitLab, Bitbucket, I don't want any of the Git repos we'll say you're using out there, and you're like, I want to add in something more. I want some testing to be happening in here. So there's different levels of tests that you can be running. Maybe you've got unit tests, you're checking to make sure things work, and this allows us to suddenly be more confident in developers pushing out to a main branch if we're starting to think about better workflows, because we know there's some minimum level of requirement for code that's going to make it out and make it into our kind of deployment cycle. And the big thing about moving to this step is it gives us, as we start testing here, finally kind of all the individual pieces we need to step into a real robust DevOps cycle. And there's going to be more evolution we'll talk about, but this is the spot where we can finally start to see this idea come together. We plan, we have our section here, then we have, our code gets written, now we have a build process at fires, we've got Composer coming in, maybe we're running some node packages and doing some pre-processing, now we've got tests that come into this step and say, hey, does this work? And then if it passes this test step, we can move into this release, we can have a release here that we can finally deploy out, run our ops to make sure that goes across our different environments, we can watch this, we can learn from it, and we can start this cycle over. And so, this kind of level is where you're wanting to get, if you're wanting to use this DevOps cycle, you want to use that to speed up what you're doing with development, but this didn't stop the kind of growing, there were still ways we could get better, and so we started to run in this challenge of, hey, our monolithic site is starting to get overloaded and different organizations hit these at different times, depending on what your path is, it's not like there's a one trajectory of maturity across your DevOps process or your workflow process, but it's almost like eventually as you go, you will start to hit these. So it's like, hey, our site's not able to perform at this level, we're getting too much traffic, it went down, I worked at a place, we had a whole bunch of traffic come into our website, it took everything down across campus, and we suddenly were like, hey, we got to do something different from this, and this is where this idea of containers or maybe some other scaling things start to show up, and containers are massive. While I was trying to find an image for this, I found an image that was the evolution of containers, so I don't have time to give this talk inside of my talk, but no, that has its own whole evolution cycle happening there, but using this is a huge, it's a massive market out there, and fundamentally underneath, this is letting us scale more than we ever have before. And then we're talking a lot about the DevOps, the back inside, but we're also seeing as we mature this process, we want to make sure that even if all of our code is working, sometimes the site looks terrible when a change is made. I've made changes and suddenly the navigation isn't where it's supposed to be, even though technically PHP is running, all of the things seem to be working well, and now we're running on this issue, plus there's tons of viewport widths, you know, a lot of this happens manually, but all of a sudden it's, hey, we need to have some kind of visual regression testing built into our process as well. How can we make sure we're not breaking things for the user, even if the code says things are okay? Developers have been using diffs for a while, that's why one of the great reasons with Git, we can see what the differences are between commits, but this is starting to let us say, hey, what differences are you seeing? As they kind of go through this. Now, you know, be careful, this can be fraught with false positives, you're going to have to make sure you can get this tweaked right for your use case, but when you can really land this, it's really beneficial to say, hey, I now know whenever I deploy something, I'm getting this response back that I didn't break anything across the site. And then this challenge here around speed where you may be at a place that needs to deploy things out where I was at the university, and we suddenly said, hey, we want to have every little department have its own sub-site, how are we going to do this? And we needed a way, you know, the CMS is great, but everybody wants one, how are we going to manage this? And so we get into, well, we might need a workflow for running a Drupal multi-site, or maybe you're using custom upstreams to deploy this out, but we now might need a workflow that says, hey, how do we take one set of code and start to apply that across a whole bunch of things? And then another challenge starts to come up, well, how can we speed up our complex app? And this is, you know, we hit containers, but we need something faster, depends on what you're doing, not everybody is out this tier, but we are, people are pushing what they can do in the Drupal space, what they can do with their machines, and so this kind of most recent step, if you will of saying, hey, what's next for us as we look to scale up? And this is, in my mind, the rise of decoupling, there's a lot of discussions at the conference here about this, the rise of microservice architecture where you might have Drupal as your back end, and then you're serving up some static content, you're hitting other APIs out there, and this can get you really incredible gains on the speed side as you need performance as you're looking to really scale up. Now, this can go too far at a recent conference, I was at DevOps Days Baltimore, and we had some open table kind of buffed style discussions and somebody was talking about is the future that we just run everything on 100% lambda functions, and we don't have any actual code, like is that the true microservice? And of course the resounding answer was like, no, too much of that is terrible. There was a headline from Amazon Prime's video where recently they said, hey, we're leaving microservices and going back to a monolithic architecture. Now, at the end of the day, they were really just scaled down microservice, they were still part of a much larger ecosystem, but there is a case of adopting too much, and so within this recent development, we're still as a community trying to figure out when's the right time to make this call, sometimes it's obviously incredibly beneficial, but other times, maybe it's too much for what we need. And that leads me into kind of our next section. So we've walked through a little bit of the timeline that's happened here, but all of this stuff hasn't been free, if you will. There's been a cost to evolving our processes. We've gained a lot, I tried to tag at the top, a lot of these gains were really focused around speed, and speed here meaning the speed of development, and the speed of a team releasing a product, less so than the speed of the actual application, that there was a lot of improvements around the quality, like how do we make sure things are working, how do we get reliability, those were really important, and scalability is a little bit more on the speed side here, but how do we make sure our things do well. But all of those have come at a cost of complexity, and that's not the only thing kind of pushing complexity on to developers. There's this idea of like shifting left, where responsibilities have started to move, hey, maybe we don't need a whole team to do this, maybe our developers, we could shift this on and handle this. The idea of just DevOps in general, or being a full stack developer, instead of just being a front-end developer or a back-end developer, there's often people who want a full stack developer, someone who can do everything, and that again raises the complexity that you're dealing with here. And on top of that, there's also other pieces coming in here, there's compliance needs of your specific organization that you might have to deal with, HIPAA, FERPA, FedRAMP, PCI, there's so many different compliance. Security side of things, the more you tackle on this, the more you need to be thinking about what security concerns you're going to have, how are you making sure that what you're doing is secure? I didn't cover any of that while I talked about that evolution, we're assuming you're keeping up with that along the way. There's tons of providers and you've got your own individual stakeholders sitting out there, and there's also a whole bunch of tools out there. I pulled up this image here of the CNCF landscape of the open source ecosystem sitting out there inside of CNCF. There's 1184 different cards represented here. You can see it says it's got like a market cap of 21.5 trillion dollars, funding of 53 billion, and over here that little tiny arrows pointing to the company I work at right now, just one small little piece of this massive ecosystem that's sitting out there. And again, this is from the CNCF landscape talking a lot about Kubernetes, containers, and that side of things. There's a whole layer of other technology that isn't even inside of that that gets layered on top of this. And that's... So what I want to bring that to is this idea of DevOps literacy. There's a cost of learning all this information. It takes time. It takes knowledge and effort. How do you skill up a team to know what to do? And it's requiring now that you've come up into Drupal. Drupal 9 now, we've got people talking about, hey, we're using Drupal 7. Well, the reason some people haven't moved from 7 to 9 yet is there's a lot of changes. There's a lot of knowledge that needs to happen to skill up, but also you're restructuring that site. That's a lot of work to have to do. And so the knowledge entry point for Drupal has come up as we've talked, you need to be more DevOps literate if you're going to be using Composer as part of your build process again. And so we have to realize that we only have a certain limited amount of time and depending on what your role is, you will have more or less times to commit to learning this. So you need to be judicial as you're saying where do I want to put my time? Now if you're in a role, maybe you're a DevOps engineer, a platform engineer, site reliability engineer, something like that, it may be that your primary focus is nearly 80% on your DevOps pipeline and you can really dig in and build something amazing, but it may be that you've only got 10% of your time to do that. Or you've been given two weeks, solve this and get this out of the door. So you may say, hey, how do I start looking at reducing complexity here as I tackle this? So there's some different ways to do this. It's probably no surprise with all that complexity coming in that people are trying to say, hey, how in this ecosystem can I fit in here? And one level is to say, hey, this whole process is just too much for me. I don't want to have to deal with this. And people saying this may very well be clients of many of you in here. If you work at an agency, this is what you're looking for. They're saying, hey, I don't want to have to deal with this. Somebody else do it. So go find a agency or a consultant to help. You can have an agency do everything. You can bring in a consultant to say, help us figure out the best way to build our pipeline. If you don't want to hand that off. And this is my little pitch here. There's a bunch of amazing agencies and groups out there that are sponsoring DrupalCon. Go check it out. I was going to put some logos, but there were so many wonderful ones. They've got spots on the floor show out there. So if that's your case, go check it out there. Now, the other step is saying, hey, well, we're handling this. What's another way to scale that down? Another way is to have somebody else run the stack. So I've got to call out for some of our sponsors here. And then there's the big cloud providers out there. You can look at saying, hey, somebody here is going to run either the infrastructure as a service to help take some of that off or the next layer up is a company like a Pantheon or an Aquia that's a platform as a service that says, hey, we're going to simplify more of this for you. And again, this is a tradeoff as you decide what level of workflow and complexity I want to use. And so as we think about these deciding that as you're trying to figure out, okay, what are the tradeoffs that are acceptable for my organization? You do get into, well, how do we start to prioritize our workflow decisions for our organization? And so I want to bring us back to this DevOps cycle. And really what we want to think about is what are the parts we need in this cycle for our organization? And what are the important parts on here? Now, that real kind of our first step, the minimum thing you need is some code and to be able to deploy that, but you're not, that's not a robust way to get about this. So we want to start with this idea of planning. This is the people side of things. Often it's much harder to wrangle than the tech side, but it is certainly equally as important. Many people are, you know, you have a bunch of people working on a project, you're going to need to keep track of that. Who are the stakeholders? Who all will be contributing to the process? Do you need to have design or content? Quality assurance that need to be a part of approving things? And maybe what compliance you need to be understanding is you're in this section. And then from the plan we move into the code side of things. When Git arrived on the scene, it was the most complex challenge for web developers. I remember me and my friends getting around and being like, this is really difficult. How do we set this up? And it's not gotten much easier, but we do have more challenging tech around nowadays too. And there's better resources for learning it, so that's definitely helped. But still, you know, if I get into things like subtrees, I really quickly get to my level of like, Git literacy. And suddenly it reminds me, so I took a couple semesters of Korean and now I'll hear a Korean word and I'm like, oh Sundubu Chigae. I've heard that word. I don't remember what it is. I'm going to go use my developer skill of googling, find out what it is and now I've got it. So that can be an acceptable level of Git literacy which is, I've heard of subtrees. I don't remember what they do, but if they come up, I can go look that up. So you try to figure out how much you want to go because there is a really deep level here. I got here like Git flow. There's different ways of deploying across your using Git. Maybe you're using a bunch of branches or maybe you're a trunk flow which is a kind of CICD pipeline and you need a certain level of development maturity if that's going to be the kind of route that you take. And I just want to end here that you do have to learn this but there's some great resources. I love cats. So go check out this resource from 2017 which talks all about how to learn Git using cats. All right. And then the next up is the build process. And thankfully as I mentioned most of the folks doing Git out there have realized that DevOps is really important and have started to build in ways to do this. At Lassie and you've got pipelines, you've got GitHub actions. I know over at GitLab they've got a whole kind of platform for deploying this stuff out. But this is a really important decision as you think about where build is going to happen. You've got your CSS pre-processors. You've got the compiling. Maybe you're pulling in some of that testing phase in here. Where is that going to fire? And with D9's Embrace of Composer, this is now a mandatory step in any kind of D9 deployment process of where is Composer going to happen? So where do you want to build this? You can build it on your machine as the run Composer locally and push that up. And if you're doing that or you have a pre-hook, you're going to be saving that artifact in your Git repo. So you're making this decision of what's going to live inside my Git repository. Am I going to have a whole artifact in here? Or do I want to keep this bare minimum? But then I'm going to need a way to run this afterwards. I talked to a company and I was asking them, okay, well how do you handle Composer on your end? And they said they use Bob deployment. And I was like, I'm not aware of that. And they're like, oh, well what that means is when we're ready to actually deploy this to the server, Bob goes into the GitHub repo, runs a Composer compile and then he pushes that up to the server. So that's one way to do it. Not what I would recommend. Automate something there. But figuring out where you want this to live. I got on here on the provider. Pantheon, if you've seen they've been talking about integrated Composer, they want to run this for you on the server, which has some benefits. You need to make sure if you're doing this, then your build process is happening over there. You're kind of handing that over. And you may not be able to then run your SAS pre... your pre-confiled SAS. You're going to have to figure out something because you've handed over this step and you're no longer controlling that. All right. Then we get into testing. And again with this what and where. So your build process, where it happens, is important because testing is a key piece of this. You're going to want to, after you kind of do that build, you're going to want to then run all this different tests that you're doing. And we can see here there's a lot of different ones. The unit tests at the very... then you got your functional ones. You might do benchmarking. You might check for code standards. There's visual regression testing. And I call out visual regression testing on here because if you're looking to add this into your pipeline, unlike a lot of the other pieces where you can run this as part of the underlying code, visual regression testing really needs that final artifact. And so if you're running visual regression testing, you're going to need to make sure that that build process is happening before you get to that because you can check and make sure developers are writing good code easily in the pre... I can't think of the word... in the files that you're writing for your Drupal site. But you don't need to compose it. You don't need the final format for those. But to be able to view that site, you do need to be able to do that. And so as you think about doing this visual regression testing, that kind of sometimes has to happen after release. So you've got this release piece that's going to happen, this artifact gets created, and now you can think about, well, maybe some of our testing will happen after this. And then we move on to deploy. So once that artifact is ready for release, we can look at moving them into production. All systems are green. This is ready to be developed. You can have however many different environments you want. All your checks have gone through. But you would need to be thinking, as you do this, if you've got multiple environments, how do you make sure they stay in sync? Because we're at a place, we had testing, we had production. But we didn't have a great syncing process for them. And we started rolling out updates to PHP, and they worked well in test. When we hit production, it broke some sites, so we rolled them back. And then for six months, we had a different version of PHP sitting on production than we did in test. And we would write code, and it would work in test, and then it would break in production. And so if you don't have a good way to keep those in sync, you lose the reliability of that. So this part of the workflow of deployment really gets into, okay, if you're going to have these different environments, how do you make sure they're all staying in sync? You might also be dealing with something like important data. Maybe you can't have that data sitting in dev or test because of HIPAA related. It's PII, and so you might need to have some Drush SQL Sanitize running to make sure as you pull that data down, people who have access to those other environments can't read the important production data. And then there's this operate phase. This is where you start using your code on the live site. This is really where you've deployed this out now across whichever environments that you have. And now you're moving on to the important spot of monitoring. Maybe you're throwing on Google Analytics. You're going to want some uptime checking as you check to say, hey, is my site staying up? You're going to want logs so you know what's happening. If something breaks or there's a problem, you can track that down. You can figure out what's going on. And then hopefully there's just a way for customer feedback or whoever your end user is that you're looking to work with. How do you get that information back in? Because the final step of this process is coming back to plan and saying, let's iterate. This thing is a cycle for a reason. How do we mature? Because you can think of DevOps maturity, like one measure for it, not the only one, but a key measure is how fast can you go through that helix, that cycle there. How fast can you make that loop? The faster you can do that, the more you're adopting and able to iterate and grow faster. All right, so we're coming to this idea. We want to customize our workflows. So for this last piece here, I thought we'd look at a few examples and kind of see how we could take some of this and look at that. So one option is maybe we've got this challenge. You've got your main job, whatever that is, but you've also got a friend. They've got a site on the side and they say, hey, can you help me start managing this? And so do we need a full on, a coupled website for this with a robust pipeline? I don't think so. And so for this as we think about what's on here, well maybe the planning, we don't need a tool for this. The occasional email comes in and I'm going to update it based on that. I'm the one who's coding any changes to this site. Maybe I do build this all locally and I take a peek at it in my local development environment. Maybe I'm using Lando or DDEV, something like that and I make sure it's working. I push this up to a Git repository and then I upload that to maybe a cheap server. I put on some Google Analytics and I call it a day. And if it's just a side thing, sometimes that's all you need. You don't want to try and say, hey, I'm going to build this robust thing for this little side project. But there's a lot of people who this isn't enough. If this site needs to stay up, if it needs to be robust we need to think about something else. So what if we're maybe a medium-sized agency that's building custom apps using Drupal? What's a workflow look like for that? So here for this on the planning side so for this organization in my mind I imagine they're using infrastructure as a service to give them a lot of maximum flexibility for their customer needs and this group is investing really heavily in the DevOps process maybe they've got two or three people who are doing that because they see application-specific workflows are a value add for customers. And so they might use GitHub for their coding but they would need something here where they're planning, how are they getting this information back from their clients they could layer in a build process on top of GitHub so maybe they're going to use GitHub actions or hooks and use something like a CircleCI to build out so whenever they want to test and make sure that, hey, you're following our linting standards, you're following our coding practices I want to do some compiling, we spend something over there using GitHub hooks they're maybe considering transitioning over to Jenkins if they need more automation as they go along. And then for visual regression they're going to use some backdrop to be able to make sure that they can check their websites to make sure that they aren't regressing visually. They've got most of their standard sites are sitting out their own Drupal 9 but they maybe have a few mobile apps and these are driven by a decoupled backend for content management and then they use a couple other APIs to be able to pull in data so with that they might also have some advanced tracking for customer advertisement campaigns as we kind of move into this monitoring section that they're using and then they implement whatever the customer's tool of choice is and because they have, they're looking to structure their agency to have regular ongoing contracts or at least having regular contact points so that they can have this loop happening over time so you know agencies out there you want that contract you want to be able to do this loop instead of, hey, we built it once and then we're done so that's one way to do this, this is an organization that has because they're building some custom apps, things like that they've really prioritized the value of a custom workflow for each one of these but that's caused the overhead and they're paying for folks to do that and then kind of a third option this was the one that I myself was in at one point and so this was, hey our planning phase here happens as JIRA tickets come in oh and I went past this but thinking of like a large university but they are building as much complex things they're standardizing a bunch of departments and kind of figure out how their websites might work so planning could happen in JIRA as tickets come in and so if you're using JIRA for that planning phase maybe it makes sense that on the code side instead of GitHub you're using Bitbucket you can tie those tickets together and hey, we moved away from our on-premise and that one system admin bottleneck and now in our case we ended up going with a platform as a service we used Pantheon and that lets us adopt custom upstreams for deploying this out to a bunch of different sites using D9, some integrated composer and then mentioned earlier with visual regression part of why Pantheon's like hey we've got this cool tool autopilot to do visual regression testing for you is because if you're relying on them for the build you're going to need that somewhere in there so that's a value, that's why they're doing that whereas if we were looking to say our tradeoff is we can't run you know a bunch of linting on our end, our build process because we've handed that off and so if that was a blocker we might not be able to use this route so that's where if you're getting value add from a provider understand what tradeoff you're getting so you know like is this acceptable for me in this case smaller sites, unit tests aren't as important, we're okay trading that off but you might need a more custom workflow if that's not the case and we use Google Tag Manager, we're going to throw it across all the sites as we move into monitoring and we'll use New Relic for our logging and uptime checking and so that's a whole different workflow than what the agency model was using or somebody at a small place so as we kind of come here to wrap up we come back to this idea of we talked about why this mattered we walked through the evolution we saw how complex things got and then we did discuss a little bit about prioritizing what are the important things to be keeping in mind and then we walked through three examples of custom workflows and I'm going to end here with some general tips for us as you're looking at working on a workflow for yourself so the first thing I want to remind you is it's not about it's not just about you I built out a really cool workflow for a place that I worked at that's why they kept coming up earlier and I thought it was magnificent it was a piece of art except I was the only person who knew how to use subtrees and when I left I had to write up this giant document and they were copying and pasting in commands and it just didn't last and so it's not just about you and building out what you want remember other people are going to need to know this they're going to have to handle this so make sure you're building for the team and not just yourself this is where we're at now but we're at a specific point in time and DevOps is not static we know it's going to keep evolving keep changing and so with that in mind tip three here is to build more for one year out so you don't want to build for where you are you'll grow but don't try to build for five years out it can make you think that you're trying to get the perfect solution but you don't know for sure where you'll be at five years what technologies are going to be around and so it's better to build for about a year out focus on where you think you're going to be so you have some expansion but without wasting time trying to hypothesize five years from now how much AI are you going to need to deploy your site you don't know don't try to set that up right now focus on the essentials what are the non-negotiables for your team so as I mentioned you know if certain parts of the build process are absolutely critical to you then you want to make sure that whatever workflow you do is built around that and if you've got certain compliance policies as I mentioned maybe like HIPAA that's going to require certain environments to only allow certain people to have access you're going to want to make sure that you start from that instead of building out a workflow finding out we can't actually use this and needing to shoehorn those essentials in later and I want to warn don't blindly copy that's why I wanted to give an example of three very different workflows that teams might use because it can be easy to say hey I went and I heard so-and-so was using this workflow I'm going to use it but they have a very different use case and you've wasted your time by doing that which leads me to my next point which is make sure you copy from other people because copying is great but don't do it blindly understand a little bit why so if you hear somebody has got a great workflow take them out grab some coffee hear about why they made those choices see what parts work for you what parts don't and then hey I told you I'd finally tie this image back so one of my favorite things about the ancestors video game is that you're trying to you're an ape out there in the wild serengeti and you're trying to survive and they have a key component on there of how do you learn and the way you learn is you have to take a small ape one of the babies you put it around your shoulders and you go out and it watches you as you gather food or climb a tree and it learns from that why does that matter well that's how Drupal grows is through mentorship through sharing what you know with others you can be brilliant and amazing and do all the cool stuff yourself but if that's not shared out it's going to end with you so make sure you're sharing with others check out the amazing mentorship booth at the sponsor area that's most of my talk here thank you I'm with paladin cloud we've got an open source project it's aws azure gcp but I don't know how many people here use that but if you don't just give us a star makes the investors happy it's open source and free that's it thank you all so much if you have other questions I'll be down by the pantheon booth where I used to work so follow up there also I think we got time for questions so I can take them here as well for the next couple minutes