Configuration management in Drupal 8 for beginners

>> SPEAKER:  All right.  Thank you, Bob.  I'm very happy to be here today to talk a little bit about configuration management in Drupal 8 for beginners.  Now, this is a topic that's particularly relevant and, um, personal to me, because, um, the problem that configuration management solves is something that makes the difference between a development process that is kind of making you want to pull your hair out and a development work flow that is professional, that is sort of web ops, which is a Pantheon, um, attribute that we've been trying to put out there, and speaking of Pantheon, my name's David Needham, I'm a developer advocate at Pantheon, I go to a lot of conferences historically, we'll see how that continues throughout the rest of this year, but, um, I spend a lot of time out in the community, um, volunteering for organizations, kind of like, um, MidCamp and Work Camp U.S. and a bunch of other organizations, and then I take everything that I learn being out in the community back to Pantheon, so that our developers are actively creating functionality and features and things like that that are useful and relevant to our customers.  

Now, I am going to be using, um, Pantheon during the live demo of the portion today, just because it gives us a nice visual interface for work flow.  The things that we talk about are relevant for any, um, other sort of service provider that you might be using, and, so, that's not really an issue, it's just purely for, um, ease of use and for you to be able to see what we're going through, but before we get to that, it helps to have a little bit of a setup.  So, for today, um, let me start just by talking a little bit about the anatomy of a CMS.  Now, this means not just Drupal, but also Word Press or YAML or just about any CMS that's out there.  It's really made‑up of three different parts.  The first one is code.  Now, code in Drupal is the Drupal Core, also the modules and the themes and all of the code that you write to make your website do what it needs to do.  

Another piece is configuration.  Now, configuration are the content types, the fields, the dynamic lists or views, all of the things that really gives your website personality, things that make it different from the other websites that are out there on the Internet, and then we also have content, and this could be made‑up of blog posts, products, um, your customers, even, sometimes, your users, um, the people who are logging into your website are all considered content, and when you go to think about using, um, the development work flow, you know, you probably are not just working directly on the live environment, you probably have at least a development, you know, a staging site, um, or, maybe, you're working locally, um, as you think about moving this site from one place to the other, you typically have three things that are being exported, these, um, the anatomy of your CMS gets broken down into three distinct parts.  The first one is code.  The second one is the database.  And the third one is files, and in this case, files are referring to those content files, those things that you upload when you create content, like your images, your PDFs, all of those things that got tied to your content.  Um, so, how do these tie to each other?  I mean, the first one is fairly self‑explanatory, the code is code, it goes over to Git, typically, you're writing PHP, that is your code, it gets exported as code.  Your configuration gets exported as part of the database.  It's, um, you know, you end up with configuration in the database, because that's where Drupal is actively reading your configuration from, and when you go to export your site, you're exporting it as part of your database.  

Now, your content is both the database and your files.  You have those files you're uploading, your images, and then you have references to those in the database related to your content, and those pieces are tied together.  So, with this sort of anatomy, this sort of baseline understanding, um, sort of out of the way, let's take a look at a developer work flow.  So, a development work flow, um, really should consist of at least three different environments, and this was considered, I think, um, way back in the day, Jen Lanton shared this with me, another, um, sort of Drupal friend and mentor, this was a work flow that is, like, the best practice, even long before Pantheon was a thing, long before, you know, even Drupal was really big, like, for any web application, for any web project, you need at least three environments, a dev environment, a test environment, and a live environment.  Now, the live environment is pretty self‑explanatory, that's where people are actively visiting your website, you might have content creators and content editors jumping in and creating content, you might have people buying things from your store.  Now, we also have our test environment, which is basically a copy of your live environment, and it's a safe space to experiment, to, um, see what's all happening on the site, and then we also have the dev environment.  The dev environment is where you're actively developing new functionality on your website, it's where you are, um, applying all of those security updates that get released for Drupal Core and all those modules and themes and all those fun things, and, so, all of that work is actively happening in dev, and when that work is done, you don't deploy it to live, that's pretty risky, you could be, you know, potentially breaking something by deploying straight to live, no, you deploy it to the test environment, and because the test environment is an exact copy of live, you are able to sus out any sort of surprises.  You can, um, review the test environment with your project manager, designer, you can run a suite of automated tests to make sure that everything is going to work the way you expect it to, so that there are absolutely no surprises, and you deploy your code up to live.  

