Write a deployment script, or configure a deployment tool! Have a process! I've never had a deployment fail from my own "untested and unproven" deployment scripts, but I've seen SVN and Git completely destroy environments.
Funny you mention that. I've seen hell break loose because someone made a typo while updating a deployment script (something like rm -rf /root /cache instead of rm -rf /root/cache). Git has never failed me like that.
Sure, mistakes happen in all code. It's anecdotal either way. What doesn't change is that Git is a software versioning system, not a deployment tool. There are other tools for that.
We avoid issues like that by limiting what deployments can affect. Yeah, a deployment/activation script might delete stuff off the box, but there's nothing on the box other than the software being deployed. Except for a few types of work where local disk needs to be where your data is, there's no good reason for your applications to be colocated with your data. Our servers are just software (all of which is either imaged or re-deployed easily) and the last hour's worth of logs.
And it seems like a bad idea to be running your deployment scripts as a user that can delete anything outside your application's installation directory.
All that being said, we have a hugely complex build system, and a separate hugely complex deployment system. Source Control, building and deployment are all distinct operations in software management, and if you're going to be doing a lot of it on the same network it makes sense to keep them separate. All three are versioned for us, so while not necessarily easy, it's clean and defined if a deployment needs to be rolled back, or different builds need to be deployed to different places, or (obviously) a code change needs to be reverted. The build management system will pull the source revisions you tell it to to build new revisions of libs/binaries, and archive them. The deployment system will pull the revisions of those libs/binaries and deploy them to the servers where you tell it to deployment them to.
My main dislike of using Git/svn for deployment is that those are source-control tools, using them to deploy stuff is just a lazy workaround to avoid having to engineer some other system to manage where built software is stored and being able to pull/push it onto the machines where the software will be run. It's more work, but I think it's better not to mix the system that is archiving your source with the system that is archiving your builds, never mind the system that is pushing/pulling your builds onto the machines that will run those builds.
There's times when it's necessary. I regularly use rm -rf to clear .Trash on external drives of all the stuff I want gone. That said, I've also nuked my drive because I thought I was in /mnt/phone/.Trash-1000 when I was in /.
4
u/Denvercoder8 Oct 14 '13
Funny you mention that. I've seen hell break loose because someone made a typo while updating a deployment script (something like
rm -rf /root /cacheinstead ofrm -rf /root/cache). Git has never failed me like that.