コンテンツにスキップこのブラウザーはサポートされなくなりました。サポートを利用できます。まつわる話題が多くなっています。ユーザーに充実したサービスと有益なデータを提供するうえで欠かせません。上質なソフトウェアを迅速に提供することはもはやオプションではなく、必須です。長期間の計画を経て繰り返し開発を行う時代はもはや過去のことです。プラットフォームの登場で、これまでのボトルネックが解消され、インフラストラクチャの共有が進んでいます。ソフトウェアは、あらゆるビジネスの成功の鍵を握る差別化要因であり、重要な要素になっています。向かう流れに逆らうことはできません。定義には、さまざまな見方があります。大半は、ソフトウェアをできる限り効率よく運用に移行できるように、開発チームと運用チームの間にある文化やテクノロジの壁を取り払うことを指します。ソフトウェアを運用に移行したら、多岐にわたる使用状況データを記録し、そのデータを開発チームと意思決定者にフィードバックできるようにする必要があります。役立つテクノロジやツールは数多く存在します。サイクルとデータ収集を支えます。使用する重要なツールやテクニックに注目し、解説します。体制による改善を見込んでいます。アプリケーション運用後の、要求の変化や不具合への迅速な対応力。重視の意思決定からデータ重視にシフトするための記録データの活用。側面を妨げるサイロは組織内にあるでしょうか。このようなサイロは、ツール、スクリプト言語、ポリシー、部門の境界線など、さまざまな形で存在します。サイロには、各業務を分担して、セキュリティを管理し、運用中の安定性を確保するという目的があります。実現を目指す多くの目標が、こうしたサイロによって妨げられることがあります。運用上の問題への対応や、迅速かつ信頼性の高いリリースなどの実現の妨げになります。多くの場合、こうしたサイロ構造が驚くほど多くの無駄の原因になっています。開発者と運用担当者は、これまで異なる目標を掲げる別のチームで仕事をしてきました。開発チームと運用チームは、サイロの壁によって生じる問題の解決に時間をとられ、ビジネスの運営に力を注ぐ時間が少なくなっています。上記のサイロによって実現を目指した本当のメリットを評価する必要があります。ソリューションを実装して無駄を省くことも容易になります。アジリティに対するニーズとのバランスをとりながら、セキュリティ、統制、コンプライアンスなどを適切に確保することは簡単ではありません。チームは、データの安全性と機密性が確保されていることを保証しなければなりません。セキュリティは、組織のどの業務にも劣らず重要であることは間違いありません。セキュリティの境界が生み出されるたびに関連コストが発生します。セキュリティの境界が原因でチームに無駄や摩擦が生じるのであれば、この境界を新しい視点で見直す価値があります。もたらされるようになります。世界有数のセキュリティを確保している組織になれたとしても、ソフトウェアを予定通りにリリースできなければ競争に遅れを取ることになります。した優先順位のバランスを取るという課題は今に始まったことではありませんが、組織がこれまで生み出してきたさまざまなプロセスやサイロに対し、率直かつ新たな視線を向けるときがきています。チーム全員が、個々の目標ではなく、ビジネス価値に重点を置くべきです。パイプラインでは、バージョン管理を行いながらコードが作成され、そのコードがさまざまな環境を経て、最終的に運用環境にリリースされます。その過程で、自動ビルドと自動テストが実行されます。パイプラインには、変更から運用への移行に透明性があり、反復可能で、信頼性が高く、その上迅速であることが求められます。ここには自動化が必要になることは間違いありません。ホスト環境のプロビジョニングが含まれることもあります。パイプラインが最適化されない可能性があります。(たとえば、開発チームと運用チームが別々のツールを使用している)。間違いが起こりやすい手作業の手順を避けている場合。新しい環境に配置するだけでも再構築が必要な場合。トレーサビリティに欠け、リリース済みのバージョンの把握が難しい場合。サイクルが長く、修正プログラムのリリースにさえ時間を要する場合。パイプラインではオプションと考えられることもあります。アプリケーションをホストする環境は既に運用されています。ようなバックエンドは、数え切れないほどのイテレーションを行って運用されています。スキーマ、および更新レベルを適切に移行するのに必要なデータ変更を配置するだけです。新しくプロビジョニングすることはありません。パイプラインを利用します。各種コンテナーの構成設定の変更を必要とするシナリオもあります。プール設定の一部の微調整が必要になることがあります。パイプラインの一部として実装することも、手動で処理することも可能です。戦略では、何らかの種類のバージョン管理システムで構成設定の変更を追跡することもあります。パイプラインの一部に含めるシナリオは、他にもいくつか考えられます。データベースを破棄してから新しく再構築し、環境に対して完全かつ自動的なテストを実行する場合です。プラットフォームでは、必要なものだけに代価を支払います。自動的にセットアップと破棄を行うことで、コスト効率が向上する可能性があります。プロビジョニングと環境の変更を自動化することで、エラーを避け、アプリケーション環境全体を管理できるようになります。このようなシナリオでは、全体的なリリース管理システムの一部にプロビジョニングを含めることが推奨されます。パイプラインの一部にプロビジョニングを含めるためのオプションやテクニックはたくさんあります。どれを利用するかは、ホストするアプリケーションの種類とホストする場所によって変わります。ホストする場合は異なります。これらのアプリケーションはコンテナーが異なり、プロビジョニング手順をサポートするのに必要なツールの使い方も違います。つの実行可能ファイルですが、運用環境との組み合わせによっては、コンパイル済みコードにもスクリプトにもなり得ます。環境が生み出す多くのメリットについて見ていきます。(bit.ly/1IiGRk1、英語)。重要なコンポーネントであることが示されました。ソフトウェアを提供するチームにとっては、プロビジョニングと構成は摩擦を引き起こす重要なポイントであることも示されました。手法を活用する必要があります。アプリケーションやサービスを実行する適切な環境を自動的に提供し、このような環境を既知の良好な状態に保つことでした。仮想化などの自動化手法が有効ですが、ノード間の同期を保ち、構成の違いを管理することは依然として課題があります。運用チームと開発チームは、これからも、さまざまなツールセットや専門技術、プロセスを駆使して奮闘することになります。コードの作成、バージョン管理、実行、およびテストが可能になるという前提に基づきます。簡単なスクリプトを使用して作成できます。ツールを使用して、インフラストラクチャのスクリプト化、バージョン管理、およびテストが可能です。他にも、既知のバージョンの環境を起動したり破棄したりできるというメリットもあります。開発環境と運用環境の違いから生まれる厄介な問題を避けることができます。アプリケーション環境固有の依存関係をコードで表し、バージョン管理でその依存関係を切り替えることができます。端的に言えば、手作業のプロセスを取り除き、アプリケーションにとって信頼性が高い自動環境コンテナーをテストできるようになります。開発と運用に共通のスクリプト言語とツールを使用できることで、このような効率化が実現されます。コードを実行するために必要なツールが決まります。いずれも、今回のシナリオに基づく同様の目標実現に有効です。コードにはさまざまなものがあります。スクリプトになるかもしれません。いずれにせよ、アプリケーションの種類とホストする環境によって、選択するコードが決まります。グループを作成および管理できます。使用して環境を記述できるようになります。データベースなど、グループに関連するリソースを一緒に管理することもできます。プロビジョニングを実行できます。テンプレートの基本構造を構成するセクションです。