I have this small SaaS web application. It has no homepage and it has no signup form or signup site. It has no marketing campaign and people only hear about it from current users. I manually onboard new users and show them around, personally. From face to face. To put it short: “I do things that don’t scale”.
The people using my software depend on it for its purpose, though. They earn real money using it and they are serious about it. They have feature requests and get annoyed when something doesn’t work — for good reason. That’s why whenever I develop a new feature or roll out a security update or fix a bug, it is really important that I don’t mess things up. It is okay to have a few minutes of downtime when the app restarts, there is no need for deployments with zero downtime. But other than that, the software and all things the users got comfortable using should work as intended.
To achieve this there are a few things in place that make this easier for me. Let me tell you about them. I test things on a staging server before deploying to production. I host my web applications, and this site, with the guys from uberspace.de. My production and my staging site sit on different servers using different user accounts. That’s okay for my purposes. The staging environment gets a duplication of the production database, although infrequently. This is not done as a backup but rather to test the staging environment with real data and real amounts of data. The environments use the same ruby version (2.1.2 at the moment) and the same rails version (4.1.1 as of writing). Of course I deploy both from the same git repository. I usually only deploy the master branch, but there may be a new feature or something specific sitting in a different branch that needs deployment to staging. Then this branch gets deployed.
But generally I prefer deploying the master branch so I know it works as intended and is without bugs. You often find the idea that “(the) master (branch) should always be ready to deploy” and I really try to develop by this. If done correctly you have the can always deploy and don’t have to worry about things that might go wrong. And there are always enough things that can go wrong.
For deploying to staging or production there are a few things you need. Of course you need the code you want to deploy. This is achieved with your distributed version control system (if you ask me use git or mercurial). You need your server you want to deploy to. And you need a script or something similar to do the deployment. It should be as easy as opening a terminal, navigate to the path of your working copy and type
$ [helper software] deploy.
I use Mina for deployment. In the past I used capistrano as well, but right now Mina serves my needs just fine. It is simple, easily configurable, I can read and change the source code and just like it. It feels right to me.
My commands for deploying look like this:
1 2 3 4 5
As I type this I realize that I should probably change that around. Deployment to staging happens more frequently than deployment to production and should be easier to do. And if I have to specify the configuration file for the environment (this is done with the -f option) I should ideally do this for production. That way — by typing more — I make sure that I only deploy to production when I really mean to and not by accident. I will change that.
Mina is quite easy to configure, I guess you can probably figure it out faster that I did. But I will show my configuration files nevertheless. Perhaps it’s of use to someone. I will give a short description after the scripts.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78
In line 4 you can see I use rbenv for managing my rubies. This works well for me in development and any other environment. Once you get used to its workflow it really shines. I recommend it for anyone who’s looking for a ruby (version) manager. If you already use something else (rvm? something home-grown?) you can set it up here.
The basic settings are pretty self-explanatory, I set up my domains, the path, the repository and the branch. I anonymized the sensitive parts. If I want to deploy a different branch than
master I change it right there in the script itself. As I don’t do this very often that’s okay for me.
Mina offers variables to tune your script to your needs right from the command line. So you could change your branch setting like this:
1 2 3 4
This should set the branch to your
new-feature-branch and everything works as expected.
The rest of the script doesn’t deviate too much from the original script files. I only queue a command to relaunch the application after a successful deployment. This command is specific to my hoster and you probably need something different for your hosting environment.
If you want to try out deploying with mina please follow the links to their site. Installation and setup are really well described. If you have any problems or questions you can probably find some answers in the documentation and guides on their site. Otherwise go to Github and open an issue. Any comments or questions about my setup? Please write a comment on my site, down below.
As always thank you for reading and make sure to subscribe to my newsletter so you don’t miss my next articles. Also I really like to connect with my readers and the newsletter is a perfect place for that. I am interested in your specific problems regarding web development. After joining you can reach me directly via email and ask your questions.