Once this sort of life cycle is completed and everything is stable and live is up‑to‑date and ready to go, you can then sync your database and files back down to dev, starting the development sort of life cycle over again, and this is how it's been for years, for many, many years, more than ten years, um, but there's a problem, and the problem is what about all that configuration?  Well, if people are adding content and buying things from the store and leaving comments and things in the live environment, we never want to be in a situation where we might accidentally overwrite the database in the live environment.  So, as a result, if you look at this work flow, the database and the files always go down, they're always going from live down to somewhere else, and the code only goes up, it's risky to change code directly on live or even test, but we move our code from dev up to test and then up to live, but configuration is both, configuration is part of the database, so how do we actually get that up to live?  Like, that's the problem, right?  Well, historically, the solution to this has been you do it again.  You built something in dev, and then you build that same thing in test, and then you build that same thing again in live, hoping that you did it exactly the same way that you did the first time.  Um, that whole process is super demoralizing, like if you've ever lost your work and had to do it again, like, anytime you have to do something more than once, it just feels like you're wasting your time, it's super depressing.  

Also, it puts you in a position where you're very, very liable to make mistakes.  Also, it makes you, all the extra work makes you a little bit lazy, like you start to question the need for a test environment at all, if it takes so much work and effort to have to redo your work over and over again, and, yes, you absolutely could, um, write scripts, you could, like, manually write scripts to take your configuration and re‑create it over, um, but that's also not great, I could never do that myself, and there were modules, you know, back Drupal 7, you know, features module that can do a little bit of this that's, like, configuration management light, but this is all built within Drupal Core now, this is a game‑changing, um, sort of new functionality.  So, what this does with configuration management is that instead of exporting our configuration to the database, we're now exporting our configuration to code, and what this allows us to do is we actually make some sort of a change in the dev environment or local environment or wherever it might be, we export that configuration, so that, you know, Drupal's reading the database, but we export that, all those changes we've made into code, into YAML files that are very readable and, you know, easy to parse and understand what's going on, and then we move our code from one environment to the other, we go from local to dev or we go from dev to test or test to live or whatever it might be, we deploy our code up, and then Drupal is still reading the database, but now we import our configuration, we do a comparison, and we say overwrite the configuration that exists in the database right now with what I have in my code, with what I've exported in a different environment, and this moves our configuration using code from dev to test to live, so that our work flow is much, much faster.  So, if we take a look at our work flow again, we still have dev test live.  

That part there hasn't changed, but as we're going through the development cycle, we are actively developing code, and we are exporting it, we are exporting all the configuration that's associated with those features from the database into code, and then when it comes time to actually deploy, we do that, we deploy our code, but then we import the configuration in this new environment, and then once we've tested it and ensured everything is working, we then do the same thing again, and then we can start the live cycle all over again.  Okay, this work flow, this change in how you're doing things has amazing benefits.  Some of them are listed here.  First of all, you can move your configuration with your code, with your modules.  Basically, whenever you add some new piece of functionality, you're probably adding a module or two to do whatever that functionality is, by enabling you to export your configuration, you're able to move that along with the code that's changing for adding that functionality, and this can be pretty cool, it can be great as you're doing a deployment, for everything to be self‑contained in one space.  You don't have to go looking at the database here and the code there, and it's all just contained in code.  It also means that you can version control your configuration, since we're using Git to manage our code and to deploy and move our code from one place to the other, we can actually see who changed configuration along the way.  We can even revert changes, if something wasn't supposed to change, um, how often have you fixed something on a site, only to have it be broken again.  

Well, if you're using configuration management, it's easy to see exactly who made the change, because someone had to commit that, someone had to, um, export the configuration, you know, get it up to live that way, and then this also enables you to work in a way that's a lot more agile, because you can actually rebuild your environment wherever you want, you don't have to wait for the entire life cycle to be completed, you don't have to wait for everything to get up to live before you refresh dev or local, you can rebuild dev at any point, because you are regularly exporting your configuration into code.  This would mean that, like, hey, if I'm, um, actively working on something and I know that, oh, there's this brand new content on the website, I want to get that local to make sure my code doesn't break anything, I just have to export my configuration, sync the database and files down, overwriting my local environment, and then I re‑import the configuration, and I'm right back to where I was, but with all of the new content too.  Um, this allows you to work in a way that's much, much better than just having to wait and hope that it works with all the new content or wait till it gets up to test when you can actually work against a new copy of live.  Also, you can automate things with Drush.  The Drupal shell allows you to have command line access to your Drupal site.  By using configuration management, you're able to use Drush commands to import and export your configuration along the way, and we can actually automate that.  You can write scripts that will, um, be associated with your deployments and say, you know, every time I deploy to test, automatically import my configuration.  I don't want to have to manually do that, I don't want to have to go through the UI to do that, I just want that to happen automatically, and it does, and that is wonderful.  That is yet another step that we'll be talking about in a few minutes that makes your whole entire work flow even better.  

