Forever Alone No More

Forever AloneA lot of us work on projects by ourselves. We’re the ones who build a website, alone. We write a plugin, again alone. When we do colaborate with others in the making of our site and codes, it’s often a cumbersome, kludgy, thing at best. The advent of code management systems like SVN and GIT make the actually coding process easier. Now multiple people can make changes, branch and fork, merge and combine to fix all sorts of problems.

But web-development, for your personal site, is still in the dark ages.

Here’s my workfolow:

  • Review changes
  • Open Coda2
  • Edit file
  • Preview changes
  • Push file

Now that’s a huge improvement since the old days, when I would edit, FTP, and so on. I still use Transmit to run a sync/backup every day before I start editing any files, but that just goes back to my paranoia. It gets harder when you use something like WordPress, because the old days of being able to easily preview your site and how it looks doesn’t exist anymore. That’s part of why the totally incredible Theme Customizer is totally incredible.

It’s also a little problematic if you share a site. Let’s face it, maintaining a website with other people is a pain. When my fellow site-folk want a small change, they can make it, but I have no way to easily roll that back without comparing my personal backup with the new one, and go make a diff. Sure I can do it, but it takes time, and it’s a hassle. A lot of the time, too, my fellow admins aren’t as good at certain things (like CSS, or tables, or PHP) as I am, and I have to bail them out. In and of itself, that’s okay. It’s why they keep me around and fee me brownies, after all.

FacepalmHave you ever had someone else make a change while you’re on vacation and call you in a panic, even though you’re on Bora Bora and have no internet, because this ‘one small tweak’ to the sidebar caused the site to go white, and they closed their file-editor, so they can’t control-z?

A lot of us cowboy code. I sure do. I’m often banging away on my sites in vi when I want to make a fast CSS change. Clearly sustainable for a professional environment, this is not.

But… What if? What if you had a way to update the code on your site, like your personal mu-plugins or the theme, and make the changes ‘live’ but still have a way to roll back when you accidentally blow it all up?

And what if I told you that a WP dedicated host has an answer. Yeah, WP Engine figured it out.

Upfront disclosure: I don’t use WP Engine. I have a lot of non-WP sites on my servers, and many of my sites aren’t using just WP. I have a VPS and I’m very happy with it. But if you want a good host to run your WordPress site that’s the step between your own VPS and WordPress.com, I strongly recommend them. Yes, it’s more expensive than many other hosts, but I am a firm believer in ‘You get what you pay for.’ With WP Engine you get hosting, upgrades, backups, and support for $30 a month.¬†And now you also get Git. They’ve come up with a Git-push-to-deploy method for their hosting platform.

Did that sound like gobbledygook? Hang on. This actually isn’t something ‘new,’ as the technology’s been around for a while, but this is something new for webhosting and WordPress hosting. WP Engine’s applied it to their servers, making version control possible. It’s like how we’ve always combined version control and staging to make a ‘development platform’ and now you get that in WP.

Okay, if you’re like me, and a total raw rookie at Git, you sat here and went ‘What the hell is this ‘push to deploy’ stuff?’

At it’s heart, push-to-deploy and push-to-live is really a fancy, buzz-wordy way of saying this: I have a git branch that is the dedicated to my site version of my code. If I edit that branch by pushing my changes to it, I have created a version-controlled update of my site, which is beneficial in case you need to roll back a change, or pin-point a specific change.

Okay, maybe that’s still unclear. You’re going to have to take a look at git.wpengine.com to really see how they’re applying the technology. Git, like SVN, is one of those things that makes a lot more sense once you sit down and use it a few times.

Really, my biggest hurdle is always wrapping my head around git’s application of branches and merging and a decentralized database. It’s complex and powerful. Vincent Driessen wrote a brilliant explanation of a successful Git branching model, complete with diagrams, that explains all this way better than I could. His examples will show you exactly what’s going on, and that a ‘push to deploy’ is really just another sneaky way of using git to manage your changes in a controlled way.

Don’t get the wrong idea. There’s nothing wrong with being sneaky to control all this, when you get down to it! It’s the perfect-world a lot of teams have been looking for, for many years. Having this built into your webhost, so you don’t have to come up with your own solution, is going to be amazing for small companies that will, over time, have a slew of developers. Someone new comes along? Hand them your primer on naming conventions and merge rules, let them fetch the repository, and off they go. Everything is right there, as safe as your backups.

I can’t say if this will revolutionize things, but it’s a harbinger of change which web dev has sorely needed.

