Drupal Gitリポジトリと本番ウェブサイトを壊さずにコアをアップグレードするためのベストプラクティスは何ですか？
私はすべてのコードがマスターブランチにあるGitリポジトリを持っています。以前はすべてのDrupalファイルを無視していたため、記述したコードを厳密に分離していました（または変更されているか、変更される可能性があります）、Drushなどで生成できるコード。
これは、Drupalをアップグレードしなければならないまでは、良い戦略のように思えました。物事がうまくいかなかった場合にロールバックできるようになりたいと思いました。それを行うには、Gitよりも優れたツールを使用する必要があります。これは機能ブランチの完璧な状況だと私は思ったので、drupal-7.14ブランチを作成し、独自の.gitignoreを指定して、すべてのコードと設定ファイルを無視し、そのファイルのみに注意を払いましたDrupalインストールの一部であり、触れないでください。robots.txtや.htaccessなどのボーダーラインのケースをソートして、手動でアップグレード（ダウンロード、解凍、解凍、コピー）を行いました） 、そしてDrupalの.gitignoreを自分のもので上書きしました。500エラーから回復するために、7.14では機能するが7.15では機能しない設定をいくつか修正しました。その後、すべてが完璧に見えるようになりました。ブランチの名前をdrupal-7.15に変更して、私の道を楽しく行きます。
誤って行ったことに気づくまで：以前はマスターブランチによって追跡されていなかったが、作業ディレクトリに残されたファイルは、追跡されなくなったファイルではなくなったため、マスターをチェックアウトしたときに作業ディレクトリから削除されました。 D'oh！
drupal-7.15ブランチをマスターとマージすると、コードの分離が失われます。
ブランチをサブモジュールに変換する方法はおそらくあるでしょう。それが可能だとすれば、それが最善の戦略かもしれません。これを行う前に、サブモジュールが「正しい」ソリューションであることを知っていましたが、以前に追跡されていないファイルにブランチを使用することの副作用を理解していなかったため、手抜きしてそのルートに進むことにしました。 （また、Drupalでサブモジュールを使用するために私が見たすべてのアプローチは、新しいプロジェクトを開始し、Drupalがマスターブランチになることを前提としています。他の誰かのコードをマスターブランチにすることは私には望ましくなく、すでにマスターブランチを持つリポジトリを持っています。これは、アップグレードを行うだけでは不必要に複雑になるように見えました。）
他に考えたことのない解決策があるかもしれません。
可能な限り少ない欠点でこれから最もよく回復するにはどうすればよいですか？
[〜＃〜] update [〜＃〜]：これは開発中です（Linuxの場合） VM）、まだプロダクションに移行していません。プロダクションに移行するときまでに、すべてを機能モジュールにラップする予定ですが、それはまだ整っていません。
UPDATE 2：サブモジュールが機能しない可能性があります。 Pro Git によると、「サブモジュールを使用すると、Gitリポジトリを別のGitリポジトリのサブディレクトリとして保持できます」。 Drupalはそのような素晴らしい分離を提供しません。すべてのDrupalコードがサブディレクトリにあるのではなく、関係は多かれ少なかれ逆になりますが、まだあります.htaccessとrobots.txtを編集している可能性があるため、明確な分離はありません。コードとDrupal repoが一緒に混在しています。私は これの回避策を探しています問題 。
上記の議論から、あなたの質問はあなたのgitリポジトリを修正することではなく、Drupal gitでサイトを維持すること、およびそれがコア更新でどのように機能するかについてです。
標準的な方法は、実際にはDrupalコアを含む）すべてのファイルをリポジトリに保存することだと思います。Drupalコードをカスタムコードから分離することは、素晴らしいアイデアのようです。 、しかし私はそれが必要だとは思いません、そしてそれがあなたにどのような利点をもたらすのか分かりません。また、コアにパッチを適用したくない（またはデプロイの一部としてそれをしなければならない）ことを想定しているようです。は、ベストプラクティスではありませんが、何かが運用環境で中断した場合に実行できることは間違いありません。コミットを適切に維持することで、この種の分離を実現することもできます。
私が使用した解決策は、すべてのコードを同じリポジトリに保持し、機能または他の種類のエクスポート/コード/構成にできる限り多く入れて、外に適用する必要があるパッチのリストを維持することです-boxコアとcontrib。
コアを更新したら、開発環境で開始します。
- 作業ディレクトリがクリーンであることを確認してください
- 最新のデータベースをダンプします（
drush sql-dump）。ダンプを使用してコミットするか、安全な場所に保存してください。 - コアを更新（
drush up drupal） - すべての変更をコミットします。
- パッチファイルを確認してください。パッチを適用する必要がある場合は、パッチを適用して、もう一度コミットします。
- 必要に応じてupdate.phpを実行します（更新にDrushを使用した場合は既に実行されています）
- 開発サイトをテストします。すべて問題なければ、本番環境にコードをプッシュします。本番環境で
drush updbを実行します。 - 問題があり、元に戻す必要がある場合は、リポジトリを元に戻すかリセットして（
git reset --hard HEAD~2で実行する必要があります）、履歴を保持する場合は2つのコミットを元に戻します。データベースをダンプに置き換えます。
更新によってデータベースに加えられた変更を元に戻すことができないため、データベースダンプが必要です。ブランチで更新を行うこともできます。その場合、元に戻すとは、マスターをチェックアウトすることを意味します。 1つの開発サイトで作業している場合、データベースが原因で実際にマスターに切り替えて並列で作業し続けることができないため、少しお勧めできません。
このよりシンプルなgitサイドのワークフローを使用すると、サブモジュールなどの複雑さなしに、必要なときにgitの全機能を使用できるようになります。これが適切でないと思われる場合は、コードをさらに分離する必要がある理由を説明できますか？
OPのように2つのブランチを使用してセットアップを実行しています。1つはカスタムコードのみを含むブランチ、もう1つはカスタムファイルとコアファイルの両方を含むブランチです。同じ状況に遭遇しました：ブランチを切り替えると、無視されたコアファイルが削除されます。
私は2つの同一のgitディレクトリを作成しました：-コアファイルは存在するが無視されたカスタムコードでの作業用で、このディレクトリの「完全な」ブランチに切り替えることはありません-マージを実行するための1つです。このディレクトリ内でのみブランチの切り替えとマージを実行します。
この2つのブランチのセットアップを選択した理由は、コアファイルへのすべてのローカルコミットを簡単に追跡したいためです。コアファイルをアップグレードするときに、コアMODを調べて再適用する方が簡単です。
上記の私のコメントから、あなたが持っているこの質問はgitでDrupal sitefilesを維持すること、およびそれがどのように機能するかについてですコアの更新あり。データベースのバックアップとアップグレードについては何も触れられていません。私はgoronの回答から何もコピーしないようにします。
この問題についてブログ投稿を作成しました pgrading Drupal Git with your website onコア
代替方法
- Drushコマンドを実行する
drush up drupal- バージョン間の違いのパッチを適用します。 http://drupal.org/node/359234 および http://fuerstnet.de/en/drupal-upgrade-easier を参照してください
あなたはこれを述べていませんが、Drupalバージョン間の変更の追跡に興味がある場合は、代わりにtagsを使用してこれを行いますbranches。masterへのアップグレードコミットが完了したら、コードに7.xのタグを付けます。