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