Since leaving my last job for freelance – where I had a lot of support from 2 talented SysAdmins, I’ve been wondering how I’d like to manage what will likely be a growing array of client sites, and the prospect of setting up a lot of things that I hitherto took for granted. Things like the SVN server, the dev and UAT environments, the firewalls, the proxys, the puppet servers… all of this useful stuff that I knew how to use, but unfortunately have little idea how to configure.
I’ve also got the prospect of working with some developers who haven’t really cut their teeth in a collaborative coding environment, and haven’t yet arrived at the point whereby they instinctively know that version-control is a good thing, and haven’t really known anything better than simply using FTP to get stuff done.
Some of that infrastructure I’ve used in the past, was used to manage around 200 websites. We’re not going to be operating anywhere near that level, and I also don’t want to scare the shit out of my new co-workers when they suddenly realise that there is indeed a learning curve, and what was once a 5 minute tweak in a WordPress plugin to make CURL work, now will now involve learning puppet, logging into puppet, making the changes, testing the changes, and then and only then can they make that WordPress plugin get past the firewall.
It can’t be like that, especially as we’re such a small team, it can’t really afford to be crippled by infrastructure that people aren’t confident enough to use, and I also refuse to be the silo of that knowledge.
Version Control
Some things however, like version control, can not/should not be removed from this equation. The benefits of GIT or SVN far outweigh the time involved in getting to grips with it, and since there’s a whole range of GUI interfaces for the two of them out there these days, it’s not even strictly necessary to scare yet more shit out of people with the command line.
Deploying
In the past with Rails, I’ve had experience using Capistrano to move sites between dev, uat and live environments. The last 3 years or so, I’ve been using YUM packages to control and role back versions. This was all well and good, but still required a few extra steps (and yet another server) to create your package, and then also to having to maintain spec files. This wasn’t such a hardship as we were generally dealing with production-line sites – they were all built on the same framework, and all shared common code-bases. Now though, we’ll be dealing with all sorts. Off the top of my head there’s already WordPress, Concrete5, Magento and some CodeIgnitor. Attempting to encourage the use of building YUM packages under these circumstances, whilst already insisting on learning the basics of GIT, isn’t going to make me any friends, and will most definitely get in the way of GTD.
So, this is where Springloops comes in. In most respects, it’s a bit of a Github clone, except that it also does deployments. You can basically set up a project (using either SVN or GIT), and then under each project you can define any number of servers, with particular roles (development, testing, live and so on), and using a particular branch. You can give Springloops access to the servers via FTP, SFTP, and (and this is a nice touch) Amazon S3. When you deploy for the first time, Springloops basically sends up the entire repo. When you then make subsequent deployments, it works a bit like rSync and only updates new/modified files. The result? It’s pretty bloody quick.
Of course at this point, you do start to wonder about where these details are going, and how well Springloops are going to treat them. At this point, I have no reason not to trust them, and the few support inquiries I’ve made have had a swift response. Having said all that though, I really wouldn’t recommend just using a root SSH account for this. It’s not that I don’t want to trust the staff, but more than I wonder what could go wrong if a bug ever sneaks through. Better to just to give Springloops an account with limited permissions, and in theory only the site will ever get damaged – not the entire server.
If all goes well, I will certainly post back here on Springloops with an update on how it all works in practice. My gut feeling though, is that having a GUI to help people manage deployments without forcing them into steep learning curves is going to be a good thing. It’s going to be a quicker route to that feeling of control and empowerment that a decent deployment process gives you, and I’m absolutely convinced that they will never fire up their FTP client again, and will never have that sinking feeling when it goes horribly wrong.
Rollback, and code-on.