 Welcome, this is Conferration Management for teams. I'm Tassilo grüper and From the next half hour. I'm gonna speaking here. I am from the company called wondrous We are wondrous situated in Basel where Swiss based digital agency design agency. I'm a so-called full-stack developer whatever this firm means and This talk actually Is originated by a colleague of mine our IT team lead Reiner Friedrich and Unfortunately, he could come so I'm giving the talk today What we do is actually heavily Inspired by daily business and Because we found out that of course we need to have a workflow to safely deploy on production a Workflow to actually maintain more than 20 triple projects Drupal 8 projects in parallel. Of course, there will be other challenges growing and Of course, we are trying to reduce the onboarding time for every new colleague for every Project I need to check out because I have to check a bug or something like Try to keep it in less than 30 minutes And of course we need to have a clear path for a developer to a unknown or new project So We're trying to have the good ability of deep playing feature and to feature and production branches. So Let's recap what configuration about the Drupal 8 configuration system and the configuration Can that can be stored in the version control system? Would look like so first of all in Drupal as you all know We can do a single or a full export via the UI So just if you want to fiddle around a little bit then you can you can do this But the actual way to do this is using the command line. So the normal drush Cx config export command so But you have to always keep in mind that the site owns the configuration not the installed module Meaning updates to model code configuration Can only happen to update functions so called update hooks, which we will hear next about But you also have to keep in mind that configuration this kind of configuration We are talking about is meant for different a virus of one single site. It's not for different sites. It's not for so-called multi-side Installation because we will have you your IDs miss mismatching so different content will generate different you your IDs and this will not work with different configurationments and the next thing to actually set some configuration is to actually do this in a Overwrite in your settings PHP So if you have for example a local settings PHP as you can see Up above there is the config variable setting the Logging as well as a system performance and way down you will also find the config split configuration for production and Development there are two config storages, of course We have the active configuration and the so-called sync configuration the active configuration lives in our Database or in a persistent cache like Redis and we have the sync Configuration which is part of our version control system mainly git or whatever version control system you need So our goal would be to use the configuration as code and why would we do this because if we treat treat this as code we are able to Change something on the remote by just in deploy so changing configuration on the remote is actually just like changing configuration on changing code on a remote and You really have to make yourself clear that Production configuration is only a temporary thing. So Since it only lives in a database. It's not versioned at some point and it's not replicated in a version control system Thus We don't have any history of code. So we want a history of our codes We can have a look at our code. We can have a look at our commits And so our configuration if this configuration is treated as code can be reverted and Of course, you actually have to export your configuration outside of your web route. So I think that's quite readable So we normally have this as a as a root folder in our version control system put a config folder in there put a Drupal in there and default and all that stuff we exported there and That's actually the hardest thing to do we need to automate it like everything We are the need to automate the database updates. We need to automate the configuration import and In the ideal way of doing so for example, if you do this on platform as age You need to separate between a built step as well as a deploy step as you can see in a built step You actually push pull all your dependencies with composer. So PHP will be Well configured you pull all your MPM note modules in this case we use yarn and Write all the nice files we actually need to have our site deployed Into the build and when this build can be deployed so connected to the database We actually have to rebuild the cache update the database run the database update hooks and import this very configuration we are Fetching from the content management system and then do our entity updates That would be the nice idea So there are two challenge and challenges actually doing this First of all We have to limit ourselves and that's something really hard to do at least for me as a developer I would like to be able to do everything but limiting the client's capability is Something I would like to do because a stable site is actually the site nobody touches But yeah to be more realistic the client has to do something on the site But we have to differentiate what he or she can do so we first of all have to limit the client to Change content only and what is content? So we have to make Realize what is the content on our website? So changing the configuration on a live site and letting others do this May have unwanted side effects first of all obviously The live configuration as I just said since it's temporary temporarily may be overwritten by the deploy itself and The config import may also abort due to differences in the live master configuration state It can also depend on content So if there is a custom block is there is if there is a custom taxonomy term that's not yet existing order or Not any more existing in the live database, then we will have a new ID mismatch and the import simply would Stop and be aborted. So and the second thing is web forms I'm highly for web forms. I really love this module, but in case of configuration and content difference This really is a hard nut to crack So web forms themselves are configuration entities, but their submissions are not So if you try to actually delete via the config of configuration update a web form that already has submissions It will say mm-hmm computer says no if the client is allowed to create update and Create an update web forms a deploy actually would delete his or her changes or as I just said simply be aborted So there are possible solutions to this Challenges so to speak they are not real problems, but challenges and Yeah, so part one would be to see if we can automate and import and See what are the changes in production are doing and the first step would be if you're using something like aqua Dev desktop To actually pull the database and export the configuration from there This may not always be possible So we also have situations where we actually are not allowed to have the database on our local machines due to sensitive data There may be some jump hosts in between and an automated fetch can also not be possible Then the database can be huge if you are not excluding your caches to a different service or something like a database of minimum one gig is fairly usual and Caching the database clearing the databases caches just before pulling something is also not always the always the best way to do and Yeah, we also have the problem with the local Development config split was the pot config who have you heard of config split the conflict split module? Okay, I'm not telling you something new if anybody's new to this thing. There's also a very nice I should be a very nice talk to this at this conference as well. So we want to have Locally a different setup than on production. So and this local setup We actually need to import before doing so. There's also the possibility second second possibility to Set a config read only with the conflict ignore module Aki aka Yolo mode because what will happen what will happen is you allow changes to certain areas of configuration for example web forms and You white load list those Sounds fairly simple. It's okay. And what you're actually doing is you try to ignore some configuration While the import or the export what will happen is that it's fairly ever-prone You will lose track of those changes So if you change something in the web form my new web form and so on you will not track this in your version control system, which is fairly the thing we wanted to do and so losing track Second thing is you cannot update those white listed convicts since you are Whitelisting them on an export as well as on the import You have to do everything manually on every either a stage So and update update hooks you may be not aware of that they are changing code and those changes You also do not track. So if you think of setting up this very website from a Default database you actually have to clone the life database again and see if there have been changes or not. So you're also losing track about and One very very annoying thing is I had this realization in the project of ours. You actually need to deactivate some UIs first of all the views UI because you cannot change anything in a views UI when you're in a read-only mode for views and Of course, you could do the export as a third possibility via the UI But this really does not play play well together with conflict split and you It's still a manual task. It is inefficient. Thus It's very error-prone as well So we try to come up with a solution which is fairly simple put but it took us quite a long Long thing to discuss because we had we had to address all those problems. I just mentioned First of all, let's recap the requirements. We wanted to have we want to have an automated build process on platformers age or mazio or whatsoever we want to use the conflict split module module and We have to have at least locally a kind of like setup that is on the prod Setup so step one easily would be to export the remote configuration into a private writable file system on the server and then sync those those changes to our local Server or a local site or a local dev environment via our sync and step two would be to Actually have a certain workflow how to manage your git repository. Sorry. First of all, the master branch is only for deploying So you would not do anything Besides and hotfix on the master branch Second you use feature and deaf branches for continuous development that's easy and You would could meet those Pot configuration production configuration into into the master So as I just said, you would not use the master as a pure develop the pure development State but you try to keep the state of the master as equal to the production state as well plus you try to Use git to merge the features into the master branch, which is fairly simple due to the fact that configuration is a Yammel file and it really nicely is able to be compared in a diff And That's fairly easy, I think I think no right But we realize that timing is very important at this point because before merging those features into the master you need to update the master configuration with a prod configuration and You have to heavily make use of automated scripts as I just said I'm sorry for the big black screen right now But that's the more easiest way to do and if you see the slides It's also helping and we slowly go through this So first of all we wrote our own script and hopefully you could yeah, it's fairly simple It's not very explicable, but if you go through a little bit then we will see that Give it a short one two three So first of all and it's just a script we wrote it's in a shell script. I started up with yarn That's nothing special. The first thing we have to acknowledge is at the moment. I'm standing at the actual feature branch, which is called front-end in the upper for you right and This feature branch the working director needs to be clean so that That's that script would abort if I would have enough not have a clean feature branch So first of all we need to check if the working director is clean then we check out the master branch Maybe battery is low. I can start going over here and After we checked the mark checked out the master branch We can optionally sync the database or file. So the script is fairly Adjustable in this situation. So normally I don't want to pull always the database to refresh everything I had there But in this situation, I also want to update the database because I want to show you something and then conflict split Conflict split part one gets into Into play because first of all the conflict split will export the default configuration and second of all Conflict split will export the production configuration Then we will reach our sync as I just said, this is a temporary folder on the remote server pull this information to our from remote to our local server and I'm just scrolling down. So after we pulled the remote database Pull this information, then we also pull the database and overwrite our local database then we because our master branch has the current state or the last current state of our configuration can now give us a correct diff difference to the master to the master of the remote and and We can finally run our database updates re-applying our dev split as you can see So we have a kind style file proxy Syslog and for example raven will be uninstalled. So installing and uninstalled are installing and in the end we switch back to our feature branch and now in our working directory We have changed files We are able to have a look at and be able to commit first of all we started off just having a automated commit of those files, but soon we realized that this would be That this would be a counterproductive Because I realized that some changes I made got committed but I did not want to commit have them committed right away and thus it really is counterproductive so Using this as I just said since there's a timing Timing sensitive we have a dirty conflict so-called dirty conflict problem because in situation one and my slides are going through and Situation one you just forget about it as we will just see in a second Yes Situation one you just forget about to actually sync the remote database And so with a master's not up to date and situation two you have a critical period during the deploy hooks some deploys take ten minutes to deploy five up to ten minutes and The first thing you would try to do is obviously to reduce the build time. This is not always possible so during this time there can be changes to the database and you can't do anything about it and So a proposition we still have and the module is up to be Created needs to be doing the following. So We could do on the one hand always export the configuration on production when configuration changes so with a service with a with what's it called With a service listener you could always do a drush export on production into this very Template folder if anything anything changes or you could easily set a dirty flag on production in whatever variable then before pushing to the Production you actually check this flag with a github for example and then if this flag is set you prevent the push to the master or you prevent at least the build Until the Flag is cleared due to a Sync we have just seen so if I'm actually pulling something and updated this Then I am able to actually push to the master again There are still some quirks you have to work out on this point But that's the actually fastest thing I we came up with so far, but yet there's not a module for that So if you have some insights on that, please remind me and There's of course content depending on Configuration or the other way around config is depending on content So as I just said view filters may depend on taxonomy terms that are not yet existing We could have custom blocks that needs to be placed But the you are the changes of course on production since it's not already there So you have to create content maybe via an update hook You could use the default content module to provide some content Or you could also use the structure sync module to export actually terms custom blocks as configuration and Of course, there is the composite development process meaning That's actually related to the config split as we just saw why are we doing this so easily for security reasons and performance the modules on production and Your local environment may have to change not all of them But certain critical ones for example development stage five proxy or coder and production We can also think of CDN century or fastly so in this case config split comes in and enable allows you to actually enable and Unable The configuration on set the configuration locally So as we just seen we actually have our configuration folder in this configuration folder We put our Drupal configuration We have all our default configuration in there and if we want to have something like that for a prot we split this and Keep it in a general folder and only certain modules Put into those and yeah since Drupal does not need those configuration of modules that are not there or yet installed It's also fine and with composites fairly easy. You just put those development requirements into a the required def in your composer Jason and Production in those will not be installed and as we seen in before as we have seen before in the Settings PHP for your remote you just switch the config split Development and production status to false and true and There you go so Once again the basic workflow would be To not hear myself too much The basic workflow Of course the order is important. So if we have at a thank you very much If we have a quick look at what to do with rush in this case first of all we need to need to run the database updates and then we have to actually in export the Updated configuration when we are locally we push this to our we push this to our version control system and On the server we actually want to import this configuration So we drush up to be because we do need to run the database updates aka update hooks and then we can import the configuration we just have in happen to have in our Version control system and Optionally we can run the entity updates and One last reminder That is also on time if you want to actually Uninstall a module you have to make sure or you have to realize that this is a two-step process It's a two-step process because for first have to uninstall the configuration set the onions and the configuration as uninstall so in your core extensions this certain module will be removed and You commit only this change so Drupal can actually run the hug the hook uninstall and Remove key entry key valued entries from your table and as a second step then you do the composer remove and Commit the removed the smaller Files so Drupal will not greet you with the following modules missing from the file system That's still a problem. And if you think about that maybe a deep deploy it takes six minutes or something like Concurrency is also problematic So you're stuck for like ten minutes and just waiting and maybe doing another push after two minutes. Yeah, it's kind of strange so if you want to have a closer look at The conflict split go check out the advanced configuration management with conflict split The script I just showed is without warranties, please for those who love to shell script At this very just are paid I I set up there and you can find the slides as this very well. I surely need to Remind I surely do does not really need to look. I should really do not really need to remind you to the sprints on Friday and Please wait to talk. Thank you very much. I still have like three minutes May I have some questions if there are some if okay The question was what's the strategy for blocks and block placement? Yeah, it actually is this manual process of first of all Allowing the region to be there maybe if you set it in a region and then actually to see if this block is a Custom module block or is it's a custom block by the created by the UI and at this point Yeah, we do this manually in both situations, which is really not the thing, but if it's Getting bigger and bigger therefore our update hooks. Okay. Thank you for the talk as If I understand stood you right you actually pick up the configuration changes from your live server, right? And you commit them. I mean, how do you know those changes were Deliberately done. How do you actually decide to keep them or throw them away? I mean a lot of the time there will be some kind of idiot just clicking around Try to change stuff and they never make kind of change do the reverse changes and So what I normally do personally I throw them away and say I They were probably bad And So having deliberate changes on the production server actually just plainly place into the system of having One single source of truth So if we go live if we are going to production that means that the developer even if he's on only Developing with himself on himself And May have the configuration all set on his machine and then he can also push it if the developer starts off with the Frontend team and the first content management. We directly change to the master to the production side as being the single source of truth so changes need to be Changes on the development on the production server is always the only source of truth and Changes coming from there need to be there But but in in CVS or get you normally your commit message will be Why did we do this change and if you didn't do it? Someone else did and it's just changed you you can see it changed and you could say well It was probably good, but how do we know it was why why did they actually do it? basically because you kind of arranged with the client that This part are able to change So if you allow the client to change web forms, then you see that changes in web forms are valid But this is also a very long topic. So please see me afterwards and all of you As you have seen call us give us a note and maybe a high five buy me a beer something like that and Come and talk to me if you have further questions Thank you very much