All right, but there are some gotchas, there are some issues that are just worth noting, that are worth getting out there and making sure everyone on your team is talking about.  The first one is that config only works to and from the same site, and this was intentional.  If you check out my slides, which I will put another link into the chat window, since we, um, have had a few more people join, um, if you check out the slides, you can click the link, that'll take you to a talk from the team that made configuration management in Drupal Core, um, and this is a talk from them way back at, um, Drupal Con Austin, and they said this was an intentional choice.  When configuration is exported, it's tied to the UUID for a specific Drupal site, and, so, it's really only intended to be used for going from, you know, dev to test to live, from staging to live, you know, from local to working with the same website.  Now, if you wanted it to go, if you wanted to change features and export them and, you know, move them from one site to another, the features module is still around, it still works in Drupal 8, and that's what that module is actually intended for.  There are actually other modules, like config split, that can help to, um, you know, split configuration and have different rules and things that could help with some of that, if you're trying to do that, but the really cool thing here is that it works for everything, like you can use configuration for all of your modules, um, whether they're from Drupal Core or a third‑party module, and it all works, but it is just tied to that one site.  It is also really important along the way to communicate with your team.  

As you are importing and exporting in configuration, you are overwrite thing database with this configuration.  If you don't talk to your team about when these things are happening or that you're switching to this new work flow, it is very likely that you're going to overwrite changes that people are making in configuration.  Um, this could be true in a dev environment, if you're actively working together.  It could also be true on live, if you have people, um, like, maybe a customer of yours is empowered to make changes directly on the website, and, all of a sudden, you start using configuration management, and when you move your configuration up to live, you import it into live, they just lost all the changes and configuration that they had made, and that can be a problem.  That's something that's worth talking about.  You know, maybe, it's time to enforce configuration‑level changes happening through this development work flow also, which is another benefit, but it's just really important to make sure everyone's on the same page about when these things happen and that this is something that you're trying to implement.  All right, another gotcha is that Drupal's a little tricky in some areas.  There are some, um, some parts of Drupal that areilatal ambiguous about if they are content or are they configuration.  You know, you might have a block on your website that welcomes people to your website and invites them to sign‑up for an account, that sort of feels like configuration, like on par with the name of your website or the slogan or, you know, something like that, but you could also have a block that is, um, clearly content, something that you just add that changes, you know, from one environment to the other or something, so that's one thing.  Taxonomy is also the same sort of scenario, where you could have categorization on your website, like free tagging is something that a content creator could add themselves to any piece of content and actually create new terms on the fly, um, that's clearly content, but you could also setup taxonomy in advance to define, I don't know, like, the difference between types of articles, is this a news article, is this a press release, is this a blog post.  Um, that is clearly configuration, people aren't actively adding to that all the time.  

Um, and there are some modules to help, um, sort of as you're exporting configuration to divvy these up as well, but that is a gotcha, it is a little tricky, to export some of those things sometimes, unless you have a plan.  So, speaking of some extra modules that we want to look at today, um, well, some of these, we'll be looking at today, the first one is config direct save.  So, by default, when you export configuration from one site, it downloads a G zipped tar file to your computer, which isn't the most helpful.  I much prefer the, um, configuration when I click export, I want that to go into my code, I want it to go, like, straight into my code, whereas the default behavior of the configuration management system is I have to download the G zipped tar file and then immediately upload that back to the website for it to actually show up in the code, or I could manually, like, unzip it and put it in place and stuff, but that's frustrating and annoying.  This module, config direct save, will give us a button in the interface to one‑click sync up our, um, code with what's in the database, so it will export the database configuration into code directly without having to actually download that ourselves.  This is a pretty good module.  I use this on any site, um, any Drupal 8 site nowadays where I'm using configuration management, which is most of them now.  

