Capistrano is useless: not as good as SVN or Git

Once again, something comes out to “revolutionize” the way things are done. I suppose when Git came out, everyone was going to jump off of the SVN boat. In reality, SVN works just as good as Git. It’s always about how you use the tool. My argument is this: Can you mess up a Capistrano release? Just as much as you can anything else. It’s all about how you do it, not necessarily what tool you use. Not to mention that it’s a Ruby Gem. So if you’re a PHP guy, you’re screwed. Gotta install a bunch more stuff on your server just to make it work. Bollocks!

If it ain’t broke, don’t fix it

So, if a company has been using SVN for years and years, why would they “need” to switch to Git, or Capistrano? I would hope that a company that’s been using SVN for 5 years, would have figured out by now how they’re using SVN. In fact, one of my old work places used SVN brilliantly.

The solution

What they did was this: They had sandboxes for devs, each set up with their own virtual box. Dev environment is complete. They would spin off individual features branches and a sprint branch at the beginning of each sprint. Done. Good so far. At the end of the sprint, they would test on their dev boxes, get business approval, and merge to the sprint branch.

Regression testing

The sprint branch would be pulled down on the qa server, and tested. Two other devs would test the original dev’s story. It took a day, and we didn’t need QA. Once the qa dev (sprint) got approval… no, we would not release to live. In fact, at this point, the lead dev would create a tag. This tag would become the snapshot for the release.

The live server

The tag would be pulled into the live server. Let me explain how the live server was set up. The vhosts had two servers set up. One was a pre-live environment, and one would be a live environment. Both of these had symlinks that pointed to previously created tags. This way you can have the code tested on the live server, using the live database, without affecting the live site code.

Update: Here’s sample bash script ./tag_www

#!/bin/bash
echo "Tag: "
read thetag
echo "Tagging $thetag"
ln -sfn $thetag www
echo "Done!"

And you would just need to run:

# bash tage_www
Tag: tag2

And you’re done

Capistrano is essentially useless

Now that we have symlinks point to different releases, and we know that we can roll back by swapping the symlink to a previous tag, and the only scripts we need are Git’s (SVN’s) commands, why exactly do we need Capistrano as an abstract layer of complication? We don’t. But, because it’s a new tool that sounds cool, your CTO who may not understand how a light switch works, may decide to go with it anyway.

Git vs SVN

So, now, that we realized the Capistrano is a useless piece of software, even though evangelists may swear that it’s better (they’re probably just too lazy to do the actual work required), it really comes down to a personal flavor. Are you used to SVN? Use SVN. Are you used to Git? Use Git. It’s that simple.

What about the scripts?

I, personally, would rather write my own scripts. I know what goes in them, I know I tested them myself, and they don’t require additional software to run. Git and SVN come with their own pre hooks and post hooks. Use the tools at hand. To me, if someone tells me that they want to use Capistrano, it tells me that they don’t know Git or SVN all that well. And to use a new tool with services that they don’t understand is ever scarier.

The shortest road is the one best known

In reality, it comes down to what you know best. But, if you don’t know SVN or Git and are using tools and scripts on a higher level, it’s like saying that you can run a marathon at the age of 50 because you did a 1k when you were 18 years old. it’s like using Zend before you pick up PHP. You’ll have a heck of a time, let me tell you. Learn the basics. If you truly learn the basics of Git, SVN, or any other similar repository, you’ll understand why you’ll never need to use Capistrano.

Don’t be afraid

You might be saying to yourself… “But, I learned Capistrano, why do I need to learn anything else?” Simply because it’s valuable. You’ll be a better developer for doing so. You’ll have a better grasp of deployment and the hows and the whys. Don’t be afraid to master the tools at hand.

What about the database?

There’s a nice UI tool that I personally use. It’s called SLQYog. For about $100 you can get yourself the SQLYog Enterprise or Ultimate which includes some much needed features, such as schema sync, data sync, SSH tunneling, and many more features. Why would you let PHP handle database syncing? I’m talking to you Laravel, and your promise to make database syncing easier with your eloquent. It’s silly to think that PHP can manage your DB. Use smarter tools, don’t be stubborn and don’t fight PHP please.

Do a schema sync before every release. You typically won’t be erasing fields, so you won’t have to worry about that problem. Very rare issue to have. So, changes are that your code will only break when you rename things or remove fields. But, for those times that you do make those exceptions, this tool will be a life saver.

Best practice for when renaming fields, don’t just rename. Add a new field, copy the data, release code, next sprint remove the previous field and done.

More control

In the end, you’ll gain much more control over deployment processes. You’ll understand what’s being pulled / pushed on what server, and you’ll be much more confident running your own scripts. Running a tool that was designed by someone else comes with its own caveats. Just be careful of others’ work. Just like composer, don’t get me started. Basically, if the main install file for composer somehow runs a command to delete your files, there’s no coming back. So much complexity for so little gained.

And remember, always K. I. S. S. (Keep it short and simple).

  • > …it really comes down to a personal flavor. Are you used to SVN? Use SVN. Are you used to Git? Use Git. It’s that simple.

    I can’t agree that “it’s that simple”. While for most of the teams choosing between git and svn becomes a dilemma of centralized source control vs. distributed version control, there is stuff where git sucks and there is stuff where svn sucks. Both of the systems are great, but some of their downsides can be critical when you make a decision. Those who work disconnected and need local repos, should definitely chose Git. But those who need immutable code development history should choose svn.

    git works great for certain types of projects, svn works great for the other part. Just an example: svn has some merge-related problems: http://svnvsgit.com/#svn-merging and git has workflow limitations for larger teams: http://svnvsgit.com/#git-scalability-for-larger-teams-myth
    And if you really need dvcs, why not take a closer look at Mercurial? 😉

    • George

      Good points. I was mostly referring to whatever your team is more comfortable with. I’ve worked in both environments where devs were comfortable using svn, and they were doing great, and other environments where users were using git and they were doing great. You can use either system as you’d like, and yes, some do things differently than others, but essentially, in the end, it’s just a code repo with bells and whistles.