 All right, just just quickly this talk happens today because I my flights got messed up on fire LA So I think out there it says something about Drupal CI So if anyone's here for that, that's not for this talk and I'll understand if you like So what this talk is about is Drupal 8 configuration management best practices My name is Justin Randall. This is sort of what I'm known as on the internet Twitter Drupal.org I'm a GPL troll who pretends to know about computers and Is that better? Yeah, so I worked in this development cycle for Drupal I worked a lot on the configuration management system For D8, which was fun and challenging I work at Acquia in on the sort of our hosting platform Okay, enough about me. So what I want to do I want to give a little bit of an outline of What the Drupal 8 configuration system is and I'll refer to kind of the Drupal 7 Analogs or to that like what it's replacing. I Want to Put forward an idea of what best practices could look like obviously Drupal 8 hasn't even been released yet So it's a little bit sort of presumptuous to talk about best practices for something that's not even a production system yet And I'd like people to ask questions as I go But I'm I've consciously try I'm trying to keep this short enough to have time at the end because For the same reason like the Drupal hasn't Drupal 8 hasn't been released A lot of this is just starting a conversation and having you know Getting questions out there and getting ideas out there because none of us are really doing it for real yet Because Drupal 8 is is is not released So before I get started Has anyone used the Drupal 8 configuration management system in already I mean has anyone been involved in the contributions for development of Drupal 8 Who's used features in Drupal 7? Cool update hooks and functions too. Okay. So I've got quite a few sort of developers in the room It sounds like and I can see why you'd want to come to this if you haven't already used the Drupal 8 features So let's start with a bit of an overview of what the config system is It's a replacement to the variable system. Can people read that? I can probably bump it. Can I bump it up? Okay, so what I've got there is basically the old variable set variable get variable delete People know what I'm talking about with that, right? It's it's basically just a table in Drupal and it has a key value The value is just serialized. So it's just like whatever you pass to it serialized function in PHP It has Some nice features for small sites like the entire table is loaded into memory on every request bootstrap Which if you have a small a small system It's very very fast and it's a really good Trade-off for small systems. If you have a big site with a lot of variables, it might not suit you so well Another thing to notice about it is variable get here Is default in code so if you ask for something from the variable system in Drupal 7 and there's nothing there in the database You can provide a default That's either depending on your outlook that either makes you want to laugh or cry I tend to be in the cry camp, but a lot of people think that it's it's a great feature One of the reasons that I pointed out is because that goes away as part of the configuration system in Drupal 8 basically we're saying Defaults are what you should provide at install time but The values that you get back should be in your configuration not in your code And it's a notable change another thing that The variable system in Drupal 7 features is terrible scope creep So as well as having things that are like configuration It also includes things like when was the last cron run and other examples people can probably bring up. It's really more State, it's not really a configuration setting For example, if you were migrating values from your dev environment to your test and test to prod You probably don't want to move over the time that cron last run lost last ran as part of that migration So it's an example of variable system just tends to be a dumping ground. It has all sorts of stuff in there That's not strictly configuration and In Drupal 8 There's a new system called the state system. I'm not going to talk about it But basically all the things that were sort of put into the variable system in Drupal 7 that weren't really configuration Can now live in the state system in Drupal 8 And that's a nice cleanup That would be great if all we got out of configuration system in Drupal 8 was a replacement for variable set and variable get That would be a big win, right? But in actual fact we get a replacement for a lot more And what I really want to focus on in this talk And that's a replacement for Does everyone recognize that? I'm not swearing at you all That's basically a drush command to to do stuff with features and it's often done Or a variation of that depending on your workflow I'm not saying this is the right way to do it, but something when you're doing a release of New code in Drupal 7 based sites often involves things like running Updb to update the database and then running some sort of features command to say these ones are now But these ones are now what I want to run on my site And then the old update functions so a Lot of what the configuration management system is aiming for in Drupal 8 apart from the sort of runtime configuration is Replacing those with a new sort of more feature-rich system so that you can Basically work in a you know have a workflow where you'll have a site You'll have different environments of that site And you can migrate configuration changes between those different environments, and that's there the Drupal 7 ways of doing it With all their limitations. I mean features right features is great until it's not and then you know you're in a world of pain and features also has a scope that's like this and Like migrating stuff between develop between environments of a site is like that so it was always sort of a Lot of people use it for the smaller job Even though it was built to try and solve a much much harder problem Which is moving configuration between sites that are not related. That's actually a very hard problem And one that I have no interest in So the the configuration management system is only really aiming to solve the problem of environments of the same site not My blog and your blog. Let's just swap configuration between them if they're when they're not related because That's very hard and some I would say quite a full-hardy Problem to try and solve So what do we get for the for variable getting variable set now in that with within the configuration system You basically deal with objects so System.site is the name of a configuration object There's a lot of different ways that you can get at one of these I just use one example and you play once you have a configuration object It's basically like an array a simple array so And if you can store anything that can be stored in YAML. Does everyone know what YAML is? Yeah, so you get you get more than just strings you get types you get you know bullions ints you get lists so basically anything you can express in a PHP array of Simple PHP types you can store in in YAML And the way you interact with it is if you want to just change things in memory Big set name to something in this case. This would literally change the site name on your on your Drupal site When you call save that's when it gets persisted. That's that's when it goes down to disk When you when you want to just get the values out if you call get with no parameter You get the whole lot. It's just an array with everything in that in that configuration object If you pass in a key, then you just get the value for that for that path So that's that's kind of like the runtime replacement When it comes to exporting your configuration System dot site will map to a YAML file called system dot site dot YAML So that's kind of the tree of files. They map one-to-one And The other thing you'll note is that When you go get there's no default you can't pass a default to that It's the value has to be in there and I think that's a big advance Over the variable system The other thing is configuration entity. So if you have something like system This is the site settings like the site name site slogan site email address There's one of them, right? And it's and a lot of modules will have a sort of Like a settings file essentially and there's just one of those and it'll be like my module name Dot settings dot YAML, right? But what about things like views image styles all of that space That's basically what config entities are they they share Code with the entity system as a whole in drip late So there's a like content entities like nodes and all those comments all those sorts of things They there's like a top-level entity system and it sort of breaks into configuration entities and content entities These generally wrap a Simple so to speak configuration file. So a config entity generally has a Config object underneath and for views it'll be something like The namespace would be something like views dot view dot machine name dot YAML, right roughly So most most subsystems basically have a namespace That that is static like a prefix and then you'll have the machine name of the thing that you're you're Storing and that's like the machine name for a view and Yeah, and so they they have a kind of richer feature set and a lot more Code runs around the life cycle of a config entity versus just a simple configuration object So that's that's kind of like the runtime replacements for the variable system The other thing is has a everyone seen this UI yet in triple 8 So even if you're not doing any of the stuff that I'm going to present a bit later in this talk even if you're just Using FTP and like forms and stuff you can do a complete configuration migration workflow between different environments. So The this UI basically will export like a Zipped up file of your entire configuration in a tree and it's just like a listing of YAML files You can go to the import screen upload a zip file and it will like Unzip what you upload and then it'll present you with screens that will basically show you the difference between your current sites configuration and What the state of the tree is that you're trying to import? I? Expect that almost no one should use this. I mean it's there because we like we can't We can't ship group elate with a requirement that you have to use git for all of this stuff all the time So we have a UI that people can use but we sort of don't really want people to use it unless they're just kind of playing around And then they just want to try things out I'm actually going to spend a lot of the time in the rest of the talk talking about the ways that you should actually do Imports and exports and stuff and it has nothing to do with this One of the other things is the single import export so You know you can add something to views where you can kind of see what a view will look like in code There's anyone ever played with that like That's kind of similar so you can go into the single import export and look at Basically the yaml representation of any configuration object in the system and you can also paste yaml in and say save Very unsafe don't do it It's there if you know what you're doing in developing you want to play with things. It's great One of the things that it does do is it makes it harder to figure out whether or not the Thing that you're trying to change Will validate properly. There's a lot of dependencies within configuration and using these forms is not recommended so that's kind of a that's an overview of Kind of what's in Drupal 8 and what what things in Drupal 7 it replaces Anyone have any questions want me to like yeah Yeah, it's just in basically what it has to do is Do a comparison so the runtime configuration storage is actually the database by default not not files So what it needs to do is take the zip unzip it somewhere temporarily and Then start to do comparisons of the objects. Yes So yeah downtime it depends that that's not like it's kind of that's kind of like another a variation of When in Drupal 7 when you want to run update hooks should you have downtime or not kind of depends on what you value And what your setup is whether or not you can still serve Traffic while disrupt potentially disruptive changes are running There's no one answer if you want to be safe. You should You take you down your site down for a little while do them I you know do the import and then put it back up again, but it's not it depends on You know what your setup is You probably You probably don't want that that sounds a little bit like What do you want with install profiles? Like that's sort of how you create things and I'm not touching on it here Because I want to get to the the workflow of like you've got a site up and you've got environments and you're migrating through but In the similar vein Yeah, but the thing is that's actually covered in so when you have a module there's a convention for having a config directory and Basically when your module is installed the configuration system will look in there and go, oh cool Here's the defaults and I'll set them up when I install a module and you can do the same thing with profile so that's kind of instead of having Like in Drupal 7 if you've got defaults for things then in your code whenever you do variable get You'll have just like some random thing that is the default value In Drupal 8 that will be expressed as a set of configuration files And they will be the defaults for all the things when it's installed and it's a much much cleaner system, I think Yeah, there is yes, but that It's important that I know exactly what you mean because for example with something like features There's this concept of kind of like here's the code and here's with this It's kind of but it's not like When you take a running site and you export it the config tree The intention is that that is something that you'll then take and Import somewhere else and that's it. It doesn't have any meaning outside of that. So the Runtime configuration values are it there is no like oh, and then you can drop something on the file system somewhere You can say well this one reads from the files and this one reads from the dot But none of that it's like the runtime configuration is the runtime configuration. That's it There are some exceptions, but let's I'll get to that So Right best practices did hasn't been released yet. What are you talking about? Just to be really clear This is a discussion. We you know Different people in the community different companies are working at Acquia. We're sort of actively working on What things can we add based on this system to make it easier? Literally just yesterday or the day before a Proposal in Drush's github queue to add config merge was created and that's something that's still being tossed around so Imagine if you wanted to have a development environment and a production environment and you want to run a drush command that like took The config from one environment and like pulled it down and imported it into another environment Still being worked out these tools are still The whole process is still in flow and Like if now is a good time to get involved if you have strong opinions about it And what I want to do in the demo is kind of walk through one possible scenario and it'll hopefully help people to sort of Tackle it and think about it so What what are some of the best practices? I'm going to suggest one is Track your configuration in git So what I've got here, let's imagine that's the Drupal directory that might be heretical to a lot of people a lot of people like to have Drupal be the root of their git directory. I don't care whatever if you want to put this inside there That's fine, but the idea is that every time you Do a release to production and You'll have you'll have a configuration tree that you deploy to production Just like you would deploy new code like that. It should just be part of your release process So you would expect So this is head but you would expect to have a bunch of different branches and tags for releases and stuff and The flow changes inside the configuration directory That is just a whole bunch of YAML files that express the state of configuration Will have exactly the same sort of life cycle and flow as any other code so that means things like If you get tasked with doing a job and it involves configuration changes, then you will create a branch called Thrubar and you will make a set of changes and you'll express that set of changes as Changes inside this configuration VCS directory and when when your change Is ready to be pushed into the master branch or whatever your workflow is There will be a configuration import and that and that way you'll have a known set and like a lockstep Sort of release process of what the changes are It's a pretty important difference to and a pretty important concept and I think it's a very it's a key part of how Best practices will develop in Drupal 8 So if anyone doesn't understand what I just said or has questions around it's probably a good time It's similar but it's way way better because features as I said has a bunch of concepts that are really bad like you can have code and database and which What's running? Well, it kind of depends one overrides the other whatever The config VCS thing is here are a set of changes that I'm going to deploy Once I deploy them. That's it. What the way the site runs is what the runtime configuration is period Never ever looks at what's inside there except for a deployment process. It's much simpler and a lot more robust expression the database Yep Part exactly so part of your deployment process Like how would you normally when you do a release you would do something if you're doing a features based released You'd probably do like maybe you did Drush up DB to get the database changes and then you might do the you know drush some features commands depending on your Workflow to to deploy the new features, right? So what would change is instead of doing the features stuff when you do a deployment You'll do a drush config import right if you've got a scripted flow And then it'll go cool as a set of changes here and pull them in and just the same as the update DB stuff When it looks in there if there are no changes it just goes well, there's nothing to do and moves on Yes, yes Yes, you can do the same in that was what a good question and that was what I alluded to about There are no defaults. It's a little bit more complicated. It's kind of like that You can set things in settings.php. Basically, there's a config variable and then within that it's kind of like System dot site something something that's it that always wins. Yes. Yeah, but I mean I would suggest if you're at that state you For some other problem, I mean it would be better now that we have sort of one path for all configuration changes There are already people working on modules that Depend will depending on an environment just won't that basically turns it into a read only system So config changes just won't work. They'll just say no you can't change it. So you can do that cleanly with one system now because There's only really one place to make the changes Can you serve them like if it's inside the top group? Yeah If you have a bad configuration, yes, and that's why I mean this is why in my mind Just don't do that like don't have it in the web route But I understand that some people like to have the web route as the base of the git and then point and use like, you know Drupal.org is one remote and blah blah blah and that's fine Just make sure that the config VCS directory is protected if you put it inside the web route or better Just don't put it in the web route It's a flat it's a flat list. So when That's the whole it's the whole tree. It's the whole tree. So This When you when you export that is system dot site dot yaml, right? So this is a unique name that refers to every Configuration object on the system and it tends to be in a typical Drupal fashion. It's like module Is the first part and that's kind of your name space and then whatever underneath that Oh, yes, so there is a whole system of configuration overrides It's a it's a big question and it's still in development. So we've worked with the domain Upstream to to kind of keep them up to speed with the triple eight config changes Actually don't know what the like Current state of head is of of the domain modules in Drupal 8 But we've been working with them the whole way through so we tried not to break them. I want to try and keep going Use a feature branch workflow So this is kind of what I said before but there's no reason at all if you are making a set of changes if you're a developer and you Get tasked with Okay, I want to do I want to move some blocks around. I want to You know a whole set of things that are sort of like maybe site buildery Type roles or jobs. You can now use a feature branch workflow Does everyone know what I mean by a feature branch workflow? Yeah, so you can basically assume you've got a shared config get repository and you know, you you're working on the foo bar feature then you're working your branch and Then when it's ready, it'll get merged into, you know master or whatever the deployment set up is So this really flows from having this config VCS directory Which expresses a set of changes that you want to make in a deployment just like Code right so when you when you're working on a code change to a module You'll create a branch and then you'll hack away and there'll be a set of differences against whatever master is Exactly the same workflow Takes a while maybe to kind of get used to it But hopefully you'll come to appreciate that that's actually awesome. That means it's exactly the same workflow you use to do development in teams, right you have a central Repo and you work in branches and you have some sort of merge process exactly the same Hopefully people will come to see that that's that's an awesome thing This is your question, right? Some of us will get lucky right some of us will be able to work with clients or internal teams in our companies and they will accept our Request where we say no Can fig changes only happen by deployments period no production changes. I Can't stress this enough If you can get away with it get away with it, right? Your life is going to be easier and droop late if you can just say we have this powerful new way To develop configuration changes in the lower environment and push them out to production So you don't need to do that in prod anymore. Thank you. Goodbye, right? If you can get away with it do it. It's going to make things a lot easier and Hopefully the fact that this is built-in to droop late and hopefully you know a lot of people using it and the bugs We found and it'll start to become reliable That will you know that will become something that more clients will accept, right? But we'll see right then there's the rest of us, right like There's is going to be a bunch of us when no matter what we say People are still going to make production changes To config, right? There's just that's that's that's life. Unfortunately And the basic thing I'm going to suggest here and I'll show a possible way of doing it in the demo is Track your production changes also in a branch in git. So When you do a deployment and you let's say you have a tag because you're saying or whatever you do it You should know Like the the point in time in git, you know a git hash that represents this deployment Create a branch off that right and take all the changes that have been that are made in production and express them as Changes against that branch because when you want to bring them back into development environment, they're now in git Right so whatever workflows you already have you can use in the same way So I'll actually show it show a simple version of that so I have a little bit come clear, but that's another very important part of Best practices where you can't stop people making production changes Yes, so config merge like I was saying that's actually a proposal. It's in the the drush queue right now The drush tools are really good. I like anything with Drupal 8 in drush They break periodically because they get behind but then they usually catch up really quickly So you can go and play with these things Right now. Okay, so I want to do a demo Everyone crossed your fingers and everything I'm gonna need the internet and hopefully it'll work. So what I want to introduce to people is Two sites one called can people see the domains names So these are two identical sites that I've just installed and which I should have done this before the talk There we go So these were created with this really simple script Which is really just Copying and pasting stuff from my history. So it's a really bad script, but Like this was enough for me to create those two sites And as you can see drush figures heavily in in this whole thing and it's already usable to play around with this stuff But I don't really want to get too much focus on the script But just to try and get across the idea that it's already easy to script a bunch of these things using core and drush Which is nice. So I created these two things. It's just an install a Drupal a bunch of develop generate to generate a bunch of content And one of them is called see my prod right the other ones called see my dev And obviously the idea is that one's development and one is proud What I want to do Is basically Deploy a basic feature. So you'll notice that There's no search bar, right? This is a really common thing, right? You have by default Drupal doesn't let you search content on sites if you're anonymous, right? Which for a lot of people and a lot of sites is not what you want. So what we're going to do is we're going to allow Anonymous users to come to the site use the search bar The other thing that's really common is if I log in To do the search bar there is here. A lot of people want it So what I'm going to do is just show you kind of how that might work. So First thing I'm going to need to do is mission roles Wait a second permissions search, okay, so You can't use search if you're anonymous either. Let's change that So that's that and the other thing is obviously a lot of people like to have block layout Search is in the header So let's do that and let's save it Okay, so I Now have if I log out Where do I log out? Yeah, thank you Yeah, I'm actually just having problems with the mouse because All right log in now. All right. So now you can see up here. I can search for stuff All right, I'm anonymous user but I prod doesn't have that so the next trick is to There we go So now If I go to the web root And I go to drash Sim which is a shortcut for config import and X is a short sex sex CX whatever It's for exporting So let's do that And one of the first things it asks is where where would you like this? Inside the settings File you can specify different destinations. Basically, that's the name And then what the value for that is any old path you feel like so in this case Inside the same idea Directory like not inside the web root. I have a config VCS directory And I taught Drupal about it by putting in the config VCS as a name with a path inside settings So it knows how it knows where to go So there we go. It's telling me will be deleted. Yes. That's fine. It's in version control So track changes cool. So what happened is it just ran and now if I do If You can yes, I can do that better Yeah, so you can see that my my Tree now has some changes to the block blah blah blah and it's basically this is stuff I don't know about There's still some bugs, but this is the change that kind of we really care about That is that the search is now in the header instead of cyber first and if we keep looking We can see that anonymous and authenticated roles now have search content, right? So they kind of looks right so Yeah, maybe this okay, so bugs in here, which is cool So what I'm going to do is something I just forgot to do which is I'm going to go get check out search And on Okay, so now I've created a feature branch sure done that format changes, but just pretend I did do that I've got a set of changes. They look right. I can use git to try and like figure out what they look like So then I can go git commit Allow and on search Don't do this obviously much better messages committed. Okay So now what I want to do is I want to move that to production. So Let's assume there was some process of testing and everyone's happy, right? So Right, that's the way it works. So now what I'm going to do is push to origin such and on now Internet yes, okay, so now if we go Here you'll see the ban compare and pull request Cool allow and on search credible request Blah right assume I go and I look and again, let's just assume that all it's all we're all happy So I'm going to merge it. So now I should be able to Go back to here and go to see my prod right again pull okay, so Log you can see there was a pull request that was merged And what this means is that the files that are inside config VCS now have those set of changes, but you'll see that like the site See my prod still looks like the old one. Nothing's happened, right? This is just sort of like going out to the system that you want to deploy to and pulling down Code but not necessarily applying the changes depending on your workflow That might mean right a separate directory and you haven't updated the link that points to what current is anymore right So what I want to do is to actually make that life. So What I'm going to do is Drush Feed import and it's going to say wait. Where do you want? Oh, I should config import Right, where would you like to take that from again completely up to you the names and the paths you control all that So I want to get that from config VCS and it's going to say here are the things that have changed, right now What's nice is that you can do preview equals diff Config VCS instead it'll look like that Here is what the changes will look like. So if you want to just kind of Cowboy it and like just eyeball the changes and then pull them in you can do that too So let's go. Yes It's not a quick change It is taking the whole two trees and comparing them So even though the set of changes is small it has to figure out that the set of changes is small So it's doesn't it's not really quick It'll probably get quicker once we start releasing Drupal 8 and we start optimizing it more. So Fresh bam, so that was a whole flow It's Pretty awesome, right? I mean that I'm not doing anything there except using standard Drupal 8 core and drush So so that's really nice. So More but wait, there's more. So the next thing is What is the next thing I probably put it in here So now let's deal with the person you can't convince that they shouldn't make changes on product, right? And we're all we're all laughing now because something So I'm gonna go to prod. I'm gonna log in And I'm gonna maybe let's say the persona here is I'm a grumpy sysadmin. I know nothing about that persona, but let's pretend and I look at my site and I've just been woken up because some idiot developer pushed this thing out and Wait Sorry, this mouse is I Notice that there's literally no caching So I go screw you into screw you developer and I want to go to sleep I'm gonna save those changes. So now In the in the configuration that's running in the database is a set of changes and they're not consistent with what was just imported by import so what I think like one answer to that is Again assuming a bunch of things that are not just in this demo, but assuming you've released from a tag or something You probably have a let's say You have a githash, right? Maybe that could has just for a tag instead of this just the head of master So you might do something like get That's be, you know release To whatever the hell whatever whatever your naming scheme is So now we have something which is on based on the last released Githash, right? And now what I can do from prod is go drush. What am I gonna do? export right Okay, I'm gonna go here Yes So now it's sort of in a very similar way. I have My changes right expressed as as you know a gift if Now I'm gonna do this manually. I'm gonna go get Come here stupid debts And now I'm gonna yeah, would that go to a local path if you're so Mm-hmm, I'm not sure I follow Maybe I don't actually know whether drush upstream supports it it probably should I know that the configuration merge command So they're working on right now Understands aliases So if the aliases are on the same machine or on separate machines It'll do the right thing with SSH and etc But I'm sure that drush will build that right. It's just kind of just a matter of coding, right? I think a lot of people will have that need so so Now what I've done is I've Committed that there's a Drupal Drupal module called config log and what it does is it records all the configuration changes That could be a source if you wanted to automate The commits to this branch, you know that this branch is like clean like comes right off Your last commit to to your last released commit So you should be able to just commit on top of it cleanly, right? So you should be able to automate it So let's assume this all happened in some background process instead of me doing it manually. So Then I do Get push origin What I call it is to So now I Kind of have the opposite problem, right? I've got I've got a set of changes that are on product and they're in depth and I want to bring them down into my development tree so So Okay, so the next thing I will do Is go back to see my dev just make sure it's there and now basically in I'm going to say There's to there's actually two options here like it gives you the tools but not like the Ability but not the policy, right? So one thing that just happened is that change could be valid. Awesome. We need to pull it into our dev workflow Another thing that can happen is that was just a complete Mistake and we don't actually want to pull it in so a valid Choice at this point is you just don't merge in this change, right? It's not automatic Then any change that's made on production you want to keep because maybe the next thing you want to do in the next deployment Is kill that change? You don't actually want to integrate it So this at this point there's a there's sort of a question of policy to think about but so but in this case So this is let's assume that that was the right thing the grand piece of sadmium was right for a change And what we actually want to do is integrate this this change So it's exactly the same process Create pull request merge pull request For merge all right, so now you can kind of I hope you can all kind of guess what's going to happen now Yeah Yeah, the Which which one would you like to see so like get it GitHub just has Yes, you can you can see when you do a if you take a zip of the configuration tree And you go to the import form and you click upload it'll grab it Unzip at all and then it'll present you a UI with the differences Yeah, because that's great. It's it's an advance. There is no such thing Right, it's not such thing. I think what you sort of one is a preview. So like You can see the difference expressed in changes in the ammo files, right? I think you are saying you would like to see the difference in the actual view like previewing a node Or is there some other thing it's get you can do whatever you like on any environment, right? So, I mean here I think I'm Well, the thing the thing is like what I'm trying to say here is maybe you don't use GitHub But yeah, I Think I see what you're saying. So what you're saying is Changes be made in Prod in the dark and like in the runtime storage and then you've got the last config tree that was imported How can you see the diff between those? So what I'm saying is just always express them as YAML files and is good What's Yes, yes So, but I think I think I can see what people are saying. So imagine if you didn't track the changes in prod That's the basic assumption you're all making So just don't do that You're you're in for pain if you don't track the changes in prod against the last import Yeah, you could do that. Yeah, you could totally do that So, you know, it's great This is the discussion I wanted and I'm sure whatever I present here people are going to do something else Because this is kind of like just taking the primitives and choosing a workflow I would suggest at all points if you can use git on a set of YAML files do it Any other workflow in my opinion is not going to be as good. It's just that simple So just don't ever ever do anything where you can't express changes as git commits Because when it comes to pretty much everything that most of us do as a workflow around deployments It's changes in git. Yep Mm-hmm. No, no, there isn't Right Right Yep Yeah Yep Well you when you Hold on when you do the import you'll know whenever you do an import the set of changes will be here There's other changes and if it doesn't if it doesn't look right at that point That's terrible because it's right at the end. You don't want to be at that point But until you say yes, nothing's nothing's changed. So Yeah Hold on Know that like the the Config UI that I pointed out before When you want to say show me some differences you need a starting point So if you you if you want to if you want to keep around like as a toggle of your last release You could use it to see a set of changes Yeah Yeah Yes Yes Yes totally totally all all that's doing is defaulting to like checking a staging directory and Showing you diffs. So like with some a standard dripper module You could build something that took any arbitrary Starting point and show you the difference between that and your running production config so All the building blocks are there. There's no limitations. It's just we don't have it in core right now If it doesn't land in core someone will build a module. It's pretty straightforward. Yeah Right Another thing I should say is um I'm I'm I'm behind so maybe you're more up to date than me. Um, so maybe what we're all asked for is already there awesome So I'm I'm aware of I'm aware of limitations in time What I'm gonna try and do is see We synchronize there's nothing there you can front your current configuration has changed. Yeah, it's already there Hold on. Let me just do that again. Look at this cool thing Yes, it's already there. I mean underlying This whole thing is basically, you know The ability to take a list of yaml files in a directory and compare it to what is in the current runtime Setting the current runtime settings for a site. So When I last looked at this this wasn't there, but it's there now because the the building blocks are You know fundamentally there It's really straightforward All that does is respond to lifecycle events. So when our configuration object changes There's there's a lifecycle you can hook into the event and what it does is basically takes When you're changing When you're changing something you get the two objects to get the old one the new one So what it does is basically looks at that saves a whole bunch of information Which user is doing it that sort of stuff and just writes it as a row in the database So it's something that ran like on cron or something that was better than that But you know whatever some other system could just read those off and turn them into commits And then you just you have that whole thing as a get history Yes So you can do all of that In your like in settings php you can override anything in configuration in settings php So you could use one one way to do it be versioned that way There's also a full config override system Which just another set of things I didn't even talk about a lot of that is used for language and localization But it can also be used for environment-based stuff, but that's a whole lot of thing I'm not sure that's mostly a sort of a political question so to speak like a module to do that would be trivial And in fact, I think that are already is one Just to basically take the storage driver for the configuration system and just be like oh, this is probably no rights Whether or not I've gotten to do before I don't know I don't know if anyone else I haven't looked in the queue recently whether whether such an issue exists I mean, I don't have a feeling for whether or not would get in I'd be in favor of it, but you know Is that reflected on the reports today's page? So maybe that could be another I mean, you know it's triple so it can either be a modular does that or it can be Corp hatched depending on who wants to like work I think that's basically all I had I wanted to show the two sides of the coin, you know taking something from Development and pushing it out to production I learned to show what you have to do or the or that you can do sane mergers back down Where where you don't have a choice? But again, if you take anything away, it's think in terms of your standard get development workflows Like that's basically the promise here if you have a certain workflow now you can probably integrate this into it Yeah, you could do it that way. Yes. Yes Got one minute go Mm-hmm. Mm-hmm. Yes. Yes, the active directory is not a thing anymore Yes Don't do that Use get I mean seriously like if I'm working if we're in a we're in development team You're working on feature bar feature food. We might be working on the same files while we're doing the development We just use get one of us wins one of us gets our stuff integrated up first and then the other one has so I pull back some changes And maybe the conflicts I'll work them out and then you know, then I'll move on and do my you know Trying to get my branch into the main line So it's the same it's the same thing and that's kind of what I'm trying to get at is like You can just use git now. You just use that flow and that's that's how you Sorry, you haven't asked the question and actually I is there is someone speaking next here. I'm holding anyone up Oh, it's lunch. Okay. Well, okay. Oh, no, that's the defaults That's the defaults, right? So like the the runtime list the differences that you saw there. There's basically For each role. There's a list of permissions, right? So and there's only one of those for a site. Thanks, everyone I'm not sure Maybe yeah, I don't I mean features as far as I understand they're doing development on d8 I don't know what they're doing But I'm sure there's a bunch of polish on top of what we ship in core and there'll be a bunch of use cases that we miss Right, yeah, that's a different use case. Yeah, okay