Another one is configuration read‑only mode.  This is really helpful for that situation where you have customers or you have people who are potentially changing configuration in the live environment, where you don't want them to make changes that could potentially be overwritten, so you can use the configuration read‑only mode to lockdown configuration changes that will become overwritten in the future, and there are ways to customize that as well.  There is also, um, config ignore, and config ignore is a great module for ignoring certain aspects of your configuration that you do not want to go from one environment to the other.  For example, you might, um, have the develop module or the views UI that you have in dev that you don't necessarily want to be enabled on live, so you could use the config ignore module to say, you know, ignore enabling those two modules or some other aspect of configuration that is specific to my development, and then it won't accidentally end up on the live site.  Then we do also have config split, which, I admit, I do not have a whole lot of experience with.  It seems rather complicated, but it will allow you to do a lot more with, um, controlling exactly how multiple, um, scenarios work with using configuration.  All right, so with all of that out of the way, um, I have held some time today to go through a quick live demo.  We're going to do a little bit of role‑playing for the demo today, so I'm going to, um, switch into a different persona and present the role‑playing aspect of the live demo, because, you know, I didn't get to do any D & D this week, like I was planning, so I'm going to throw in some role‑playing and see if this works.  

All right, so, we have our website, so, one moment.  Hello, everyone.  I am the editor of Umami Magazine, and today, I am live‑streaming to publish a product to the website.  We thought it would be good to have more transparency, so we are going to show you how I create an article on our website so that you could see how you could create an article on your own website.  Let's begin.  So, first of all, I'm on the Umami Food Magazine website, and I need to log‑in, so I go into the log‑in screen.  Now that I'm logged into my website, many of my responsibilities include adding new articles and promoting them so that our readers are able to get what they're looking for and can make, um, great, delicious recipes and our, um, magazine is able to sell more copies and things like that, so to do this, I just need to go over to the content page, I'm going to, um, go and take a look at all the content we have in our website and then, um, this looks pretty good, I'm going to click on the add content button to create a new piece of content on here, and I would like to create an article.  The article is going to let us write a new blog post for our article section, so that it shows up there, and, you know, I really love oatmeal, so I'm going to create a new blog post all about oatmeal.  So, you should definitely eat some hearty oatmeal, because it's good for you.  All right, and then for the body, um, this is where I would, um, send it out to our content creators, we'd come up with a whole, um, slew of tips and tricks and some of the hottest new recipes and the best organic grains to use for creating your oatmeal, but for now, um, I'm going to put in just some placeholder information.  It helps that the, um, oatmeal company is one of our, um, great sponsors, so we're promoting them at the same time.  I'm going to go in now and add a new image to our website.  

We happen to have a great image of our oatmeal that's been added right here, so I'm going to click on that, and, um, one second.  I'm going to click on the new oatmeal.  That all looks good, and, you know, since I'm the editor, I have the ability to promote this or to make it go live right away.  Um, I'm going to go ahead and do that.  I'm going to say published, and I'm going to click save.  All right, I am definitely ready to eat some delicious oatmeal.  So, um, now that this is done, it automatically gets promoted to our article section of our website.  So, if I go over to the article section, I can see, hmm, well, I can definitely see the article that I created, but there's supposed to be more articles there.  Um, hmm, live demos, right?  So, let me go back over to the content page.  I can see that, yeah, there are definitely lots of articles here.  Oh, don't touch my face.  So, there are lots of articles here.  Yeah, it should definitely be showing up there.  All right, well, I'm not sure.  Well, thanks, everyone.  I'm going to go ahead and end the live‑stream at this point, and I'm going to, maybe, contact the developer, to see if they can tell me exactly why the website's not working anymore.  So, yeah, um, we'll see you next time, and then please wait while I switch into the, um, developer persona.  Hello, everyone, and welcome to the live‑stream.  I am the developer for the Umami Food Magazine, and today, our editor contacted us to say that there is some sort of a problem with the articles page, and so I went to the articles page on our live website, and, yeah, it sure looks like there's just one piece of content there.  Maybe, they deleted the content again.  Let's go check that out.  Let's go to the content section of the website, and, yeah, no, there's definitely lots of content there.  

