 A little known fact about that song when Miley Cyrus is singing like we can't stop we won't stop like She's not talking about the LA party scene. She's actually talking about the Drupal 8 development cycle But you sooner come on Hello everyone My name is Matt Cheney. I work at the Pantheon and this session is on Drupal 8 CMI to manage workflow. So hopefully you all had a good lunch We can get in and we can get to this You know most amazing and wonderful of presentations today because I am a chaos wizard. I Particularly love Drupal. I've been doing it for about 10 years and I'm very excited actually to talk to you about Drupal 8 CMI configuration management putting your configuration in code and Really leveling up your development practice See a creation management is in fact my favorite feature in Drupal 8 I think it probably should be one of yours and I think it's like fundamentally Going to change how we all build sites in the future That it's something that I think in 2015 and beyond that's a necessary feature for any modern content management system or even software development project and hopefully today Sort of as an overview I'll really give you all a sort of understanding of what configuration management is Why sort of it got decided the way it was decided? How it works and then we're gonna 100% live demo the beta 10. We're gonna do it with Hoover to drash Don't clap yet wait till it works Because I want people to actually see see see and rock this so Anyway, let's start the story. So in the beginning of the Drupal, you know Bang sort of in a dorm room in Belgium We have this like you know explosion of websites these all the sites that we sort of all make here They're a small way or part of this sort of explosion of Drupal of Drupal stuff You know our websites are either made of stardust or of nuclear waste depending on how you think about it and That you know since that time we've had this very powerful aspect of Drupal Specifically, we have the ability in the website to like make little configuration changes and have it work differently And that's something that actually is very unique to Drupal or what is unique content management systems and gives it a lot of the power that it has Because when we talk about websites and when we talk about building websites We have these two different pillars really of stuff on the website On one hand we have the configuration of the site These are the like content types to define the you know fields on the blog post These are the image styles of how you know the dimensions or the modifications would work These are the views of our listings of contents with their various filters These are the variables and the settings and all the different things that go into it And these are things that as developers in the room. We are responsible for developing on our sites We write some code We do some configuration and we really define that site and that is that is configuration in Drupal We also on the other hand the other pillar here is we have the content of the website Really what we need to have on that website These are the actual blog posts the nodes that are created the user accounts that are set up The comments the menu items the taxonomy terms we we add these are the you know the information about it and These two things exist together in Drupal which we can talk about some of that But this is what we need to do to make a website What becomes really important and this is sort of the crux of why configuration management is important is that the Configuration that you're doing is something that you're doing as a developer You're doing it on your local machine or on your development instance And the content the stuff that the users are doing you're doing on the production site on the live website And these things become very different when we start to talk about it in the context of a managed workflow Which is also part of the advertised benefits of this talk is we'll talk about sort of using configuration management to Sort of run a really modern web development practice Because if you're not already you should all be doing some version of this for your projects You should have a development instance where you're writing and writing the code Getting the configuration right and having that experience you have a testing instance That you can actually push all that information or that configuration and code to to test it Then you have a live instance where the new contents being created and it changes ultimately end up But what you'll notice especially if you have a site you've been working on for a while Is that you also have this other loop where as more blog posts and like taxonomy terms and stuff are added to your Production site you need to pull back that information into your development environment refresh your Your refresh your sandbox so that you're working from the latest and greatest and The problem here for those that are probably familiar is that for code this works just fine I can like push some CSS changes and do it in dev push it to test push it live And I have a pretty good expectation of what it will do the problem is Configuration which is the stuff that we're going to sort of ultimately be caring most about this hour is Stuff that is actually sometimes very difficult to actually Repeatedly deploy to test and alive. I won't ask for a show of hands in the room But you know I as a developer There are you know probably had the experience of having like a legal pad of like configuration things You need to do when you go live so you push the code and then you like change some fields or modify some stuff Or turn some things on or off and that process is brittle that process is prone to human air Requires time and it also doesn't take advantage of any of the modern sort of continuous integration testing patterns A lot of which are talked about this conference. You can't run unit tests. You can't run, you know Visual CSS regressions you can't really even even truly test your end result because you don't have you have to do a human step to do your deployments and That's basically the problem configuration management is trying to solve is let's figure out that configuration that you're doing for your site And let's put that in code and let's that let that be deployed There are of course ways to do this right now in Drupal 7 when you know Drupal 6 and before Those will talk about as well But like the configuration management in Drupal 8 I think is sort of top-notch and that's sort of sort of what we're doing Because and this sort of is the crux of the problem with Drupal is that Drupal doesn't really care about that configuration content distinction on a data level These are some of the tables that Drupal site if you install it will give you You can see some of the tables are for field data some are for variables and configurations and that you know the idea of being able to sort of make some Configurations on in the database and push some tables or even part of the database to a new site is very very difficult and that's something that That all of the websites that we work on Are going to have this problem that this You know the ability to sort of cleanly export that configuration is not has not in Drupal been possible told Drupal 8 that even the sort of most advanced sites with you know using features and like extensive workflows like they still You know as Charles Darwin said like mayor, you know have the Undelicable stamp of their lowly existence, and they don't have that kind of really cool configuration management So this is now where we're sort of talking about we're talking about Doing this kind of stuff because the world we live in without configuration management The world that probably most of us on a day-to-day process working makes the idea of taking some of the Configuration that's here putting it into code pretty difficult. There are ways to do it And I don't want to under sort of cut those ways that those processes have gotten us a long way There's sort of in Drupal There's a hook update end system that a lot of you might be familiar with This is basically a function that you can put a series of functions actually in your install file for a module And every time you sort of you know push a new change with that module It'll actually run a set of them a set of like PHP logic from the Drupal bootstrap that can do stuff This is an example from the monopoly images module It does a large variable set for some information about some cropping cropping requirements And that this is something when you're talking about sort of how do you resimulate configuration? Instead of just having a legal pad with a bunch of settings are sort of things you have to do You could simulate this in PHP and some people do You can set variables obviously, but you can also like do fake form submissions or do data imports or stuff But this is a brittle process it requires every single time you want to do this to write some custom PHP code You have to like simulate certain user actions, and this is that sort of you know bespoke kind of you know Artisan thing you got to like write it yourself. You don't have any cool export tools so improving on this is sort of Features module, which I think we all know and you know mostly love. I'm a big fan of features I think it was a game changer for Drupal when it came out It's more or less a lot ushered in this world of feature driven development where people have the ability to actually you know write Modules that have feature files that have the configuration export and it's been around since 2009 It's been it's one of the most popular Drupal modules And it's honestly a requirement for any large or honestly even sort of seriously small site And it's gotten us a long way in the community, and I think that's that's really awesome But there are some problems with it that I think are sort of really where configuration management sort of picks up and Sort of solves and I'd say like the first issue with sort of features module is that it it wasn't built To be a place to store configuration and code like that wasn't it wasn't its purpose to sort of do what it is now for those that remember features module is developed to allow for a A distribution of Drupal called open atrium which is pretty fantastic to have actually packaged sort of content together Features module can make an image gallery with a bunch of stuff or it can make a you know a blog system or something It wasn't designed to export all your configuration for your site It was just designed as really sort of the packages now will do configuration and people have used it But it has a lot of limitations in terms of what's possible Specifically it's a contrived module so it doesn't have sort of core level You know sort of enforcement of any sort of practice So if you've looked at the features code It has a lot of sort of handling of like to do a view we use this system or to do you know this thing We do this system and you have to work around Work around each individual contrived module and also keep up with it contrived modules change You know exports are a little crazy people are from a panelizer module That's like has a ton of really interesting features integration, but you know you have to sort of do it sort of each one little bespoke You also have in Drupal core itself a bunch of like limitations around for example Like there isn't unique identifiers for a lot of the objects configuration objects in Drupal So you'll have you know auto incrementing values, but that becomes really difficult You know if you want to sort of associate, you know this kind of thing with that kind of thing And you know features took us pretty far, but it sort of has you know It had to sort of deal with a lot of sort of original sin of Drupal in terms of you know these these limitations But one of the things that you know commander Warfier can attest to is that you know like you in Klingon Society if you have sort of you're dishonored or you do something sort of you know a little off-color here is as a Council high council talking about the house of Doros and his father's actions at Kittimer and such But the the issue is that with Klingons you can have if you have dishonor you have the dishonor for seven generations But one of the great things with Drupal 8 is that we're now at a point where like some of this like old kind of history Can be can be redone and this brings us to Greg Dunlap So basically in 2011 when the Drupal 8 cycle was sort of kicking up Greg Dunlap and some other folks will talk about sort of got together and says look like Doing configuration with features in a sort of like hodgepodge way is not the sort of like You know big picture way we want to do this that there's a better system that we can set up and develop to store our configuration and code and so he sort of got anointed by Dries as the first Drupal 8 initiative lead to develop what became knows the configuration management initiative and There's a lot of loss or a discussion that went on to this most of this with public You can read it on groups by triple org and some other issues But the basic philosophy was let's create a system that will export all of the configuration that Drupal has in Decode and let's force it on a core Drupal core level so that all the config modules configure all the contributed modules All the the custom code people write all have to use this feature and this will allow us to have a system where we can export all the configuration to code and I think that's really cool, and he really kicked off a large sort of initiative that ended up including a lot of other people So David Strauss one of my good friends. He also was really involved in terms of the technical architecture This is his slide I I took from him and the basic idea sort of Greg and and David came up with is We're going to try to put configuration into code But let's not like reinvent the wheel on this like there are a lot of solutions of how people do Configuration to actually keep it, you know in a versionable and sort of testable way And so this is also in the world before symphony sort of became the de facto sort of Drupal Drupal direction So they were sort of looking around at XML as an initial choice the idea being we could take all the configuration could put it in XML files and We can use sort of, you know common parsing libraries But Drupal's had a problem in the past for example It's not info files where it comes up with a sort of custom format of its own does some fancy reg access But for for CMI it's like no we want to use a sort of standard Well, it's also really inspiring sort of in terms of this choice is if folks are familiar with the Jenkins system it's Helps with some continuous integration stuff But Jenkins is really cool because Jenkins has the ability to do Configuration in Jenkins in the UI and it actually will write that configuration to disk In a in what becomes a declarative way, and this is very important That you can have a web UI to actually do configuration But as soon as you hit save you've made an assumption that says this is the configuration We will have and that's something that I think is a shift to from features If you're sort of familiar how features does configuration management that Drupal 8 it's you know There's not like default values for things like you have the configuration is the configuration is the configuration And so you when you export it out you get that value it's declarative It's gonna be that value and you sort of have to go for it And so that's sort of what Jenkins does that works really well in Jenkins Once symphony sort of became the sort of marching orders for the project It was switched from X and L to yaml Yaml is a cool format. We'll be looking at it as well But there's a there's a cool parser for it in symphony student. I'm to write any of that stuff And the idea was okay. We're gonna use the yaml format We're gonna put configuration into it, and then it will be yaml time. So I know these are camels I just thought it was funny and The way that the yaml stuff works and the way the configuration management works is really simple This is a settings form in Drupal. It's the site information form We have some values we have the name of the site the slogan the email address the front page the air pages all values hit save Traditionally this would go into the database with a bunch of different serialized values or individual values Stead goes into a yaml file This is the yaml file. It's system.site.yaml. You can see name mail slogan air pages this cuff These fields save into these files, and that is how the configuration Drupal is stored No, it's sort of starting a little basic But I think this is important because every value in Drupal that you're going to have some configuration ability to deal with Is going to be represented in this kind of format Yaml is a cool format to read doesn't have a lot of extra cruft pretty straightforward looks right in a diff too We'll show that and the idea is that you know you sort of have this representation And there's of course a lot of representations, you know for this these are blog types and blog fields So you can see on the left we've got a blog content type on the on the right We have a blog body field and these are all if you sort of scan them These are all sort of you know description tax help tax. These are things that you're going to probably configure as well And we have tons of them Drupal Drupal eight ships with all these different Yeah, yeah, or the all these different configurations you export them out. You get something that looks like this These are sort of logical chunks of configuration, and you sort of have them all on the scene So that's sort of the idea Configuration in the ammo not too crazy declarative it configuration to what's in the ammo file is what the value is There's a lot of magic here. How do we work with it? Let's talk about that for four ways. I'll show To actually use this system to actually set values So first option we're just going to take a single configuration change basic title change and Get that and remember we're always working in a managed workflow setting So we have a dev environment in a live environment here So we're on dev We have a module in configuration management. I'll show this in the demo as well, but it's called configuration manager You can go to admin config development configuration and get it and you have an option here. Yeah single export Single single item export export simple configuration and let's go just get that same Same yaml file and right here in the UI you hit export It'll give you you know the title of your site with all this information So if you've changed your title and then you go export you get that yaml file that we have and that's on your dev site So you can have it all look look on your dev site pretty fun You have that file you can copy down your computer copy and paste it and then if you go to the live site And you want to actually do it you go again to that single single import option go to import You type the system site yaml file paste the configuration to hit import It asks you to confirm it, and then you actually have that value saved in the system So pretty simple export out on the dev site Copy it into the live site hit save confirm you now have that value changed and then the system title would be changed and this is helpful because You have structured data that you're working with there's not a lot of room for error There's a lot of testability of this we'll get more advanced in terms of how to use this But the idea is you don't have to like remember to change the title of this stuff You just have these files and you do it pretty straightforward That's for a single file so it's option to Say we want to take all the all the configuration This I think might be one of the more popular ways that we do configuration management Ideas that I've done a dev site. I've done a lot of work. I've changed a bunch of settings I've done a bunch of different configuration now. I'm ready to actually export it out So I go back into configuration manager module. I hit export And it gives me a tar ball. This has all my configuration in it that has all those files We showed earlier and I can take that tar ball go to my live site Hit choose file and upload It'll like go through and actually now give me more information about what's changed. Oh look We've got a blog content type. We have a blog body field. We've maybe changed the site name and Next each of the different operations you see this view differences button That'll actually show us sort of a distinction So oh look the title has been changed from this to that and you can start to see sort of that Configuration that you were doing in the UI Actually sort of be reflected as a change and if you went in and hit that import button You'll upload all the sites all the stuff be able to import it takes a hot second And then you actually import it and you've taken the full configuration on dev and pushes it to live And that's pretty cool Because now you have like this ability to have your live site have exactly the same configuration as your dev site You didn't have to like go through a like a checkbox list of things to do You just had to go export and import now. I thought that's pretty cool Way three So of course you can use drush for all these operations the UI stuff I think is the easiest just to orient but as we go deeper down, you know Suddenly you can do a lot of some on the command line so odd Content management has a bunch of different drush commands. We'll talk about a few of them can think get pretty obvious one Basically, we can specify that system site say we want the name value and drush will actually kick us out That a specific value so it'll say okay the value of site is this and that's sort of how you would interact It's sort of on a drush level to get the data so you can take that string Go on your live site. You see drush site alive and say let me go config set another another value And actually set those values And you have this ability using drush take a single value get it from one set it to the other He's enough last sort of thing before we get into some crazy stuff. You can also use drush to do the whole thing I could take drush and run of the option called config export that's going to do that whole dump But instead of like giving me a tar ball that I have to manage It's actually going to go and dump that onto the file system One of the things that you do when you set up sort of Drupal is you can define what directory you want for the configuration management Like file the ammo files to live by default It's set up in the files directory because that's writable in Drupal and you can do it there Not you know it's sort of its default behavior, but you can also define other places So in this case I've defined sites default config is where the config lives That's just a value in the settings dot PHP when I hit a drush export it exports all that stuff in the sites default config What becomes cool is because that's in my like version control route when I actually do a commit I can actually do a full drug get commit and take all that configuration and push it into You know commit hash. There's one right there. I can then deploy that code to live and Then run a config import command to actually pull it all in you'll see I'll get some information there about what's going on And that this is the workflow this last one that I think is really you know from a programmatic level sort of what you would end up Doing on a really regular basis So let's talk. Where's the magic? It's in the workflow dev exports YAML YAML exists goes into import import goes to live site And we all you know party time Okay, all right now we're gonna do the demo I'm demoing off the latest version of a droop late beta 10, which is actually pretty nice And I'm gonna show a few different things So first thing I've done. Oh, let's get First thing I've done is I saw I've I've done it. I've set up a site on the pantheon, which is Which has dev test in live a little bigger so we can see Okay, cool, and the only thing I've done is I've taken that latest version of Drupal and I've got ahead and installed it So we have a dev a dev instance test instance live instance and I've also got ahead and ran that drush config export command once just so we actually have all those YAML files So I can actually go in and you know, you know, you'll see this is basically all the YAML files For the entire configuration of the site and I you know only did the install So just have like the site name and some other stuff off the default And I've logged into each one this kind of thing So first thing I can just show you Just from a sort of browse around standpoint is the actual configuration management the stuff I was showing all lives in this module called configuration management And if you go to it, you'll see the kind of stuff we saw before single export full export and then synchronize and The single export sort of I think the slides do pretty well. You can just you know, go to a simple kind of thing. Oh Pick a kind of pick the kind of thing you want from export and You can get you know any kind of values that you want Depending on what oh what what the settings is and so that'll be helpful for a little individual thing But what we're really caring about here is that is that full full export So if I want to go ahead and get that tar ball looks like this I grab it and it'll generate it and then let me save it. Okay, but let's do cool Let's do some really cool stuff. So here's the sort of scenario I've got this dev site that I'm working on and I'm trying to build, you know, make some changes to the site so We'll first just go in and we'll just make the basic change. We'll make that site Information change instead of calling it my great Drupal con la site. I'll say my great CMI Drupal con la site And I'll go ahead and hit save and this is a configuration This is now created, you know that value and then what I can do is Jump it on my command line. I Have my drush site set up. So you'll see I Can go ahead and this is doing on the dev site and I can run This command called config export Which is what will actually export on all the config so it's going to take all that stuff Tell me oh look system site has an update to it great I'll go ahead and hit export and then a well-banned surprise if I go up here We've now seen sites default config system site yaml has been changed if I go look at it You'll see old value new value and I can actually go ahead and Do a quick commit here, you know changing the title and what's really great about this is that like now This is going to go ahead and actually make that a full git commit It'll have a git hash and that as a developer you can sort of start to see you know What I might be interested in doing is not just doing config changes although those are powerful But I'm also might be interested in writing some other code to so I can do some count configuration changes I can write some module code some theme code I can do it all in one commit and that's like you know and that's this commit that has this information So when I do a deployment now go to my test environment, I'll do a deploy And I actually push that code It's going to move that from the dev environment to the test environment And now I have in that directory sites default config and updated yaml file. It's just pretty cool And now once I do that and I'll go back to my test environment I have a couple things I can do so looks like it's deployed Okay, cool If I go back to my test environment and See you see at the top it says test just because we're in the test environment and I go to configuration And I go down to caught configuration management I actually will now use this a synchronized tab and this synchronized tab is basically saying okay Let's go scan everything in that the yaml files, and let's see anything that like you know Looks like a change from what we had before Let's let people see the change right here, and then if we want to actually do the import We'll go ahead and just hit import and it'll do it right there so it'll go import that in cross their fingers looks like it's successful and Not that I necessarily can get to you But now I have you know changed the title for my great CMI Drupal la site Which is really cool and as you guess if I went to live and do a deploy there It'll work basically the same way and this is cool because now instead of going just beyond the yaml files I've you know actually been able to think it's automated Okay, we're all good now. Let's go. Let's go even crazier. Yeah it is It is this it is sort of like doing a features revert So the the process here is you're basically telling Drupal. Hey, there's new config go push that in it be like doing a features Revert, but it's more because it's more declarative. It's sort of like it's almost like installing a new feature And I have you telling to override everything So now let's now we can do a more exam case I can go to my dev site and I'll maybe go ahead and hit like You know create a quick content type, so I'll go into content type And I'll go ahead and add that blog post and I'll do you know blog post Oh burst of genius And I'll go save that Because configuration isn't just like little variables like it can be full on you know content types and fields I could go add an image field if I wanted as well. I'll go show you that one and so Go image You know picture and go ahead and save and so I'll go go create that kind of stuff hit field settings and tell you what maybe Let's even go do just for fun because views is in Drupal 8 core. She's pretty awesome I'll go ahead and add a new view for the blogs and call blogs and we'll just show all of all of type type blog and we'll go save and exit that and With a little bit of work We now have got that view. We've got that content type and If you were to go back to that dev site and run config export again It's gonna go and detect. Hey, we got some fields. We got this view this kind of stuff And it'll go it'll go drop that in and we basically can go through that same process Here's now the eight files changed different yaml files, you know my great blog system And what you would see here is that like not only you have this configuration But I could also add, you know, maybe some CSS styles for the for the blog system Or I could add, you know, some other modules that are dependent or whatever and I can get one really solid git commit That has that configuration and that code that's necessary to really put it all together And that's something I could test against I could do visual regression testing I could run unit tests against I could run any battery of tests on just that commit And now I've taken this entirely out of the realm of any clicking I just have the export and then I get commit and it's good to go So we'll go ahead and to play that And that's an important difference. I think like features you'd used to like take little features and like, you know Put it in little box here in this case. You just dump everything there. Just cool. Yeah Yeah, so well one thing that exists is the ammo files are sort of in this in this sort of like Storage kind of staging directory when he actually for the runtime it doesn't load all the files every single time It actually does all that cash good cash is that information and then that's what it uses during the runtime for performance reasons Which are pretty cool. Yeah, I have a slide in that later And then Drush commands. Yeah. Oh, yeah Well, so one thing that's I think really cool about configuration management I'll get a little bit of this a little bit later But that because you have declarative configuration you don't necessarily have the same ordering constraints of other stuff You don't have to have one thing turned on before another so you could turn on a module have the configuration for it But because the configuration is like a clean yaml file It's not like you have to have all that runtime there in order to run the import process and stuff like that So you actually get some get some proof. Yeah Yeah, yeah, so great. It's a great point just for the recording the um So one of the things that this this is absolutely changes where I think a couple of folks have picked up on is that We're talking about full config export So people are gonna develop and they're gonna dump a ton of config every time because if you're doing config export I mean obviously a stuff I changed there But a lot of developers change a lot of things a lot of the time and I think there's some strategies to deal with that We can be chat a bit more about but I think you know, that's that's a limitation I think things like developer settings I think there'll be ways to exempt some of this and there's some override stuff. I'll show in a minute But you all I think get the idea on the workflow sort of makes sense A couple other things just I want it that are sort of related configure management are really helpful The first is that like Drupal and this is new with beta 10 it actually has a lot of smarts with the config with the dependencies So I create even I made a blog type and I add that blog type and added it with a view on it But if I was to go in Under my content type and I was to do like let me go remove that blog Blog post content type There's a section here called configuration deletions that exists and it actually will tell me look yo if you're removing a content type called blog like you're gonna need to lose those fields also and You're gonna need to actually lose that view because you can't have a view of blogs without a blog content type What also becomes really cool is if I had actually gone in and added let's say an actual blog burst a genius So we'll go do you know my great post You know my great blog post for LA and if I actually have a full-on blog post like this and I try to go back and do the lesion similar to Drupal 7, you know Hey, it's used by one piece of content. We can't do the lesion and understanding those relationships between things is really important Because that means that like it's harder to blow away or hurt your sight with some exports Okay, well, so that's the workflow sort of you know Did that make sense to people in terms of just getting deployments of the two basic to advanced? But this is what you're gonna do as developers. You're gonna create these situations Where you're doing commits with the configuration and then you can do deployments with that kind of stuff All right, let's get in some even more cool stuff So that's that that's basically the demo you want to try this out install Drupal 8 you can get a Panpan we have a Drupal 8 like sandbox you can spit up in a few minutes a lot of other people have that and you can Install yourself definitely try off the beta 10 a lot of energy here So hopefully it's good Otherwise I've you know Blame factors beyond my control. Okay, so let's talk about some more getting some of the more development patterns Some of the more sort of advanced kind of topics because I think this is going to be relevant to our sort of day-to-day here First up is that as developers things like variable get and variable set are no longer in Drupal 8 Those aren't things that you're going to use as a developer instead. You've got this you know configuration API Drupal Drupal 8 has four four APIs of this sort configuration state cash and then the Which department yeah, thank you Configuration API is like this you can do that you call get again on a particular valuable So system site name for see how that pairs up and get this value You can also go ahead and set as well so you can set a name to something else it's safe This is the pattern if you're doing variable get and variable set that you're going to end up using So that's a pretty cool way if you're doing a module or you're writing some code You need to access or set stuff you do it this way Sometimes you've got values that you don't necessarily want into in the configuration like stuff like like brant was saying if you have a developer And you want to have a development API key for your Google analytics But you don't necessarily want that to be part of the configuration deploy to production You can use an API called state API that basically sets things like last time as cron has run or developer API keys Or settings that you need to run the site But aren't necessarily going to want to have in version control as part of what you deploy And so you can do get and sets for particular environments without having that effect the larger sort of configuration stuff So you'll probably end up doing this a little bit if you're trying to do some stuff That isn't necessarily configuration for deployment, but you need it in a particular environment Same thing if you're looking to do some overrides of configuration So like in settings dot PHP right now you can override Drupal variables if you want Configuration management sort of takes that same approach And so if you wanted for example to put your site into maintenance mode and set a message You don't necessarily need to have that message be saved and dev and pushed up You could just change the studies that PHP file and it would override that same for any other use case And this could be situations for if I'm a developer and I have some develop settings I could drop that all into settings dot PHP and use it that way and then mine can be different than my friend Who's also working on the site? Yeah? Yes Yeah, if you don't like gifts you could you know have your image field settings You know not let that kind of a file be uploaded or whatever you want that you have full access to the different configuration Management stores, and that's pretty cool because then you can have very localized localized kind of kind of I mean it depends on you. I mean it says that PHP you have a lot of like a lot of power like that But you know just if you want to just have the module name We'd have to do it slightly differently, but you could have settings for the modules that you would override and have it really clean me right here You could you could do that to be on module. There's the module name all other versions module name module disable That you could call and that would you could sort of force that on to say every time I run this I want this module name will no problem You also have the ability to modify different languages for developers You have like a multilingual site the yaml files allow for the same sort of it and pretext prefects So you can have you know, hey, we've got like some Dutch language or we've got some You know Hungarian language and because you're going to have like a site title or the labels and different languages It supports all this all this pretty cleanly. She's pretty excellent Few limitations, okay That's sort of the developer kind of stuff you might end up using some limitations and some other modules that we can Go and then we get into a little more QA the last like you know five ten minutes of this thing So question from before so one of the problems you're going to run into if you start to do this for real with other People is that you end up actually having a lot of different git branches and developers that are changing and doing stuff at once Like I can give you a pretty clean demo with like I'm gonna add a blog post and push it from dev to test because I'm the Only one working on the site and it's a pretty simple change But what happens when I'm making a blog system over here and my friend She's got like you know a whole different forum system and like somebody else is doing some other you know thing on the site We're all committing config in different ways. We all have different feature branches We're working from and we're all trying to sort of you know push up the latest and greatest We don't want to override our stuff right we don't want to say Oh, I'm gonna drop all my config on my dev site and force that as the issue because I might not have made a config Change that somebody else made and because we have declarative configuration if I'm saying oh well, you know Let's like you know dump out my config if it has a different value it'll start to override So the answer to this With mr. Greg Anderson has created a drush command called config merge Which is currently in drush 7 RC 2 to check this out and basically what this does is this says look if I'm working With CMI and say my local computer and I'm like you know wanting to actually like commit my work Instead of just doing the export and pushing up that code I can run config merge and I can tell it the targets that I'm interested in sort of like merging So I could say okay. I've got my local sandbox where I'm working on I'm gonna take that local sandbox run config merge It's actually gonna get that export from the dev site or the life So whatever pull it down into my local things merge the changes together And then as one commit sort of push it right back up And that this is the kind of thing when I'm actually interacting with feature branches and different developers Then I'm gonna do on the regular that like I'm very interested is when I actually do that merge to be able to kick You know all the different features together and give that clean commit that represents the most up-to-date configuration And so you can get this it's in drush 7 RC 2 so new features and different kind of support for you know More remotes and this kind of stuff that's coming, but this is something I feel as developers We're gonna end up for using configuration management use a lot You also have this problem sort of in terms of limitations that Drupal 8 configuration management system was designed to export all the config for just one site That it's not actually very good or very well designed for doing you know sharing configuration between sites You are gonna Drupal distribution or you have like you want to make it like a press room feature You're gonna share with all of your you know all the sites you're making for your organization It doesn't really let you do this you're just getting a big export of all the configuration So luckily there's gonna be a features for Drupal 8 that's gonna directly address this issue Features is something obviously that before was used to do that code code saving But in Drupal 8 features actually gets to do really what it was designed to do It doesn't have to deal with the setting and and getting a values It's just gonna do packaging for features. This is what it looks like in Drupal 8 There already is a version of it out you can play around with it if you're really interested in it I would definitely build on Thursday to check out mr. Potter's talk and he'll go for to show you the whole thing and talk all about it Couple other things so this is Drupal 8 obviously as we talked about there is a version for Drupal 7 if you're interested in playing with it It's not exactly the same and I definitely recommend using the dev branch to this module But Drupal org such project configuration will let you try some of these same patterns in Drupal 7 I'm not sure I recommend you do this Nestle for production production sites initially But I if you're looking to check it out and you're working on a Drupal 7 project and you want to sort of see how it Would work this will get you a lot of those same patterns with the different, you know, just see in my data stores Something else that sort of becomes an issue is trackability of your of your changes So the demo I showed you have to formally go do that config export every time you want to actually export your stuff And sometimes it makes sense because you can like logically group your features But if you are very interested in having very granular auditing of the difference of different stuff It's a Drupal module called config tools that will actually set it up to do a git commit every time you make a config change So you can get a pretty clean record of when and how and allow for sort of reversions if you need it One thing that's my favorite one So one other issue that you run into is I showed you the dev workflow dev test live That's totally a best practice also not necessarily something you have to do that all the config changes I was doing on dev you could have done in live if you have a particular customer or client That's like sort of a little bit overexcited they may go in and do those those config changes on the production server and You know cause a little bit of mess to the project really great module is something called configuration read-only mode Doesn't do a whole lot It just tells you not to do any config changes on the live environment And that's something that I think would be a totally good best practice to use Hey, look you shouldn't do config on the audio production sites. You should only do it in dev So we're just gonna force that to not be the case You don't always want that but in some cases you do Some module for that Glass up of things Sometimes you know sort of working with features. This is the dependency of features you if you have modules that provide their own Configurations you can get a little bit of confusion around that it's a configuration update manager That'll actually look and sort of say hey install this module had these configuration values The new version maybe has changed some of them How do I handle that and this module does a lot of work work with that? So this is the cool one to have features will require it so it will work pretty well like that It's also sort of the case if you're doing a lot of development and you're trying to get out a lot of the different configurations that you know Sort of getting a specific Kind of configuration export out could be a little tricky, especially doing a lot of development Chicks maintains this configuration development module that does a lot of quick exporting So if you're a module developer and you try to develop this stuff and want to work with it This makes it really easy But let's just talk big picture like this is configuration management is really the kind of technology and techniques That I think we'll pretty much all use in this room for you know for pretty much the rest of our like web development life That you know having configuration values in the database that's things that we can't version control We can't test against we have to like replicate on a like like production site It's just it's that's not sort of where this industry is going and I think it was really awesome that we got you know Configuration management into Drupal 8 is one of the first things that got done It's one of the things a lot of people are really excited about using it is my favorite feature And I think that um, you know, I invite sort of everyone to sort of try it out You know check out the different you know config modules and watch the space like the core system for configuration management It's pretty powerful, but there's a lot of contrib modules and other practices that are coming But with that I think you know definitely hopefully you get a little bit excited about configuration management Sort of see how it works, but other than that I'll take some questions And thank you all for your attention and time to watch this presentation So yeah, I guess there's the mic Can you exclude specific sections of conflict for export so they don't get exported anymore? Yes, the question is oh you have the mic um No, actually that's I mean there are ways you could do that But that like the general practice is that you know you're gonna want to export export out You know the all this after all the stuff for the site one of the techniques that I have seen is that you know When you do the export you're right You might have done some other configuration that you didn't want to do in the get commit And that's something you can actually use get to sort of handle that you can sort of you know Sort of add only those YAML files when you do the export that um that exists Although it wouldn't surprise me if that if you either the export function could be extended with some variable or some some parameters to have some Restrictions I think you know it's one of the things when I demo it. It's pretty clear like I made this change Obviously I want that to go but in the real world You're doing a lot of different changes and you have to be sort of careful And luckily when you do the export you can do some management and get to only deploy the stuff you want The main reason is because features it was used as a site config was meant as packaging specific sections of config That you can share between sites. Yeah, if you want to do that or you just have one specific content type You want to share across three different sites. You have to be able to exclude that from a site specific configuration export Yeah, that's well I mean that's this is the distinction that's that's very important from features to CMI is that in features You do have very you're sort of you're selecting the kinds of stuff you want to export You sort of have an opt-in kind of strategy for configuration export with with configuration management in Drupal 8 you assume You need all the configurations you do that sort of full export and you can play some games with like making sure you're just getting Out the stuff you want but the base assumption is that all the configuration will be exported for that site and will exist in those YAML files And that's what will be important the site that it's a sort of different model But I think it'll work better for the kinds of like sites We're building you know for a single site to do it with respect to features Definitely check Mike's session on Thursday and he'll talk about using CMI and actually share features across sites. It's pretty cool. Okay. Thank you Yeah Our blocks considered content or config and CMI Configure the box and configure our configuration They're their content. No, the settings are configuration. Oh, are they okay? So you can you can have for example, you could change the blocks to the blocks on like your page You could push that in the CMI and you can do deployment for that. Okay Yeah, we've had some experiences with clients updating blocks on live having to regenerate the feature from live So we've oh, yeah, because like the ordering and yeah crazy Yeah, that's one of the things why I think that read only configuration module is pretty cool You know sometimes clients do want to do some configuration changes But try to lock some that downs helpful because you can move stuff around for the weird ways Yeah Install profiles is there just a directory where I dump the configuration in or do I have to register? Somehow what I have In terms of configuration for install 10. Yeah, so great question. So install profiles. There's actually a There's like a framework for doing this where if you're making install profile You can actually just dump your CMI or your configuration from an existing site Into a directory and then there's some logic that will actually import that all in as part of the install profile installation And so like to actually make an install profile ends up being pretty easy because you just configure the site the way You want you export all the config into your profile directory and then you set it up So when you do an install for that installation profile, it'll actually dump in all the config into the database So you just just dump it in yeah wholesale Whole sales and I could see some picked up automatically. Yeah, well, you have to put some watch to do it But yeah, you pick up the whole thing automatically And what you could do on top of this is actually then have some additional Configuration screens to like change things like the title or some of the other stuff But I think it'll make it a lot easier to make certain kinds of distributions With with CMI because you don't have to worry about how I have features all work the right way You just build the site the way you want you can clone it sort of in mass, which I think will be pretty cool Couple more yeah, so when you change a setting from the UI it goes on and change the YAML file Once you do the export yeah, yeah So what happens if you change the YAML file then you have to trigger address to pick it up Yeah, so if you change the YAML file directly, which I wouldn't recommend but you could do You then have to either go into configuration management and go to synchronize page Or run the drush config import command and that'll then scan those YAML files Detect a difference and then push that difference up here And you talk about using kernel events to see what YAML files are changing and synchronize on its own or anything like that I mean you wouldn't need to drush drush will give you a pretty good set of Output of what's changed and what's being imported. Okay. Thank you Yeah, last question. Hey Matt So It's actually similar to the install profile, but but slightly different. I'm wondering if there is any concept yet of Increasing specificity of locations for config and the reason I'm asking that is in the install case If you're using a distribution and something changes upstream what you mentioned doesn't really work Because that's just a single point in time You do an initial dump and then you're on your own from there that changes upstream. You don't get that Unless there was some sort of a well, you know I'm more specific now and now my my configs now take over whatever it was You know and you can see some diff etc. Yeah Yeah, I would say I don't have a great answer for that honestly I think one of the things and this may be a good thing to close on is that like You know that the kind of specificity I think that you're talking about that I think people will need Are things where there's like there's some options to build additional contrived space kind of work and some additional patterns That like this is all really new like there's not a ton of Drupal 8 sites There's not a ton of people who have really developed big sites with this and that one of the things I think sort of in terms of watching the space is once configuration management because more more wide-stream The Drupal community has a great amount of like customization in different patterns and I think the stuff that we think now the house is going to be used is something that might very well change and You know might be different adapted in different ways And I think one of the great things about Drupal 8 with semantic versioning is that a lot of this ton of stuff can be updated improved in Drupal 8.1 So I'd say in general configuration management start learning start working with it see the different patterns and you know When you run a use cases that are sort of new start posting about it talking about it Because I think there's a lot of flexibility as Drupal does to do this kind of stuff right both in simver and then contrived potential That's right. Well, thanks. Yeah, but otherwise everyone have a fantastic Drupal con and uh