 Okay, hello everyone. You're at Deploy with Capistrano. Everybody having fun? Too warm. All right, my name is Michael Priest. I'm a tech lead with Trellin and I've been working with them for about three and a half years now. I'm working with Drupal about six and a half or so. I'm from Adelaide, Australia, so it's been a fair hike to get here, but it's good to be here. Unfortunately things are almost over, but that's too bad. Okay, so I'm going to talk about Capistrano and a bit of an introduction to automated deployment, and I'll just kind of pretext things with why I got interested in Capistrano, and basically it was client concerns. We needed to do a pretty complex sort of deployment where a client needed to review a site before it went live in its entirety, in a staging environment, before getting pushed to multiple production servers, sitting behind a load balancer. So that's kind of... I didn't really look too much around. I just knew of Capistrano and that seemed to be fine for the job. So that's why I've gone with it, but there are other options. Okay. So the point of automated deployment is to make a new version of application available on one or more remote web servers. Wikipedia said it must be true. So we wanted to play our new features, new functionality, configuration changes, bug fixes, whatever that change may be, put it in code, and hopefully we can deploy it nicely. So what I'll deal with today is just this very basic use case, but you know, Capistrano supports a whole range of, you know, and so do many other deployment tools, supported range of multiple server deployments and what have you. So I guess we'll start with how people are deploying right now. Hopefully, hopefully not that. Definitely not the first one. scprr sync, well, it's not a whole lot better, but you're probably on a command line. That's a good start. Bash scripting, well, that's kind of one step before you realize that that's not enough and maybe you want to use some sort of framework like Capistrano or Fabric or something. A lot of people are just happy to, you know, log into that production server and just get pulled or you know, if you're still using SVM. Some people are deploying using Ago. Don't know much about it myself, but and Drush is always getting new features in relation to deployment. So I'm sure I have no idea what's going on there and it's really awesome, but we're gonna look at Capistrano. Acquire DevCloud and Pantheon also have some really nice tools for just drag-and-drop deployment between like a development staging and production environment, which is very nice and similar to this, but this is more about a custom solution. So if something like that is going to work for you and you're willing to pay their fees and what have you, rather than run your own server, that might be a good option too. Maybe you don't care. Maybe you have some minions to do that job for you. So the reasons why you want to automate this process, you know, it's a very repetitive process, log into production, go through all these steps and then tomorrow you make a change and you need to do the same thing again. That's great. It's boring. Coders are lazy for the most part, I think, and so we want to do it once and then never have to worry about it again. Humans are prone to making errors, so when we're logging into a server, I'm sure there's some of us that are guilty of doing something silly on a server. I know that I've managed to wipe out a production database once. Many years ago. It was backed up, you know, within the last 24 hours. It was not a big deal, but it was some time ago. I've lent my lesson. And then there's permissions issues. You need to have access to that production server and so perhaps you know, on the smaller side of things, this permission is too lenient and so you can log in and you know, you've got root on that server and you can accidentally stuff things up very easily in... That didn't work so well. In a bigger sort of environment, you tend to find that permissions are too restrictive. You log into that production server and then, oh, I don't have pseudo access or don't have permission to rewrite those files or whatever. So all this can lead to a bit of rage on when you face a sysadmin. Please fix it for me and this will be true. So the aims of automated deployment, you know, we want quick, safe. So by quick, I mean we just want to run one command or a very limited set of commands to do our deployment. Safe, you know, we're thinking about permissions so that if we have a set of steps in place, they're just going to execute and nothing different will happen from the last time that we did it. It should be easy, you know, one step. And efficient. So we write it once, get it right, and then after that, we start reaping those rewards of setting this up properly in the first place and not having to do everything manually. So it's awesome. How do I do it? First you need to pick a tool. There's quite a few hammers to get the job done. Capistrano is just one of them, but it seems to be that Python is all the rage given a number of these other ones available. Fabric was aimed to be very similar to Capistrano. Zappy is a we looked at Capistrano on Fabric and we don't like it. It's too complex. Everything's broken. Let's make it really simple. You can find that one on code.google.com and Ansible is a bit of a combination of configuration management and automated deployment and code deployment. So that's kind of a new one. And I think four kitchens have a good blog post about that, which might be worth checking out. Okay, so Capistrano was written in Ruby, originally based around deploying Rails applications because I'm sure that can be a bit of a pain. I don't know much about Ruby, but it sounds like people were having a lot of trouble and so Capistrano came about to simplify that process. And what Capistrano does is build a set of commands locally, so from where you initiate the deployment and then SSH is into each remote server. You may only have one or you may even deploy to your local machine, but it will still SSH in locally and execute whatever commands you have queued up in a task. So there's a few aspects about automated deployment and really we're just concerned with code deployment with Capistrano. You can essentially run whatever commands you want, but there's some other better tools like for configuration management or system automation like Hudson and Jenkins for that and Chef and Puppet configuration management tools. So really it was just a convenient way for me to get the job done, but it's not limited to Ruby or anything. You can use it for deploying any sort of application. Installing it is pretty straightforward on Ubuntu. I did it this way and that will already install the Capistrano gem, but if you want to get it up to the latest release, you just install the gem through the gem package manager, which is like Ruby's appget or peckle. I just had some other things there. It was interesting to see how many other gems are available in that repository related to Capistrano and Drupal. It might be worth having a look. So if you're not on Ubuntu or Debian or something similar, you probably need to do something a bit more substantial to get up and running with Ruby and Rails and the gems to be able to install the gems, which Capistrano is a gem itself. You can find some links from the wiki, which I have got some links at the end. One thing you do need to get configured, it's not a hard requirement, but if you don't set up SSH keys, each time you run a set of commands or a task, you will be prompted for a password, which is very annoying. I recommend setting up those SSH keys. You may also need it for authenticating with Git if you're using GitHub or something, which requires a SSH key for authentication. These are the two files that you can serve with when you start using Capistrano. One is your cap file, which contains project specific requirements. If you're using some plugin for Capistrano, which you can install through the gem management tool, then you need to specify that in there. Also, you're able to define your own task within that cap file. If you have some very specific tasks that are specific to your project, you would want to define them in there. Also, you deploy .rb, and that's where you define things like paths, passwords, users, all these sorts of things that are required to log in or specify where an application is living. The terminology can be a little bit daunting if you haven't looked at a code deployment tool before. Primarily, you deal with roles, and so a role is essentially a server. You can assign multiple servers to a role and also multiple roles to a server. Basically, that means that when a task is executed, it can be run against many servers or just one, or you can mix and match as you need to. There is one special thing there about the primary, and that's just to say that that's the primary database server. If you specify other database servers, that's the one that Capistrano will try and deploy to when you're using Capistrano to make database changes. A task is pretty straightforward, you give it a name, you say which host or which roles it applies to, so you can just not worry about the roles if you want. You can just specify a host directly, and then some command. This is just an example, so it's a pretty useless command really, in my Drupal. When you start using Capistrano, you need to Capify your project, which creates the Cap file and the DeployRB file, and these are very default configurations, so pretty useless in terms of Drupal. You really need to make a few changes to get up and running, but you just replace them as you need to. It's as simple as just running Capify and then the path, so .works just fine, and you'll see those files get generated. Additionally, you can set up multi-stage deployment, and so you would just manually add these config deploy dev staging production. You can also add tasks within those RBS as well, so that you can have specific tasks related to a specific server, which could be useful, but try and write things generically so that you can reuse them. This is where, as I said, you keep your configuration and you can set up some roles in there. This is an example. We're setting our application, which is basically the directory that it lives in, for the most part, a repository that's where we're pulling from, where we're cloning from, and the app path is where we are deploying to, which branch we want to be pulling against, and some of these are a little bit obscure, and you're just going to have to deal with it, unfortunately. There are some strange ones down the bottom, default run options. This one's required to prompt you for a password as needed, so if you run a shoot-o command on a remote host, then it needs a way of prompting on your local to receive a password back. That's one little gotcha, and the SSH options, forward agent, that's about authentication using an SSH key. The responsibility is to cap file, load those tasks from any sort of gems that you plug in for Capistrano, and define any project specific tasks. It may look something like this. These are the gems at the top, and this is what you get by default when you capify. It's basically just the way of loading those recipes by default, and you can comment these out if you don't want any of these standard recipes. Deploying should be as simple as just cap deploy, just running that, which sounds easier than all that to me, or maybe more, depending on how many servers you have to do or whatever. It sounds good in theory. It does require an investment of time up front to get everything up and running, working, and learning Capistrano or any deployment tool I'm sure has some learning curve. I don't know Ruby, so just some of those basic sort of things that I wanted to do were a little bit tougher just because I had to learn the syntax a bit, or understand how Capistrano is a little bit strange about global variables. When you can just sort of set up some variables, but bringing those into scope is a little trick to it. Documentation tends to be a bit Ruby specific, and so it's targeted deploying a Ruby application most of the time. But I think that's starting to change a bit. The more you sort of Google around, you can find some more Drupal specific information. There's quite a few links on the wiki from, well, there's a link on the wiki to a Drupal specific deployment. There's a Capistrano Drupal Jam, which I'm going to show you later. It does require a bit of sysadmin knowledge, and what I mean by that is when you're building a recipe yourself, writing some tasks, the errors that you get back can be kind of obscure at times, and so you can be scratching your head a little bit, and basically Google saves the day eventually. So just keep Googling around and you'll figure it out. So try and keep it simple to start with, at least, is my recommendation. And if you can find something that somebody else has written that works, well, come with it, because it can be a little bit time-consuming, figuring it out yourself. Alright, so I'm going to try and demo this. This could be interesting. So I have two virtual servers here, and they both have Drupal running off each, so the Adelaide server is where it's coming from, and Munich's where it's going. And so this is where our app is living, so if we cap deploy, you see that it runs through a bunch of commands that have been defined in this Capstrano-Drupal-Jam. Now this Capstrano-Drupal-Jam, you just need to install through the gem installer, and it's something that was made by Kim Pepper from previous Next in Australia. And so he's kind of the inspiration for this talk, really. It's not perfect, I found, but works for the most part. It's very finicky about where you configure things and make some assumptions about setting things up a certain way to begin with. Right, so now we've made a release, let's have a look on the other side. So this is how the production side looks. We've got this releases folder, which if we look in there, you can see a timestamped set of folders which has each release in there. Our shared folder is where our files are kept, files and private files, neither of those get changed between releases, so they're kind of put aside in a static area. And settings PHP, that's something that won't be changed each time, it's something with production-specific settings, so you keep that aside. And the cached copy is basically a git checkout of the latest. So if we look in the cached copy, okay, so we can see that a bunch of releases got tagged. The reason that not all of those releases in the tags is because I came across a little bug and was debugging that. And the deployments to work with the very last step is to tag those releases, and so that's why they're missing. So I'm just going to show you the actual gem itself. So if you install it, I mean, this is probably the easiest way to find it. Just do a locate on capstrano-drupal. Don't do that. Okay, so this is the capstrano-drupal gem. And so, for example, this is that tag piece of code that I had the problem with, so this is a task, push-deploy tag. And so it was having some path issues. This doesn't seem quite right in this section, so I've just kind of hacked it to make sure that it changes to the right directory before it does that tag, get tag, and push the origin of that new tag. Okay, so with a bit of luck, we can do a bit more demonstration, and we'll try and make a change, commit it, and see what happens on the other side. So I'll try and make a change to a feature and export feature and see what happens when we deploy if it ever loads. This is a very slow laptop. And so the benefits also is that when you've done a deployment, you can do a cap rollback if something goes wrong with that deployment, and it will just take that sim link. You kind of miss this point. So you see that current release is just a sim link to a specific release, and so on a rollback it's just changing that sim link back to the previous release. We might skip that. I think it's probably not going to work. All right, see if that becomes back. Very fast. Okay, so I'll probably give thanks to Kim Pepper for making a fair bit of effort on that Capstrano Drupal Jam. It really is in need of some TLC, and it's a project on GitHub, so if you want to contribute, I'm sure it's more than welcome to merge some patches, and thanks for Trillin for getting me here, because it's a very long journey for me. So any questions? You showed like you can do rollback, right? You can switch the sim link. Do you have something for the database? Not with the Capstrano Drupal Jam. It's not really concerned with doing a database deployment. It's just code. No, not for that instance, but you wrote another project. Another project where we did do a whole database dump, and that's been since improved for this client project where that database was restored, and yeah. That would be a very nice idea if you're just aware and also you can rollback. So another thing that we did on that particular project was instead of replacing the existing database, we just had like an AB database, so when you actually switch sim link, you had a second settings PHP file, which allowed and two databases sitting side by side, so when it came time to actually deploy, you could very quickly rollback to the previous database without having to reload a database to restore, as well as making backups of course. Anything else? Sure. Just use the microphone please. Hopefully it works. Hello. User uploaded images and files. Is there something you should think about? Some kind of a best practice when deploying with Capstrano? Like so. Are you talking in terms of like on the production server or... I mean, using this particular Capstrano Drupal Jam, I mean those files are set aside. So they're not... Unless Drupal has some sort of bug where it decides to delete them, you're not really in having too much of a problem. Well, they're just set aside. They're in that... Right. So they get sim linked into where they need to be. Right. Exactly. So if you're starting from scratch, of course that functionality isn't there, but if you use like that Capstrano Drupal Jam, you get a whole heap of features for free, but it's just a little bit finicky. Sure. You mentioned that you had to hack the Gem a little bit because of... Something about the files not being in the right places or something? Just... How default are the sort of the settings? Is it trying to do something like... Or... In that case, I think it was using a call which would have been looking in my home directory rather than actually changing into the directory where Drupal is. So when it was trying to commit something... When it was trying to generate that tag, there was no repository because it was sitting in the home... So it was trying... It was a situation because of how you develop rather than say what's the problem with the Gem itself? Well, I'm not 100% sure. I think it may be a problem with the Gem. It may be a problem with my configuration. I just haven't figured it out yet. And that's what I mean with this particular Gem. It's just a little bit finicky. And so that was like the last issue that I had to resolve with it for this presentation. Really, my use of it for Trellin was completely from scratch. And so dealing with this other deployment which had some very special needs. So... Any other questions? Go once, go twice, three times or... Alright, thanks everyone. I think if I had my time back, I'd probably hit towards one of those Python ones. One of the Python alternatives rather than Cap Astronomy.