Drupal 6 から Drupal 7 へのアップグレード:プログラマーのベストプラクティス?

Question

私は D4 シリーズから Drupal を使用していますが、専門的に開発を始めたのは D6 からでした。そのため、さまざまなサイトのアップグレードを行ったにもかかわらず、次のようなタスクに直面したことはありませんでした。 自分のコードを移植する必要がある 新しいバージョンに。

Drupal コミュニティが、変更された API やアーキテクチャの変更に関して多くの技術サポートを提供してくれることはわかっています ( デッドウッドモジュール D5 ～ D6 または D6 ～ D7 のハウツーのスタブでも モジュール用 とテーマ).

しかし、私の質問で私が探しているのは、より多くのことです 戦略的思考, 、つまり、 自分のコードを移植するプロセスを計画/実装/レビューする方法に関する入力とアドバイスを探しています, 、同僚の開発者が以前の経験から学んだことを踏まえて。いくつかの例:

1. 時間ができたらすぐにモジュールの移植を開始し、しばらくの間は並行 D7 を維持するようにアドバイスしていただけますか (D デイに向けて「準備ができている」ので)、それともむしろ、実際に港が来る日 差し迫った その後、モジュールを D7 にアップグレードして、D6 バージョンを削除しますか?
2. 私のモジュールの一部だけが完全なテスト カバレッジを持っています。D6 バージョンのテスト カバレッジを完了して、すべてのテストが動作して D7 ポートをチェックするようにアドバイスしてください。それとも、D7 バージョンをテストするために、移植時に指示するテストを作成するようにアドバイスしてください。
3. 早期導入者になることで、新機能や優れた API の点で優位性が得られると思いましたか、それとも、すぐに利用できる大量の contrib モジュールを活用するために変換を遅らせたほうが便利だと思いましたか?
4. 品質基準/評価基準を自分で設定しましたか、それとも単に「うまくいけば満足」という基準を設定しましたか?なぜ？特定の基準や目標を設定した場合、それらはどこに何をしたのか、どのようなものになるのでしょうか?彼らはあなたをどのように助けましたか?
5. 過去に経験した、D6 ～ D7 移植プロセスに当てはまると思われる一般的な落とし穴はありますか?
6. 移植はリファクタリングを行う良い機会なのでしょうか、それとも元に戻すとすべてがより複雑になるだけでしょうか?
7. ...

これらの質問はすべてを網羅したリストではありませんが、私がどのような種類の情報を探しているのかを理解していただければ幸いです。むしろ次のように言いたいです。あなたが関連性があると思うもの、そして私が上に挙げていないものはすべて「プラス」を獲得します！:)

私の考えを十分に明確に表現できなかった場合は、質問に追加すべきと思われる情報をコメントとして投稿してください。よろしくお願いいたします。

追伸：はい、知っています...D7 はまだリリースされておらず、重要な contrib モジュールがアップグレードされるまでには数か月かかります...しかし、考え始めるのに早すぎるということはありません。:)

Answer 1

良い質問ですので、見てみましょう。

1. (移植を開始する時期)
   これは確かに、移植するモジュールの複雑さに依存します。本当に複雑/大規模なものがある場合は、プレッシャーをかけずに難しい箇所を見つけるために、早めに始めると便利かもしれません。小規模/標準的なものについては、日常的な内容をすぐに覚えられるように (そして、おそらく改善されたドキュメントの恩恵を受けるために)、それらの多くを連続して移植できる、より大きな時間枠を後で見つけようとします。

2. (テスト範囲)
   通常、リファクタリング/移植を開始する前に十分なテスト カバレッジを取得することが確かに賢明であると思います。しかし、Drupal-7 がテスト フレームワークをコアに移動することで大きな変更を導入していることを考えると、いずれにしてもかなりの量のテストを書き直す必要があると予想されます。したがって、移行後に Drupal-6 バージョンを維持する必要がない場合は、時間/手間を節約し、移植後の適用範囲の拡大を目指します。

