2 つのサイト (ステージングとライブ) があります。両方のサイトにプッシュしてデプロイする中央の git リポジトリが必要です。
また、ステージング サイトとライブ サイトの両方でコードに発生する変更 (プラグインのインストール、テーマ、拡張機能など) をキャプチャする必要もあります。最適な構造のアイデアが必要です。
明らかに、私たちのチームは中央リポジトリの作業コピーをローカルに保持する必要があります。ありがとう!
2 つのサイト (ステージングとライブ) があります。両方のサイトにプッシュしてデプロイする中央の git リポジトリが必要です。
また、ステージング サイトとライブ サイトの両方でコードに発生する変更 (プラグインのインストール、テーマ、拡張機能など) をキャプチャする必要もあります。最適な構造のアイデアが必要です。
明らかに、私たちのチームは中央リポジトリの作業コピーをローカルに保持する必要があります。ありがとう!
使用するのは 2 つのブランチmaster
とproduction
です。通常master
、ステージング時にチェックアウトされる開発が行われます。
すべてが正常に機能したら、プロダクションをマスターにリセットし、プッシュを強制します。production
次に、チェックアウトされている場所でライブを実行します。これらすべてを実行するスクリプトは、すべてを実行する前に、ライブでプッシュされていない変更がないことを確認します。
で実行する必要があるホットフィックスについてproduction
は、チェリー ピック ポリシーがありmaster
ます。
注目すべきは、まったくマージしないことです。やりましたが、うまくいきませんでした。
カピストラーノを多段階展開で使用して、必要なものを処理できます。デプロイされるレポは、アプリ サーバー環境からプルするためにアクセスできるほとんどどこにでも配置できます。
たとえば、最近のプロジェクトでは、プライベート GitHub リポジトリをデプロイ リポジトリとして使用しました。GitHub で認証するためにアプリ サーバーに SSH キーを設定し、ローカル ワークステーションから発行する Capistrano コマンドに応じて、ステージングまたは本番環境にデプロイできます。ローカルの Capistrano インスタンスはリモートで (SSH を介して) アプリ サーバーに、Github の適切なブランチから最新のものをチェックアウトして独自のローカル リポジトリにフェッチし、最新のコードを新しいディレクトリにコピーしてから、タスクのチェックリスト (config変更、アセットのコンパイル、データベースの移行など)。デプロイが成功すると、Capistrano はサーバーに最新のコードに切り替えるように指示します。問題が発生すると、展開がロールバックされます。
デプロイするコマンドは次のように簡単です:cap deploy
またはcap production deploy