2

現在のphp開発ソリューションのセットアップ方法は次のとおりです。

各開発者は自分のローカル マシンで作業します。各開発者は、変更を共通の SVN サーバー (イントラネット) にコミットします。コミット フックは、変更をステージング サーバーにアップロードし、検証タスクを実行します。製品の準備ができたら、SFTP 経由で手動で本番サーバーにデプロイします。

注: ほとんどの場合 (すべてではないにしても)、サーバーへの SSH アクセスがなく、SFTP のみです。

ステージング サーバーを更新するのと同じ方法で運用サーバーへの展開を自動化できますが、このソリューションは一方向にしか機能しません。問題が発生した場合、以前のリビジョンに戻すにはどうすればよいですか?

このソリューションを改善するにはどうすればよいですか?

私の英語に感謝し、申し訳ありません。

4

1 に答える 1

4

https with webdavなどの安全なチャネルを介してSVNリポジトリにアクセスするように本番サーバーを設定できる場合は、次のことを試してください。

タグディレクトリやリビジョン番号/日付を入力してsvnエクスポートを実行できるスクリプトを本番サーバーに作成します。このようにして、prodサーバーはsvnから変更をプルしています。

ここで、このスクリプトをから安全に呼び出す方法がある場合は、コミットスクリプトと言います。出来上がり、あなたには自動化があります。

最も重要なことは、計画していないprodサーバーに対して自動更新が実行されないようにすることです。

これを解決するには：

コミットスクリプトは、何かが「/ path / to / tags / release/dir」にコミットされたときにのみprodupdateスクリプトを呼び出す必要があります

適切な変更管理スタッフ（または現在手動の製品供給を管理している人）だけが、リポジトリ内のこのディレクトリへのsvnコピーを実行できることを確認してください。

たとえば、リポジトリが次のように設定されているとします。

/yourWebsite
--> /branches
--> /trunk
--> /tags
----> /releases

prodへの自動デプロイメントをトリガーするコミットは次のようになります。

svn copy https://mySvnRepo/yourWebSite/trunk \
   https://mySvnRepo/yourWebSite/tags/releases/x.y \
   -m "Tagging for production deployment"

ロールバックは、以前のリリースディレクトリにコミットすることで実現できます。ただし、これにより、追加された新しいファイルがロールバックされることはありません。

もちろん、マイレージは異なる場合があります。これはあなたの調査のための単なる提案です。正しく設定されていない場合は、セキュリティへの影響と災害の可能性を検討するために時間をかける必要があります。

他の解決策を考えさせるためだけでも、これが役立つことを願っています。

于 2009-11-10T01:14:22.160 に答える