Okay, well, um, I think this is going to call for some development of some sort, so let's actually, um, let me switch to my website and, um, I'm using Pantheon in this case, but let me just take a look at my dev site.  I'm going to go ahead and click on here to log into my dev site and just see if I can re‑create the problem on my own system.  So, here, we have a, um, website, if I go to articles and, yeah, sure enough, there is, um, just one article there.  Okay, well, let me log‑in as my account as a developer, maybe we can get to the bottom of this.  So, I definitely created this site with some help from the rest of the development team, but, you know, maybe it's a views thing.  Views is our system that we're using within Drupal Core for creating a list of content automatically, and it should be showing 6 here, but, um, let's go ahead and take a look.  I'll go in here, I'm going to click the button, click on edit view, and we're going to take a look and see what the problem could be.  All right, so, I see the problem already.  So, it says right here, um, for this page, use a specified number of items, one item.  Hmm, I wonder how that happened.  Okay, well, let's change this, we can fix it pretty quickly, if I go in here, I'm going to say paged output full pager, and I'm going to click apply, and items per page, we're supposed to be showing six, not one, so let me change that.  

All right, I'm going to click apply, and that looks good so far, and go ahead and click save, and we'll take a look at it on the development side, and I can see it's the development side, because it starts with dev, and I'm sure I'm not on the live site right now, and there we go.  Okay, this looks great.  So, we can see it all working how we expect it to.  Okay, well then, the next thing I need to do, I want to get this configuration change up to our test environment, I'd like our editor to review the work there, maybe we can run some automated tests and make sure we're not breaking something else in the process, so let's go ahead and get that going.  We'll just jump over to our website, actually, we got to go back in here, we're going to go through the Drupal UI for this, we're going to go down to configuration, and we'll find the configuration synchronization section, that's where we're going to go to get that all synced up.  It takes just a minute for it to load up.  All right, so we can definitely see that there's a change here now.  What we do not want to do is click this import all button.  If we click import all, it's going to overwrite our changes in code, I'm sorry, it's going to overwrite our changes in the database with what already exist in code, because we've exported configuration in the past, this is not the first time we've done this, but what we can do from here is actually view the difference.  We can see exactly what changed and make sure this is the change that we're expecting.  Um, yeah, so, this is actually, being familiar with views, this is already pretty similar to what I was expecting.  You see here, we went from some to full, and we went from showing one to showing six, so that looks good.  

Now, again, I get pretty frustrated sometimes with the Drupal interface.  If I go in here to export, if I want to take my configuration out of the database and into code, I have to click this button to export, and you see here, it says it's going to download it.  Whew, that's terrible.  I added the config direct save module, and it gives me this interface up here for choosing update, and if I choose update configuration, it's actually just going to save it to my code directly, I don't have to download and upload that directly, I can just do it directly from here, which is exactly what I want.  Um, so, now that I've made that change, I think this environment's ready to go.  If I jump back to my dashboard, I should be able to see a code change get fired off in here, and it should show me a dif, which is pretty helpful, so if I see here, it says one file is ready to commit, and I can see basically what I saw before, I'm changing this configuration file that's stored within sites default config, and it's created one specifically for this view that I created, so there's lots and lots of YAML files that get created every time that you export your code, there could be dozens or even hundreds of configuration files for all the different things you're working with, and I can see here, I updated it from some to full, and I updated it from one to six, with a whole bunch of additional configuration related to that pager that was added.  So, yeah, this looks like what I expect.  I'm going to go ahead and commit this.  Always good to write a good commit message.  

