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.
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.
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.
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).