3. (アーリーアダプター vs.成り行きを見守る）
   バージョン 4.7 から Drupal を使用してきましたが、移植について考える前に、少なくとも新しいメジャー バージョンの最初の正式リリースを常に待ってきました。Drupal 6 では、最初のサイトを移植する前にビュー モジュールを待ちました。Drupal-5 にはまだいくつかの小さなプロジェクトがあり、それらは問題なく動作しており、クライアントに追加の請求を正当化するのは難しいためです。メンテナンス/セキュリティ修正がまだ残っています。1 日にはあまりにも時間があり、修正すべきバグや追加すべき機能などの未処理の作業が常にあります。そのため、クライアントにすぐに利益をもたらす差し迫ったやるべきことがあるにもかかわらず、未完成のテクノロジーをいじっていても無駄です。1 つ以上の「公式」寄稿モジュールを維持する必要がある場合は、早期ポートを提供することが良いことになるため、これは確かに異なります。
   ここで少し困っています。修正される前に誰かがそのバグを見つけなければならないため、アーリーアダプターであることは確かにコミュニティに利益をもたらしますが、その一方で、何時間もバグと戦うことはビジネス上あまり意味がありません。もう少し待っていれば、他の人が見つけたり修正したりしたかもしれません。生計を立てるためにこれをしなければならない限り、私は自分のリソースに気をつけて、コミュニティへの奉仕とコミュニティからの利益の間で許容可能なバランスを保つように努める必要があります :-/

4. （品質基準）
   「うまくいったら幸せ」という言葉は通用しません。瞬間だけ幸せになりたいのではなく、明日も幸せになりたいのです。したがって、私の品質基準の 1 つは、単に物事を機能させるだけでなく、正常に機能させるために、新しいコンセプトを十分に「理解」したことを (ある程度) 確信する必要があるということです。さて、これをより正確に定義するのは困難です。「理解する」前に「理解した」かどうかを知ることは明らかに不可能であるため、結局のところ、「ああ、それはうまくいく」か「うまくいく」かの直感/区別になります。「そうだ、それは正しいようだ」そして、人はこれについてかなり定期的に間違っていることを受け入れなければなりません。
   とはいえ、私が特に気をつけている点は「できるだけ早く介入する」ということです。初心者として、私はテーマ設定段階で「事後」に調整することがよくありましたが、処理チェーンの早い段階で何らかのフックを使用して「修正」を適用するほうがはるかに簡単でした。そのため現在、テーマレイヤーで何かを「調整」しようとしているときは常に、意図的に少し時間をとって、フック内でこれをもっときれいに/互換性を持って行うことができないかどうかを確認します。Drupal-7 ではさらに多くのフック オプションが追加されると予想しているため、新しいモジュールを追加する際の競合や突然の「内容の中断」が通常は軽減されるため、これには特に注意を払うことになります。

5. (よくある落とし穴)
   そうですね - 主に初期への移植ですが、後から/途中で、必要な 1 つ以上のモジュールが新しいバージョンではまったく利用できないか、開発/アルファ/初期ベータ状態でしか利用できないことがわかりました。だから私は必ずコンパイルします 完了 最初に使用/必要なモジュールのリストを表示し、それらの移植状態をリストし、発行キューを簡単に検査します。
   それに加えて、私はこれまで常に とても 新しいバージョンとその改良点には満足しており、また Drupal-7 を楽しみにしています。

6. (移植時のリファクタリング)
   移植自体はかなり大規模なリファクタリングであるため、移植に関連しないものを再構築して複雑さを増す必要はないと言えます。一方、すでにモジュールを粉々に砕かなければならない場合は、この機会を利用して大規模な見直しをしてみてはいかがでしょうか?私は複雑さに基づいて線を引くようにします。大規模で複雑なモジュールの場合は、ポートをできるだけまっすぐに実行し、必要に応じて後でさらにリファクタリングします。小さなモジュールの場合、微妙なバグが発生する可能性はかなり低いはずなので、実際には問題にはなりません。

7. （他のもの）
   ...それについて考える必要があります...

---

さて、その他のこと:

• リソースのニーズ - Drupal-7 スレッドの一部を考慮すると、スレッドが増加する可能性が高いため、共有/制限付きホスティング アカウントにある小規模なサイトを移植する前に評価する必要があります。

• 最新バージョンを最初に - これはかなり明白であり、アップグレード ガイドで常に強調されていますが、それでも言及する価値があります。アップグレード コードが正しく動作するためには最新のテーブル/データ構造に依存する可能性が高いため、メジャー アップグレードを実行する前に、まずコアとすべてのモジュールを最新バージョンにアップグレードしてください。Drupals の「段階的」更新戦略を考慮すると、さまざまなアップグレード前の状態を検出し、それに応じて動作するアップグレード コードを実装するのは非常に困難です。