 Before starting, when I was last year at the Drupal, I noticed that by the audience in the room, if it's a few people or a lot of people who understand that there is a problem on the future, what the session is about, a problem or understanding or too many doubts or enough documentation, so something that people want to know. So I'm happy that I'm not the only one with doubts about configuration in Drupal 8. So today we're going to talk about configuration deployment in Drupal 8. It's an intermediate session, so I will skip the presentation of what the configuration management is, how you can use it, brush, basic things, so we can proceed to the deployment itself. So a bit about me, I'm Gabriela, I'm from Italy and most of the people here in the UK are from Gabi, and I'm Gabri everywhere, on Drupal, on Twitter and on any other social media platform that I don't use actually. I've been a lot of time at this Drupal developer for 8 years as a Drupal. I'm a dad, I'm a beautiful folk, which is 3 years old now. And sometimes then yes, I can talk about manifesto, and this is what I like. It's recording, there's no speakers in there because they're really so small. Yes. It's not good, I mean as I have a beautiful voice. I always thought the last series that I like to watch, I've been watching Shameless recently, and I love it, that's why I deserve a mention on my presentation. So today, we're going to discuss about configuration management deployment. So this is a bit of a description of what a configuration management is. It's a feature which will give us the possibility to have the configuration in files. It's not because the file itself, it's because now we can have a single source of through about the configuration of our website. And we can take this file, we can take this block of configuration, and we can version it on our workflow, on our virtual control system, or on our file system directory, which you just use to download the touch-it-z from the web UI. So this is a piece of something that I'm going to discuss about, but this is what we're going to chat. This is so, the presentation is more an exercise. I won't tell you the through, I want to discuss with you about what my feeling is about what the configuration is, how we can deploy it. So this is how the simple configuration deployment works. We have a source website, and our configuration is in the active state. So our configuration is a configuration running on the website. And when we want to migrate, when we want to deploy this configuration from the source website to the destination website, most of the time it's from staging or death to production. We export the configuration. We export the configuration, and normally the configuration goes to the sync storage, which again normally is directed on your global instance, but we don't have to forget when we think about deployment, we think about configuration. We don't have to forget that there are people using just the web UI, so your exporting can be just to export the touch-it-z from the web UI. And then you have this monolithic configuration. It's really important. You have the whole block of configuration in a single storage unit, whatever it is, the directory, or a package. And then you import straight inside the destination website from a sync state to an active state. And again, what you do is you push the whole configuration. So you are the master of through, and whatever is on the destination website will be overridden or deleted. So if you have a priority, if you are new on Drupal, or not a new on Drupal, sooner or later you will have this problem, or you push the configuration, and you see that something doesn't work. So you have this question. Will I override existing configuration settings on production when I import to production? Yes, you will. You are the master of through, so whatever you have on your files will be, and is existing on production will be overridden. Will I delete new configuration changes on production? So my client created a web form, which is not on my configuration, my monolithic configuration. Will I delete it? Yes, you will. Any new thing done on production will be deleted normally. So these are the rules on import. So the new configuration will be created. An existing configuration will be overridden. So a configuration coming from here, which exists on here will be overridden. And the missing configuration, which is in here, but is not on our import block, will be deleted. So in a simple deployment, we have a simple website. It's just a two-page website, or two-lining page website. It's a simple website. It's fine. It can work. So we always push our configuration, like it was a waterfall, no? Pushing water and water and water, and we delete all the dirty things, so it stays on the pool because we keep pushing. But what if our configuration is not simple? What if we have a big website? Some of the configuration is coming from us. Are the configurations coming from the client? How do we deal with it? And most of the times, a two-page website is not a website with a simple configuration. So it doesn't look normally like this. It's more like this. We have small parts of configuration, right? And we, as a developer, we recognize most of these parts. And the exercise that we are going to do today is try to find common patterns so we can react to these patterns. This is how our configuration will look like. In this presentation, I identified four segments that we are going to check at the moment. But on the old and new, our configuration is something that is like the base of the website, which is the node, the fields, the user roles, something that is the core of our website. Then we have something like this on the top, the yellow one, which is something that the client is going to create. One of my clients is the page manager massively. So they create a landing page continuously like once a week. I don't have these pages, these page manager instances, or the variants, or my depth. So every time that I will push my configuration, I will delete all the client jobs. So we have to take care of new stuff. And then these are the funny things to which I call it, I'll show you in a second, I call it the one-time installation configuration. So Google Analytics is a good example. When we create Google Analytics, we maybe put Google Analytics on our depth environment, right? So we have it on the configuration and we push to the configuration to production. But then the client has to be able to change the Google Analytics code so the configuration setting will change. So if we push again this configuration, we will remove the configuration settings from Google Analytics. So we have something that we suggest a configuration edited to production. Do you have it? But that should say, yes, I have it. And then you don't give this configuration. So it's a one-time configuration. And then we have an environment-specific configuration. In this case, it's on your development environment. You stay there, you stay for proxy, you stay for private. So this configuration is still part of your configuration. It's environment-related, so we have to recognize it. So I go through these four segments that I think they have to be recognized. Again, it's an exercise. This is what I came up after reading some of the solutions to the problems. I will put these slides almost immediately on the website. So don't worry about taking screenshots or notes. Everything will be there. The primary segment is the bones of a website. So it's the configuration that the client should not change. Fields, nodes, views, block types. So the core settings. So it's something that it's what, at the moment, the configuration management does. So new configuration must be created. Existing configuration of a reader, missing configuration must be deleted. So if you have a new field, the new field has to be created. If you are making an update on a field, the update has to be of a reader or production. If you are removing a field because it's not reading anymore, it has to be the reader or production. So the export part of the configuration is the master of this segment. The next segment is the secondary configuration. So this is anything new created by the client. We don't have this configuration on our, most of the times, we don't have this configuration on our exported block. But it's part of the environment, it's part of the configuration. Even if it's not part of the configuration that you are importing, it will be part of the configuration of production, which is probably much more important than the configuration that you are shipping, because it's the one that will face the public. So it must be recognized as an important segment of the configuration. So together with that thing that we are going to update, we have to take care of things that we shouldn't delete. The master is active. So the master is the active state of production. And it's something that we have to consider. One example is the new block instances, or as I said, the page manager instances, or new web forms. So we give the possibility to the client to create campaigns and web forms. And they shouldn't be deleted, so we have to take care of this segment. The first segment is probably a funny one, it's a new one. So as I said, it's configuration. The client should be able to change, and you just want to give an install state or a one-time state. Another good example is the site settings. On the site settings, you add the email destination or the email source of any mail sent by the website. This is on the site settings. The client used to add the account of an intern on these settings. So the email address was changing twice a month. So I don't know what the next value would be. But I must provide this because this is the core of the website. So I must provide this configuration. And I have to say, look, Drupal in production, do you have this configuration? And maybe when you first set up the website, this configuration is not there. So the configuration will be installed in port. But next time, you don't have to override this configuration. So if a new configuration must be created, if it doesn't exist on production, it shouldn't be touched. The third segment on our configuration is... I call it data, but it's not really data. It's anything about an environment. So it must be part of our configuration. The settings and the configuration did it use the data environment. So we want to keep the stage by proxy, web profiler, and endeavor. Or it could be that we want a segmental configuration for the testing environment with specific settings, with specific modules for the stage. So we cannot identify this segmental configuration. As I said here, I'm using the conditional. Because it doesn't matter about the production, where this configuration stays, if it is part of the configuration, or if, for example, we don't have this on our client, we don't have this segment on our configuration. We use automatic scripts to enable module or disable module in a specific environment. But maybe this is part of the segment that we should talk about and discuss about. So this presentation is full of recap because it's maybe a new concept. It's something that all the customers want to propose and we should discuss about. So what we need to do in a service is to understand to which segment that configuration belongs to. It's important. It's not important. It's new. It's not new. It's a regular production for a production. And to be able to react, it's maybe too much. So I was wondering if we had a solution that was much more than the deployment with hoping everything would work. And actually we have solutions. We have solutions. These are the main, the current main actors on the configuration management management in Drupal. But maybe in the future we can have more. So we'll discuss about this comparing all these tools with these segments. So first of all it's trash. Everybody knows trash. I won't talk about trash. Trash out of the box contains the commands to import and export. So how trash this with our primary configuration is the configuration that we have to push, no matter what. It does automatically with trash. And sex, it takes care of the box of the primary configuration. The second configuration, which is the configuration that the client can change, the client can create, so it's new instances. It's the configuration that we don't have to delete while we import. And it does it kind of out of the box with a partial switch. What this does, the way it works is if you use trash from the command line, it pulls first the configuration from production and then it puts your configuration on top. So it means that the new things coming from production that you don't have on your configuration will be merged on this copy and over. So your configuration will be yours plus the new stuff. And it does it works. What it does is deleting what you want to delete. So as soon as you have a field that you want to delete, it won't be deleted because you don't have this field on your configuration to be imported, you don't have this configuration because you've deleted the field. But it's still on production, so if you use the trash partial, it won't delete it. You have to do it manually. It doesn't work with an install one-time initial configuration, which is, just to remember, it's the one that we suggest. Production, do you have it? No, I don't. Do you have it? Yes, I do. Okay, I won't give it to you. Environment-specific configuration. It kind of does it, so you can skip modules. So for example, you can have some modules on your dev or stage, and when you export, it doesn't export you. So you get kind of create environment-specific configuration. But first, this is just for exporting. So basically, you won't export your environment configuration. And then, on the other side, when you import the configuration, you have to manually enable the module. So you kind of understand your environment. You can tell Drush, look, you don't know that we are on dev, but I'm telling you, skip this module, skip this configuration. So Drush, it kind of does what we need, not fully, but part of it. Config Split is a really interesting model. What it does is exactly what the name says. It splits your configuration in several... I don't know. It's folder at the end of the day. I was trying to find a good name to things, but at the end of the day, it's just a folder. So you can... You can have a per-environment configuration this state, so you say, okay, on this specific setting of Config Split setting, I don't want this module and this module and this module, so the module it says and how a configuration belonging to the module, it will be not exported on that block of configuration. In case of the primary, yes, it does. By default, all the... Drush, by default, takes care of the primary, so more or less all the solution they can deal with the overall problems of the website. Plus, Config Split comes with Drush and Drupal Console implementation with the OS command, so you can import just those blocks of configuration you want. It doesn't take care of the secondary, unless you rely on Drush, but this module is made for creating... splitting your configuration. It's known about dealing with the configuration. And of course, it doesn't take care of the initial, of the secondary as well, because it has to have this capability. It takes care of the environment configuration because this is what the module has been built for. Then another actor is Cotic Read Only, which approach the configuration deployment in a really drastic way. It just makes it impossible for your client to make changes on the production environment. So every time the client will try to submit on a phone a configuration change, the website will say, no way, this is locked. You can't make any change. So going back to our segments, that's configuration that only fuels this module, workflow deployment. Yes, it does. Everything is covered by Drush. All the configuration and synchronization web interface. That's it. Take care of the secondary configuration, which is the configuration that the client has to be able to create, but it shouldn't be destroyed by the input. It does. Configuration Read Only actually shouldn't allow the client to make any changes. Even if you create a new instance, it should say, no, you can't do it. But as a... You can create a module that hooks on the... I think it's an event that is patched more than a phone book. But anyway, you can hook to that Read Only process. What should I say, it's a Read Only event. It's an event. You can hook to the process and allow some new configuration. So it's tricky, but you can allow the primary configuration to be pushed, secondary configuration to be kept. But for every module, sorry, let's keep the speed. You have, even if it's a web UI or a command line module. So if you can do the same task from the web UI and or from the command line. You can do it, but then you cannot use the web UI nor the command line because it must be a web developer going there, building a module, booking on the event and subscribing the event and allowing some configuration. So one of these segments and one of these presentations I just kept an eye on the developer experience on then maybe the normal user experience. So the people that they installed Drupal already installed they don't know anything about code. They don't know anything about Flash. They just want to use the configuration. They want to have maybe the website locally with work or whatever it is. They want to have the website in production and they just use the web interface. So why should we keep two tools only for us developers? Everybody should allow to have primary settings and secondary settings not be deleted. So it could be a solution for these two, but it's only for coders. Which is a really interesting one and this may Drupal 8 configuration less scary. This is on Drupal 7 feature they lock this feature. So don't revet this feature when I revet the whole. Don't revet this particular part of my feature when I revet all of them. So what it does is importing the web UI from the command line. What it does is it ignores the new changes. So you can use it how it works is there is a web UI settings page where you can exclude or ignore specific configuration like we create web forms we don't want to delete web forms created by the client when we import. So it works with white card as well. What we do is we take the configuration name and we work on the configuration. For example we write web form.astresk so anything belonging to the web form configuration it will be ignored so it won't be deleted on import it won't be overwritten on on import as well. Does it take care of the primary? Yes, everything dealing with the trash it takes care of the primary but in this case it hooks even on what you are importing from a terminal guy even if you are a group of developers you can use this module to take care of the primary of the secondary and even of the initial configuration. So it deals even with the one type of configuration the one that I suggest you have it or not it doesn't work it's a bit tricky because it should shift the configuration the new configuration the one that you are suggesting together with conflict ignore settings to ignore the configuration so the first import because it doesn't know it has to ignore this configuration it will import it and then you import the configuration ignore setting as well so next time it won't be imported again because you just told the module say look there is a new rule and it's to skip this one it doesn't take care of the apparent environment dealing with the configuration maybe because config.node doesn't know anything so far about export it's just looking or subscribing on the import set not on the export so you can select the feature so when we hit on 2x7 the feature when you look it will override the feature but when you export it will export the whole feature again the final one is rush CMI tools which is a previous next rush extension which luckily takes care of everything for this presentation I thought about these 3 segments of configuration before knowing the rush CMI tools it had exactly as wish to deal with the issue so it was a confirmation that there is something going around there is something that we should talk about and probably there is some segments that we have to identify maybe these 3 or 4 good candidates again for 2 it's an extension of the config import export of rush it has CMI and sexy so it's does it take care of the primary? yes it does and there is default CMI integrate the partial so by default rush CMI would be like doing rush configuration import partial on your configuration we will keep on the configuration existing on production and missing on your shipping block if we keep the configuration on production what about new feeds what about old feeds that we want to delete these 2 so instead of keeping everything on production and it's not on my configuration you can mention there is this 3 configuration because I don't need them anymore for example delete these feeds there is this node type or there is this block because station leaves on my environment anymore so again we set the rush CMI by default it's the equivalent of rush CMI partial so it will take care of new configuration existing on production and not coming from my import it doesn't care of the initial install segment so when in import you can say in a different folder you can so it's something even that is out of power of your sync directory in a different folder you say 10 minutes come on it's not your life insurance on your import it's blue book plus production has this other configuration if it does this is for you and then exporting on an environment base segment you can just skip modules and you can enforce with ignore the list of configuration because skip modules by default on rush it's not buggy it can lead to unexpected configuration depending on the module can lead to be saved for your sync anyway in this case don't see a backwards text care of this saying be sure that this part won't leave by configuration anymore but it was a lot and maybe it's a new stuff it was the sketch that after the presentation available it's not just me that we recognize that we have this set when from the configuration this is briefly the process so we have a monolithic block and then on our side we recognize some segments and we know that on our export or the import process we don't need the environment-related configuration so this is the configuration that we have to ship which is the primary plus the initial configuration so this is the one that we ship but then we have to compare with the production one the production has part of our primary part of our initial and then we have the secondary configuration the new stuff that we are not aware of we should take care of that and that would be a summary of our configuration on production the primary would be deleted because we are the master the initial will be deleted because we have D so we will take care of it from the process but we have to keep the secondary configuration so about the secondary configuration that will be imported it's a merge of all this I don't know better about the sheet but all this block so all these segments so this then will become our monolithic configuration that we can push because the monolithic bit is what configuration management understands we have to work the middle part this is very good this table is very good so it's better how we see all the tools here all the segments that we recognize there can be more I just understand these three this is environment related so we can have one more on all of these segment of configuration and then in here how we can use this is good because if I I love flash I have access to my server I should use because it does everything for me but if I know if I'm a normal business manager dealing with I don't know cats I mean I sell fast food I don't know anything about curling or I have this website I know that I have my configuration I can use what do I do to deal with my things I can just use for example coffee to ignore if I just have these three segments of my configuration that's it really I know that we have three minutes so I'm really love if you have any love or any qualification for me this was an exercise coming from a real life someone mentioned to me you don't give an example we just got to ignore on our website mainly because we identified these three segments and we saw the company ignore does all of them but yeah and open to you now if you have any question or you want to throw me yes how are you dealing with custom content like menu items which are content or taxonomy terms that you can for structure aside or kind of custom block that has the address that needs to go on the site somewhere how do you get that kind of configuration content this shouldn't be a configuration there was a huge discussion about if content should be it should be part of deployment or shouldn't be part of your deployment on my deployment, on my workflow we leave content to parent and base we don't export the content so the content needs some production if we don't get the content I pull the database or I export the content in some way if you want to do it I think there is also a module called content default I guess where you can stage your content it's a demo I think it's yes, default where you stage your content but I think it's a one of the different here it's a common pattern sorting or shipping the content it's more about yeah, again, path based scenario, the situation you can do it with content default does he answer your question? yeah, it's just those bits of content that actually must be a structure that you need for building the site so you have to make sure that your UID will stay the same otherwise if you have menu items it's my main point and always one of us yeah, it makes sense maybe content default is a solution yeah and you stage those important ones but it is an excitement like core content core not like to back call both of your websites yeah what if you want to change some of the configuration in particular like a contact form you want to change the fields in the contact form but not the email address that the contact form goes to because the client controls that how would you manage that? that's a good question I don't have a both solution because this is not possible at the moment with the configuration tools that we have yeah I don't have an answer for you I never try I know that for example you can ignore configuration otherwise you can go deep to the settings I don't think you can at the moment because you go through the configuration names I don't know if you can go deep to the settings but I don't see how you you should be able to do it so going deep to the settings instead of limiting to the the whole config block by the moment I don't think this is possible with any of the tools I'm afraid yes man, what would you do for the how would you change the settings let's say in views or if you have that clashes how would you resolve it is there any good aspects this is a common question and it looks like there is a big step for adopting configuration deployment with Drupal 8 but personally I had this problem with features in Drupal 7 so I don't see any difference really what I can tell you is that now with Drupal 8 providing everything compact structured and standardised in a configuration that I actually think it's much easier to avoid these kind of problems then it was with a feature on Drupal 8 in Drupal 7 the way I personally avoid it is there is no global solution to this the personal normality is I try to create when is a problem we work in a agile way when I saw that a story is a possible case of complex I create more large features for each of the stories so I try to limit the change only to few lines and then it should be possible to me this is so far the only way so creating micro changes instead of global changes so hopefully someone will change even if it's all the same file just from line of settings . . . . . . . . . . . . .