 Hello everyone You are probably already noted that there are two surnames on the presentation But another guy he wasn't able to make it to make it so I'm alone and I will show you the tool which we Are using a lot in production. It's not about any there is no theory. There is nothing Strategies and everything it's about the real tool and it's about how it works and how it is about how we see the multi-site management Just before I need to excuse myself because if at some point you are you are understanding that I'm too complicated I'm saying some strange strange things and And just if you don't understand what I'm saying because I have a terrible Russian accent so So let's get started The presentation is about the document to Why it's document because it's it's the shortcut of a dog root management. So let me introduce myself before My name is Oleg Sidkashenko. I am a project manager and the Drupal architecture in Ajax You probably heard already about Ajax. We are the big company and We are the leader in Europe for the Drupal development I'm working with Drupal since 2007 from what I remember The version was like 4.6 or 4.7. It was horrible But now it's of course much better than before Originally I'm from Ukraine But since 2009 I'm living in Paris and working with Ajax for five years even more than that Then just a little bit a little presentation about what we are doing You probably all saw that already Before we start I Separated presentation into three parts the first part is Theoretical part I will explain what we are what are the terms that we are using the second part is the actual implementation The third part is the live demo about what we are doing So by saying dog root Everyone knows what is dog root for us. It's the Drupal installation Somewhere on the server. This is the place on the server where your configuration files are Where your application is so This is the main point of entrance for the local for the server By Here is why we created the tool we had different problems and most of them were coming of course from our clients and And And as a as our job is mostly about delivering solutions So I will just briefly explain what kind of a problems we were trying to fix with this tool and The first one is that we were approached by the big client who said that I'm not a cave with Working of was having a lot of Drupal websites with the code duplication and I have a lot of Drupal agencies all around the world working with the Different Drupal websites for for the client. Let's say it's it can be the just a client website or Any kind of website? It's just it's global global company. It's it has a little local branches and They wanted to actually They understand that when there are a lot of agencies we're working. They're all working with the same Drupal It's still Drupal 7 and what's good is that the Drupal was standardized as a tool for the website management there in the field for This client. So this is a good news but Every agency has its own approach about how how to work with Drupal some people use Context some people use panels some people use anything they want sometimes and people don't use views so And another problem is that all the deployment processes were different for each website So whenever one agency is doing the website for the client The standards of the relevant are different. The hosting is different. The deployment procedures, of course are different, too So Just to make it more clear We had the most the problem the most the huge the the most Important problem here was like the deployment of all the different websites is painful It means that the IT department of the company should take all the websites and Work with the with the hosting and deploy with different tools So it takes a lot of time and it's not standard. Some people use Capistrano. Some people use other tools like Chef Why not? The production environment was never stable They didn't know how to merge and how to work of multiple people and how to integrate the work of multiple people in one central place By insane multiple people I mean different agencies working on different websites because the goal was to reduce the time the time frame of the creation of the website and The standardize the process So everyone is working with the same standard process everyone is the deployment schema is simple The governance procedures are simple, too Okay, so the next problem It while I already say that but I just want to put the pressure on it. So then Whenever you have whenever you're a big company, you don't want to have a different approaches of development You want you want to use your own modules You want to be sure that whenever people are working on your websites. They are actually using always panels for example or always contacts and For example, all the features are in the default state So people are using features and the configuration is always in code Because it depends on the size of the website, but this is the best practice to have the features as default and Most of the people didn't know how to work because Whenever you're working on one website as an agency You are normally using the default director of Drupal and you're putting everything inside and it just works But whenever you have some standards, you don't know what we don't know what to do with that or you're putting them in all but There are some other people working on that. So you're not you're never sure The third problem the third problem that we that we got is the governance you never know about what is happening and You want to centralize Drupal? you want to use only one Drupal for for everything and You don't know who should update the Drupal you have your platform based on Drupal and all the agencies are using it and You need to streamline the process of governance. So the governance is always clear You know that there is a team who is working on the platform who is getting the Drupal updated the update modules they always know what's happening in your doc route and They need to know about the latest changes and versions Another problem was whenever you have whenever you want to to centralize everything you have your Drupal, you have your modules you have your automated tests and You never know in the multi-site environment how and when to launch the test because the One agency is working on one part of the website in the multi-site environment another agency is working in another part in another multi in another website in multi-site environment and There is no stable version of the whole platform. They don't know how to work with it and when to run the tests and the last problem is that usually cloud hosting doesn't really support the multi-site environment, multi-site management It always works because of course all the people from Acquire from Pantheon is already inside So it's it's not a big surprise for anyone So in order to try to streamline the process of working for different agencies Delivering different websites in one standard Drupal installation We created the tool which is called dogman. The dogman is the dog route management There is a website on github so you can just go there and look at it. It's very brief so we are working on the commutation and The first thing that you normally will do to test it you will have to install the Document game because the tool is written in Ruby So let's get back to the practical example This is the schema of how we see the different agencies working On the website on the different websites for one in one multi-site environment as you can see there is Everything is based on different git repositories. So each repository have its own code. We separated the project code Which is usually in your sites slash site module Which we separated common modules which are usually in sites slash all We separated profiles directly because some of some people actually delivering profiles instead of the websites It's another approach of the deployment we all also we have the core which is normal and There is a this yellow one the sites repository is the helper repository to be which represents the sites directory of Drupal 7 with sites dot PHP and all the common stuff for multi-site environment and The git cloud git cloud hooks. This is mostly about aqua hosting because aqua hosting provides this paradigm of Cloud hooks where you can launch different different actions We are the we are choir and For example, whenever you want to run any script right after deployment The cloud this is this is why they created cloud hooks. You can run different scripts whenever you need Before before I switch to the next slide, I just want you to understand that we created a constructor. This is a tool which really Doesn't need to know what what it's building. It can be Drupal can be Drupal 7 Can be Drupal 8 because we don't we actually don't do not rely on Drupal at all This is the thing that we used to build the dog root the tool Which is called dogman is taking all these repositories and as output it generates a dog root and this dog root Based on your template can be used Whenever you need and wherever you need because if you if you are using aqua hosting your dog root standard is There is one standard if you're on Pantheon It's different if you have your custom hosting. Of course, it's different too. So we are by using the tool We are streamlining this process of people working with different repositories and if I will take just a practical example of what we thought of what you see here is that You have project a which is one website. You have project B, which is another website and you have command modules and These are the standards you are want you want to people for people to use These are the standard modules like panels like instant settings like admin menu because we want all your websites to have admin menu There are profiles and of course there is there is core and You can see that there are all sites Okay, so let's switch to the configuration What we are doing is that Before document can build anything you should use your configuration files and put them in the proper places It's all documented on the website and this is one this one is a is an example of what we are seeing of what we are Normally doing when we have a multi-site environment with two websites common modules common profiles and Some default modules that you want that you want for everyone to use You can this you can change completely What you see here is basically replicates the The dog root of aqua if you look at the master master directory, you can see there is a dog root There are projects profiles and there are also hooks so dogman will scum Everything that you have in this directory and generate the dog root based on the configuration files and each configuration files each configuration file describe what are the Directories that that you that you want to use what are the Git repositories that you want to use in this example The I will I will need to show you I will show you later how it works So before the initial stuff initial the most important part of dogman is this Configure repository by doing by creating this you are describing what you want to build and This is the main configuration file so like like this you can see that you You are describing first your environments because normally you're if you're focusing on aqua and this is an example of aqua You are you have your development environment you have your staging environment and you have your production environment and By using them you are you are you agree you have an agreement that you have developed branch to develop to use the to work with develop environment stage and the master branch to use for the master environment for the staging environment, sorry and Production environment is usually deployed by text so It's only that it's just the tag in the master branch In this file, you're basically showing to dogman what you are What you are going to do and what is your dog root and In this case, it's aqua aqua cloud hosting and we are saying we are putting some specific configuration about What are the specific file paths on their poor environment? What are The SSH host what are what is this what is SSH user because that the tool needs to connect to aqua git and It needs first of all what it needs to be doing is to Push the dog root to aqua. This is happening automatically and incrementally and It needs to verify if the code is in place By by doing this we are our tool always know When exactly the code is in the is in the git repository and deployed in aqua because as you if you already worked with that you can You probably saw that between push to acquire environment and the actual deployment of code it It can happen in one minute. It can happen in one hour. It depends on the on the platform lot and our tool Knows and can verify if the code is in place. Why we are doing this because we need to launch scripts The tool is acting like a layer between the list of repositories that you have and The actual dog root in a multi-site environment. So we are building the dog root and pushing it to acquire this example that you see here is about Specific our specific example when we want to have the common modules for all your for all your people for all your agencies working with the same Drupal website and it describes the document When and where it should get the code and what to launch after You see this is like a constructor you say that in this directory you need the document you need to take the common repository you need to To describe all the environments and you say that that after execution after the build of This directory launch these scripts. We are using it mostly for launching drush features revert clearing caches all this kind of normal stuff and I will just skip everything here because it's we are what we are what I'm trying to show you is that Each each directory has its own configuration and this one is about where to get the Drupal core This one is about where to get the project code and the project code in this in this example is just What you have in your sites slash sites directory its modules Dems libraries, etc. This is core Okay, and This are this is the repository. It's why why we are using why I'm using a quay as an example because this Represents the cloud hooks of a quay. So you need the document can take this repository and put it in place Okay, as a features and what we were trying to do is That we are trying to be focused on the environments on the cloud environments like a quay and pantheon because you have only One gets repository there and if you want to work with the multisite environment It's very hard for you because you know that you have different addresses working in the same with site environment They commit some code. You don't know what kind of what what is the stable version of the environment? You never know how it's happening. So whenever people deploy something There is one website, which is stable another website, which is not stable So we wanted to separate all the code and then merge it and create the stable versions of the doc root This is very important. We are not pushing all the time the full doc root because it will be a big overhead We are always Checking out the difference and pushing only the difference. So you do your so your system will never push whole doc root with like like 20 websites All the time when it's launched and we are using it for the for the deployment I will show you the case study the actual example of how we use this tool to To manage a lot of different websites And it's not finished We have we are saying that we are truly it's ready because we don't really care what Drupal is We don't we just need to know the structure of the directories you want to build we are always working in adax with these standards that we are forcing people all the developers even sometimes it takes more time We are just forcing them to always keep features by default to launch to launch update DB all the time to revert features and to build registry whenever whenever they needed and All the environments have the same configuration. So all your agency The only thing they they need to do is to respect your standards They do not be possible for them to deploy your website without for example Reverting all the features. So it means that they will be blocked and This is very important to keep the configuration files. So this is what we are forcing here and If something hurts do it more often It means that all the time whenever it hurts all different engines Some people are okay with that sometimes not but you know on your side as the client that Your Drupal will always be standard your multi-site environment will be stable and People from one agency will never be able to touch the touch the code of other agency Which is very important for you because you don't want them to even have access to everything You only have your aqua for example aqua hosting with only one git repository and Your and we are acting as a layer And we can also support multiple doc routes because Everything is based on the configuration files. So whenever you can have the common Drupal common modules common Profiles and then you can say for each website Which doc route it will go so the tool what it will do it will take it will build the doc route and push it into specific Hosting in the specific place on the hosting it means that you will get your website Whenever needed you are you don't have any code duplication because the Drupal is always in place and it's always the same and like this For some of political reasons for example, you can separate doc routes. You can have two three Whenever we say we have a stable and versioned production environment It means that each time something is deployed each time the doc route is built the multi-site environment has the stable version by How we are doing that each repository that we use to build the doc route contains the stable version number and And when we build the doc route, we just scan everything scan get all the stable version numbers And normally there are in git tags and we are merging all these tags and creating a specific tag Which represents the stable version of the doc route like this you are always sure that your doc route is in state isn't stable position and We are saying that we are have a Jenkins friendly workflow Because we are just a command line tool so you can use it whenever you want. It's not only about Jenkins It's just about something that is building your tasks something that you are using to automate your process and You can see that different deployment scenarios can be achieved through this conflict you can Simplify the continuous integration in your multi-site environment Imagine that whenever one agency commits something Change the website in multi-site environment and they need to launch tests. They need to build something on top of it there They're able to do that because you always know that they will never break your multi-site environment You have your tool to launch your scripts. You know how to work with the scripts and you can deliver For each agency the stable the stable environment, of course Most of the people need to start from something Imagine that you you are new to this system and you need to start working with it and By doing that we provide in a simple command To which will generate your local build of the dog root It will it will be exactly the same dog root as you will see in a co-ailator It's this is the way for you to get your stable local environment to work on it Your agency your an agency you want to know you want to get the standard Drupal which is standardized in the company level You have you want to get the standard modules that are standardized by on the company level and you have your own custom code to produce so like this you will get the full the full Drupal it will work directly with you and You will not see any other multi-site environments So you will be only you will be alone in this multi-site environment You will not see the code of other agency, which is important for the client and then in order to work with the staging and and production environment and Staging and development environment we provide another another comments. What's important for you to understand is that it's very simple there is document build which says that document you need to build something and then there is a there is a Parameter saying the target and the target can be in the previous slide. It's local on This slide it's good target local means that you will just build the dog root and put it somewhere on your local machine and Get target means that you want that the tool to push directly something To your cloud and to your cloud hosting in this case. It's a choir by running this This common the first one the first one is you see document build the target staging will generate the dog root with By using master branches of all the repositories that we have Push it automatically in a choir. This is only one comment for you. So it means that Later I will show you then again example, but imagine that whenever you whenever your local agency changing some custom code and Saying, okay, this is read. This is ready for staging. They just push the code in the git repository and Your automated task machine like Jenkins See this and generate the dog root and push it directly to a choir So like this what you achieve the agency doesn't even need to know What is what the hosting is because your this is for your tool? It's not for The their job is to deliver the code that their job is not to understand what the hosting is What what to do is that they only push the code and it appears automatically in a choir by using Jenkins And we have the specific command to build a live environment Which is stable? document build get target stable How can you and how can you understand what kind what kind of parameters you have here? These are actually in the configuration file in the main configuration file So if when we when we say staging or development, it means that this staging environment is described in my main Configuration file. So the document knows what exactly to do with it. Okay? Next one, okay We don't have a lot of comments, which sorry We don't have a lot of comments here. We are trying to make it simple you for now you only have the init command which will Initialize the repository with the configuration. I will show you an example. So we'll understand what is that? We have a build command which will actually build something depends on your configuration And we have a bump command which is used for the production environment So Each time you work with the repository and you don't have to think about what is work What is where whenever you get the access to to the repository as an agency like you have your custom code? The tool always generate change log files By using commit comments It generates the version files. So you always know what is the stable version of the of your current website and you have Info files like almost everywhere Just helping you in describing you what what the tool is doing right now It displays a lot of debug comments You will see when you will if you will try to to use it You will see there is a lot of debug comments But this is for us because it's kind of I will say it's an alpha state were using it in production But we will always need to know what's happening and Let me just show you a small example the small case study about What was the problem we had and how we fixed it? One of the clients they were taking the Drupal installation with one website and cloning it for different For another websites, it's just the code duplication They changed the code they clone the Drupal Drupal database Drupal code and the website and then just change something and Then they changed another thing and like this you have three different Drupal installations without normal set environment And it's becoming hard to support it because whenever you need to update Drupal into do it three times So it's it's a big pain and the first problem is that everyone will get with this configuration is that The features whenever we clone the website You just you just change the site name and your features are already overridden So you have to work on again with the features you have to put them for the clone website specifically for it it takes time and The water is what I already said the manual deployment, which is not what you want to do The maintenance and the standards So whenever the website was cloned it was given to some agency and they are changing everything there and This is not a clone anymore. It's just another website which leaves its own life and This is a simple example as you can see that there is we only use Code of the one website code of the second website common modules Get core and the git sites like this you give you give an access to your agency only for the for the site a You have you give them the read-only access to the common to the core and to the sites So like this they can change only the code of your on their website and they have access to all your standard modules and on your standard Drupal core and As what I'm trying to show you that the doc root is generated by document and everything below it's in git So it's just five different git repositories. Nothing special and Sorry, I will get back to you again. Yeah So this is how this this is how the solution is managed Like this you don't have to think about What is what is wrong with the websites? You have only your one Drupal installation and the common the modules are standard and Each code is separated for each agency. So they are Very familiar with this approach and whenever they work on the website. It's still the normal Drupal website Okay, the next case studies is what is basically why we created the tool Because we wanted to really fix this these issues As you can see the company is global. So they have probably at least 10 or 15 different Drupal agencies all around the world building websites Drupal is the company level standard, which is great And what I work here that in our example, we had three different Drupal agency, but it can be 10 What kind of problems you usually get with that This is one of the problems too They are delivering independent independently different websites So all the standards are their own and you cannot as a client just say that okay You just need to use this one this model or another model because some people from their agency saying that okay I'm going I'm going to use only panels and rather say that I hate panels I will never use them anyway and the maintenance the same each agency has its own maintenance Standards non-standards Deployment what I already said They're just doing whatever it whatever they they want to do whatever it's whatever it's faster for them And this is what this is not what you want to do because normally you want to have a streamlined process You want to know how much does it cost for you to build the website? How much does it cost for you to standardize the process and what are what are you winning after? What are the things that you are getting whenever when they have only one Drupal core and multi-site environment and the kind of common modules and This is the schema of what was implemented It's basically the same you have the same different git repositories for each for each thing You need you want to you want to separate? you have the integration platform which is based on the Jenkins and git lab and Document of course, and we have a dog root which is an aqua cloud. It's only one subscription only one git repository and What is what is what is what's done here is that? the integration platform Have Jenkins installed and has github installed if you know what github is github if you don't know what is it? It's the it's like a github what for your local environment you can install you can manage the repositories in the web interface it's much more practical and Like this whenever you need to create different repositories you can do it with the web interface You don't have to go on the server and do some good in it bear on all this stuff So you manage all your repositories in git lab You launch your tasks in Jenkins by using github's which means that for example if one agency is committing only to site a The Jenkins via github see that some changes happened Build the development dog root and push it directly to aqua. So in five minutes it depends from two to five minutes normally The agency see directly the code in the aqua environment, which is pretty great because Whatever they need is they push the code and They see the result. They don't even know how what's happening and how it works the integration platform do it Do it all for them? Okay, so I will show you a small demo about how it's working because I totally understand that Whenever the first time you encounter this kind of system you say, it's not that clear the configuration files are big You don't really see what you can do with that and I Will just show you the simplest example with several repositories Here is the list of repositories that I have and they're all local I'm not going to show you something very complicated. I Didn't I cannot even push to any where because they're on my local computer We have The configuration repository, which is the main one where you describe what you want to build We have the core with Drupal inside. We have the sites directory with size dot PHP and all the Multisite stuff we have the project to re project to repository project one repository which represents just your modules teams libraries and We have you have your common modules which are in Sites all normally and This repository if I will show you this is this represents the aqua repository It will be generated and by I have it here to show you what's exactly the result of our tool so Let's imagine that I'm someone Who is not really? Understanding what's happening. I'm there. I'm an agency who is just want to work on this environment and I want first of all what I want to do. I want to start committing my code I didn't want to understand what's what's around here because this is the platform level and I Have my configuration repository and configuration repository represents this one and This is what they would this what was on this slide I say that the file pass to that way environment is this one You can find it all the time in the in the you are quite dashboard the URL to connect We are stages here the user is here and they have three environments dev test and put So the configuration repository contains of common doc root profiles projects and sites so each Directory has its own configuration Here I say that the common modules are here The development and stange in stable environments are here and represented by the branch develop master Here I say that the core is in this repository this the files are all the same as I said already, but I will I have to repeat the document will scan your config repository and Build whatever you say to build For the profiles in this case in this example, I have no common profiles for everyone. So it's just disabled like this these are the projects and Again, this is the configuration file saying that the project one is here What I need to do after execute what I need to do be after and before deployment and the same for the project to and Here decides the repository So let's get back to business. I'm I Know that I need to get my first of all I know there is some kind of a droop all installed somewhere and I know that it's a multi-site environment I've been already told and I want to start working. So I'm first of all what I'm doing is that I'm I want to I want to Init and get the initial state of the dog root. So I'm doing document in it. I say that My directory where I will work will be like demo dog root and The fourth the fourth parameter will be the configuration repository. So like this dog one will know how and what to build and I'm using my local repository. So It's somewhere like this Docman Okay, and this one is my configurate. It's my it's my repository with the testing configuration, which I just show you So what I'm doing here is that? This command will not do much. It will just prepare the directory for you to work so what it what it what it did is that first of all it's it's created my Demo dog root and I have only configuration repository here. Nothing more. Nothing less and Then I'm just building the dog root. I'm saying local because I'm a local computer I don't want it. I didn't want build the crew to go anywhere. It just stays here. So I say document build local development and we have a lot of debug information here and it says complete When it says complete that it will probably be a bit better like this We had this config repository We have now we have a new directory created which is called master and now and we have the states repository so the master repository is It's basically get all the information from all the different directories in your configuration repository and Get it all together so you have your common and I will just I just show you what's what's inside my different Common repositories. I have this common test. I have libraries module seems nothing nothing specific here and Automatically doc docman knows that I need to get this repository and it puts it in this directory Then there is a dog root This is exactly what we wanted to have that the Drupal core then there are projects with the custom with the custom modules and Websites and there is a subsites directory So by doing it by doing this I already have with one command my local development environment because I The only thing I need to do is to get This dog root directory that to get my web server and point this to the directory and it and it directly It will directly work you have your sites you have your project Have another project and they all come in from From different repositories and the tool just took all of them and put them inside. Yeah, we still have some some time Okay, so now as an agency I have my dog root I can work with it. I can commit some code So what I'm doing I'm going to the master Projects project one this represents one website and I'm on the developer branch So I just want to change something. I say that Do we have here? Okay, we will just Change something here and say like this and we just commit it as as usual. There is nothing specific here Okay, it's committed. So I just changed something on my website and then directly for example, I'm just taking this code putting in the station and I wanted I wanted to to to be directly committed to acquire so imagine what imagine what I'm what I'm what I'm doing here is that I'm just Doing a check out of a master branch in this example. It will be it will be fairly simple I will just merge my developer branch with my master like this. So so my change is now in the master and Imagine that whenever you do this commit, there is something triggers and build directly the docker on a choir which means that Let's take an example another example that I'm on the server and I receive the new commit So I'm just they doing one moment So I will get I will get this example. So I will just what I will type here is that and I want to get The actual state of what will be pushed to a choir so I committed something and On the server side We are Jenkins for example. I'm launching this comment Which means that I want to get all the latest commits from my repositories from the master branch Prepare them merge them into one place and push it directly as a target to acquire. So this is it Right now it starts to get Takes it takes all the repositories Get get this the master branch merge them and Okay, something goes wrong as usual. Oh, yeah, I don't have a stage That's an environment. So I will just build the development one Notice that it's trying to see it's saying SSH SSH target checker It means that it right now is very fine if the code is in place in a choir What is doing the right now? It's generating everything and push it directly. So I will just log into my acquire dashboard Okay And it says complete and I see my commit here directly. So what I just did I just Change the change the code in only one of my repositories Build the doc root and push it automatically to acquire which means that First of all your code your modules are all separated the custom code is separate and the tool is Automatically working with the kids repository of a choir. So you don't have to do it by by yourself If you of course you can achieve the same result by writing a lot of SSH as such script and bash and like this You're just getting this tool and working with it as you're working with the know with the normal environment and your builds in whatever you want to build So I will just switch back to the presentation If something is not clear just ask me questions after because I understand that it's kind of this is kind of a thing that needs to be First of all you need to think about that where and when and how you want to use it when you will understand the power of this tool You will see that by doing this you can achieve a lot of things you can achieve the continuous integration In the multi-site environment where you where you don't have where the code is separated, which is quite rare So I'm switching back Right now what we are going to do is that we are we are going to generate the background image for all the websites it means that All the websites in which site environment right now. They do only share code. So we only have the code You don't have any databases you your standard environment is different So we are going to generate automatically with the tool the background image Which means that if you are an agency working on the website in multi-site environment Then you just launch the tool and get the full virtual Machine with the doc root already built with all the servers servers configure configured directly and ready for your development Another another thing that we are going to do is that we need a wizard as you can as you already saw that the Configuration file is quite quite big and it's not that clear exactly what you want to do with that So we want to help people to understand so we are we are going to write a wizard for that and of course the commutation documentation right now it's in it's We don't have a lot, but on the website The example that I just showed to you is available So you will be able to replicate exactly the same environment that I did you will have the configuration is already Configured to have to have a choir as a target so just try it again What we are going to do and where we need some help if someone if someone is interested with that We want to have complete configuration templates for various environment It's a big pain for all the time whenever you need to create a new and a new Configuration template the result of manual work you set up this SSH host It's that's all those things to do So we want to prepare just the different templates So whenever whenever you want you will get your dog root built for Pantheon for example The deployment targets You saw only the local one when we generate the dog root on your local machine You saw git target which push the dog root to some git repository But we want to have more because this is not not a big not a big issue The not a big issue to create another target saying that just take the repository and put it of some SFTP file and some FTP file system. It doesn't it doesn't change anything It's just the target of where you want your dog root to be to be hosted and the templates Okay, so now if you have any questions just let me know Please you can use microphone here. I think Okay, so I thank you very much for the useful presentation. My name is Mori. I Have a couple questions around it is a bit more higher level than actual the problem that documents trying to solve that there's there are some implications to sharing a Or different sites sharing a dog root for example If you have different sites using different modules, but on the set, you know on the same Stack then those sites would be sharing like APC and then cash and all that. Yeah So, you know, there are some those issues Some some of the issues which I'm aware of but can you identify any other kind of pitfalls? There is there is a one pitfall and for example, and let's take a course an example It's of it says you said it's a PC memory because like this If you if many where if many websites are not a what many different agencies are not aware about what modules are used and They put some let's say let's say they they take views and put them in their local code Which will generate a big duplication which will of course take a lot of PC memory So this is kind of thing that needs to be managed mostly on the on the platform level Directly saying to agencies what kind of modules they can use and there is not a lot of code duplication So we are using this tool for one dog root with at least 55 websites inside so it generates It's for only two agencies, but it they're all very separated and it's it just works Okay, and sorry another question. So, yeah, of course So if there are various Benders working on you know multiple website on the single Drupal installation and if you need to upgrade the Drupal core How how would you coordinate it because there are some you know co-op days for example triple seven point two three or two four which addressed Dorsi shoe with Men men cash and you know things like that You know that have a big impact on all sites How would you manage that the workflow for updating Drupal and this in this case It's one of the things that we tried trying to solve To it to try to solve and we achieved it means that you have your own Core repository in it with the Drupal core and there is a team who is working only on the platform who is Responsible for maintaining modules from that in Drupal. So they just update Drupal in this repository and they write And there is a way to launch some scripts When the docker is built? So they just write scripts put them in the SH files in the directory and you they Build and your tool and none. Sorry the Jenkins which builds the doc root. It just launched It gets the latest Drupal core generated the doc root and launch The script which will launch all the updates like update DB for all the websites in the inside in the environment Because the tool already knows how many websites they have and you can easily write a small configuration small script We should just Do for each for all the websites in the environment launch this SH command So this is the workflow. We imagine how it and we already did it once and it worked Thank you very much You're welcome Any more questions? I've experimented with the multi-side environments in the past. So I actually made scripts in bash Yeah, it's kind of sucked but it works everyone had this kind of scripts here and there And that's why we actually started to taking the Ruby approach is very nice but one problem I ran Frequently was having different versions of modules patches patching core these kind of things are Quite hard to maintain on this kind of infrastructure but one particular usefulness I see for this is for example when you have An installation for each client using this tool and you just Add the components you want the tool to fetch and to deploy on the specific environments Yeah, this is a good use for this tool. I wouldn't use it for Managing multiple sites of multiple clients. I think that's way too risky Let's just a remark Okay, yeah, I mean this kind of this kind of there are a lot of different use cases of the tool We are using it to build the dog roots And pushing into some servers But you can actually build anything you want because there the configuration fails are standard and you just only you only say what to get from where and where to push and like this you don't have to write tons of scripts and Your Drupal environment will be ready directly and you don't have to like do a git clone of core Do a git clone of the project file You just launch the build and work with it directly precisely Where I see the the great usefulness of this tool is automating the Bigot clones that it pulls and deploying. Yeah, this is what we are doing with Jenkins For example, we are we created the development and staging workflow are quite simple whenever someone commits to develop and Push to develop branch it generates a dog root and push it directly to acquire incrementally So there is nothing specific the same for stage, but for the production what we are doing is that first of all we are We are Jenkins there are different modules and you can say that the build must be approved And that and we are using this tool and with in this in the merge with cloud hooks saying that Okay, whenever someone bumped the version of the stable of the stable Website they say that my website has a version 1.1 What we are doing is that we are getting The database from production environment we are cloud hooks We are putting this database on the specific environment for automated testing and We are launching the automated tests Directly because we can build the dog root for each environment quite fairly easy So you see you see my point is that I just Launch I launched the tool it gets the database from production to the array environment Let's say today the testing environment and the launch test because you can you can simply launch tests with it Whenever you have the the way to put as such SH comments inside You just launch big head test or whatever you want and in Jenkins We can we can say that we launch build and the build is not pushing anything to acquire until it's Validated by someone there is a team who is responsible only for that They are seeing that the new dog root version has been built the stable tag is this the change log is automatically Generated by taking all the changes from all the repositories and they say okay I validate the build and Jenkins continue to deploy the production environment to acquire and in a quay you are getting the I cannot show you the real example because I don't have a production Subscription on a quay, but it generates the tech which you can just directly deploy from the dashboard Yes, yes, yes, precisely the tags are really useful for deploying specific stable versions Yeah, so we generated by using the time and the date so you can directly see what's happening Okay, thank you very much. You're welcome anything else okay, so thank you very much and If something wasn't clear just find me I can I can explain you because we have a lot of different case studies So I will answer all the questions. Thank you