Now it's worth noting, if you don't have a Pantheon account, that's okay, you're probably still using your version control, your code, um, you could still write a commit that way, that's still the same, we're really just using it here today to visualize the process as you go through from one environment to the other.  This is not a Pantheon‑specific thing that we're talking about.  All right, so that is completed.  Now, I can jump over to my test.  I'm going to deploy my code up here, and I'm going to be sure to sync up my live database in the process.  This just takes a moment to finish, and then we'll be able to actually see all of the configuration changes that we made alongside all of the new content that our fine editor had created earlier.  So, let's go ahead and take a look at this as soon as it completes.  Just takes a moment.  I'm going to see if I can jump on it and see it.  Nobody likes to wait, especially when we're doing a live‑stream.  That's not what we like to see though.  Let me go to the articles page.  Yes, we only see the one article, but that's okay, we actually, um, that's okay, because we, um, haven't actually imported the configuration yet, so that's just fine.  Now, if I go in and log into this test environment, that's not good, let me go back.  It hasn't actually completed yet.  I was jumping the gun, I should have waited for it to finish.  Let me just wait for a moment for this to be completed, and then we can continue.  There we go.  It just finished, so let me jump back in again.  I'm going to visit the test environment, and let's go back to the articles page, and there we go.  Yes, we see the eat some hearty oatmeal that our fine editor created earlier.  Brand new content in this new environment, because this is a copy of our live environment, and if I go into my log‑in, oh, no, I don't need to go to the install, I need to go to the user log‑in, there's probably a caching thing happening here at the moment, let me go back and clear the cache.  Of course, live demos, right?  There we go.  

Now, let's go back.  Okay, and, um, looks like we're logged in, it looks like it worked, but it shouldn't have.  No, I'm still in the dev environment, that's why.  Okay, well, let me go back here, let me click on my test environment again, and let's go take a look at this.  Okay, so now let's go to log‑in again.  Hey, there we go.  Okay, so now, I'm going to log‑in as my developer account, and now we can actually take a look at this website from my perspective with all the new content and all of the existing configuration that we built in dev.  So, if I go back to my article section, I should see that eat some hearty oatmeal article that our editor created, that looks good.  Now, I could certainly just edit the view directly, it's a pretty simple change that Imade, to be honest, but that's not the way we do things.  We go through configuration management to do it this way, and the reason is is because, yeah, this is a pretty simple example, a pretty simple, um, demonstration that we're going through today, but if you were building out a content type with fields and views and all those different things, you're not going to want to do that again in each environment, you want to do it once in dev and export the configuration and have it move through your work flow.  So, let's actually import this configuration, and we should be able to get our team to review it.  So, we'll go over to configuration, we'll go down to configuration synchronization, and this is the case now where we actually do want to click this button here to import all.  

This is going to look at the code that we have in our configuration that we've already exported and compare it to our database, and we want to import those changes into our database, so that it actually overwrites the things that we had changed in the previous environment.  So, I could click the dif, if I want to see the dif, but I've already seen that twice, we don't need to look at that again, I'm just going to click the import all button, and that should get us all synced up and ready to go.  Takes just a moment.  I can tell that our manager is getting a little antsy here, so we need to hurry up and give him something he can look at.  Hey, already.  Wow, okay.  So, we can see here, we have the eat some hearty oatmeal article that was just created on live, we have all six articles, all of our configurations, so now, everything is working in test.  That's wonderful.  So, what we can do now is give this URL, I'm actually going to Slack over to the editor right now, he's going to take a look at that and let me know if it's good to go, and while he's doing that, I actually have some test results that ran, um, just to make sure that it's all working the way we expect it to and that there isn't any other sort of, like, performance issues.  That's actually something we started somewhat recently, otherwise, we would have caught this error before, but, hey, oh, just got a message from the editor.  Yeah, so, he is excited, he said that looks good.  A little curious why it happened in the first place, but, hey, let's ignore that and just continue on.  So, okay, he says it's good to go, so now we can continue and go back to our live environment now, and we're going to deploy.  

We're going to put in our message here, and we're going to deploy our code from test to live, and you know what?  This is actually kind of the boring part now.  We have already went through the process of importing and testing in the test environment, we know that we're not going to have any surprises in the live environment, because we've already went through all of that process once, we don't have to think about it anymore, it's just going to work this time.  So, once this is in, it's just going to take a moment to actually import into this environment, and we'll be done.  Now, I could certainly go in through the dashboard, but, you know, I could do this directly with Drush too, I don't necessarily have to log into my account, I don't have to log into, um, the live website, I could do it directly from the command line with Drush, and that would also work pretty well.  Um, you know, let's give it a try.  Let's try to do this directly with Drush and see what happens.  So, let's go ahead and get this going.  Um, wait until we're done with all the import, we don't want to have a mistake like we had earlier.  So, we are still deploying code to live, twiddling our thumbs a little bit and waiting for this to happen.  How about that game night last night, right?  That was fun.  Got to watch some people play some Red 7, got to catch some Pokemons.  Love me some Pokemons.  All right, so we're done.  So now, um, let's go to our, um, our command line interface.  So, um, this is one aspect that's a little bit more Pantheon, just because we're using, um, Pantheons tool to use Drush directly on the server, but if you're using Drush alias files and things like that, it's going to be exactly the same.  The only difference in this case is that I'm using a terminus Drush command, which is Pantheon's thing, but the Drush thing is going to be exactly the same, and then I need to say what site this is.  So, let me go out and just make sure I'm grabbing the right site, and then I'm going to choose a, um, configuration import, and that's summarized CIM.  If you just do a Drush CIM, this is going to do a configuration import, and, in this case, since we said it's in a live environment, it should import the configuration for us directly on the live environment, and that should take care of it for us without us having to actually log‑in.  Yes, I would like to import that file, synchronous configuration, looks good.  Success.  Excellent.  

