18

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

Drupal コミュニティが、変更された API とアーキテクチャの変更について多くの技術サポートを提供することを私は知っています (D5-D6 のデッドウッド モジュール、またはモジュール とテーマの D6-D7 ハウツーのこれらのスタブを参照してください)。

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

  1. 時間ができたらすぐにモジュールの移植を開始し、しばらくの間並行 D7 を維持することをお勧めしますか (そのため、D デイの「準備」ができています)、それとも、移植が実際に差し迫っていて、モジュールを D7 にアップグレードし、D6 バージョンをドロップする日は?
  2. 一部のモジュールのみが完全なテスト カバレッジを備えています。D7 への移植をチェックするためにすべてのテストが機能するように、D6 バージョンのテスト カバレッジを完了することをお勧めしますか、それとも、D7 バージョンをテストするために、移植時に私のテスト ディレクティングを書くことをお勧めしますか?
  3. アーリー アダプターになると、新機能やより優れた API の点で優位に立つことがわかりましたか、それとも、すぐに利用できる大量の contrib モジュールを活用するために、変換を遅らせる方が便利だと思いましたか?
  4. 品質基準・評価基準はご自身で設定されましたか？なんで？特定の基準または目標を設定した場合、それらはどこでどのようなものになりましたか? 彼らはどのようにあなたを助けましたか?
  5. 過去に経験した、D6-D7 移植プロセスに当てはまると思われるよくある落とし穴はありますか?
  6. 移植はリファクタリングを行うのに良い時期ですか、それとも元に戻すためにすべてがより複雑になるだけですか?
  7. ...

これらの質問は網羅的なリストではありませんが、私が探している情報の種類についてのアイデアを提供してくれることを願っています. むしろ、あなたが関連性があると思うものは何でも、上にリストしなかったものはすべて「プラス」になります！:)

私が自分自身を十分に明確に表現できなかった場合は、質問に追加する必要があると思われる情報をコメントに投稿してください. お時間をいただきありがとうございます。

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

4

1 に答える 1

16

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

  1. (いつ移植を開始するか)
    これは確かに、移植するモジュールの複雑さに依存します。非常に複雑で大きなものがある場合は、プレッシャーを受けずにトリッキーなスポットを見つけるために、早めに開始すると役立つ場合があります。小規模/標準的なものについては、日常的なものをすばやく記憶するために（そしておそらく改善されたドキュメントの恩恵を受けるために）、それらの多くを連続して移植できるより大きな時間枠を後で見つけようとします.

  2. (テスト カバレッジ)
    通常、リファクタリング/移植を開始する前に、適切なテスト カバレッジを用意しておくことをお勧めします。しかし、Drupal-7 がテスト フレームワークをコアに移動することで大きな変更を導入したことを考えると、とにかくかなりの量のテストを書き直す必要があると思います。そのため、移行後に Drupal-6 のバージョンを維持する必要がなければ、時間と手間を省いて、移植後のカバレッジの拡大を目指します。

  3. (アーリー アダプター vs. 様子見)
    バージョン 4.7 から Drupal を使用しており、移植について考える前に、少なくとも新しいメジャー バージョンの最初の公式リリースを常に待っていました。Drupal 6 では、最初のサイトを移植する前にビュー モジュールを待ちました。メンテナンス/セキュリティ修正がまだあります。1 日には非常に多くの時間があり、修正すべきバグや追加する機能などのバックログが常に存在するため、未完成のテクノロジーで遊んでいる間は、すぐにクライアントに利益をもたらす差し迫ったことを行う必要があります。初期のポートを提供することは良いことなので、1 つ以上の「公式」に提供されたモジュールを維持する必要がある場合、これは確かに異なります。
    私はここで少し窮地に立たされています - アーリー アダプターであることは確かにコミュニティに利益をもたらします。誰かがバグを修正する前にそのバグを見つけなければならないからです。もう少し待っていれば、他の人が見つけた/修正したかもしれません。生活のためにこれをしなければならない限り、コミュニティへの奉仕とコミュニティからの利益の間で許容できるバランスをとろうとして、自分のリソースを監視する必要があります:-/

  4. （品質基準）
    「うまくいったら幸せ」じゃダメ、一瞬だけ幸せにしたくないから明日も。つまり、私の品質基準の 1 つは、物事を機能させるだけでなく、本来あるべきように機能させるために、新しい概念を十分に「理解」したことを (ある程度) 確信する必要があるということです。これをより正確に定義するのは困難です。なぜなら、「理解する」前に「理解した」かどうかを知ることは明らかに不可能だからです。 、それは正しいように見えます」、そして彼がこれについてかなり定期的に間違っていることを受け入れる必要があります.
    とはいえ、私が注目している特定のポイントの 1 つは、「できるだけ早く介入する」ことです。初心者として、テーマ設定段階で「事後」に微調整することがよくありましたが、処理チェーンの早い段階でいずれかのフックを使用して「修正」を適用する方がはるかに簡単でした。そのため、現在、テーマレイヤーで何かを「調整」しようとするときはいつでも、意図的に少し時間をかけて、フック内でこれをよりきれいに/互換性を持たせることができないかどうかを確認しています。Drupal-7 がさらに多くのフック オプションを追加することを期待しているので、新しいモジュールを追加するときの競合や突然の「破壊」を通常は減らすため、これには特別な注意を払います。

  5. (よくある落とし穴)
    まあ - 主に早期に移植し、後で/その間に、1 つ以上の必要なモジュールが新しいバージョンでまったく利用できないか、開発/アルファ/初期ベータ状態でしか利用できないことを発見します。そのため、最初に使用済み/必要なモジュールの完全なリストをコンパイルし、それらの移植状態をリストし、それらの問題キューを簡単に検査するようにします.
    それに加えて、これまでのところ、新しいバージョンとその改善に非常に満足しており、Drupal-7 を再び楽しみにしています。

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

  7. (その他のもの)
    ... 考える必要があります ...

わかりました、他のもの：

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

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

于 2009-11-17T20:06:44.887 に答える