Main question: Is deployment using Git on production servers a good strategy?
Many, many deployment strategies I see revolve around having Git on your servers (dev, staging and production).
The merits of this seem obvious for deployment to stage/production:
- Ability to pull in changes quickly
- Easier automation
- Can switch branches if needed (branch per test server perhaps)
- Can see if files are somehow changed in a production server
However, I see some drawbacks to this:
- Security – Git seems like a potential vector of attack, even if production has read-only access
git pullon a production server can fail if there are somehow unstaged changes in production (altho surmountable with -f)
Deployment as a service companies (e.g. Beanstalkapp.com, deployhq.com) use FTP, SFTP or SSH. Beanstalkapp in particular is good at only modifying files based on git history (vs re-deploying every file). These services don't request that you have git on your stage/production servers (Altho if you deploy via SSH, it's arguable that you would/could use that strategy).
I've found that I like using sftp:
- Can run scripts pre/post-deploy still
- Overwrites, moves, deletes files regardless of whats on production server (That's a plus to me)
- Don't have .git directory or any git-based attack vulnerability in production
Is the ease of using git on a production server worth it in terms of best-practices and security? If not, what's a good way to deploy while skipping continuous integration tools?
(I only ask about skipping CI tools as time/budgetary/client limitations don't allow them in my day-to-day use).
Best Answer
Answering your question: Yes, deployment using git (or any other revision control really) is the way to go, specially when your infrastructure starts to become complex/big.
Answering to your concers
Security must be done in layers, and even if git was a really concerning attack vector someone would still have to gain access to the servers to do that. Have good server security, SSH key based authentication and access control/logging and you will have very low risk on that.
If you want to write a deploy tool of course you have to consider a rollback procedure in case the code update fails. The good thing is that tools like capistrano (that I am more familiar with) already have all those steps built in, and you can change the behavior and etc.
I think the best is using deployment tool like capistrano or Vlad the Deployer or even Chef deploys if you already have Chef (or other config management tool).
Capistrano for example is kinda directed at rails by default but you can tailor it to deploy anything. It will connect to your servers, update the code (keeping some older versions around in case you need to rollback to a previous version), execute tasks like DB migrations or cleanups, then restart services if needed. You can tailor that for your environment and even have different environments (I worked with production, stating + 3 others).
All other tools will let you do something like that, and I think that spending time to write a deploy script is only valid if your system is really different from the 'usual' ones.