Okay, let's go back and check it.  So, um, we have, um, our live environment, I'm going to go ahead and open up an incognito window, just to show that it's completely locked out and nothing fancy going on.  Go back to the articles page.  Yay, we fixed it.  All right, well, I think this concludes the live‑stream of the developer of Umami Magazine.  Thank you very much for joining us today, and I hope you have a good rest of your day, and we'll see you around.  Definitely consider attending MidCamp.  It's a great camp.

>> SPEAKER:  And I'm back.  Okay, thank you all for, um, allowing me to have a little bit of fun with the presentation today.  Like I said, I was bummed I didn't get to do any of the, um, D&D and all that stuff, so thank you very much for humoring me as I stepped through and tried something a little bit new.  So, that was the live demo.  That is what a typical development process could look like using configuration management.  It's much, much better than having to do it yourself over and over again, that's just a pain, so let's actually continue on with the presentation.  We are almost done, and I'd like to leave time for questions, but there is still one question that you might still be asking yourself, and that is who broke the page?  Who caused that particular issue to come up?  Well, I mentioned earlier that since we're using configuration management and that's in version control, we can tell who made that change.  It's actually not a very big mystery, because I made this demo, so the answer is going to be me, clearly, but, however, you can do this great command here, if you go to the directory where the configuration is saved, you can do a git log‑P and then define the specific file that you want to do, and it will, um, tell you exactly when that specific file has been changed and who did it and what commit and all that stuff.  So, let's give it a try.  I have my command line here again, let me do a quick clear.  I'm currently in the code folder for the Umami CFM.  If I just go into, um, sites default config, um, from here, if I want to do a git log‑P and then, um, something articles, um, which one is it?  Let me see.  There it is.  All right, and if I click enter, I can see that I did it back in February, debugging a problem with the articles page.  Um, so, this was something that I staged way back in February, I didn't change my git history or anything like that to cause this to be architected this way, um, I've actually given this presentation a few times, so this was one of the last times that I gave this presentation, I did this problem, I broke it, debugging a problem on the articles page, and that caused this to change from showing nine items per page to one and from many to some, and another solution that our fine Umami developer could have done would have been to do this command, to basically see exactly when this changed, like, he didn't have to fix it and then re, kind of overwrite it, he could have went back and seen, like, oh, this changed, let me go back and see when that file changed, went here and been like, yep, that shouldn't have happened, revert this commit or go back and revert the specific file even, undo the changes, and then you're right back to where you started, you don't have to, um, guess who did what, why, it's all documented here, which is pretty cool.  

All right, so, we know that mystery is now solved, we're good to go.  Now, about the CLI, the command line interface and automation, I was able to demo some of this just now using the config import, and I didn't do the config export.  Um, this is also sort of a game‑changer in its own way, because it does mean that you can cut one entire step out of your work flow, because the previous work flow with configuration management is, you know, you make a change on dev, you export configuration, you then deploy to test, you then import configuration, you deploy to live and then import configuration there, so that's actually two steps.  We could setup a script that would just run Drush import, um, Drush config import automatically after a deployment, just as part of our deployment script, and then it would just do it for us automatically, which, um, is pretty cool, once you have it setup, but, remember, this is one opportunity where you could overwrite changes that people have made in those environments, so you definitely want to talk to your team, your customer, people that could be changing things, just to make sure that, um, you're not going to be overwriting any of their changes.  So, with this new work flow, it would look a little bit something like this.  Development work flow with configuration management automated with Drush, you still have dev, test, live, of course.  You also still export your configuration, but now, as a single step, you both sync up your files in database and deploy and import your configuration.  So, once the test environment's stood up, you deploy and import at the same time, and then you don't have to think about if it's going to work, all of the things should just be done there and ready for review, which is great, because this is a required step, if you want to do automated testing, if you want fully automated testing to happen every time that you deploy, then automating the configuration import is sort of a prerequisite.  Otherwise, you're not actually testing the changes you put in there.  

