2

私たちの展開戦略: 環境スコープの db 構成とファイルがあります (とを.htaccess考えprod.htaccessてください)。デプロイは capistrano を使用して行われます。これは、デプロイするブランチのチェックアウトから始まり、スコープ外のファイルを削除して、スコープ内の htaccess の名前を から に変更します。これが完了すると、ディレクトリは非削除 rsync を介して apache webroot に転送されます。dev.htaccesslocal.htaccessCapfile.htaccess[env].htaccess.htaccessrepository/public_html

背景: 私が働いている会社は、1998 年から存在しているオンライン出版物であり、フォルダー構造がごちゃごちゃしているため、展開戦略は複雑です。バージョン管理されたファイルは、生成されたファイルとユーザーがアップロードしたファイルの隣に存在します。この場合、apache webroot フォルダー全体を の対応するフォルダーに単純にシンボリック リンクすることはできません/current。生成されたファイルは、新しいデプロイが行われるたびに消去され、ユーザーがアップロードしたディレクトリに散在するファイルは、他の場所からシンボリックリンクする必要があります。したがって、非削除 rsync 操作.

ただし、上記でほのめかされた現在の狂気は、別の日の質問です.

私が欲しいのは、デプロイ時にレポ内の htaccess および db 構成ファイルの削除と名前変更を必要としないソリューションです。/deploy/currentその理由は、デプロイからのローカル変更のもつれと戦う必要なく、作業してコミットできるようにするためです。

このような環境スコープのファイルを展開するための一般的なソリューションは何ですか? /configそれらを上記のフォルダーに移動し、環境に応じて/public_htmlApache webrootから関連ファイルにシンボリックリンクする必要がありますか?/config

4

1 に答える 1

2

次の方法でこれにアプローチすることをお勧めします。

  • すべての[env].htaccessファイルをリポジトリに保持します。
  • deploy:updateすべての[env].htaccessファイルをシンボリックリンクにシンボリックリンクした後.htaccess ( ln --symbolic [env].htaccess .htaccess)
  • ファイルを削除しないでください*.htaccess。
  • 開発者/管理者に*.htaccessファイルを編集してもらいます (彼らは、シンボリック リンクを介して範囲内のファイルにアクセスし、範囲外.htaccessのすべての [env].htaccess ファイルにアクセスできます。
  • 開発者/管理者がdeploy/currentフォルダーから直接コミットできるようにします (ただし、コミットできる有効なリポジトリであることを確認してください)。
  • 作業する他のタイプのファイルには、このプロセスを使用してください。

これにより、あなたが説明した問題が解決されるか、少なくとも緩和されると思います。私は個人的にそのようにこれを開始し、それがどのように機能するかを見ていきます.

ところで、なぜCapfileafterを削除するのdeploy:updateですか?

于 2012-10-19T15:57:39.107 に答える