DevOps-開発チームと運用チーム間の新しいレベルの相互作用

アプリケーションの作成は、コードの作成、テスト、バグの修正、チェック、最終的な運用の実行など、いくつかの要素を含む複雑なプロセスです。 このプロセスには、開発部門、テスター部門、運用部門の従業員という3つの独立した「州」が関係していると言えます。 これらの各グループは独自のタスクを実行し、異なる基準を使用して作業の有効性を評価します。 開発者にとっては、これは書き込みの速度と、プログラムコードに実装された機能の数、テスターに​​とっては、検出されたエラーの数、運用部門にとっては、システムの安定性とインシデントの最小数です。 このような作業モデルは、多くの場合、利益相反につながります。最初のコードは、可能な限り迅速にコードを記述して検証のために送信します。2番目のコードは、可能な限りすべてのバグを特定するために可能な限りチェックおよびテストする準備ができており、3番目のコードは変更を伴う可能性があるため、ほとんどコードを受け入れませんITインフラストラクチャ全体に対するリスク。 その結果、アプリケーションを作成するプロセス全体が長時間にわたって続きます。これは、困難な経済状況を考えると、ビジネスは可能な限り柔軟で顧客指向であり、新しい製品やサービスをタイムリーにリリースする必要があるため、まったく受け入れられません。











もちろん、多くの企業はこのようなアプリケーションリリースモデルの非効率性を長い間認識しており、最適化する方法を模索し始めました。 そのような方法の1つは、開発部門とテスト部門の実り多い相互作用を提供するアジャイルモデルであり、一般的な目標、一般的な規則、および一般的な有効性の基準に従って実行されます。 同時に、運用部門はまだアジャイルモデルの「範囲を超えています」。 開発者とテスターがエラーのない実行可能なコードの可能な限り高速な作成に関心がある場合、操作は以前のように新しいアプローチに対応できません。 結局のところ、新しいプログラムコードの出現によって加えられた変更は、潜在的な緊急事態やITインフラストラクチャの運用におけるその他の望ましくないインシデントに満ちています。 新しいバージョンのソフトウェアをインストールすると、すべてが単に「クラッシュ」する可能性があります。 これはまさに、運用サービスの専門家が恐れるものであり、多くの場合、そのような恐れは根拠のないものではありません。



開発者とテスターの間の最後の障壁と、運用サービスの間の最後の障壁を排除する必要があります。 このタスクは、本質的にアジャイルの範囲を拡大するDevOps方法論によって解決されることを目的としています。アジャイルには運用ユニットが含まれますが、それだけではありません。 また、従来の古典的なウォーターフォール開発モデルに実装することもできます。 チームの一部がアジャイル手法に従って動作し、他の一部がウォーターフォールに従って動作する場合のオプションがあります。 同時に、DevOpsへの移行により、開発者、テスター、運用スペシャリストといった文字通りすべての部門の共同の効果的な相互作用を確立するために、共通の関心と基準を考慮することができます。 実際、DevOpsの本質は、正式なプロセスだけでなく、ソフトウェア開発の文化を変えることにあります。



会社にDevOps方法論を実装するのに何が役立ちますか？ まず、すべてのプロセスと開発サイクル全体を自動化するようなアプローチが必要です。 開発サイクルは大規模で多面的であるため、その自動化では、HPEソリューションやフリーソフトウェアなどのサードパーティアプリケーションを含む幅広い製品を使用しています。









Ho DevOpsはテクノロジーだけではありません。 同様に重要な役割は、人間の相互作用とプロセスに与えられます。 昨年末に発表されたGartnerによると、DevOpsプロジェクトの成功の50％は人的要因に、37％はプロセスに、8％はテクノロジーにのみあります。 多くの場合、顧客はすべての必要なソフトウェア製品をインストールして統合した後、DevOpsを獲得することを望みますが、そのようなプロジェクトはほとんどの場合失敗します。 人々が共通の関心とパフォーマンス基準を持つ単一のチームになるまで、DevOpsは機能できません。 操作の専門家が要件を設定する段階で自分の責任を認識せず、開発者が操作中のコードの品質に責任を負わない限り、DevOps方法論は主張されません。



DevOpsルールに従って単一のチームを作成するには、何をする必要がありますか？ まず、従業員がどのように働くか、何が彼らを助け、何が彼らを妨げるかを知る必要があります。 DevOpsの構築に関するさまざまな教育コースがあり、HPEにはそのようなコースがあります。 組織で従来のウォーターフォール開発アプローチだけでなくアジャイル手法も使用している場合、複数のチームが参加するプロセス全体をスケールアップすることを検討する必要があります。 HPEは、このタスクに最も効果的なツールとして、Scaled Agile Frameworkを推奨しています。



