 All right, let's get started. All right, thanks for coming, everyone. This is configuration management on managed workflow. My name's Moshe Weitzman. I'm a longtime Drupal contributor, now working for Acquia as the director of research and development. My co-presenter here, Matt Cheney, is a distinguished Drupal community member for many years and found a chapter three and Pantheon. So Matt's gonna kick us off. Awesome, everyone. It's great to be here. As Moshe said, my name's Matt Cheney. I work at Pantheon. Moshe works at Acquia. Hopefully that shows you the importance and the really awesomeness that is configuration management. That I know you're all here because hopefully your favorite feature in Drupal 8 is configuration management. It's certainly mine, it's certainly Moshe's. And we think that this is gonna bring on a sort of new day for developers. It's gonna allow a lot of really awesome new things to happen in Drupal. And it's something that is, in fact, going to happen in about two weeks. That, if you saw Dries's keynote this morning, I hope you are all there. We will have an RC1 in two weeks' time. The long wait is over. We'll have that release candidate. And the next time we gather together for DrupalCon, be it in Mumbai or New Orleans, we'll be using the kind of technology and techniques that we'll be talking about in this presentation on a regular basis. And that's awesome because this is something that for sort of a little bit of throat clearing, if you had been at DrupalCon Amsterdam, I gave a similar kind of talk on configuration management and it was sort of like, hey, it's all happening then. We've updated this talk, of course, added a little Moshe magic, added some new updates. But that this is my favorite feature of Drupal 8. It's all happening and I think it's gonna create Drupal 8 as a professional and really robust content management system that fits modern development practices and lets you, me and everyone in this room build really awesome sites. So just with that, I'll sort of put that out there. This is awesome. I'm super excited about it. I hope you are too. The goal of your presentation is to make you be like, configuration management is awesome. I want to use this for all my projects right now. And it's important because configuration management solves a sort of problem that has existed in Drupal more or less since the beginning. That we have a world of content management system where you really have these two different things. On one hand, we have the configuration of the website. That's sort of the feeds and speeds that make the website as awesome as it is. It's the content types that define what kind of data we're storing, it's the image styles that define sort of how the graphics will be presented, the different fields on the data, the listings of the data, and any of the settings that you click to make Drupal do the kinds of things that you want. And this is awesome. This is actually one of the really powerful things about Drupal is that we as developers basically can click our way and work our way into building a pretty awesome site. And that's the configuration. That's done by professionals who more or less understand Drupal as part of their development process. On the other hand, we have the content of the website, the blog posts, the comments, the taxonomy terms, the user profiles. These are the things that get put in by the end users, by the people who are using the websites as editors or people who are logging in to check it out. And this is also a really good strength of Drupal. This is an interactive kind of living website. It's why a lot of folks choose Drupal as their solution. And for every individual Drupal site, we've got that configuration that's done by developers and we have that content done by end users. And now there's a little bit of gray area in the middle. Some things that are config sort of our content and vice versa, but there's a separation that I hope you all can see in this situation. The problem though, and this gets into sort of this talk around managed workflow, is that when we're building a modern website, we don't just have one version of the site that we add the content and edit the code on. We have a workflow that looks something like this. I hope this is familiar to folks in the room, that you are having a development environment, one or several, that you actually are gonna write code, you're gonna do configuration, you're gonna build the things that people want in that environment. And then you have a live environment, which is actually what people are seeing on the internet when they go to your site. And then you have a test environment in the middle that sort of looks at reviewing it before it goes live. And as you see from sort of the diagram here, the code, which is the red line, starts in dev, moves to test, and then to live. And then the content, the stuff that we want sort of to test against in work is obviously added to live and needs to go back to dev and back to test as appropriate. And this, a lot of modern sort of web platforms will do something like this for us, for the content. But when they say content, what they really mean is database, that if I'm refreshing my dev environment, that means copying the database from live to dev. The problem here is that the configuration of this site is caught up in that content store. It's in the database right now in Drupal 7. And this is sort of a problem because Drupal doesn't really care in Drupal 7 world about having the configuration be separated. Here's a bunch of tables from a Drupal 7 site. Some of the tables are configuration tables. Some are content tables. And this creates a situation where I can't just, if I want to update my dev site, I can't just take all of the stuff from live because it might overwrite a view that I have or overwrite some configuration that I've done. And this is a problem because I want to be able to do all my work in dev. I want to be able to push it to test. I want to push it to live without having to worry a lot about is it gonna work, et cetera, et cetera. And that luckily we do have some solutions to this problem. I assume most of us in the room who are interested in configuration management are probably used to using one of these two methods right now, that we have a very powerful function, hook update N that will allow us when we do updates to our site to run any amount of Drupal code that we think is appropriate. We can set configuration. We can modify values. We can do a lot of stuff. And that's really cool. That actually will in fact let us put configuration and code. I've seen some projects that have literally thousands of these kind of update hooks because they're doing a lot of updating every single time. The problem though is that hook update N it requires a lot of work. You have to write each update function yourself. You have to test it yourself. You have to use the Drupal API and it can get a little crazy. This is just an example from a module that just sets a bunch of variables. That's a pretty simple case. Doing more gets to be a little bit wild. We also have on the right features module which I personally love. I know it can get some bad raps in the community but I think it creates a solution to a problem which is features module does try to get us into this world where we can put all of the configuration that we've done on the site, the content types, the field groups, the image styles, et cetera, into code. And that's cool. There are a lot of successful Drupal projects that use features to put their configuration into code and that's cool. The problem though, and this I aside from last year but I love it so much, is that features wasn't set up to be a management solution for all your site's configuration. It was not what it was supposed to do. That it was set up to be like a tool to share packaged image gallery or slideshow or blog system or news system in your site. It was made for a Drupal distribution called Open Atrium which is fabulous but it was designed to be a way to share stuff within Atrium. But it had this opportunity to grow into something bigger because it did in fact put content types and views and stuff into code in a somewhat unified way. The problem though is that it ends up getting blamed for a lot of problems, sort of like this is Commander Worf from Star Trek, much like Worf got blamed, his father's got blamed for a lot of problems at Kinmer is that features is a contrived module. It's not a core solution. So it's constantly trying to work around what Drupal core will provide. And there's limitations in Drupal core about putting stuff in code. That Drupal core by default doesn't use UU IDs to reference various things. It uses incremental IDs. Well the problem is that if I have a dev site that has an incremental ID and a live site that has an incremental ID, they may not be the same which will cause me problems. The other thing is that features module because it's supporting a bunch of other contrived modules that all are doing that config in sort of their own way, features module sort of has to work with views, it has to work with core, it has to work with a lot of different kinds of modules to make it all work right. And it's constantly chasing those modules. The module updates, changes its format a bit, features has to change. And this creates a little bit of confusion. So if you use features you're definitely familiar with little variations of the code, sort of struggling to get it all right. I was talking to someone yesterday who was, or two days ago who had a site that didn't have features on it and they were tasked over the course of like six weeks to put it all into features. And he's a smart guy, he has a good team. They worked on it. They said they got 95% of it right into features. And I was like, oh man, well it's complicated site, a lot of things, a lot of custom stuff. But that's a real problem, that's sort of a legacy kind of problem of this config and content not being the same thing. And this causes a struggle for developers. Drupal 8 obviously is gonna be a little bit better. And I say that because, so one of the things in Klingon society is that if you're like a Klingon and you get dishonored. Like it's not just your dishonor, your dishonor extends for seven generations into your family. But I feel that with Drupal 8, in the eighth version we can be free of this sort of distinction. We can move on from that and we can have a solution for creating configuration and code that doesn't take six weeks, three sprints. That's just one button, export all the config. And sort of how we got there, how we have the system starts with Pinball Wizard, Greg Dunlap in 2011, who basically came to the Drupal 8 process and said, we need to put our configuration in code. Because Greg's a smart developer, he's worked at a lot of big Drupal companies, a lot of big Drupal projects, used features and he saw that the solutions that we had in the Drupal 7 world were inadequate. We needed a great solution to put all of the configuration in code and have it be a core solution that's there by default. That everyone has to use that makes it easy and consistent. And he got a lot of help from a lot of smart people. People like David Strauss, Alex Pott, Matthew Tift, XJM, Tim Plunkett, The Sun all came together and sort of brainstormed a lot of ideas. Like how are we gonna do this and how are we gonna make this work over the next three years? And they looked at a lot of inspirations, things like Jenkins that has a pretty cool configuration export option. And they basically said, what do we wanna do? We wanna do something fun. We wanna put all the configuration in code in a standard way. So what we need it to be, the YAML time. So I know these are camels. But the idea and sort of the crux of the Drupal 8 configuration system is that on the sort of data level, it is possible to take any value that is put into Drupal as configuration and export it out into a YAML file. And a YAML file, I'll show you it in just a second, but it's just a structured data file. It works like XML in that respect. And what's really awesome about YAML is that it also exists in just one place. That in the world of features, you can sort of have multiple features that have the same value for the same, or the same value, but like different values and it can have conflicts and overrides and stuff like that. In the case of configuration management, you have just one place that keeps all of your configuration and you have this sort of authoritative version. So here's the YAML file for the system information settings in Drupal. That you have a title for the site, Drupal 8 CMI demo, for example. That when you put that into a YAML file, that is the configuration, is the configuration, is the configuration. It uses a model called declarative configuration that says for system site name, that's the value full stop. And that's really awesome because we can now have this central place that defines all the configuration. That we can take a form like this that has all the site information. This should be familiar to developers or folks using Drupal. You have the different fields. These do different things in Drupal. They all can be represented here in this YAML file. And YAML was chosen for a lot of reasons. Symphony really likes it, which is good. But also it's pretty readable. If you compare this to features code, for example, night and day difference. This is pretty clean. It diffs really well if you look at it in a diff situation. And it's the human readable format that we like. I did a work for a simple page like something like this. But we can also have other kinds of settings in it. In fact, we have all the settings in it. Here's the blog type on the left. This is type of blog, description, this kind of thing. And then we have a field on the right. And you can sort of tell from some of these values, these are the things that you would be setting in the UI. In fact, you have files for everything in the website. This is actually just Drupal core for Drupal 8. All the different files. And you can sort of see the pattern, system.something.yaml. And these are sort of separated out for what's happening. And so this is how we store configuration in Drupal 8. It's by design, works pretty well. And it's awesome because the great thing about having your configuration in files versus a database, let's say, is that I can put this in version control. I can deploy this as part of my workflow. I can make this something that I have a commit hash for, that I can test against, that I can be engaged with. If this, the configuration works the same way as the code, as theme changes I make, as module updates I make, and stuff like that. And that's really powerful. That allows a lot of things you'll see in Moshe's demo and the benefits of what we're doing. So does that dive with people? We pumped? It's good? Okay, like that, I like that energy. I know it's morning. I know we're following Drees, which is a hard act also. But I'm tall, so I'll pull, do the best I can. Okay, so all our stuff in files, that's great. So what about the database? How do we use the database in configuration management? So this actually changed a little bit. The original design for configuration management just had the stuff in files, and that was how you did it. Problem is, reading all these files can be sort of expensive, not always best. So the way that you use the database in configuration management is that the database is sort of your run time data store. That when you sort of save values from the web form, it doesn't just write files every single time. It actually puts it into the database. It's for your run time configuration. It's only when you actually use the import, export operations that Moshe will show you that you actually then push it out to the file system. And the place where it goes in the file system is defined in settings.php. Basically, here is the directory that the configuration will live. All this stuff goes into a place you define in settings.php. By default in Drupal 8, it's been, it's put into the files directory. It's a files config underscore that has like an M time kind of security hash. And that works for the sort of minimum use case. You're just on a shared host or something that's not using version control. You can still install Drupal 8. You can still have all the files sort of be pushed out or config pushed out in the files directory totally works. But the problem is something in the files directory is typically not put in version control. We don't want to do that. So what you can do is you can take, define your sort of config directories value to say, hey, I want my config at, for example, sites default config and I'm gonna put all the config there. And then that's something that now can be put into version control and it could be set up as something to look into your managed workflow. And this is the power of configuration management. The ability to say, I'm gonna treat a click on my view the same way as I treat a custom module that I wrote. They both exist in code. They both have get hashes and they can both work through a managed workflow. So that's sort of my razzle-dazzle started off. Turn it over to Mosh to actually show you how this stuff works and then we'll go in and do a little more talking about some of the benefits, but let's go. Okay, Matt's taller than I am. Okay, so we covered some of this but there's real magic in the workflow here. Here we see, we start out with a dev site. You can export from that dev site. That will put YAML files onto your file system into the staging directory, wherever you've mapped that to in settings.php. And then over on your live site, you go ahead and do a configuration import and that's the moment when your live site starts recognizing the configuration that you've put into Git, okay? Right here. Oh, we lost our animation in our three transfers. It's important Google to have our point to there. So Chris Ruebel's got to stand on a stand. Okay, cool, let's keep going. All right, so let's try this live. I had a minor panic attack when Holly said none of your demos should be done on live during the keynote. I did plan on using Acquia Cloud for this demo. I think I'm gonna just do it locally. I was working furiously during Dries's keynote to get everything working locally. So yes, this is a talk about managed workflow, but it's also a talk doing conference Wi-Fi that's awful. So everything's gonna be local in my machine. You gotta take my word for it that this works perfectly on Pantheon, it works perfectly on Acquia Cloud, and other managed workflow environments should handle it just fine. Okay, here I am in my terminal. Let's make the prompt a little smaller. I'm on my local machine in a Drupal site called D8. The directory is called D8, you can see there at the bottom. Yeah, you hopefully can see. Is the font big enough for people? Good, okay, I get thumbs up in the back. Okay, so let's call this my development site. The other local site that I'll show you in a minute is the testing site. All right, and I'm gonna show you how to move configuration from development to testing and then testing to live would be the exact same process, okay? Okay, so the first thing that I've done as a setup is I've installed Drupal. I have done a config export of my installed Drupal, so that means my staging directory is populated with hundreds of YAML files. I have gone ahead and added that staging directory, sites default config to my Git repository. So that's now being managed by Git, okay? It's the same Git repository as the one that's managing code, okay? So the solution that we're recommending for managed workflows, there's only one repository, right? In case people weren't clear about that. Okay, okay, let's export from this site or let's make a configuration change. Okay, so we're now looking at the UI for the configuration management module in Drupal 8. This is a core module. Everyone's gonna have it. You can see three tabs here. One tab, which I'll show you, but I don't necessarily encourage you to use it, is the single export and import, but I think it's helpful to at least know about it and know what it does. So you can take any of the YAML files or any of the configurations and just get them using the UI, okay? Get all these values. If you care to, you can actually make changes on your site. I just changed that from five to 10 and I don't remember what the name of it was that I had actually. So that's not gonna work too well. Let's do it again. Contact.settings, exporting, now importing. Okay, so if you don't like the Drupal Forms, you can use other Drupal Forms. So full import and full export is closer to what we're recommending for managed workflow. What these tabs provide is you can go ahead and get all of your configuration as a tar ball, okay? It's useful. You can see it downloading there at the bottom of my screen. Now let's say if I have, like this is one way to go from production, you grab a tar ball and you take it to your dev site and you can put it in the directory, the staging directory, and commit that and now you have taken all of the stuff that was done in production and put it into your Git code. So it's a handy tab and similarly you can import one of these tar balls using the UI if you care to. The way that we hope people are gonna use this is actually to use a few Drush commands that we've added. So if you're using the latest version of Drush, Drush 8, you will find a bunch of config commands, the ones that I'm gonna show are called config export and config import, okay? Okay. I am changing the site name. Don't get too excited. The new site name for this dev site is Barca. Okay. Here we see that there's two changes about to be committed to, that are about to be overwritten in my staging directory by the config export command. One of them is a foo configuration change, which is something I did for Matt right before this example. It's okay to leave it like that. The other one is the one we just made, system.site. That is a file that exists already that's being updated, okay? So Drush is providing you a preview of what's about to happen to your staging directory. We say yes to confirm it. All of the YAML files from the runtime database got exported to the staging directory, okay? Okay, so we see that there's one modified file. Sites default config system.site.yaml, all right? So Git has told me that there's one pending modification. Let's go ahead and commit it. I didn't need to push it because that's actually the master repo in the local. Okay, so we now have made a config change and we have pushed it to Git, okay? So this is terrific. Now we go over to the next site, which is the testing site and we do a Git pull to get our new code and a config import to have that new code be recognized by the runtime, all right? I switched over to the other site, that's d8test, okay? And continuing in our terminal with Drush, that's what happens with demos that are pushed too quickly. Okay, so what I was expecting to see there is that, oh, I didn't pull, thanks. Someone was looking quizzically out there and gave me a clue. Okay, that's better. Okay, so Drush is telling me that is it okay? Do you really want this change before it goes into the runtime? And it gives me a clue that it's system.site that's being changed. Drush actually has another option for viewing the preview. You can actually see the code that's gonna go in. I'll show you that. So if I say no here, add the option dash dash preview equals diff. I get a diff, okay? With the usual unified plus minus stuff that says the site name is changing to Barca, okay? If I say yes, Drupal's working. All right, imported successfully, okay? So the site name is changing from site install to Barca, we hope. There it is, right up here, okay? So that was using two Drush commands, only two, all right? It's not a ton of things you have to learn. And we have sort of had Drush and Git doing a happy interaction here, such that we're taking that staging directory and using it as a way to move configuration through sites. All right? So that's really the demo. I'm gonna switch back to the slides. I have a little more time. I'm actually gonna do more complex just to show you something more exciting than the site name. So let's go back to our dev site. What I've done just there is I created the blog content type, okay? I've added a picture, an image field, called pick to the blog content type. So what I'm doing right now is creating a view that's showing all of the blogs, okay? So what I'm simulating here is like a whole feature that I've created on this dev site. It's a blog content type, it has an image field, it has a body field, and it has a view that shows the data, okay? If I go over to my terminal now, switch over to the dev site, I'm gonna do an export, okay? So all the work I've been doing on my dev site, I now need to export it so I can get it to get, all right? That's your next step once you're ready. I'm gonna show you a new option here, dash dash commit, all right? So if you're feeling kind of confident, you can have Drush go ahead and do the commit for you. So it's doing the Drush work and the get work for you, all right? We're still gonna get our prompt from Drush to say, is everything looking okay? And you can see all the stuff that, all the YAML files that are getting created based on that blog feature I just made, all right? I'm creating the node type, obviously, a body, a picture, more picture stuff, and then the form modes and the display modes that got created for my blog content type and final at the end, the view, all right? The configuration entity that is the view. So all that stuff is about to go into get. If I say yes, oh, it just did it, cool. I think dash dash commit means keep going. Okay, so just to show you, this is the last commit on my repo. You can see that Drush went ahead and made a nice commit message that is basically the whole preview. It put it in there, and so if people are curious about what the commit it has in it, they can go look at that commit message. And just scrolling through the commit, you see that it's a bunch of YAML. Okay, so switch to the testing site, the next site in the workflow, did a get pull this time, and now my staging directory's up to date, all right? I didn't, oh, something, it said something wrong. Untracked would be overwritten. I don't care about that file. That's okay. For now. Sites default files, HG access? Sites default config, easy for you guys. You don't have everyone looking at you. Okay, so did the pull really work or no? Now it worked. Okay, all right. So let's go ahead and import, all right? It's not sufficient to just move your code over. You have to import it to bring it into the runtime. I had an idea to do it differently this time. Okay, so here we're in the configuration UI that Drupal provides on our test site, okay? So there is a tab here called synchronize, which I didn't show before. The point of synchronize is it looks at your staging directory and sees what's different from what's in your runtime, okay? So an alternative to running config import is to just do a synchronize using the UI. So let's go ahead and try that here so you see all the different options that are provided by Dresch and by Core. You get a preview of what's coming. You can see the blog content type is coming along with the image field and the view and all that stuff. So import all is our only option. So let's go ahead and do that, hope for the best. Failed. Oh, foo is invalid. Yeah, that was a dodgy thing that I did by putting in something that has no module recognizing it. So I shouldn't have done that right before getting on here. Let's just see if Dresch config import will care. Can't do it, same error. Okay, all right, so now you have almost seen a complex feature moving from dev to stage, okay? All right, so let's go back to our slides. You get your speaker notes going when you need them. All right, hopefully the demo was cool. It was mostly cool. You even got to see me make a few mistakes which is kind of exciting. Let's go back to the top level and see what the benefits are of the configuration management on managed workflow. All right, I think this is the biggest one. There is finally accountability and auditability of what's happening with the configuration on your website, okay? We are using Git, the world's best accountability and auditability tool. It doesn't forget anything and it knows exactly who made what configuration changes, okay? Config import and config export are very scriptable operations, okay? With scriptability, we finally get the things like continuous integration, all right? It's quite easy now to just have config import and export as part of your routines and we can be testing our pull requests on our CI systems and all that kind of stuff. Since this is Git, you can roll back to a prior configuration. If something went wrong, let's say you weren't doing full testing which certainly happens, something went wrong, you can roll back to a prior configuration. I will say your mileage may vary. Simple rollbacks are pretty simple. Complex rollbacks are still hard. Configuration management solves some of our problems but not all of them. Okay, so I'll hand it over to Matt here and you'll hear about the live environment. Okay, for the demo. Yay for configuration management. So I think this is really cool. I think having a unification of Git and your configuration makes the kinds of things that most just showed and talked about possible. That we can have the continuous integration run on all the commits. We can have a lot of confidence in our development process and we can use this to do really honestly better and more awesome stuff and I think that's part of the Drupal story as we continually build tools and techniques to make bigger and better and more awesome websites for everyone. I think configuration management is part of that story. There are a couple of things that I wanna sort of point out sort of in closing before we do some questions, just so like when we show demos and sort of show the simple cases, they help show you how this kind of stuff works. You do your config and dev, you push the test, you deploy live, like that totally works. But there's this thing called the real world we live in where this isn't always the case. And this is specifically not the case when we're talking about sort of say a deployed project where we have a client or a customer or someone who wants to also make changes to the live environment. So say we have a website, customer has paid for it, has worked on it. They're like, I'm just gonna edit views in production. This is what Drupal's for, you know. And they're gonna go do a bunch of config on the live environment. If you as a developer don't realize that or don't care about that and you then go make some new stuff on dev, push it to test and import it to live, what you effectively do is blow away all their work. This is a problem. And that this is something that sort of configuration management doesn't really because it's declarative it has a hard time doing this. That if you make a commit that says the value for this is this and dev, you push it to test, you push it to live and you import, live's just gonna accept that value. It's not gonna be like, oh, like somebody changed this two days ago, what's going on? So, but there are ways to deal with this. And there's sort of three ways I'll show you of how to deal with this situation where configuration changes have happened in the live environment and also in your dev environment, what do you do? Well, first option is you can just say no. I was gonna use the slide of Nancy Reagan in the 80s her anti-drug campaign but I don't know if that works in Europe. But there is a sort of best practice, good practice that says, look, you can't make, you can't edit, you shouldn't edit your theme or your module code in live, you shouldn't edit your config either. Like just don't do it, push it through the workflow, run it through the test, like this is best. And luckily, there's a Drupal 8 module for it, a project configured only. It's being worked on this week, it's not super crazy as a module, it basically just says, hey, if you put something special in your settings file that says only have configured only, don't let people do config. So if you install this module and you like turn it on your live site and then someone goes in and tries to edit a view, it'll be like, no, no, no. You must do that in dev. And I like this approach. I actually think it's pretty good for discipline. I think that's how you should work with a website, you shouldn't do the changes in live. So that's option one, just say no, use something module like this, force the changes to go through dev. Promise, that doesn't always work for everyone. Some people do want to do config in live. Okay, okay. Option two, this also is animated, but it was from Windows, so it's not that great. So option two is you can have this process where if you're on dev and you're doing some work, you can sort of export out your config from dev and then you can sort of refresh your dev environment. So you can take the database from live and put it in your dev site and then you can do a config export again. This is sort of how it commonly works now with features and such. Like if you do have changes, you can pull it back to dev, put it into code. And whoa, and there's some commands for that. There's a really great dresh command, sequel sync, they'll bring your database back. Mysql dump of course will do that. And then as a developer, you can do this process where you can sort of like set your changes aside, bring in the live, and then put it together yourself and then you can push it up through the workflow. And I feel this is probably gonna be the most common way people handle this problem. Because the developers were used to refreshing our dev environments and we'll go push the code in that way. The problem is that we can run into some issues where we don't want to overwrite config. So if you do have something in live, it's something in dev and they're sort of both existing, you gotta be sort of careful when you do this. So there's also an option three, which is just use magic to do this, which is great. There's a new dresh command called config merge that is available at drushops config extra. And it's basically a command that says if I'm using drush and I can specify my live environment with like a drush side alias and I'm running it on my local environment, it'll actually go in and do a really cool operation. It'll say let's connect to the live site, let's export the config off the live site, let's bring it into local, let's export the config from local, and then we'll just take the two config and we'll try to merge them together. And often this will work no problem. We got a view edited on live, developers made a new content type, no conflicts. We'll just put them both in and commit them all at once. In the case where we do have some conflicts, which we will, this will bring up a visual diffing tool, Kdef3, and it'll actually say okay, like hey, the view's been changed in live and in dev, how do we wanna reconcile this? And then we can actually make the decisions we wanna make and do commits. So this is a little more advanced, you have to sort of set up the drush aliases, you have to have SSH and get access to the server. But it's something that I think is really cool. And if you're interested in sort of being using configuration management and you have changes in live and changes in dev, or for what it's worth, you have two or three developers that are all working on the same stuff, you can use drush config merge to merge another developer. She's working over here, I can take her stuff and merge it with my stuff as well. So definitely point people to check out drush config merge. Sort of works like magic, which is awesome, but it is code, you can see it as well. And hopefully one of those three options will work to handle cases with live config. The second sort of last thing that sort of can be an issue is sharing of configuration. Sharing is super cute, as my graphic suggests. And it's something that we wanna do, that part of the Drupal ethic is sharing the work you have. We want people to do cool config and share it with other people. It's part of like sharing code and such like that. The problem, or challenge, is that Drupal 8's configuration system wasn't actually designed for sharing very well. That if you take, this is the export of all the YAML files, if I install Drupal 8, do a cool config and then be like, hey, this config's awesome and I export it all out and send it to you. If you go spin up a Drupal site and import it in your site, it's gonna give you an error. It's like you can't use another site's config. True story. And there's some reasons for that. But it makes it a little bit difficult because I just can't take config from one and put it in the other very easily. But we can do it, but this is a challenge we deal with. So one option that we can do to deal with is the drush config import command has a dash dash partial option. That'll soon be available at this URL, the drush 8x8, it's only in the 8 branch which isn't yet a drush commands, but when it will be, it'll be there. And the cool thing about partial is that say I make a really awesome blog system. I've got five fields, I've got a content type, I've got a view. I could export just those pieces and I could end up with like five or six of these files. I could post them on my blog and say hey, did you like this system? Do you want it yourself? You could put those files into a directory, run drush config import dash dash partial and it'll actually pull all that stuff into your repository. And it will just work with those files. It'll just add that content type, that view. It won't be like oh, there's not all the other content types, so delete everything. Which is what Drupal would normally do. So this is a cool way to share. And I can see a world where people are tweeting and blogging and posting little config stuff they've done and let people share it that way. So that's one way to share, pretty easy to use. For one reason, I didn't even include a slide by this. You could also use the UI that Mo Show to do the import where if you have five files you could just go to single import one, two, three, four, five times. Totally possible. Second way you can share sort of config and this gets a little more of the developer world but if you write your own custom module you can actually provide new configuration defaults for the site. So you basically make a folder, a config install and you put all the ammo files for the default for your module there. So if I'm shipping a cool module that does an awesome slideshow I wanna make sure all the config is right. I can put my default config in that directory and then everybody gets it. And that's pretty cool. This can't be, I can't override existing config this way but I can add new config which is pretty awesome. So I can share my config that way. Modules can have their defaults. And that's neat. That works way better than like a variable get with like a default value that's a second argument that has to be always put in all the time. It, you just put it in this way. The limitation though of this and this is very important for if you're install a module with default config it'll only read that configuration one time. That the beginning. It'll take the default and it'll put it in. But if you get a new version of the module or maybe they change the description to make it better you won't get that new configuration. It's one time only operation. Luckily there is a module that will not make it a one time only operation. Module config update. Config update will allow you as a module maintainer to have a module with config that will get if you update the config it'll actually give you some interactive ability to then continually update that configuration. And that's pretty cool. You can have a custom module for your site that has some default config that you can keep updating which is really awesome. And this module is the foundation for coming full circle in this talk to features module which does exist for Drupal 8 is actually pretty cool. And the stuff I'd point out here is that unlike the Drupal 7 version where features have sort of its own system if you look in the menu of this thing features is actually sitting in the configuration management menu. You have synchronize which most showed single import export, full import export and features that it's working with the configuration management system. So features is a lot smaller than it is in Drupal 7 because it doesn't have to do crud operations. It doesn't need to export or import its own stuff. All features does is use the config update process to update default config and allows you to make stuff like, to make actual features. Here's my article system. Here's my new system. So if you are a person who likes features and uses it to actually share a configuration between sites this is still possible using configuration management. And in my view it's better because features doesn't have to work with all the weird exceptions just uses the config API. So a big picture before I take a few questions. I feel this is gonna change how you do development. It's gonna allow a lot of new things for developers to use. It will make things like continuous integration much easier, it'll make accountability and these other things real for your projects. And that hopefully this talk has helped you to get a little more love for configuration management and make sure that it's your favorite and best feature in Drupal 8 because it's something I believe we'll all use. And if you like what we're talking about and are more of a developer in building your own modules totally check out the great Alex Pot session tomorrow. She's gonna talk more about configuration management but he's gonna get more into the developer kind of stuff, what's a configuration entity? How do I write modules with this? How do I deal with schemas? And getting to sort of some of the more nitty gritty about using it on a site. So if you want more configuration management Alex is one of the co-maintainers of the system. He also knows a bunch of stuff so definitely check that out tomorrow. Other than that we both thank you for your attention and we'll take a couple of questions if people have it about our favorite system in Drupal 8. Thank you. Yeah, I'll kick it off then. What about when you don't want the configuration to be exactly the same on your live site on your dev side? Your server servers might have different host name. You don't want to push things actually to MailChimp whenever you touch a button in your test site and send out 20,000 newsletters. Yeah, so a couple things which Alex will also talk about is all of the configuration, all the configuration, great question also by the way, all the configuration management can be overridden in settings.php. So for example, you have like some sort of API key that's supposed to be different in test and dev than in live. You can just in the settings.php for those environments use, you know, dollar site configuration and then the values and you can override it on a per site basis using settings.php. And that's a good way if you have sort of some differences there to deal with that. Yeah, just the default settings.php in Drupal 8 actually references settings.local.php. So you're welcome to put local changes there for just that environment. Right here, I can repeat the question if you just ask him. Okay, so the question was, is there still a place for hook update N and the example was deleting a content type? Okay, well there's definitely still hook update and still exists in Drupal and you're welcome to use it for arbitrary updates, including things related to configuration if you so choose. The specific example about updates, content types. Content types are stored only in configuration. There's no other way to do it. So if it disappears from your Git directory, your staging directory and you do an import, that content type is definitely gone. And not only is it gone, anything that depended on that content type is also gone. Okay, so I didn't show this in the demo, but if you delete a content type in Drupal 8, there's a new section called configuration deletions. And it will show you that such and such field are gonna go away. That blog, if I deleted the blog content type, the view would go away. So Drupal 8's quite good at tracking dependencies like that and it will keep your Drupal site very clean should you choose to delete something. So that's something to keep in mind there. So how would you handle multi-sites? Is there like an inheritance system or like a base config folder and with all the subsites reading out just changed stuff not from the settings PHP file? Okay, good question. So the staging folder that we've selected sites default config is multi-site friendly. So each of your multi-sites will have one of those. Site slash site two slash config would be the next config folder and so on. So everyone gets their own folder in Git. I think you were starting to allude to the next level of complexity which is about how do I share my config across my multi-sites. And I don't have an answer for that one. Right now they all are different essentially. They're all different folders in your Git. I think you can do some Git ninja work to try to make them not be different or sim links so that they're not different. I think that you are in real trouble in super ninja land if you go that way. But you guys are smart so you'll figure it out. Another question then about the configuration scope. Today on our triple site seven site we use panels a lot. That's configuration I guess when you use the blocks and later I'm not really looking into it. Is it in configuration where when this blog is on this page and it's configured like this? Yeah so like the line between content configuration can get a little blurry for it. And I wouldn't propose to know exactly all of the different things. But something like the specific maybe callbacks in page manager would be configuration but maybe the individual content that we're placing in the panel maybe config or something like that. The line is a little bit arbitrage because people use Drupal in different ways. Like I've seen taxonomy terms for example be like structural parts of the site configuration that's like how it was designed. But Drupal will treat it that way. So. Yeah I just wonder we have the front page it changes about 10 times a day. They want to move it back around feature a larger article instead of a small one and if I have to say to my editors stop working on that part because we're gonna make some changes in configuration. We'll have it through testing and staging and release in about three days. They're gonna be mad at me. Yeah. Yeah I think if you want it to be auditable and testable then you put it in config and if that's actually a bad thing because of the speed of that you need to change it maybe it's not a good idea. So I think we'd really have to ask the panels folks how they're architecting panels for Drupal 8 and what is configured what isn't. I'm not too familiar with how that's going at that level anyway. Yes sir. Yeah so the question is if I change a field name for reasons I might want to change a field name how do we handle that in configuration management because this could cause some trouble. I think my first guy would be like renaming field names especially machine names is a little tricky anyway in Drupal it's not something I probably would recommend. I changed the label for sure. But this could be a situation where if you do need to change a field name that this isn't where you could use like a hook update end function because configuration management won't support that operation for you. But what you could do is as part of the update process you could do actually some readjustment as well. All the configuration management stuff that we're showing like config import all uses the configuration API and you could actually call those operations outside of the module and outside of Drush and so you could write logic that says hey get this data get this config change it in this way resave it modify the data. That's a more advanced operation but I would say you can definitely use configuration API to do all this all the stuff in your own code that we're showing in the demo as you like it. I'll just add that like in Drupal 7 the field API completely denies you the ability to rename a field name. It doesn't know how to migrate your data from one table to the other and so it just denies it. So like in Drupal 7 you're on your own if you wanna do that operation. Other than that we thank you all for coming to this talk. We're around all conference and if you have questions or questions just come up here we'll keep chatting but everybody have a fantastic DrupalCon.