Check out WP Engine’s Git FAQ (where they explain all the nitty gritty about handling version control, so if you’re a nutjob like me and want to run aortic, you can), or just read their getting started guide. The directions are clear enough for a Git newbie like me to understand.

Unlike Capistrano or RAMP, this hasn’t been released outside of WP Engine, but that makes sense as it’s all homegrown and built to their servers. This should be interesting to watch how other WP (and non WP) managed hosts handle the next wave of support.

Related:

StudioPress Theme of the Month

Comments

  1. This is interesting indeed and I’m glad they built it. However, I was just looking at RAMP recently to possibly apply it for a client who has a Multisite install that wants to do a total redesign and rework of their content. The catch is that they are adding content daily and from what I understand RAMP doesn’t sync content from live database back to the “dev” site.

    Unfortunately, moving this client to WP Engine isn’t an option.

    I hope the addition of WP Engine’s solution will inspire others to consider creating their own WordPress development environment solutions that solves the syncing back and forth between between live and dev.

  2. To be honest, I would be more interested in a self-hosting solution. I looked at WP Stack, but it’s WAY overkill for my needs.

    • For folks who can’t managehost (too many non WP things in my install), yes, we need our own solution, and I hope that people start pushing a better, easier way.

      My Coda method works because I’m the only one who mucks with code. But that isn’t true of all things.

  3. Hey Mika,

    Thanks for an awesome explanation of git and version control. You’ve hit the nail on the head about how important it is, as well as how it works. It’s a bit technical, and you’ve done a great job of explaining it for folks who may be new to the concept!

    -Austin

  4. I’ve been managing and deploying a couple of sites using SVN for quite a while.

    How: http://ottopress.com/2011/creating-a-wordpress-site-using-svn/

    We at .org deploy lots of stuff via SVN, what it really comes down to is just having your SVN for deployment separate from what you do for development.

    I personally find git to be far too dependent upon “magic names” of various systems and branches to be really easy-to-use. I mean, I understand it, I just don’t like it. It also is heavily command line oriented and I know of no good GUI way to use it. I don’t often use svn on the command line, nor have I ever really felt the need to do so. With git, you have no other real choice.

    • @Otto,
      Thanks for the link. You’ve been a great contributor to WP for a long time! I am somewhat comfortable with SVN, so I will check out your page and see if it makes sense for me. I am not prepared for yet another learning curve, go Git is probably not an option for me at this time. I have a hard enough time keeping up to WordPress itself.

      Thanks again, my friend!

    • I understand what you’re saying about git and magic — or at least confusing and undiscoverable — names of things.

      In our instance that’s not the case. There’s no branching or fancy requirements. Just a single line to one-time configure our servers as a push-target, then just “git push deploy.” That’s not too bad!

      Still you’re right that there’s various nice things about svn. There’s better tools and integrations around it, lots more people understand it, it’s used by all the .org stuff, and so on.

      If you still want Subversion + “push to deploy” semantics with us — or other hosting providers — you can! We have a great integration with Beanstalk which makes this seamless.

    • I do the ‘create a WP site on SVN’ here (and actually most everywhere), with scripts. What I don’t usually do is version my themes/mu-plugins, which is where this would come in more important. In a funny way, this Git to deploy would be magic for people who don’t use versioning CMS like WP. I mean, if you had a basic website, all HTML, this is the versioning you end up moving to WP for!

  5. We recently started using a modified version of this script to deploy from local to staging to production: https://gist.github.com/1809044

    On some projects, we’re using Git in vanilla form and just essentially doing auto-pulls from the server when we push from local. On GitHub, this is done using WebHook URL service hooks. We also discovered it can be done with BitBucket by adding a POST hook under Services.

    On other, more complex projects, we’ve been using Git Flow which complicates the process only because we can’t very well run it on our staging and production servers. In that case, deployment becomes a two-step process (which I’m actually a big fan of, btw). The process looks something like this:
    1. Push from local on /develop branch (Staging only auto-pulls from /develop branch). Changes reflect on staging.
    2. When we’re ready to go live, we branch to /release and push. Changes are merged into both /develop and /Master. (Production only auto-pulls from /master branch).
    3. Staging and Production are both up to date and we’re off to the races again.

    I guess I should do a write up on the process as this is kind of the abridged version of it. The nice thing about the entire process is that it only requires that you have git installed on your production and/or staging environments and have ssh access. Protip: If you’re working with clients on shared hosting, Hostgator already has Git installed.

Half-Elf? Try Half OFF WordPress ebooks!