マルチサーバー展開戦略-本番サーバーでGit？
主な質問：本番サーバーでGitを使用したデプロイは良い戦略ですか？
私が目にする多くの展開戦略は、サーバーにGitを配置することを中心に展開しています（開発、ステージング、本番）。
これのメリットは、ステージ/本番環境への展開にとって明らかなようです。
- 変更をすばやく取り込む機能
- より簡単な自動化
- 必要に応じてブランチを切り替えることができます（おそらくテストサーバーごとのブランチ）
- 本番サーバーでファイルが何らかの形で変更されているかどうかを確認できます
ただし、これにはいくつかの欠点があります。
- セキュリティ-本番環境に読み取り専用アクセスがある場合でも、Gitは潜在的な攻撃のベクトルのようです
git pull本番サーバーで、ステージングされていない本番環境の変更があると失敗する可能性があります（-fでも克服できます）
サービス会社（Beanstalkapp.com、deployhq.comなど）としての展開では、FTP、SFTP、またはSSHを使用します。特にBeanstalkappは、git履歴に基づいてファイルを変更することだけが得意です（すべてのファイルを再デプロイするのではありません）。これらのサービスは、ステージ/本番サーバーにgitがあることを要求しません（SSH経由でデプロイする場合も、その戦略を使用する/使用できるかどうかは議論の余地があります）。
私はsftpを使うのが好きだとわかりました：
- デプロイ前/デプロイ後もスクリプトを実行できます
- 本番サーバーの内容に関係なく、ファイルを上書き、移動、削除します（これは私にとってプラスです）
- 本番環境に.gitディレクトリやgitベースの攻撃の脆弱性はありません
本番サーバーでのgitの使いやすさは、ベストプラクティスとセキュリティの観点から価値がありますか？そうでない場合は、継続的インテグレーションツールをスキップしてデプロイするのに適した方法は何ですか？
（時間/予算/クライアントの制限により、CIツールを日常的に使用できないため、CIツールをスキップすることについてのみ質問します）。
質問への回答：はい、特にインフラストラクチャが複雑/大規模になり始めた場合は、git（または実際には他のリビジョン管理）を使用したデプロイが最適です。
あなたの懸念に答える
セキュリティはレイヤーで実行する必要があり、gitが本当に懸念される攻撃ベクトルであったとしても、それを行うには誰かがサーバーにアクセスする必要があります。優れたサーバーセキュリティ、SSHキーベースの認証、アクセス制御/ロギングがあれば、リスクは非常に低くなります。
もちろん、デプロイツールを作成する場合は、コードの更新が失敗した場合のロールバック手順を検討する必要があります。良い点は、capistrano（私がよく知っている）のようなツールにはすでにこれらのすべてのステップが組み込まれており、動作などを変更できることです。
capistrano または Vlad the Deployer 、さらには Chefがデプロイ （Chef（または他の構成管理ツール）を既にお持ちの場合）のようなデプロイメントツールを使用するのが最善だと思います）。
たとえば、Capistranoは、デフォルトでRailsに向けられていますが、何でもデプロイするように調整できます。サーバーに接続し、コードを更新します（ロールバックが必要な場合に備えて、古いバージョンをいくつか保持します）。以前のバージョンへ）、DBの移行やクリーンアップなどのタスクを実行し、必要に応じてサービスを再起動します。環境に合わせて調整することも、さまざまな環境を使用することもできます（私は本番環境で作業し、他に3つを述べました）。
他のすべてのツールを使用すると、そのようなことができます。デプロイスクリプトの作成に時間を費やすのは、システムが「通常の」システムと実際に異なる場合にのみ有効だと思います。