 So this is configuration management in Drupal 7. Just had somebody come up and ask me what this presentation's about. So if you haven't read the intro, we're going to be talking about stuff that you can do in Drupal 7 before you get to Drupal 8 with CMI. OK, so some of the stuff we're going to cover, first cover the state of where we are right now, some of the stuff that we can do in D7 for exportables and cover some stuff on the features module, configuration module, and some of the where we're going to go. We're going to have time for questions and answers. First, a little bit about me. My name is Alan Doucette. Dragonwise on B.0 and IRC and everywhere else, pretty much everywhere. I work at a company called Riot Games. Build a little game called League of Legends. Anybody heard of League of Legends? Whoa, that was more than I thought. Well, I got swag if you guys want. Free skin codes, everything, because you can talk to me afterwards. Besides that, I've been a Drupal developer for over five years, freelancing as well as working with enterprises and other companies building great Drupal stuff. I am a maintainer of several modules on Drupal.org. The most popular of which is better formats. This is what most people usually think of when they think of configuration management in Drupal. I usually term it controlled chaos, because you can do it. It is possible. You can do things. But you've got to know exactly what's going on and how to do it, and it's a very delicate area. It's not a defined process really well. You've got to really do a lot of stuff on your own. So we're going to try to make that better, obviously. D8 is moving a big way towards that. Hopefully, you caught a few sessions already on CMI, maybe Greg's talk on the state of it or any of the other ones. So what are we in Drupal 7 right now? Right now, we have exportables as our biggest problem. Unfortunately, Drupal uses a lot of unique IDs inside the database, which are different from your dev, your live, your staging, and many other things that cause problems. So not everything is very easily exported. But because we need to, there have been ways around that. So there's been a lot of work in the contrib space to make this possible from C tools, their exportable system, to features, and it's kind of faux exportable system. And many other models that kind of hook into different places and try to give you access to be able to export things out to code. Unfortunately, that's a really hard area to solve that everything has to be able to support everywhere else. It's really hard. So we're probably not going to change that in 7 from what the existing state of it is today, where we have C tools, exports, and many other ways of exporting things. That's probably going to have to wait till D8. But lots of other things, we can make better. So we're going to talk about those a lot. We're going to cover a little bit on the features module. If you don't know about that, you'll learn about that here. And a newer module, many of you may not have heard, is a configuration module where we're trying to basically backport a lot as much of the D8CMI stuff back to Drupal 7. So in the next two or three years before you use Drupal 8, you can actually use as much of that as possible. There are a lot of other things out there that you can do. There are other models out there like patterns, some other stuff that's not very well used. I think last time I looked, patterns had like 10 installs on the project page. But there's also Drush. There's been a wave. People just use simply Drush with their C-Tooled exports, just simply on the command line. In my personal favorite, how many people still do something on their local, write it down on a piece of paper, and then do it on live? Yes, see? Don't mess up what works, right? So we're not going to talk about that today, even though that is configuration management. So what can you export in Drupal 7? You know, lots of things between, like I said, C-Tools exports, and Foexports, and lots of other things. We can export node types, fields, some, you know, text formats, image styles, when you link taxonomy permissions, roles, and core itself. So most of the stuff in core, you can export in one way or another. Now, that doesn't mean that it's really easily done, and a lot of that stuff is, there's a lot of gray area between what's configuration and what's not configuration, so you have to be careful. A lot of things you want one way on your Dev site and another way, a completely different way on your live site, so even though it is exportable, you don't necessarily want to export it and send it to your live site and turn something on or off that you have on your Dev site. So areas in there are a little bit gray, but most of the stuff in there, we have some way to export in there. Exportals in Dribble 7 and Trib, very similar. Not everything is, because a module has to support it. So there's a lot of stuff out there that doesn't, but most of the major things that we do today do have support for some sort of exportable stuff, so especially views, the file entities and the stuff around that. The settings around file entities, Relation, Lajen, many other popular modules all have some way to export something, and if they don't, it's probably fairly easy to get some way to export that stuff out. So the state of that stuff, like I said, we can't really change a lot of it. It's really, really, really hard, because we're going to have to have a large case of adoption. We already have adoption with all these modules in all these systems, like Ctools, exports, and many other things. So while we could write a brand new system in D7 to have everybody support it, by the time everybody supported it, D8 probably would be out and being used by everybody. So that's probably last on our list to try to make better in D7. Who in here's used features? All right, whoa, whoa, whoa, whoa, yeah. All right, so that's basically everybody. So you know this screen, a little hard to see, but you create a feature module, you say, hey, give me this piece of configuration, that piece of configuration, give it a name, hit the download button, and it gives you a little module that you install on your site, and you check it on into features. How many of you ever turn those features off? A lot less, right? Guess what? You're not using features as a feature, you're using it as configuration management. That's one of the areas that we're trying to solve and make better a little bit in D7, is that features itself has kind of a double conflicting use case. It's used for all of these things. How many of you have used one of these? Is there distributions in Drupal? Distributions started with the most popular there in the middle, Open Atrium by DevSeed, and they actually created features around that. And it's really, I think, highlights in Open Atrium what a feature really is intended to be used for. One use case of it, at least. And that use case is, hey, you want to be able to turn things on and off in different spaces, and I own that, and the module owns the code, you're able to, when it turns off, menu items go away, views go away, lots of things go on and off in different things like that. And it works really great for these things. When you write a distribution, that's what you want. You're writing something for general public, generally. You don't know what features they want. You don't know what they have, so you write a whole bunch of stuff, and you let people write additional features, and you turn it off on and off. It's the same kind of model Drupal has, right? You have modules, and you turn on and off the pieces you do or do not want. But that really doesn't play with configuration management when I have my dev site and my prod site. And it's not two different sites. It's just two versions of the same site. And all I want to do is migrate a little bit of data from one place to another. A lot of these ones, these ones have the distributions. You're done features, and you create a feature module that has, well, it's like, here's the feature module that didn't fit in any other features. It's just like all the other stuff in your site that doesn't fit into a blog or a photo gallery or something. It's just like, hey, here's my miscellaneous feature that wraps up everything else, or a base feature that every other feature requires. And so that right there is really you're trying to do configuration management. And by a baseline, that's what features had to do, because there really wasn't a good configuration management to be able to do what they had to do. So that's what they did. So what features does well, though, is it gives you a really great way to use reusable, hopefully. As long as you actually write your feature correctly, you'll be able to use a reusable module you'll be able to use between different sites. I say different sites. I mean completely different sites. Not staging and prod, right? Not two versions of the same site, but completely different sites. You could use that feature between if you wrote it well. An ability to turn on and off those configurations to say, just like you do with a module in Drupal, because it is a module in Drupal. And that's really great, especially for things like distributions and other things that you want to be able to create those kind of workflows. And it allows you to bundle many different kinds of configuration together from one different place, so I can take a view and a menu item and a taxonomy term. And all these one piece from here and there and everything else, and bundle it all up and give it a name. We're going to call it a photo gallery. And not just my whole site or any other thing. But that's what's happening in D8. A lot of people don't realize that change is coming. In D8, configuration management isn't features. Because features isn't configuration management. So in D8, you have an entire site. All the configuration in your site gets put down into one bit of configuration. One folder area where all your configuration is. That's your configuration in your site. It's not separated by your photo gallery and your blog or anything like that. It's like, here is your site configuration. And then you can move that between dev and staging and prod, but it doesn't solve the use case that features does of building these. You can't do that with configuration management. That is a step above configuration management. So that's what we're trying to do in the configuration module. So in D7, we're trying to backport that stuff as much as we can and try to take those same kind of thoughts and ideas, try to benefit from it in D7 so that we can use that and try to, you know, we're also trying to say, well, how does features work in a world like that, right? So the differences between what configuration and features is, you know, we have the config like in D8 doesn't live in a module. It's just a bundle of configuration that is for your site. What we do allow you to do, and it's slightly different than D8 right now, is like, say what you can track and not track, because we don't really have a good way right now. In D8, they're solving this in different ways, but in D7, we don't. So that allows us to say, well, you know, this piece of configuration is different between my dev, staging, and prod. I don't want to track it and move it back and forth. I'm just going to leave it as is, and I'm going to track everything else and move it between my staging and prods. So once you have all your config in your database, that's where it all runs from. It doesn't run from a file. It runs from your database, so it's actually imported into your database where it runs today. Then you can actually export that to a file, move it, save it to your git, you know, re-import it when you get to the live. You can see that there's changes been made, there's changes done, import it, much like if you've seen the preview of D8 that Dries gave during his keys note, that, you know, is the same kind of idea there. So you're also able to do something really great that I really like, that you can't do in many other places. And Features is really great because it gives you a UI. One of the things I love about Features gives you a UI that you're like really quickly say, click, click, click, give me this taxonomy term and this view and this, you know, this content type in. I want to use it over here, right? Like just give me that. But to do that in Features, you have to actually create a Feature module. But if you're in a site that you've built with Features, you can't create another Feature out of the stuff that's already in a Feature. So it's really hard. Then you have to try to take, if you want to take one piece out of three different features and try to move it to another site to get started over again, that's really hard. It's a really hard thing to do. And it doesn't, you can do it by going to each one of those places and trying to do a configuration, but not all those places have a nice UI like Features does. So what this will allow you to, Configuration module allows you to do is exactly that as well. Say, hey, just give me these three things and download it, give me the configuration, let me import it into a completely different site. Now I can just start from there because I've already done most of the work because like, oh, let me just change the two things different on this new site. And then if you want to put that in a Feature or put that in the site configuration or whatever you want to do, that's your choice from that point. But it gives you that kind of like stepping stone to say, hey, I just did that in this other site. Let me go ahead and just like move it over really quickly. So that's really nice. And the configuration module doesn't replace Features. Like we've said, Features is built on top of that. Just like it is in D8, Features will be built on top of CMI. And that's where it's meant to be. It's that 20% of what Features does that is the other use case. So fitting those distributions, doing, owning the modules, turning them on and off, making them reusable, bundling them in a way that it gives them a name, all these other things, that's what Features is going to be doing. And configuration is currently in active development. It works pretty much. It was started by taking a fork of Features to iterate on it. So the very version one is sort of a fork of Features with the Features part removed out, that 20% of what Features does to try to just take the configuration part. So a lot of that stuff is there. Version two is kind of a complete OO rewrite to bring it much closer to what the D8 CMI is. So, and that's on the way to being done. And there's some project page. This is one of the migrate screens that I was just talking about. So you can literally, very similar to Features, slightly different, but you can see you can just go through and select a couple boxes and hit download and import and export at the top of the screen there. You also have your tracking and not tracking. Things what you can do is you can tell it, like I said, you wanna track different parts of your configuration, track your node types, track taxonomy terms, whatever you wanna make sure between different sites. And that's what's gonna be written to your data store file whenever you ask it to actually write it. You can set that up on Cron, you can leave it as manual, you can do a lot of different things. It also has capabilities for you to go in there and it'll nag you when things change. So it'll say, hey, you've changed something. You can turn that off or you can leave it on. So, in the future of CM in Drupal 7, we have is, like I said, we're backporting a lot more of those features. We're working pretty good on that. We're also working with CMI and Greg trying to make that good as well in D8 and try to get as much as that backport to D7 as we can so that we can use that same kind of workflow that D8 will have today. Once we have that a little bit more solidified, we're gonna be rewriting features on top of that. Because features has such a large base, that probably needs to mature a great deal, but we're gonna learn a lot of that along the way. So depending on how much work actually gets done, it's gonna depend on how far that actually makes it. Will this take full foothold in Drupal 7 in the full community with all those distributions is yet to be seen. That's a lot of work, even over the next two or three years. So we'll see how much adoption it really gets, but if you're not using one of those distributions or doing something on your own, you could benefit greatly from it. If you want to help, A, we're coming up on a feature freeze, so D8 CMI could use a lot of help. I would say start there first, because any knowledge you gain there is makes it easy to backport that stuff, so start there. But if you want to, you can also come over to the configuration module. We'll always need more testers and devs and UI people, anybody that wants to have a crack at this, right? And any of this stuff that if we find a good way, we can push that back. If we still have time, we can push that into D8 as well. So time for questions and answers. I left plenty of time. I wanna know you guys probably have a lot of questions on individual configuration stuff, so I'll leave that up to you. Doesn't look like we have mics, so just raise your hand. So the question is, if you have two developers and they're both doing changes, can you merge those together and diff them and see what it looks like and all that stuff? Yeah, so all the tools that you're used to today is how you do that, that's source control. When you go and change something and diff it, make it happen, see what it has inside the actual UI, you can turn on the diff module just like in features and see the diff of things if you want to. You can also use tools outside of that to see what's going on. If you commit one thing versus another, that's the whole point of putting stuff down into code is so that you can diff it, merge it and do different things. So that works the same way as it sort of does today. The default is the files directory because that's the only place that is writable in Drupal but in the settings you can change it to wherever you want. Obviously it's recommended that you put that outside your doc root for security in other places but by default if you turn on the module like and you wanna go use it, you can. Things in the files directory is protected by HT access so it has some level of security but you aren't gonna be able to throw it in your version scroll or to some degree some people don't wanna do that. So one of the options that we've been kind of that configuration has in it that we haven't really made a good way of UI is situations like when you're going into Pantheon or the Aquia Cloud or other places like that that don't allow you access to the file system. Some places do, some places don't. If you're on prod and you wanna backport configuration, you can't say save this to disk and let me get it, right? Like it's a lot harder. So a lot of times you have to be able to like, hey, write that in some place that is not the file system. You wanna write it in a files area or somewhere else that they give you that you can write to because they don't allow you to write into your area where your site is because it's all auto-deployed via get and everything else. You don't have access to that piece. You just commit to your get repository and it shows up, right? And that's great. Auto-magical works good and all that stuff but it sort of like limits you in that fact and saying, oh, well, I can't just go writing to disk all the time or whatever. Or I have to do it in a different place or whatever. So you have to configure that. You can do different things. So far, again, we've been trying to backport most of what's done in D8 and there really is no, it's not a great way of doing that right now. We're, lots of ideas, we're trying to work towards stuff but there's not a good way of saying, hey, I want a different configuration in my dev because what is dev, right? For a lot of different people that, means a lot of different things. A lot of people that's their local and there's 15 of them, right? And so it's like, but each 15 of those are all different, right? Like I'm doing it one way and the guy over there is doing it another way and he has this module turned on, but he doesn't like develop, but I do, when I'm developing and things like that, he just uses PHP for Firefox and stuff like that. So I mean, it's a hard problem space. Some of the areas that have been solved, like I know there's been some work in the Drush exportables to try to give you capabilities to do that with some of your exportables via C tools and give you an environment around that so you can try to just tell it, you can do a Drush command and tell it what environment you're on and it'll kind of make environment level changes. There's a lot of scripts out there, especially in Drush as well, for like if you do backups with your database with Drush, you can have it change things in your database or other stuff as it backports it and munch data and do different things like that. So you can use those for environment, but as far as saving your development configuration in your prod source code, it's like there's so many different use cases and a lot of people, it's not really good necessarily to do that first place, but even if you did, like everybody has a different way of using that, it's really hard. Yeah, so there's a, all right, so the question, I haven't been repeating though, sorry, hopefully everybody's been hearing. The question was that, how can you automate kind of the deploy around this stuff? Can you write it in update hooks and things like that? If you are already writing update hooks, same is true with features. There are commands, you can run the actual, if you're running in a PHP in an update hook, you can call a function that auto does the import from the files on disk. You can also, if you're doing automation another way, you can use Drush commands to actually do imports and exports as well. You can check status and things like that. So I mean, a lot of that same stuff, you can do in features with feature commands and stuff like that. You can also do in like configuration for the most part, so whatever system you're using, that would be the way, like yes, you can automate that stuff. Where you get tricky is just like, if you, just like automating like, doing a DB update, update.php or a Drush update DB, when you automate that, there's always chances that something could go wrong, so you have to monitor it. Any update you run, any update hook of making changes, you can test it on a, hopefully a staging box at mirrors production and then you'd have somewhat degree of confidence that it's gonna work. But other, besides that, because you are just telling it to automatically do stuff, like if tested it, hopefully it'll work. If you haven't, then you're probably gonna need to watch it. So yes, the question is, can configuration or features for that matter tell you whether or not something has changed? And the answer is yes. Both features and configuration know, if anything that you are tracking, I mean, when I say that, I mean features, if you've created a feature module out of it, so only for the stuff that you've actually created a feature module out of, will it tell you if it's changed? Because the rest of the stuff is just there, it's just available for you to do something with. In configuration module, we call it tracking where you're tracking it across different, you know, your sites. But if that changes, because we know what it was when you started tracking that, when you created the feature module, we have that in code, right? We have it on disk and we know what's in the database and we know what's on the disk and the diff between those, if they're not the same, it's different, right? That means you've made a change. And if you've made a change in the database, that means we know to tell you that you should either A, revert that change because it may not be right, or B, you need to save that change to code so that you can replicate that elsewhere, right? Or vice versa, if you make a change and then put a new file on there, we say, hey, the file is different, right? Because we know that the file is not the same as it used to be, right? So then we can say, hey, you need to import these or revert your files because they're different from what's in live, or what's running in your database. So you need to make that change and you say, here's the different, all the ones that are different are changed. So I've seen a lot of hands go up for going to the code sprint tomorrow. Anybody helping with CMI? Oh, one, one, one. Really? Oh, two, maybe? How many people in here have a lot of pains in configuration management? Or do you feel like it's okay? Well, tomorrow is the day to change that. Well, we should change that. Greg, Greg is not in here, is he? Anyways, yes, come. Anyways, there'll be people that are working on it. I already talked to him. He will definitely be working on making it better. He's gonna be working on the field API tomorrow and trying to get fields in the V8 and stuff like that. So, all right, so no, I mean the question, I guess there is, how are you using, is it okay to deploy development configuration or prod? And that's not what I'm saying is not that you don't use the same code base. My point is that is the code base that you use both in development and prod if they're different, if they have different configuration, then they're not. So what is not generally good is to deploy two separate kinds of configuration to the same thing because you're using one of them and if you accidentally deploy the other one, like you completely screwed that up, right? So if you have different branches and you keep them separate or if you have them in a different way, if you have 30 developers and they have 30 different development configurations and they're all committing to your prod branch of, you know, you have, like, you know, then have 30 different configurations, you know, plus your prod and staging and everything else, like it can get kind of hairy, right? And that's all I'm saying is not that it's, you gotta be careful about that stuff other than that, like you can use any workflow you want. Hopefully you don't have to. If you're compatible with C-Tools or Features or the standard exportable ways that work in Drupal 7 the day, you should be already or very close to working with configuration. It doesn't actually, you don't actually necessarily have to do anything crazy. We haven't addressed exactly what we're gonna do for, oh, I went off. For some of the full exportables in Features, we haven't implemented every one of those yet. So if you're using one of those, come talk to us, we're still trying to make that better. But other than that, if you're using anything else that's already being done by Features or if you work with Features or C-Tools exportables or any of those systems, you're probably already supported. Because we're not changing that part of it, we're just changing the part about, like, again, how you use those configurations, right? So if you take your configuration and you take it off of Dev and you put it on prod and you leave it there and you never turn it off and you don't really ever use it in another site because it's two sites specific and all that other stuff. It's really just configuration, kind of just been hacking Features to do what you wanna do with it. And so that's what we're trying to make that better and trying to take that use case and really use that use case appropriately and then build a proper API on top of it that we can make Features even better, rip out most of the code in there and make Features to be able to say, hey, I just wanna take this configuration and stick it in and pull it out and do different things like that and worry about the things it really cares about. Is that it? Well, happy Drupalgon. Come by if you want some League of Legends swag, right, swag?