 Hello, how's everybody doing? I think we've got a few chairs in the front, if some of the people standing want to try and slip in before we get started. Thanks for joining me before lunch. I know last session of the morning can sometimes drag on a little bit, so we're going to try and keep this party going while we do some live setup of DevOps tools. I got to tell you, coming from a non-computer science background, a lot of what we're going to be doing today when I started doing it for the first time was really scary. And the reason I like doing talks like this, first of all, my degrees are in English and Design, so if I can do this, you can do this. And second, when I work with customers, I'm with Acquia Professional Services, I work with customers all the time, and I hear, weekly, like I'm not joking, weekly, oh, we don't do local development because it's too hard, or we don't do continuous integration because nobody on the team knows how to do it, it's too hard. So we're going to move quick today, but my goal with this session is to show you this is not hard. It may be a little scary, but get into it, try it out. I guarantee you you can do it. And with apologies, we are going to move pretty quick today. So if you're trying to follow along, they're recording this session, I'm going to post my code online on GitLab so you can see it later. I'm going to post my slides. So if I leave you behind a little bit, I'm sorry. Come back, do it after. Hopefully you won't regret it. So just to introduce myself real quick, if you don't know me, I'm Mike Madison, I'm a senior manager on Acquia's Professional Services team. I oversee our Drupal delivery in North America, so I see some familiar faces in the crowd, and if we haven't met, hello, thanks for joining me. Some contact info there for me. Please do hit me up sometime. Always interested in connecting. Today, mostly like I said, what I really want to do today is show you how easy it is to integrate these different technologies on your project. So we are going to start completely fresh. Hopefully the Wi-Fi holds out. If it doesn't, I have some videos we can pull up, but that's less fun. And my goal in 45 minutes or less is to set up a new project with Composer, virtual environment. We're going to use Lando today, but pick your poison. You can use whatever you want. Get Drupal installed, get a basic config strategy in place, get MPM wired into a custom theme, and get continuous integration going. That is doable in 45 minutes on a good day, so we'll see how far we get. And a couple of disclaimers I want to give you. You're not going to see me spend four hours setting up my computer as like a container factory. Depending on wireless and on conference Wi-Fi, it probably would take several hours. I've already installed Xcode. I've already got Homebrew set up. So Composer, get PHP, all that junk. It's already here. It's ready to go. So if you have a brand new computer or if you have a computer that you haven't done some of this dev-up stuff on before, just be aware there are some prereqs to sort of get it ready to do some of what we're doing here today. Most of you I see are on Macs. That's good. You can do this stuff on a Windows machine, but it is harder and it does take longer. So if at all possible, I do recommend trying to do it on a Mac. So again, this is sort of all of the stuff I've pre-loaded on my machine that you're not going to see happening on camera today. So we can essentially just jump in and go. So the very first thing that we're going to do is use Composer to set up a brand new project. Now, if you know me, typically I do this using AQUI BLT. We're not going to do BLT today. We're going to start just with the most basic Drupal recommended project. I'm going to call this live. One second. Not Composer Require, Composer Create Project. And again, I'm doing this live, so I'm going to make some mistakes and that's okay. So as Composer downloads this for me and sets up a brand new project, it's going to pull in whatever dependencies are in that Drupal recommended project, which in this case is very, very minimal and that's good. That's what we want in this case. I use PHP Storm as an IDE. That's not an advertisement for PHP Storm. I just think it's really good. You can use whatever you want, but if you're using, if you are doing work in Drupal 8, 9, 10, please do it in an IDE. They're not that scary and you will be very sad if you try to do this with another code editor. IDEs really, really, really do make the world go around when it comes to working with Drupal 9. So the first thing you may notice here is that my Drupal install is in a web folder. In the Acquia world, we prefer to put Drupal in a folder called docroot. Okay, that's pretty straightforward. We're just going to come into our Composer file, come down to the Drupal scaffolding and we're just going to update the web root location. So instead of web, we're going to change that to docroot. If you're not familiar with Composer scaffolding, it is legitimately one of my favorite parts of working with Composer. Every Composer package out there, the composer.json file basically has a type of thing. So is it Drupal core? Is it a module? Is it a theme? Whatever. And the Composer scaffold lets me tell Composer where to put all that stuff. So if I add a new module to my project, for instance, Composer is automatically going to say, okay, this is a type of Drupal module and I want you to put that in docroot modules, contrib, and then the name of the module. It's really important we're going to come back to that in a sec, but I'm going to now come back and do a Composer update which will essentially move all of my Drupal stuff out of this web directory and dump it into a docroot directory, which is where I want it. Don't let me down, Wi-Fi. All right, while that is running, I'm going to open another project that has some of this stuff already done just in case. We're also going to go ahead and remove that web directory because we don't actually need it anymore. All right, while my Composer is trying to run, I'm thinking about it, we're going to do a couple other things. I'm going to go ahead and set up get and we're going to create a get ignore file. One of the most common things I see when people are setting up Composer and DevOps tools for the first time is they make the mistake that you're seeing right here, which is that this vendor directory is not get ignored. So I actually did some counting once, and if you have a Drupal 9 project with a modest number of modules, there's something like 40 to 50,000 files that Composer is going to pull in for Drupal core, all your modules, and then all the dependency trees all the way down to the bottom. That's a lot of junk you don't need in your get repository. Now, you need it to host Drupal, you need it to run Drupal, but imagine every time you do a Composer update or a Drupal core update, you're trying to track version control across 50,000 files. That's nuts. That makes your get history just worthless. So one of the first things I always do on a brand new project is I'll actually go in and get ignore everything that Composer is doing for me. That way I don't have to worry about committing anything to Composer.json and the Composer.loc file. If you don't have a lot of experience with Composer, we're not going to go super deep into any of these technologies today. There have been some really fantastic Composer presentations at previous Drupal cons. Go check those out. But TLDR, you don't want all of the Composer's managed stuff to get committed and to get. So you'll notice we're dropping vendor, doc root core, remember how I was telling you how these paths are really important? Well, we just get ignored all of those paths. So doc root modules contrib, any of the contributed modules, any of the contributed themes, again, all that stuff is being managed by Composer. We don't want it committed and to get. Cool. We're also going to add a couple of additional Composer packages. So if you're not familiar with the Composer patches plug-in, it is a must-have in my opinion, drush is a must-have. If you're not hosting with Acquia, you probably don't want our environment detector, but you should have something similar. Because remember when you're hosting in the cloud, you're going to have one set of database credentials for each environment. When you're working locally, you don't want your production database credentials local. When you're doing CI, you don't want your local credentials in your CI. So an environment detector is there to help your code figure out where you are and based on where you are, which credentials to use. So I'm using Acquia's today. You do not have to use ours, as I said. So Composer require drush drush and Acquia Drupal environment. Excellent. And again, since I've already updated my Get Ignore, you can see now PHPStorm is showing vendor as green or yellow or whatever color we want to call that, and all of those additional dependencies are automatically going to go into the vendor directory. Cool. All right, let's move on from setting up that new project. We've already initialized and gotten Get set up. I am going to add a Get remote. Don't worry about trying to write this URL down. I've already tweeted it so you can get to it there, and I will flash my Twitter again at the end. It's just Mike Madison on Twitter, so you can get to it easily. And again, this is a public-facing repo so you can get to it. All right, next thing we're going to do is we're going to get a local environment set up. Now, again, as I said earlier, I'm going to set up using Lando. Ddev, Doxel, if you're not using an M1 Mac, Drupal VM still works, like pick your poison, any container is fine. I'm going to use Lando. So to do that, I need to modify and create a few files. So the first thing we're going to do is we're going to copy default settings.php and turn this into a settings.php file. And of course, phpstorm is still indexing, so it's not going to let me copy the file. That's okay. Cool. We'll come back to that in just a sec. We're also going to create a .Lando.yaml file. Now, you might wonder, why am I using a container as opposed to just running this on, like, my computer's web server? Two reasons. Number one, it's way faster to set up a container using Lando or Ddev than it is for me to run all the crap to get my Mac to actually run a web server. And second, I can actually commit this Lando.yaml file into my repository. So if all of you want to work with me, I can set this up once, you can pull down the file, Lando start, and you're up and running, ready to go. So it actually makes collaboration a ton easier using any of these containerization tools that let you commit this file. And again, Doxel, Ddev, Lando, Drupal VM, they all give you that. So sure, it is an extra thing that you have to run on top of your bare computer. But without this, every one of you would have to set up your own web server. There's a chance you're going to do it differently than me. If you're running Windows and somebody over there is running Linux and I'm running Mac, yeah, that doesn't matter, right? Lando's, Lando's, Lando. It's going to work. It's going to be the same. So pretty cool. I'm using just the Drupal 9 recipe, because again, we're going for super basic here today. I am running PHP 8. I am telling Lando that my web root is in doc root. And I honestly don't remember if X debug is on or not by default in this recipe, and I'm turning it off because I don't want to wait for it to do anything extra today. And we will just get that started provisioning in the background. While it's doing so, we're going to make a quick tweet to the settings file. So remember, we added our Acquia Drupal environment detector. So we're going to add a use statement into the settings.php so I can actually use that plugin. And I'm just going to pull in a quick code snippet because it's faster than typing it out. This is just saying there is a is local environment method inside this environment detector. And if we are local, I haven't actually created this config split yet, but bear with me, we'll get there. I'm telling Drupal to use this database stuff, which is the default database settings for Lando. Cool. And again, I've obviously provisioned this a few times, it's all cached, but I now have a local DevOps Lando site. I'm going to run Lando drush site install, minimal with no interaction. And based on that change, I just made into the settings.php file. You can see we're talking to the Drupal 9 database already. That's good. And this is going to finish up here in just a matter of seconds. So that's from absolutely nothing to a bootstrap Drupal in 14 minutes. That's not terrible on conference Wi-Fi. But this is a pretty terrible looking Drupal site. I'm not sure any of your customers or your own company would pay much money for this. So we need to do a little bit more with it. So let's get logged in and do a little bit of configuration magic to at least make this look less terrible. I don't know if you've set up minimal without Clara or anything recently, but yeah, that's not awesome. All right. We're going to add a couple of additional Drupal modules just to make life easier just for fun. Let's go in and actually enable a real theme that doesn't look absolutely terrible. So we're going to go ahead and set Oliveiro as our default. That's much better. And then we'll also install Claro. It is. Set that to be the admin theme. And then we'll go in and turn on just a handful of modules to make this a actually reasonably functional Drupal site. Well, that's spinning. Super common thing that happens right about now which is kind of annoying which is why I'm telling you about it because it annoys me is that when you install Drupal for the very first time sometimes it will attempt to overwrite and change your settings.php file without you realizing it. And PHP storm is likely still indexing so we may just suddenly have another database array. So if you ever are going through these steps and it works and then all of a sudden you can't communicate with your database anymore go look in your settings.php file. Drupal may have tried to helpfully write your database array for you which in this case is not super helpful. We're also going to reset the permissions of the default directory which again Drupal will sometimes reset which is a great security measure on an actual web server but kind of a pain in the butt locally. You may notice I'm setting my config sync directory here to be outside the doc root into config default. Drupal will try to store all of your site config in the files directory which is wildly insecure so you should always change that to put it outside the doc root just to be sure it's never web accessible. And now I'm going to do just a drush config export which will spit out all of the config from this project and if all went well it should have created a config default directory for me. Like I said sometimes PHP store minutes indexing is a little slow and it may not be seeing everything here. Yeah and slash app slash config is inside the Lando container so that is actually right here or it should be. So let's move on while we let PHP storm continue doing what it's doing. I feel like I'm a couple of slides behind yeah we've done that and we're going to move on to CI CD here in just a sec. What we need to do is try to force PHP storm to edit this file which it is struggling I think to do. Remember it's a little deceptive what we're doing here but this project that we're using has thrown something like 50,000 files into this directory. So it does believe it or not struggle a little bit sometimes to keep up with that outpouring of stuff. So let's try a config export one more time and then we're going to move on. And it is not mounting into this right now that's exciting cool. If we have time we'll come back and look at that more seriously but this should have stored it there should be a config default directory right here where that is being written. Cool. So let's talk a little bit about where we go from here. Now normally I would be reinstalling from config and again it's a little odd that my config is not where I want it to be. See if it actually did write it. It did. That's the right version of the file. Cool. Neat. It wouldn't be a live demo if something didn't go wrong. We're going to just create a duplicate lab file and talk about this real quick. Actually no before we move on to that let's create a theme and talk about MPM real quick. So we're going to create a new theme called devops. Now you might wonder why are we talking about MPM on a Drupal project. Remember that themes much like other Drupal code have best practices for how you develop and build those tools. And it's very commonly overlooked especially if you have a PHP background to go oh we don't need to worry about that it's just CSS. Yeah I mean it is just CSS but you should still be writing good CSS. So if you're pulling MPM and Gulp and some of those best in class front end tools into your theme you can start doing things like JavaScript Lenting, SAS or CSS Lenting, you can minify your CSS and JavaScript automatically as part of your build process etc. So we're going to go all the way down that rabbit hole today but I do just want to show you how easy it is to tie that into this process along with composer and everything else. So we're just going to create a basic theme that is a base theme of stable and we're not going to do really anything else to it right this second. We'll run MPM in net just do all the default stuff we're not actually going to use this for anything and we'll do MPM install Gulp just for just for fun. And again if there's an actual front end person in the room you may have opinions about webpack versus Gulp you can do it the same way you might want to use yarn instead of MPM same way doesn't matter. Super easy to swap those things over. The point is what you want to end up with is a package.json package.loc file and you'll notice I didn't explicitly call it out earlier but I did in my getignore getignore node modules and it's the same reason right for the exact same reason you don't want to commit your composer vendor folder you don't want to commit your node modules. Also most of the tools that we're talking about using here for front end theming stuff are for development so you don't necessarily need or want them out on your production website anyway. Getignoring these they'll be there locally they'll be there during your CI CD process and then they won't be there when you deploy out to the cloud which again typically typically is a good thing. Alright so we've got MPM in place we're going to come back to the GitLab CI in just a sec. Let's talk about how to actually start using some of this stuff. Now as I said before typically I use BLT AQUIA's build and launch tools it has automation built in for a lot of what we're talking about. Since we're doing this without BLT I'm actually going to use Composer to help me drive some of this stuff so I'm just going to grab this snippet and then we'll talk through it. So Composer allows you to define scripts as part of your composer.json file. So for instance I could every time I did an install manually run, drush, site install, existing config, whatever whatever other options you want to pass in. Or I can write a little composer script called site install and then instead of running drush, site install blah blah blah I can just run composer site install or lando composer install and it'll run this command. Similarly I can do a post command so in this case I'm doing a post install command which means whenever I run composer install composer will then go into my theme and run npm install. So again these little things you can automate and script so that they happen the same way every time well worth the energy and we will see this at play in our GitLab build process here in just a moment. So we're going to go ahead and rename this file and actually make it the right name because GitLab isn't going to cut it it needs to be .gitlabci.yaml and I have just a basic very basic build here and you may look at this and go Mike that's like 30 lines that's not super basic but like let's talk about this for a second so I'm pulling in an image this is actually a lando image so believe it or not I'm using the exact same image in my CI that I'm using locally in lando it's not a bad thing I have one step it's a build step I've defined a couple of variables for my MySQL stuff that I'm doing down here you don't strictly speaking have to do that and then we get into the build so this is stage build we don't allow failure failure is sometimes an option but not during CI services we do need a MySQL service because if you don't have a database you're not going to run Drupal I am very manually creating like this is about as manual as you can get a Drupal database in which to install Drupal we'll come back to that in a sec I'm installing Node.js again this is a few different steps to do that and that's okay and then I'm running a couple of Composer commands so Composer Validate this just guarantees that the Composer.json and the Composer.loc file that I've committed are valid essentially that will cause the build to fail early if they're not I'm running a Composer install which remember we get for free now an NPM install with that because of our post install command cool and then we're using two different Composer commands that I defined for this project we're doing Composer site install which will run Drush site install minimal existing config yes and then site update which is a Drush UPDB and then a couple of config imports which in this case are probably superfluous since we're installing from existing config but that's okay now before we actually jump out to GitLab and look at what this build process looks like let's talk about this for a sec so you'll notice that I'm creating a database called Drupal and when we looked at my settings.php file a little while ago I had a bunch of database credentials called Drupal 9 so this isn't going to work right and it shouldn't I can't stress enough that this should not work in GitLab because these are my local credentials for my database so I'm going to go back to my preformatted file here just to grab the example so I don't have to manually type it all out GitLab has an environment variable and you can find this in their documentation or any other build system has similar environment variables so basically I'm just checking to see if there's a GitLab CI environment variable then I'm going to have a completely different database array for GitLab and again depending on how you host, where you host some hosting providers have a single credentials in all their junk you may have a whole big long database array like this that switches between but the point is you're probably going to need to start managing upwards of at least three different sets of credentials you're going to have your cloud credentials for hosting you're going to have your local credentials for development and then you're going to have your CI credentials whether you have an environment detector like the AQUIA one or you have environment variables it doesn't really matter again as long as you know for sure right now I am in dev, right now I am in CI you just don't want to start crossing database credentials for hopefully obvious reasons and again we're not doing anything with config splits right this second but I did just want to show an example here of how you know again we typically would set up environment based splits as part of configuration management so you know if I'm local I'm going to want like my DB log module on I'm probably going to want to turn this log off I want all my UI modules turned on it may very well be in the CI environment that we have some other stuff that we want to turn on for testing so on and so forth take advantage of this if statement right like once we know we're in CI once we know we're in local there's no reason not to do some of that other stuff sort of in line in the same place so we're going to jump over to a example repo this is all of this stuff you can see in the repo already I basically have an initial commit that is just a doc root notice there is no vendor if you clone this repo down which you're welcome to do as soon as you run composer install you're going to have the vendor folder right it's just not committed as we talked about earlier I do have a merge request open right now which we will have a look at here and that merge request actually is running a CICID build based on this file that I showed you a moment ago it's thinking and what we can see in that CICD build once it's there is essentially this step right we're going to see the output of composer validate the output of composer install npm install site install site update etc and you can essentially go through and see now we're not going to do this today because we we're running out of time but the next steps from here and again I'll show you these steps if this ever loads the next steps from here are to start thinking about what other types of validation and automated testing do you want to happen during CI so are you using PHP unit night watch B hat are you doing any visual regression testing whatever and again the conversation I always have with people is automated testing isn't that hard as long as you have some place to run it well here you go this is this is some place to run it so once you have this basic piece in place the next logical step is to start building on top of that remember the ultimate goal with any DevOps setup like this is that every time you make a code change whether that's a Drupal security update a feature update a bug fix whatever you want to go from a known working state layer your new stuff on top of it and see if it still works so that's why we install Drupal as part of CI because if we know Drupal installs today and Drupal 9.4 comes out whenever it comes out and I run that update through CI and all of a sudden my CI fails and Drupal won't install there's a pretty good sign that something from 9.3 whatever working to 9.4 whatever not working something there's a problem so we have a safety net from CI for that the more robust you can make your continuous integration the better your safety net we may not get to see the build output but if you go check out the hey there we go it's there you can see we do have a passing build in this case you can see I've got quite a few files because again we're I'm adding config I'm adding the theme all that stuff here in this merge request and I'm going to just try to pull up continuous integration at this point so we can check that out but again you're welcome to have a look here again this is a public facing get lab you can get into all of this and see it after the talk and we'll come back to that in a sec when it's done spinning so again next steps thinking about coding standards thinking about automated testing accessibility testing visual regression testing this is the baseline to get all of those things started and again most of the time when I start talking to organizations about well why aren't you doing any automated testing well we don't have any way to run it okay that's fine cool get something like this in place and then you can start building on top of it the other thing you want to think about is a lot of what we've talked about here and what we're thinking about here are more the CI piece than the CD right continuous integration deployment in an ideal world you would actually use the same process the same pipeline to actually then deploy out into your hosting environment so my very very very very very basic build is probably not sufficient for that because it doesn't have a deploy step but you can see how to build on top of it from here to get there keep in mind that I happen to be using get lab as an example here but most hosting providers have their preferred build system pipelines tool or what not so I don't want you to walk away from here thinking oh we have to use get lab we have to use get lab pipelines like everybody has this the important thing is that you have it so find the right get for your organization find the right continuous integration tool for your organization and use that the syntax will be a little different than my example but not significantly alright we'll get this loading and maybe by the time we get to the end of the talk we can look at the build so yeah just a reminder at the end of the day I don't really care what you use to accomplish what we're looking at here we could have done this with github actions or yeah github actions we could have done it with travis ci we could have done it with aquia pipelines any number of different options just get something in place and you also can start very simple right having a build that installs drupal installs composer and then installs drupal is better than nothing there is immense value in confirming that your codebase can install drupal you'd be surprised how many people I've worked with that their way of testing if they broke anything is deploying out to their dev environment I mean yeah that'll tell you real quick if it works or not but then you have to go unbreak dev if you broke dev break ci ci is cheap break that first here is our build step well that's finishing up I'm gonna be doing some more talking about devops at the aquia booth in a little bit what you're seeing here is like gitlab.com aquia has a brand new proprietary gitlab implementation called aquia code studio that we haven't really touched on here I'm gonna be doing a live demo of that at the aquia booth during lunch so if you're free in about an hour I hope you swing by to have a look at that and I'm also gonna be talking at the booth tomorrow about drupal 10 readiness so if you're already running a drupal 8 or drupal 9 site you're thinking about drupal 10 swing by if nothing else grab a voodoo donut and say hello I'm not gonna make this load and make you wait I want to make sure we have time to answer your questions so thanks for coming what questions do you have today yeah so the question is do I ever keep the build artifact for diagnosing or things like that so I do tend to keep it I very rarely use it just because hopefully theoretically everything you're doing locally is gonna be the same as your ci everything you're doing locally in ci should be the same as what you deploy out so if something fails in ci I'm gonna go back to my pull request locally reinstall or resync or do whatever introduce it there fix it and then push it back up but yeah I mean if you can do like a soft commit or a soft deploy of that artifact some place so you can hang on to it that would be great and if you have a hosting provider that lets you like spin up ephemeral environments as part of builds and deploy there that's really cool and yeah there's immense value in that if you have that option other questions yeah so the question is what are the recommendations for doing continuous deployment so for me because I'm pretty paranoid I don't ever do a deployment unless I know my normal build passes so typically the way I wire up my builds is I do a ci pass on a pull request or a merge request when that gets merged I run a whole another build on the integration and assuming that passes I'll do a commit into a branch and I will typically auto deploy that branch into a development environment I like doing tagged based deployments into staging and prod you know I know people who will put branches for staging prod and when they're ready to go to stage they'll do a whole another build into like their staging branch and deploy there that's an option but I really like the simplicity of I'm going to deploy whatever to dev and when I'm ready I'm going to take that thing and cut a tag right there tag to staging that way there's absolutely no chance that what's going to stage is different I like having that certainty that you know it's exactly the same but yeah I mean the big thing is just make sure that prod is a tagged release you should never ever ever push directly to prod on a branch and auto deploy always tag a prod release before you do it so the question is what about merging into like your primary integration branch the workflows there are going to be a little different depending on what kind of get workflow you're doing you know I unless once I'm in production then then you know having separate like main and develop branches I think are quite useful but yeah typically I would do a pull request into an integration branch develop main names don't really matter right and then I would also have another commit that happens to push out into the hosting environment the only real downside you would have to that sorry the question was marking the vendor directory so it doesn't get indexed all the time similar you can do things with like Drupal VM and Lando to stop NFS from constantly re-indexing and trying to sync large quantities of files so you don't have what happened to me happen to you the downside to doing that is if you do like a composer update or if you redraw your dependencies and end up with a lot of changes in that folder then you have to remember to do that indexing manually so if you're a developer who has somebody else who's doing those things for you I would say the danger is higher that you could actually somehow get out of sync with like your dependencies if you're the person who's doing those changes and updates yourself you're always going to know when it happens so it's a little easier for you to keep track of I typically don't do that and I typically don't have a problem other than this initial setup when it's like oh god there's 50,000 new files you know other than that it's usually not a problem but I know many people who do some variation of stopping that indexing for performance reasons yeah yeah so the question is if you're working with an outside vendor kind of what do we think about to get started so AQUIA's professional services team is is not an agency but we operate kind of like an agency inside of AQUIA so we have a standard way we like to work with a standard set of tools that we like to work with so when we when we start working with a new partner with a new customer you know if somebody has a strong opinion we use Lando here we use DDEV here whatever cool fine we'll work with that if we're going in with somebody who doesn't have a strong opinion we usually say cool we're going to build this our way and then you're welcome to continue doing that or not so I think you know my advice is whether you're more on the agency like provider side or you're more of a you know an end user who owns an application like think about what is the best thing for you and you may work with somebody who has a super strong opinion right if you work with a development team or you bring in a new partner and they have a way they normally work there's a non-zero cost associated to making somebody change their workflow so usually what we try to figure out is like is this a hill we want to tie on that we're going to use GitHub actions on this project instead of Acquia Pipelines no I don't care cool we use GitHub right it's fine oh yeah you want to use the bare web server on your MacBook instead of Lando no sorry we're using Lando you like you do you we're going to use Lando you know so I try to pick my battles respectfully there because like I've said a couple of times during this talk a lot of what we're talking about in this sort of DevOps world it matters that you do it it matters less what you use to do it and I think the notion of figuring out what works for you what you're familiar with there is immense time-saving there's immense benefits in training and onboarding if you have a standard set of tools a standard set of documentation you know if you work at an organization an agency whatever that does a lot of different like revolving door sorts of projects right I'm going to switch from this to that and that to this if you're using six different tech stacks different projects that's hard if you're using one maybe two different tech stacks across six projects it's a lot easier to flip between those and you know no hey because I'm doing this thing over here it's going to work exactly the same way over there does that help yeah yeah the question is any recommendation for database use in CI my fervent opinion is that you should never ever ever ever do anything with a database in CI so if you're writing tests if you're doing something in CI you should assume it doesn't exist and create it as part of the build and the reason for that and not everybody at Acquia will agree with you I don't know that everybody in the room will agree with me on this but like I said we want to go from a known working state and make one change or as small of a change as possible to see where we're at and relying on a database as well I've seen this many times where you open a pull request and it fails so the assumption is oh I screwed something up in my merge request and then I go down this rabbit hole trying to debug or chase down the problem and then as it turns out the reason the build fails is because somebody deleted a piece of content in production and it's not in the database anymore and hopefully you figure that out like in a matter of minutes in the database right if you design your builds so that the CI process creates the content that it needs I use the default content module a lot if you're not familiar with that we talked about having a config split for the CI environment if you have a module that has content in it that you need and you turn it on as part of your config split for CI that's another trick to getting your content there without relying on a database anyway if you create the content as part of the build if you delete the content as part of the build you know it's going to go away there's no question of relying on an external database which again gets you back to the state of knowing 100% if it stops working it's something inside that pull request that broke it so if he's asking if it's a config related change instead of a content change again I store all of my config on disk I always do address config export as part of builds I do address config import as part of deploys I do address config import so again anything that I need or want on my site I'm putting it there as part of the build so that's why composer runs during the build that's why npm runs that's why drush site install config import all of that stuff happens in the build and it really forces you in that case like if I'm doing site building if I go out of view to my site I have to export that config from wherever I built my view I have to commit it into my repo and then I have to make sure that both my CI and my deployment process will ingest that config somehow to get it out whether that's doing a hook update in or a config import or whatever again it's forcing me to sort of track that change just like I would a PHP change good questions I want to be respectful of lunch I think we're at time I'm happy to keep chatting so if you have questions keep them coming but I don't want to keep the whole room hostage so I appreciate you guys coming and I hope you enjoy the rest of your conference