開発者向け
危険な「ビッグバン」リリースなしでウェブサイトを再プラットフォーム化する方法
By Tom Marshall
大規模なWebサイトをチャンクで再プラットフォーム化し、リスクを軽減し、顧客価値をより早く提供できるとしたらどうでしょうか。 KyanのTomMarshallがその方法を説明します。
プラットフォームを変更する必要がある大規模なWebサイトがあるとします。おそらく、競争はより良いデジタル体験を提供しているのかもしれませんし、あるいは私たちはレガシーインフラストラクチャと格闘し始めているのかもしれません。動機は重要ではありませんが、決定が下されました。Jamstackなどの別のプラットフォームに移行します。
それには何ヶ月も、多分何年もかかるでしょう。新しいサイトの準備が整うのを待っている間、ビジネスは立ち止まることはできません。そのため、バックグラウンドで新しいサイトを構築している間、レガシーサイトに機能を追加し続ける必要があります。
レガシーサイトに追加するすべての機能は、新しいサイトにスコープを追加し、リリースを遅らせ、再構築が完了する前にさらに多くの機能を追加するためのウィンドウを増やします。それは悪循環です。
競争の激しい市場で大規模なWebサイトを再プラットフォーム化したことがある場合、これはおそらくおなじみのように聞こえます。「ビッグバン」リリースの問題のあるスコープクリープを回避し、顧客価値をより早く提供する方法があったとしたらどうでしょうか。
「ビッグバン」リリースの問題
「ビッグバン」リリースの問題は、サイトをリリースする前に、サイトの完全な機能を再構築する必要があることです。それには時間がかかり、その間に顧客と企業は新しい機能を要求します。
新しい機能を追加したいという衝動に抵抗すると、競争に負けるリスクがあります。そのため、レガシーサイトに機能を組み込み続けています。それは顧客価値を提供しますが、高いコストが伴います。
まず、レガシーサイトに追加された新しい機能も新しいサイトに追加する必要があるため、開発作業を複製しています。これにより、開発コストが2倍になります。これで終わりだと思われるかもしれませんが、実際にはもっと悪いです。再構築にスコープを追加することで、リリースを遅らせ、さらに多くの機能を追加してリリースをさらに遅らせる機会を増やします。
マラソンを走るために出発し、26マイルに到達したところ、フィニッシュラインに向かって走っているときに、マラソンが遠ざかり、さらに12マイル走ることができたと想像してみてください。あなたはかなり動揺するでしょう。
これらすべてが、ビジネス内の利害関係者からの圧力が高まっている状況下で、新しいサイトの構築に投資して顧客に価値を提供し始めることができるように、新しいサイトの完成を推進しています。
インクリメンタルオルタナティブ
新しいサイトが完成するのを待つ代わりに、既存のサイトを少しずつ置き換えて、新しいサイトをセクションごとにリリースできるとしたらどうでしょうか。
HTTPリライトを使用すると、リクエストパスに基づいて、同じドメインへのトラフィックをサーバー側の異なる宛先に転送できます。したがって、サイトをURLパスに基づいてセクションに分割すると、このパスベースのルーティングを使用して、これらのセクションで新しいサイトを段階的に配信できます。
サイトを複数の方法でセクションに分割することもできますが、最も簡単なのは副産物(検索、カスタマーポータルなど)である可能性があります。
典型的なeコマースWebサイトのサイトマップを見てみましょう。これを次のセクションに分割できます。
各セクションは、既存のWebサイトの一連のURLパスにマップされます。たとえば、ブラウズには、次のものが含まれます。
- /製品
- / products /:id
- / products / category
- / products / category /:id
これらのページルートが構築され、リリースのためにサインオフされると、パスベースのルーティングを更新して、これらのページのリクエストを新しいサイトに転送し、残りのトラフィックは引き続きレガシーサイトによって処理されます。
ここで実用性に関するいくつかの問題を発見したかもしれません。インクリメンタルリリースアプローチは、プラットフォームを再構築するための特効薬ではありません。考慮すべきいくつかのトレードオフがあります。
トレードオフ
まず、本番環境で異なるスタック上に2つのサイトを並べて実行することによる管理オーバーヘッドがあります。第二に、2つの異なるサイト間をジャンプしていることに顧客に気付かせることはできません。そうしないと、不快な体験が生まれます。
真にシームレスなエクスペリエンスを作成するには、次のことを考慮する必要があります。
- レイアウト
- セッション
- サードパーティのタグ/スクリプト
- クッキー管理
- サイトマップ
- ファビコン
- エラーページ
これらに一つずつ取り組んでいきましょう。
レイアウト
従来のサイトデザインを想定すると、レイアウト、つまりヘッダーとフッターは、デザインとコンテンツの両方でサイト間で一貫している必要があります。
デザインが変更されておらず、コンテンツが静的である場合、これは簡単です。レガシーサイトのヘッダーとフッターを新しいサイトに複製するだけで、すぐに使用できます。
ただし、よくあることですが、サイトがリプラットフォームの一部として視覚的に更新されている場合、またはヘッダーまたはフッターに動的コンテンツが含まれている場合は、ここでさらに多くのことを行う必要があります。
デザインが変更される場合は、2つのオプションがあります。私たちのどちらか。
- レガシーサイトを新しいデザインで更新し、
- または、レガシーサイトのヘッダーとフッターを新しいサイトに複製し、プロジェクトの最後に新しいデザインを実装します。新しいサイトがすべてのページを提供している場合です。
あなたのサイトに最適なものはあなたの状況に依存します。たとえば、新しい設計をレガシーサイトに実装するのはどれほど簡単でしょうか。等々。
一部のサイトでは、ヘッダーまたはフッターに動的コンテンツが含まれます。そのコンテンツは、在庫レベルに基づいて表示/非表示になる製品カテゴリである場合もあれば、ユーザーがログインしているかどうかに基づいて表示されるヘッダー内のさまざまなアクションである場合もあります。動的コンテンツが何であれ、3つの選択肢があります。削除するか、静的にするか、新しいサイトで再利用できるように公開します。おそらくAPIエンドポイントを介して行います。
セッション
はい、セッションです。ユーザーにサイトに部分的にログインさせることはできません。または、2回ログインする必要があります。サイト全体をカバーする単一の共有セッションが必要です。
新しいサイトでセッションが必要なものは3つあります。
- 現在のセッションが有効かどうかを確認します。
- パーソナライズされたコンテンツを取得します。
- 読み取りおよび書き込みアクションを許可します。
セッションの共有に伴う複雑さは、サイトによって異なります。
両方のサイトが同じHTTPオリジン(https://example.comなど)上にあるため、両方のサイトがクライアント側のクレデンシャル、つまりCookieにアクセスして使用できるようになります。ただし、クライアント側にCookieが存在しても、その有効性は保証されません。それはサーバーによって確認される必要があります。
レガシーサイトに認証APIがある場合、これらを再利用できる可能性があります。APIがない場合は、APIを作成する必要があります。GET /whoami
基本的なユーザー情報のみが必要なシナリオでは、これは、その情報を返す単一のエンドポイントのように単純な401 Unauthorised
場合もあれば、Cookieが有効なセッションに属していない場合もあります。
新しいサイトでよりパーソナライズされたコンテンツが必要な場合は、追加のAPIを提供する必要があります。
サードパーティのタグ/スクリプト
ほとんどの大規模なサイトには、との両方で、分析、広告追跡、サイト検証などのサードパーティツールからの多数の追加のタグとスクリプトが<head>
あり<body>
ます。
エンドユーザーがこれらに気付くことはめったにありませんが、ツール内に死角が生じるのを防ぐために、これらが新しいサイトのページにも配置されていることを確認する必要があります。
クッキーの同意
サードパーティのスクリプトからうまくリードして、Cookieの同意があります。Cookieの同意ポップアップは1回は煩わしいので、ユーザーがこの問題を2回経験しないようにする必要があります。
レガシーサイトと新しいサイトが同じドメインにある場合、新しいサイトはCookieの同意ステータスをそれほど問題なく読み取って、新しいページがそれに応じてCookieをドロップしていることを確認できるはずです。レガシーサイトがGoogleTagManagerを使用している場合、これは比較的簡単です。
サイトマップ
サイトが公開されていると仮定すると、新しいサイトのページをサイトマップに含める必要があります。両方のサイトが並行して実行されている場合、ここでの最も簡単なアプローチは、sitemap.xmlをそれぞれのサイトマップを含むインデックスに変換し、各サイトが提供するページのサイトマップを作成することです。
ファビコン
おそらくリストで最も簡単なアイテムです。新しいサイトには、従来のサイトと同じファビコンと<meta>
タグが必要です。
エラーページ
重要性ははるかに低いですが、石を残したくない場合は、404、500、およびその他のカスタムエラーページも複製する必要があります。
努力する価値がある理由
大変な作業のように思われるかもしれませんが、サイトの規模が大きく、プラットフォームの再構築に時間がかかる場合は、インクリメンタルアプローチの複数の利点が重要であると言えます。欠点。
では、利点は何ですか?
より早く価値を提供する
サイトの各セクションを完成時にリリースすることで、顧客とビジネスの価値を早期に提供します。完成した機能が棚に置かれている間、サイトの残りの部分が完了するのを待つ必要はもうありません。開発努力はより早くその投資に戻ります。
減圧
大規模なプラットフォーム再構築プロジェクトには、多額の投資が必要です。「ビッグバン」アプローチでは、さらに多くの機能を追加する前にプロジェクトを急いで完了するため、その投資は潜在的なものになります。コストが増加するにつれて、内部の利害関係者からの圧力も増加します。完成したセクションを展開することで、その投資から価値を提供し、そのプレッシャーを解放します。
リスクの軽減
ソフトウェアをユーザーの手に早く手に入れると、フィードバックループが短縮され、前提条件を検証し、より速く学習し、それに応じてコースを調整できるようになります。フィードバックサイクルを短くすると、製品の観点からリスクが軽減されますが、技術面でもリスクが軽減されます。
サイトを一度に置き換えるのはストレスがたまります。ルーティングは正しく構成されていますか?自動スケーリングは機能しますか?CDNキャッシングは正しく行われていますか?うまくいかないことが無数にあります。
一度に1つのセクションでサイトを立ち上げることには、2つの利点があります。まず、サイト全体ではなく、機能のサブセットのインフラストラクチャ要件に注意を向けることができます。次に、ビジネスクリティカルな領域に取り組む前に、リスクの低いセクションから開始することで、新しいサイトインフラストラクチャに対する信頼と経験を構築できます。
レガシーの廃止、より早く
複数のシステムがレガシーサイトを提供している場合、それらのいくつかは他のシステムよりも維持するのに問題がある可能性があります。その場合は、サイトのセクションに優先順位を付けて、これらの困難なシステムをより早く廃止し、インフラストラクチャをオフにして、「ビッグバン」アプローチよりも早く頭痛の種を減らすことができます。
「銀行」の進捗状況
最後に、すでにリリースしたセクションに重要な新機能が登場した場合、その機能を2回ではなく、1回構築できます。これにより、レガシーサイトへの苛立たしく高価な使い捨て投資を回避し、新しいサイト機能の提供を遅らせることなく実現できます。それはすでに完了しています。
これはフィニッシュラインを完全に「修正」するわけではありませんが、加速が大幅に遅くなるため、プロジェクト全体をより早く完了することができます。
インクリメンタルアプローチはあなたに適していますか?
ここまで進んだら、サイトを再プラットフォーム化するための段階的なアプローチがすべてのプロジェクトに適しているわけではないことは明らかです。
サイトが比較的小さいか、成熟していて頻繁に変更されない場合は、従来の「ビッグバン」の再構築を使用したほうがよいでしょう。
ただし、大規模なサイトが活発に開発されている場合は、段階的なアプローチでプラットフォームを再構築することで、リスクを軽減し、コストを削減し、顧客価値をより早く提供できる可能性があります。
魅力的なトリオ、聞いたことがあるとしたら。
Jamstackへの再プラットフォームを検討していますか?KontentDiscordでそれについて話し合ってください。