 So good afternoon everybody and welcome to my session about manage and deploy your site with thrush Let us first begin where my my name is bastion. I work with amazing labs in Zurich You find me on Drupal org under Das Recht also on Twitter and on Facebook and everything Um, I'm also the dev ops chair the track chair So I organized all the talks you hear during this loop I come in the dev ops track and As job description, I'd like to point out. I'm from the fuck it. We do it live operations. So there's no dev ops We do that so for this afternoon, I give you a Small introduction into drush deploy. Where are we today? Where do we want to go with thrush deploy? I will cover everything that you need to put the things together because it's not just drop a module in flip a switch and then get going and I will also cover Some parts on Drupal 8 how it does work what currently broken whatnot. So Um, where are we today? So currently a lot of people are using third-party frameworks like Capistrano or edifics. You probably know them. So who uses Capistrano by show of hands? Some who use something different Okay, good. So there are currently a lot of deployment strategies like we Deploy on one server then we are sync to all other servers and hope nothing breaks There are some who use custom bash scripts by which I usually relate to duck-take deployment because it could break in some points. It will not break. It's not the perfect way There are also Deployment strategy, which you probably know of from years ago, which was FTP upload Yes, that still exists. We still have customers which say yeah, we want to host an or server It's really fancy. It's fast and you get an FTP accounts like okay, that works. You can do it, but no And there's also just checking it out on the live servers do a good pull and pray that everything runs through Yeah, can you please close the door? so Some words about drush deploy the main maintainer is mark Sonabalm I don't know if he is here yet yell if you are Give a nice hand to that guy and back. He did a great work on this so The whole drush deploy is in heavily inspired by Capistrano and There hasn't been much movement since the whole drush deploy has finished because it Has any functionality we currently need so there is not a lot things we just need to add So it supports just git which is okay for what we use and it needs php 53 at least So there will be some changes for making it php 54 ready. That's also in the making currently So something else to deploy who knows about cluster SSH Who loves it? Okay, so I refer to that one sets the DevOps way to kill five servers with one keystroke because you run one Comment on several servers and you do it remove directory and you find out. Oh, that was the wrong directory And you successfully trashed your life environment doesn't happen Yeah, where do you want to go so The idea behind drush deploy is to use a tool we own all know by heart which is drush So we also want to do multi-server deployments So not any site is deployed on just one server for amazing labs We have around five web servers and not all sites are running on the same servers. So we don't want to deal with the burden to make everyone everyone everybody and Aware that yeah on which server are those clients deployed? We just want to do a drush deploy at life and it should know automatically what's done We also want to run tasks like updating DB's running custom scripts and doing monitoring things like automating everything that you could probably miss out We also want to remote cache All the git things so we want to have a speedy deployment without needing to check out a 150 megabyte git repository multiple times and trying something like that and We will also have the possibility to roll back a release So if something fails, we want to go back one step We use this sometimes when you try to enable HTTPS for example you do some changes and then something is missing and you see oh There is one side which on the customer side which behaves a little bit differently and we need to roll back now and You just can't roll back then with drush deploy. So as a small conclusions We try to sneak in a little bit more automation which leaves then less room for human error So look at your future deployment Guess like this We run drush deploy at life and hit enter and Actually, that's a pre-recorded yesterday because I didn't want to do it live now because when I need to fix a site During a talk with a packed room. I don't like it and it adds a little bit of stress so what do you see it first loads all the alias web servers then it starts to deploy and Then it checks out all get some modules. It does magic to the sub-modules and some seconds afterwards We have deployed Easy isn't it? We also have a nice little message on the hipchat which says hey I Deployed a site for a customer So that said I try to enable all team members to deploy To live There is no need for me to do to do a deployment because When I get sick no deployment is happening So everybody should be able and you should really strive to the way that you can enable all team members to deploy So that happened. I told two people from our sister company amazing metrics how to deploy with drush deploy they did it and Five minutes afterwards the CEO came to my desk and asks yeah, that's really nice And we like that you do that, but what if they break it? That old yeah, they can break it, but we can also fix it because we can roll back so You need to Calm down some people sometimes So now back to me should we put all parts together to see what's needed to do a drush deploy of course So we start with installing drush deploy we then cover a bit of the drush aliases. So actually who uses drush aliases Good very good So afterwards we will then cover the drush deploy configuration and we will do our first Deployment like running through what it would do So installing drush deploy is rather easy. We just run We just go to the drush directory, which is in your home directory You get clone the actual branch and you run a drush cc drush After running then a drush Command without any arguments you should see that there are now the drush deploy actions So that's quite easy Now we need to get the Drupal sites ready Which is a task when you have more than one side could be a little bit tedious in the end in the beginning so We need to do some standardization We need to clean up all our environments. You need to establish some standards for let's say configuration You need to have like a settings local that php as Drupal 8 does it you can also incorporate this in Drupal 7 I will have some code snippets afterwards You need to standardize your File path your web root path. So actually you need to have a Setup that every customer sites look almost the same. Why because it eases Your workload when you need to change something over all customers you host so what we do we have the settings php committed to to or get repository and In the end we just check if there is a settings local that php and if it's there We just load that when you load the site so That eases us a little bit that we just have the Site related settings in the settings local it gives you a better overview and all configurations you will have in Your standard setup are committed to the repository. So you don't need to change anything there What we also do we do We move the settings local that php to a directory, which is accessible from every server So you just change it once and you run a deployment and it's deployed on every server But we still copied the file to have like in every revision in every Deployment you do there is the settings that local that php Which is exactly from that revision that you know that you can go back and you have the old file again So that's nice, but we also need the aliases. So some of you know the aliases already aliases is a way to tell the rush How your environment looks like you can say that there is a web server one You can give a web route a remote user and the remote host so drush automatically knows by running a Comment at web one on which server it should connect You can also say web 2 is the same as web one, but the remote host is web 2.example.com Which is really easy So what does this enable us? We can run Drush at web one user login We'll take some time drush makes an SSH comment to the server it runs in ULI and it gets back to One-time user login URL to your shell. So that's nice You can also run a drush SQL sync from web one to your default default environment and you get back to data That's also something we you we use regularly because it eases the way you can move data around You don't need to dump it and copy the file you just SQL sync it and you need to know on which server but usually we use the web server one for Connecting to the my SQL server and getting the data back. So that's about aliases I will go a little bit deeper on aliases afterwards because We evolved the setup which we use for drush deploy a little bit over the last two months. So I will Have this somehow split in two parts is the part which I describe how to set up easily and How we do currently the deployment stuff? So drush deploy configuration there is drush deploy.drushrc.php Which has a lot of information in it how drush deploy knows what to do so first you need to know drush deploy needs to know where the deploy repository is so you just fill in your deployment repository and you say Which branch it should deploy I Personally strongly suggest that you adopt Somehow a git workflow We at Amazelabs use the git flow which has It started out that we just wanted to do it and then we try to incorporate drush deploy and say okay Now we need to do it. So what brings git flow to the table? It's one of many branching models. So I don't say it's the right branching model, but it works fine for us So we have a live and the dev branch the live branch Nobody ever commits directly into the live branch. So all Merges to the live branch are done by pull requests or manual merging There is also the way to To use future feature branches that you create a from life From life you create a branch which has the feature number you develop on it and you merge back to the life There's also hotfix branches, which I personally use quite often if I need to fix something fast So I go from life do the hotfix and get back to life. So that's what and one Important thing life is always deployable. There is nothing like oh, yeah We shouldn't deploy life because it will break some small things That's not gonna happen because if you have that you will not be able to automate it Because when you have a life branch, which you can put your hand down and say, okay We can deploy it at any given time You gain some confidence to just run drush deploy at life and it will run through and decide will not go down So that's something you need to do there's something else in the Deploy.rush or C.php the keep releases keep releases tells drush deploy how many release directories it should Keep so that's the steps you can go to roll back Like when you have ten you can go back ten steps in deployments If you have just one you can just go back one Actually, it's not cleaning up automatically So when you run the cleanup there is drush deploy cleanup it will remove everything. That's over that threshold so that's something also worth mentioning and If you use git sub-modules for having the modules you need to tell it get enable sub-modules to true that it knows That it needs to check out your sub-modules unless you will have Drupal site with that some of those the next thing is the file system structure, which is quite a bit different to what You usually do for deployment. So You can prepare your server by running drush deploy setup at web one and this will create you different directories It will create exactly that directory structure without the Public HTML the public HTML is what we use so we have For every website a user and a public HTML directory, which is either a folder or a sim link So pop it when it runs through and it sees oh, it's not there It creates a folder and if there is a sim link or already a folder. It does nothing. So in the current Directory that's a sim link to the latest release. So the current directory always links to a release folder and We have the releases which is a Folder which is created for every time you run drush deploy So you run drush deploy it starts to create one of those folders after it's done It will link to public HTML No, it will link the current directory to the release directory and then the deployment is done We also have a shared directory Which has a cached copy of your whole code? So it does get check out the git pull is all always done there and then From there we copy it over. I will cover that later and we have the public HTML which Always links to the current directory and the current directory always links to the latest release So you see that's a chain of sim links, which is probably not optimal, but it's currently the way we go So what exactly happens? When we run drush deploy at one it goes to every web server It updates your remote cache like the shared directory. I told you it initializes and updates the sub modules So you have always the same the right version in it So and it does it it does it in a harsh way. So it just Trashes everything. That's not as It's described in git. So you are sure that you have the right versions It creates a new release directory and copies over your code base to the release directory It then links the current directory to your current deploy code and Executes the tasks we define if something Goes wrong you can run a drush deploy rollback and you will get back to the web to the Lightest release so it will just switch The sim link as it does for copy strong for example So you now tell me yeah, that's nice, but what's about drush deploy at life? so For multi server deployments. There is alias lists who uses them Yeah, you of course you invented it somehow well drush enables you to tell drush There is an alias life and you can give it more Servers as we just defined them at web one of web two and drush then knows that It's a group of servers So you cannot do every command with it You could do a drush ULI and it will go to every server and give you a one-time login link for every server Which is pointless? But for deploying you can group the servers together so That's nice, but I told about standardization keeping the things together We covered that so If you don't know about a drush alias a thing Go to that URL read through be enlightened because there are a lot of things you can have parent Aliases which take the same data as the parent has There are a lot of things which are not widely used, but they are there since years so Let's cover automated aliases What we do currently is we Create the alias files on the fly so We have a file which stores how our servers are set up and that's a JSON file Which is really easy to see like it's even Open to the wild it's on our GitHub account so there is life is web server one web server to a web server three with the eyepiece and We try to build the server groups Automatically, so or Ali alias is five currently looks like this We have a site name which is the unique identifier to the sites and from there we can Find out how the site should look like and we also can override it in case of we want to override something If some site is currently just deployed on one server Which has changed a JSON file for one customer which then overrides the standard configuration You ask about the time to implement this it was about one evening We did it last year at Ruppelkamp proc the whole team sat together for one evening We went through all customer sites and moved to rush deploy in one evening. It was around I guess 40 clients 50 clients, so You can do that quite fast deployment tasks You can run deployment tasks before or after moving to a new version and You can also say if you want to do it on one or all servers So a drush cc all you just want to run it on all servers because you will have quite a lot of time Wasted when you run it on five servers and it does the same Also Something that's important to say don't link settings files copy them We first linked the settings files all the time and then found out that it's probably not the best idea Okay, we came across that idea at 2 o'clock in the morning So linking the settings file was perfect But when you try to roll back and you did a change to your settings file you cannot roll back because it's a link So don't do that copy settings files um What are we doing with deployment tasks? We update and link Settings local files because we can we will copy it with any revision and link it inside their revision So every deployment will be linked, but we have it copied. So it's also version We will link the sites default files because we have it Centrally stored on one of our NFS servers We will run a drush up to be just on one server We will have run a drush cc all also on one server and in the end We notify New Relic about the deployment which then goes back to hipchat and informs the team that the deployment happened That said having New Relic integrated with hipchat is a really cool thing because every everyone is Kept in the loop what's happening because any anyone from the team knows that a deployment happens So if you see a deployment coming in and New Relic no Patriot duty afterwards calling you that there is something wrong with the site You know who to tell and you know who to set on fire afterwards. So that's easy But We talked about it and said, okay, we want to just have one aliases file we sat down one weekend of work and It's currently not all rolled out yet But we changed the way how we deal with the settings file At the aliases file, excuse me so we have just one file which has the site identifier in it and We have a set of JSON files files which define how life the life server environment should look how For example a staging environment should look like and we can define per customer How it should be it griff it gives you complete flexibility, but it adds also a lot of complexity So you need to think through it quite a lot until you get there and you know what to do If you're interested in it and if you're interested in seeing it come to me afterwards I can show you it's currently not completely rolled out because we are dealing with some problems with over writing environments because we started to have for some If you have like a feature release we have feature Servers which like a dev server which just has this feature on it and people can like brush deploy this feature So it's not perfect yet. Let's talk about mything things. So Currently we also have the thing that we just want to update code. We don't want to run an update B We don't want to run something else. So There is a way to overwrite the deployment tasks But if you automate it in the way we did it It's not that easy to just say I don't want to do it. So my idea is that we have Somehow an identifier on the deployment tasks to say I don't want to do this set of deployment tasks Currently there are mandatory tasks, but I want to do something like I want to do just the linking tasks Or that you have groups something like that Also something if you work the way we do it and you have a new user a completely new created user And you do the drush deploy the first time it will Fail because trying to connect to github Forces you to type yes and enter and because drush deploy is automated. It will fail. There is a patch I wrote which is not very nice. It just Runs the command and does it but it's not working for every so for everyone. So I want to do it a little bit more generically There are also breaking things. So thrush changed in the recent weeks So the discovery of thrush RC files changed which leaves you behind with you run drush deploy and get a lot of errors And it is not working. So that's something I'm working currently on to make this work again because it's I don't know the exact issue queue number, but thrush Changed because through Paul changed a little bit. They want to discover the files Which are for drush just in sites drush and not in sites default. So That also gates give gave us some headaches through Palate changed, but less than beginning of the year. So Drush deploy should work fine with through Palate now because we have the The configuration files which are on life and imported are not in the files in the files anymore They are in the database. So that Was a bit easier. There is also one bug about perl locale warnings They can ruin your day or break the deployment. So the deployment just stopped. I Spend around four to five hours debugging this because you just run the drush deploy and it stops and you don't Get any error back and it was I can run it all the time. My colleagues can run it sometimes and it's just because Some error passing isn't done the right way and drush deploy isn't expecting it and you are not expecting it either So, yeah, and who uses a PC? okay thrush deploy is not nice to a PC because Every time you change the sim link APCC is oh, there is new code and starts to keep that in memory. So you end up in having your APC Having old code, which is not used anymore in memory That sucks. It sucks that much that you sometimes kill your production environment We found out about this like Rolled out drush deploy on many sites. We did some deployments and then suddenly things got worse Like you had problems that sites got slow You had sites that just on one server we had 500 errors and something like that and after seeing that we found out that we should probably clear APC from time to time Yeah, no, I want to go bigger It should actually Yeah Thank you for pointing this out. Yeah, as you told APC should find out that oh my god. I might Share memories real running full, but on that version we are running There is some weird bug that if you hit like five megabytes of free space It just starts going haywire and not cleaning itself out. It should but it doesn't. Oh, yeah Keep that in mind Yeah, the thing is on our servers. We are bound to Ubuntu long-term service so we can't just Exchange things so we're working on that too Drupal 8 There's a configuration management initiative and as I told you Beginning of the year there were two directories storing all your configuration So you had either the live configuration Which is the configuration you currently use and you had the staging configuration if you change something to roll it out They found out that the idea of having that is a good idea, but somehow it wasn't practical because You needed to copy files over and you couldn't version it because if someone Works on the same view and commits it the chase and add a jammel file got somehow corrupted and your site broke so The live configuration is now in database which eases the deployment a little bit The dealing with configuration files is also a little bit different, but as I told you in the talk when you Incorporated the local file. You're safe Head is also moving quite fast not as beginning of this year. It gets stable. It's more stable and doesn't break that much it should be a Drush deploy should work with through Palate. I did test it yesterday evening and it worked on our site So you should be fine Yeah That's it Some take-home messages Um We started the drush deploy adventure around one year ago You don't need to do anything Automate in automation at once you can do little steps go with the aliases file first then Clean up the settings clean up your environments go to drush deploy afterwards You don't need to do anything at once because if you try to do this, it's a little bit too much Automatic alias files are awesome because you change You move aside to another server. You just change In a JSON file. Okay, it's now in server 2 and you don't need to tell anyone Because they run just drush deploy and they drush deploy knows that it's there You also need to clean up your environments. That's something I do regularly or I try to do it regularly because Things mess up sometimes you just deploy a patch somewhere and you do something and drush deploy really forces you to do At least in the life environments nice work that you don't deploy something just on life So because on the next deployment when somebody does the right process you just trash their changes Standardization saves time. That's I can't leave that without saying something. It's just the way it is and Deployments are fun when you run them with drush deploy because anybody can do it in the company. So, yeah If you want to download the slides, you can go to s.nurdy.ch slash drush deploy Amsterdam and Yeah That's it. I'll be here for a quick Q&A if you have some questions Can you probably pass the mic Somehow because it's all recorded and it's easier when people have it there. Can you specify? extra commands to execute per target So just executing comments on one target When you when you deploy to a staging environment, I want to execute extra commands like enable the mill reroute module, etc Currently not that's also something you could try to do or Is something we also want to do that? Model enabling disabling Thanks Probably he can answer the question a little bit better. Yeah, so and then that's a very Very common Like sort of feature request that ended up in the queue for drush deploy and yes, like there could be a lot of Drupal Specific tasks that you could add to it to do things like that But you can still do all of it by just Creating an after task like a creating a task like he showed and then run it or set it to run before or after the deploy But that would run for every deployment if He asked specifically about like if I have a stage alias, and I just deploy in stage. He just wants to run It for the stage right so and and it's common I mean I used to do some couple strata all the time where you have even you have your things that you're going to run on every deploy But not every deploy needs the same tasks like say like rebuilding No access permissions. You definitely don't want to run that but sometimes you need to do it once I don't think there's anything wrong with just make putting that in your file Maybe committed it running it and then taking it out because then you're documenting I needed that for this deploy and I don't need it anymore. Yeah, that's also a way About the questions No, yeah, I can rephrase it. Yes and no so he was asking if the Path to the files directory needs to be set consistently. Yes, but it's a per site consistently Yeah, because every every site has a different configuration So you can have it on every on every site a little bit set a little bit different. That's a good question No, unless you do a drush SQL dump before so What we are doing when we we have two types of deployments currently one is When we can agree with the customer that they will have a staging server created two hours before and they have a content freeze So we can just prepare everything on the staging and then move to databases And if something is not all right, they will spot it on the staging and Rolling back if you have a lot of user-generated content that will create some pain for you. So No, not yet But you could run a task to dump the database and then for the rollback unit just to keep it in There's one related thing about that Because you showed the you can put tasks before and after that's actually very much related to rollback And so any task that's before if it fails that automatically triggers a rollback So in the case where you deploy It's already live things are happening and you need to rollback then you're you're in pain but if you if you have a bunch of tasks that are running in the database and they're all in before hooks as long as you in the At the start of it say dump the database first any of those can fail and then you can still restore that And then flip back So the the tooling is there for it. You just have to set that up yourself depending on how you need it done Yeah, that's right He was asking about if we wanted to do stage deployment and using features Yes, we thought about that We are using it for some sites that we run we use features but It heavily depends on the site sometimes if you just needs to push out some code or some CSS changes It's easier to just do it that way We also have something where our developers are working on which is kind of like features But it's for it's easier to just code things and do the changes in in up DB hook So we partially use that yes Does that answer your question? Contestation right No, so Everything that needs to run stage so we have one customer which has like publishing of yearly results So we prepare everything on a staging environment and then Copy it over to have a consistent state of everything. So we don't use it yet Yes That's not Related to to drush deploy in Because rushy play just does the code site the SQL sync is done still manually currently, but you could also do it I guess there is a way to exclude tables from a sink Yeah, SQL sync is not part of the game. So you can you don't need to SQL sync That's not mandatory you can script it, but it's not mandatory Other questions Not okay, um, please rate my talk I'm happy to have some feedback and if there are questions or you want to see something just Come here Thank you