So, for example, if you wanted to do a visual regression test to compare screen‑shots of live and test and make sure that they're working or that they're different, because you changed something, um, you would want to automate this step, and then it's also handy then, the last step here is to deploy our code and import config into the live environment, and then, of course, sync everything back down.  So, um, that really brings us to the end of the presentation today.  There are some more resources you can get into, if you want to learn more about this, this is really just scratching the surface and showing you what's possible, but, um, within, um, the Drupal.org, you can find the CFM guide directly, and if you, um, go to, um, my website and you grab my slides, you can click these links yourself so that you don't have to actually, um, wonder what this page is, you can just click the link in the slide directly there.  So, Drupal.org, the CFM guide is pretty solid, has a lot of great information, possibly outdated in a couple of spaces, because it's documentation, definitely consider fixing it, if you find something that's out‑of‑date, go back and improve it, if you can, make it better for everyone else.  There is also Drupalize.me has a great CFM series on their website, so it's a great video learning series for Drupal, you can subscribe and check out their CFM series, it's also very good, and then there's articles from the folks in chromatic who are in, um, Chicago area, and with the configuration management thing, you know, they actually added this great article that does a really fine job of defining the problem and then also, um, kind of fitting configuration management into the solution and figuring out, you know, how to use configuration management in a team, you know, sort of agency work flow.  So, that's a really great article to dig in deeper, and then also, the Pantheon docs, we have a great page created by, um, one of my colleagues, Dwayne McDaniel, who has the, um, the Pantheon docs configuration work flow for Drupal 8 site.  It's a really great resource also for digging deeper and learning more about configuration management.  All right, and with that, um, hey Bob, I see you're trying to get me off the stage already.  I see you having the, um‑‑

>> SPEAKER:  No.

(Laughing.) 

>> SPEAKER:  There is also a contribution day, don't forget, tomorrow, 10:00 a.m. to 4:00 p.m.  I would highly recommend, if you're here, you should be there.  It is a really great place to contribute back to Drupal, but also, if you would like to learn how to contribute back, um, there will be a couple really great classes, first one with Amy June, second one with, um, Randy Fay, I think.  The first one with Amy June is meant for folks who don't really know anything about contributing back to the community, you don't have to know code, you don't have to, um, be technical in any way whatsoever to get something out of that and to be able to give back.  With Randy Fay's talk, I think he's going to walk through installing D dev or one of the, I think it's D dev, but it's one of the local development tools that can get you up and running and, um, get that, if you do want to contribute back in a code sort of way.  So, definitely, check that out.  Should be lots of fun, lots of great opportunities, and with that, I will thank you very much for, um, the MidCamp organizers for inviting me to speak today and for, um, to Bob for hosting the room today and encouraging me to leave the stage in a timely fashion.

(Laughing.)

>> SPEAKER:  And if anyone has any questions, um, I'd be happy to jump in and take them now. 

>> SPEAKER:  David, I have a question.  Using Drush config dash export, that does not do the config direct save type of stuff, does it?

>> SPEAKER:  I think it does, um, because since you're running it from the command line, I think config direct save saves it directly from your database to your code.  Yeah.

>> SPEAKER:  Excellent.

>> SPEAKER:  All right, well, I don't see anyone else asking any questions, so I will, um, I'm already in the hash tag MidCamp 314B Slack within the MidCamp Slack, so feel free to throw stuff over there, if you, um, if you have any questions, I can handle it there.  Otherwise, hit me up on Twitter or e‑mail or whatever works best for you, and I definitely hope to see you all around the Drupal community.

>> SPEAKER:  I think at this point, can everybody hear me?

>> SPEAKER:  Yeah.

>> SPEAKER:  Okay, good.  I think at this point, everybody should un‑mute themselves and give David a great round of applause.  Thank you very much, David.

(Applause.) 

>> SPEAKER:  Very good.  Very good.

>> SPEAKER:  Thank you.