DevOpsとは？

ソフトウェアアプリケーションが大規模かつ複雑になるにつれて、各チームが協働する必要性に迫られています。テスト、開発、デプロイ、運用などの非機能的な流れ作業を実行する目的で、新しいチームが結成されています。これらのチームには、ビジネスアナリスト、プロジェクトマネージャー、システムエンジニア、および以前は別のチームの一員としてこれらの機能を実行していたその他のメンバーによって構成されています。

アプリケーション開発におけるDevOpsのアプローチは、開発チームと運用チームが一体となってソフトウェアをより迅速、かつ頻繁に提供し、お客様のニーズをこれまで以上に満足させることを目的としています。

従来、ソフトウェア開発者がコードを書いていました。開発者がコードを書き終わると、アプリケーションはQAを経て、IT運用担当者によって本番環境に導入されます。IT運用担当者は、コードが期待通りに動作するようにサーバー、ストレージ、その他の必要なものを手配します。組込みシステムでは、運用担当者は組込みシステムにソフトウェアを搭載し、そのソフトウェアが動作するデバイスの製造を監督していました。

このモデルは、ウォーターフォール方式のソフトウェア開発ではうまく機能していましたが、開発者が組込みシステムのソフトウェアを完成させるまでにある程度長い時間を費やし、それから運用に回すため、時間がかかるという欠点がありました。

従来の開発手法では、競争の激しい今日の組込み市場ではスピードが足りません。

アジャイル開発は、開発チームが「スクラム」を組んで作業を行い、より速いスピードでリリースを行うという、ソフトウェア開発に新しいアプローチをもたらしました。この開発手法を取り入れると、アジャイルチームがあまりにも速くコードを作成することができたため、運用チームとQAチームを開発プロセスに統合した方が良いということが分かりました。その結果、DevOpsの手法の下、両チームが一緒に作業を行うようになりました。

DevOpsのもう一つの影響は、新しいコード自体の統合と配布の仕組みに関連します。コードリリースのペースは非常に速くなり、自動化されたソフトウェアでなければ対応できなくなりました。さらに、コードリリースの多くは、既存のアプリケーションへの小さな更新に過ぎませんでした。DevOpsチームから新しいコードが出てくるたびに、毎日（または数時間おきに）大規模なアンインストール/再インストールを実行するルーチンはあまり意味のないことでした。この問題を解決するために、コードの継続的インテグレーション（CI）と継続的デリバリー（CD）の実行が標準となりました。CI/CDツールは、コードの実行を停止することなく、コードを本番アプリケーションにそのまま搭載します。これは、昔の「車が動いている間にタイヤを交換する」というコンセプトと似ていますす。しかし、ここでは、それが機能するのです。

DevOpsとCI/CDの手法を実践するためには、技術的には別々でありながら相互依存関係にあるツールセットが必要です。図1は、最も一般的なDevOpsからクラウドへのCI/CDのワークフローを簡略化したものです。ワークフローの各ステップは、特定の種類のツールによってサポートされています。

DevOpsは、ポジティブ、およびネガティブな両方の理由で、組込みシステムメーカーに普及しつつあります。ポジティブな理由としては、より良い製品をより早く市場に送り出すことができることが挙げられます。DevOpsを正しく実行することで、かつては連続した開発、QA、セキュリティ、および運用スケジュールをある程度並行して行うことを可能にし、いずれは実質的にDevSecOpsへと変化していきます。各サイクルにおけるイテレーションの回数が減るため、すべてがより迅速に進みます。

CI/CDの手法は、市場投入までの時間を短縮し、コラボレーションを改善し、より良い製品を生み出しますが、企業はこれらの新しい概念を導入しようとする際に課題に直面します。

企業がDevOpsの導入を余儀なくされているネガティブな要因は、人材の制約に大きく関係しています。優れたコードを書くことができ、組込みシステムを熟知している開発者は、なかなか見つかりません。多くの設計チームは、組込みシステムと、航空宇宙や自動車などの特定の業界におけるその役割を理解する開発者の不足という課題に直面しています。

この基本的な人手不足は、開発者にセキュリティクリアランスを要求することでさらに深刻化しています。このような状況においてDevOpsは、小規模で限られた人材プールで、これまで以上に多くのソフトウェアを生産することを可能にするため、非常に重要です。

DevOpsへの移行を進めたいと強く考えていても、すべての組込みシステム関連企業が簡単に移行できるわけではありません。問題点として挙げられるのは、グループ間の連携不足です。単にDevOpsをソフトウェア開発とリリースに適用すると宣言するだけでは、チームのプロセスを統合させるのに不十分です。

DevOpsの採用は、管理プロセスの革命的な変化でなければなりません。チームメンバーは、新しい開発手法とツールについてトレーニングを受ける必要があります。質問をし、これらの新しい方法が自分たちの特定の組織でどのように機能するかを判断する機会が必要です。DevOpsとCI/CDは、技術的・段階的であると同時に、文化的な転換でもあるのです。

セキュリティもDevOpsの進展を阻害する可能性があります。アプリケーションのセキュリティは困難であり、開発プロセスを加速化しても、自動的にリスクが軽減されるわけではありません。どちらかといえば、リスクが増加します。組込み開発プロセス全体を通してセキュリティを確保する必要があります。

ハードウェアも障壁となり得ます。従来の開発では、開発チームは、使い慣れたプロセッサと回路基板の組み合わせに特定のオペレーティングシステムを搭載するなど、既知のターゲットハードウェア向けにコードを作成する必要がありました。プロセス全体が加速化するにつれ、DevOpsチームがターゲットとするハードウェアを迅速に提供することが難しくなっています。ハードウェアの中には、非常に高価なもの、入手が難しいもの、あるいはまだ構築されていないものがあるかもしれません。

Wind River Simics^®などの適切なツールを使用することで、ハードウェアの障害を排除し、高品質な組込み製品の迅速な開発を可能にします。

多くのデータセンターツールセットには、すでにDevOpsやCI/CDに適した機能が搭載されていますが、組込みの世界では、ほとんどの開発が依然として従来のウォーターフォール方式で行われています。ウインドリバーは、すべての製品リリースとロードマップに堅牢なアジャイル機能を搭載し、最新の開発手法を先駆けて取り入れています。

ウインドリバー製品は、完全なDevOps-CI/CDワークフローを可能にします。お客様の成功を支援するために、独自の開発-テスト-リリースプロセスを開始しました。Wind River Linux、VxWorks^®、Wind River Helix™ Virtualization Platformなどの製品は、当社独自のDevOps環境を使用して生産されています。私たちは、組込みシステムのコンテキストにおけるこれらの手法のユニークなニーズについて、多くのことを学びました。プロセスに対する我々の洞察は、図2に描かれているように、効果的なDevOps-CI/CDスタックにつながりました。

図2. ウインドリバー製品は、DevOpsおよびCI/CD機能を直接提供するか、または、ワークフローの各機能領域でさまざまな業界標準のツールセットを
サポートします。

ウインドリバー製品は、完全なDevOps-CI/CDワークフローを可能にします。お客様の成功を支援するために、独自の開発ーテストーリリースプロセスを開始しました。Wind River Linux、VxWorks^®、Wind River^®Helix™ Virtualization Platformなどの製品は、当社独自のDevOps環境を使用して生産されています。私たちは、組込みシステムのコンテキストにおけるこれらの手法のユニークなニーズについて、多くのことを学びました。プロセスに対する私たちの洞察は、図2に描かれているように、効果的なDevOps-CI/CDスタックにつながりました。