HPEは積極的に準備を進めており、DevOps方法論の移行と開発に関するトレーニングコースの一部をすでに開始しています。 その1つであるDevOps Awarenessはロシアで利用可能です。 HPEの方法論の一般原則と専門的なアプローチをカバーしています。 さらに、他のコースは、ロシアのユーザー向けにほとんど準備が整っています。DevOps、その実用、および関連ソフトウェア製品の詳細です。



DevOpsモデルへの移行は、顧客にどのような経済的メリットをもたらしますか？ 方法論的には、スケーリングされたアジャイルフレームワークに基づいており、ウォーターフォール、アジャイル、および混合オプションの場合にDevOpsに切り替えるときの利点をルーブルとパーセントで計算できます。 実際、DevOpsは、完成した車をエンジニアから消費者にすばやく表示する自動車用コンベアと比較できます。 たとえば、Waterfallと比較して、DevOpsには否定できない利点があります。それは、すべてのプロセスの自動化による展開リスクの最大削減です。 ウォーターフォールモデルに従って開発する場合、すべてのエラーの約3分の1はヒューマンファクターが原因です。人々は、変更を行うとき、インフラストラクチャを準備するときなどにミスを犯します。 ほとんどの場合、これらのエラーは、ソフトウェアの作成に関与するさまざまな部門に共通のツールがなく、得られた知識を共有する機会がないために発生します。 もう1つの重要な点は、責任の侵食です。各スペシャリストは、自分の狭いセクションに対してのみ責任を負います。









次に、DevOpsの製品サポートの実装方法について少し説明します。 HPE Project Portfolio ManagerおよびService Managerは、最初に変更を計画します。 これには、ビジネスが報告するニーズと要求が含まれます。



さらに、Service Managerを使用して、メンテナンスサービスは特定のインシデントを解決するためにプログラムコードに行う必要がある変更を通知でき、これらの変更はすぐにProject Portfolio Managerのタスクに変換されます。 Project Portfolio Managerが統合するもう1つの製品は、HPE Agile Managerです。これは、タスクをユーザーストーリーに関連付けます。 したがって、Project Portfolio Managerでタスクを割り当てた後、このタスクがAgile Managerの柔軟な方法論に従って実装されることを示すことができます。つまり、それらを統合し、その結果、すべてのユーザーストーリーAgile ManagerがProject Portfolio Managerに表示されます。



次の段階は開発です。 Visual Studio、Eclipseなど、あらゆる開発環境を使用できます。 これらの製品はすべてAgile Managerと統合され、ユーザーストーリーにアクセスできます。 馴染みのある環境の開発者は、Agile Managerから1つまたは別のユーザーストーリーの割り当てに関する通知を受信します。その後、彼はそれを使用し、タスクに従ってプログラムコードを変更し始めます。 コードを変更した後、HPE Fortify Static Code Analyzerを使用してセキュリティ制御を実行し、必要に応じて他の補助操作を実行してから、後続の操作を実行するコマンドを与えることができます。 生成されたコードはリポジトリ（Gitまたはその他）に保存され、その後、コンパイルアーティファクトを保持して自動的にコンパイルされます。 同時に、ユニバーサル構成管理データベース（UCMDB）が更新され、開発中のソフトウェアの新しいバージョンに自動的に切り替わります。 原則として、このプロセス全体はJenkinsまたは別のContinuous Integration Tool（ソフトウェア開発プロセスの継続性を保証する統合プラットフォーム）によって「導かれ」ます。



その後、ジェンキンスはテスト環境を準備します。 HPE Codar、VMware、Docker、またはその他の製品をここで使用できます。 最も一般的なのは、変更が自動的に行われる静的テストループです。 必要に応じて、テスト環境（物理的、仮想、または混合）を完全にゼロから作成できます。 手動モードでこの手順を実行するときに発生する構成エラーの3分の1が回避されるのは、この段階です。 監視はテスト環境に組み込まれており、潜在的なエラーをできるだけ早く特定するのに役立ちます。 将来、監視スクリプトは産業環境に適用される予定です。



テスト環境を展開した後、Jenkinsは自動テスト手順を開始します：機能テスト、ロードテスト、生産テスト、統合テスト、回帰テスト、またはその他のタイプのテスト。 すべての回路で正常に通過した場合、コードは産業環境に自動的に展開され、最後に操作性がチェックされます。



多くの顧客によると、記述されたアプローチの価値は、明確に定義されたプロセスと統合メカニズムを備えた、絶対にすべての関係者の参加により、開発モデルの全体像を取得できるという事実にあります。 結論として、DevOpsに関連したHewlett Packard Enterpriseの戦略には、HPE製品だけでなく他のソリューションの使用も含まれることを強調する必要があります。前述の主なものはテクノロジーではなく、人とプロセスです。