Blog

Kentico Kontentの環境は、火災の防止にどのように役立ちますか？そして、従うべき2つの展開ルールは何ですか？ KontentMVPのMichaelKinkaidが書いたこの記事で、それ以上のことを学びましょう。

私はCTOです。特にたくさんの帽子をかぶるのが好きなら、それはかなりやりがいのある仕事です。あなたは技術者であり、戦略家であり、コンピュータの電源を切ったり入れたりしても問題が解決しない場合があります。

ギグは少しストレスを感じることがあります。ちょっとだけ。 CTOが幽霊のように白くなるのを見たいですか？展開に失敗し、会社のサイトがダウンしていることを伝えます。

CTOは、展開の失敗の可能性に非常に夢中になっているため、CTOと、彼らが雇う賢いDevOpsの人々は、通常、展開プロセスを「強化」するためにかなりの時間と労力を費やします。

ルール＃1。本番サーバーにはライブコーディングはありません！

何かが発火する可能性は非常に高いです。このリスクを冒してください。そうすれば、インシデントレポートに次のような内容を書くことになります。

「サイトは2時間ダウンし、推定収益は6,000ドル減少しました。私を信じてください、私たちはあなたと同じように驚きました。コードは実際にはかなり良さそうだった。 」

今、私はあなたが何を考えているか知っています：

「これは私たちには決して起こり得ません！広範な開発パイプラインがあります。独立した開発、QA、UAT、ステージングビルドなど。コードの変更は、本番環境の近くにある場所に到達する前に、徹底的にレビューおよびテストされます。 」🤓

よかったね。ルール番号2に従っています。

ルール＃2。 DevOpsに真剣に取り組む

継続的インテグレーション。継続的デプロイ。コードの変更は適切に行われ、真に管理されています。厄介な事件報告は回避されましたか？完全ではありません。ご覧のとおり、時間の経過とともに変化するのはコードだけではありません。ソリューションにもデータがあると仮定すると、これらも進化します。時間の経過とともに新しいデータを追加するだけでなく、データの構造そのものが新しい要件を満たすために変更されます。

ソリューションの一部としてヘッドレスCMSを使用している場合は、それも「データ」、つまりCMSの世界でより一般的に呼ばれている「コンテンツ」を保存します。そのコンテンツの構造は、 コンテンツモデルで定義されています。サイト、アプリ、デジタル製品などに機能を追加および更新するには、コンテンツモデルの構造を変更する必要があります。生産とまったく同じ構造が、たまたま今依存しているのです。間違ったことを変えて、誰が別の事件報告を書いているのか推測しますか？

「サイトは2時間ダウンし、推定収益は6,000ドル減少しました。私を信じてください、私たちはあなたと同じように驚きました。コードは特定のコンテンツ構造を想定していることがわかりました。アイデアをテストするためにコンテンツタイプの要素を削除しました。

機能フラグ、非常に防御的なコーディング、および不要になったコンテンツモデルのビットを削除しないことで、コンテンツモデルの変更を管理できる場合があります。あなたはそうかもしれませんが、これが取引です：ある時点で、変更は物事が壊れるほど重要になるでしょう。

コードの更新を管理するために複数の環境をセットアップします。ルール＃1を覚えていますか？本番サーバーにはライブコーディングはありません。コンテンツモデルでも同じアプローチを取る必要があります。これがまさにKontent環境の出番です。

Kontentの環境は、同じプロジェクト内のコンテンツモデル（およびオプションで実際のコンテンツ）の完全なコピーです。それらは[プロジェクト設定]> [環境]で作成できます。

コードがブランチに編成されているのと同じように、Kontent環境を作成して、各ビルドに独自のバージョンのコンテンツモデルとコンテンツインベントリを持たせることができます。

各Kontent環境には、開発パイプラインの構築に必要なすべてのものがあります。それはそれ自身が付属しています：

• APIエンドポイント。ビルドがコンテンツとコンテンツモデルに到達できるようにします
• 開発パイプラインでビルドをトリガーするために使用できるWebhook
• URLをプレビューして、編集者がその特定のビルドとKontent環境の組み合わせの変更をプレビューできるようにします
• 独自のワークフローや言語設定など、他にもたくさんあります

これにより、コンテンツモデルを安全に変更し、本番環境に移行する前にテストするために必要なすべての分離が可能になります。 「進行中」であるがプライムタイムの準備がまだ整っていない本番環境でのコンテンツモデルの変更を無視するように編集者に指示する必要はありません。何かが誤ってライブになることを心配する必要はありません。さらに言えば、サイト全体がダウンすることを心配する必要はありません。

コンテンツモデルの変更をあるKontent環境から別の環境に移行する方法については、 KontentCLIとKontentManagementAPIを使用して行うことができます。

代理店のWebサイトでKontent環境と移行スクリプトを使用して、基盤となるコンテンツモデルに大きな変更を加え、テストし、展開してきました。私たちのコンテンツストラテジストと開発者のチームは、本番環境を終了し、コンテンツを作成するマーケティング担当者に任せて喜んでいます。代わりに、チームは、別の非本番ビルドに接続された安全なKontent環境で実験することができます。インシデントレポートは必要ありません😄、私はそれが読むと思いますが：

「開発サイトがダウンしました。 Whatevs。 」

環境は、無料のDeveloperプランも含め、すべてのKontentプランで利用できます。あなたの展開から恐れを取り除き、今日それらを使い始めてください。