「Microsoftはようやく動き始め、他のツールと互換性を取るようになってきた。だが、オープンソースで進化したエコシステムからは何年も遅れている」と語るのは、アジャイルコンサルティング企業cPrimeでDevOps部門のディレクターを務めるブランドン・サイプス氏だ。

Windows DevOpsのギャップを埋めるサードパーティー製ツール

　Windows DevOpsを利用するIT部門は、Microsoftアプリケーションとサードパーティー製ツール間の非効率なマルチホップのハンドオフ群を自動化パイプラインにまとめている。多くの企業にとって、Linuxベースのスタックに切り替えるのは口で言うほど簡単なことではない。

　「Microsoft製品を使用する部署は、その製品の使用を決して中止しない。当社のクライアントには、Linuxで多くの業務を行っている企業もある。だが、どの企業も少なくとも1つの部署またはその一部で依然Microsoft製品を使用している。こうした部署が完全にMicrosoft製品を手放すことはまずないという」（サイプス氏）

　TeamCity、Octopus Deploy、Electric Cloud、Automic（CA Technologiesが買収）などのベンダーのツールは、DevOpsを早期導入した企業の助けとなっている。そのような企業の一例が、自動車業界に特化したデータ分析企業Urban Scienceだ。同社はElectric Cloudの継続的インテグレーションと継続的デリバリー（CI/CD）ツール「ElectricFlow」を使用して、Windowsの使用比率が非常に高い環境でソフトウェアの配信を自動化している。

　「ElectricFlowのオーケストレーションを利用すると、ワークフロー作成時に全体像が見渡せる」と、Urban Scienceで構成マネジャーを務めるマーク・プリオロ氏は言う。

　ElectricFlowは、同社のIT環境の80％を占めるWindowsでのDevOpsを管理する。同社は、ElectricFlowを使って、環境全体を1つのツールで管理することを試みている。残りの20％の大半の作業では、Microsoftの「Team Foundation Server（TFS）」など、他のツールからElectricFlowへのハンドオフが必要になる。ここでの組織の惰性がUrban Scienceの妨げになると同氏は言う。

　「残りの20％では、開発者がTFSを扱う方法を変えなければならないことになる。ただ、やり方を変えることはいつも後回しになる」（プリオロ氏）

　サードパーティー製のDevOpsツールを旧バージョンのMicrosoftソフトウェアと統合しなければならない場合、cPrimeのWindowsクライアントは、しばしばこうした自動化の波に取り残されることになる。

　「自動化に波に乗り遅れたら、もう打つ手は無くなるだろう。多くのIT部門が、この問題への対処方法を探っている」と同氏は話す。

　Windows DevOpsを使用するIT部門は、ElectricFlowなどのツールを使って自動化インフラの構築に成功している。オンラインゲームシステムのサービスプロバイダーNetEntは、ElectricFlowを社内展開して、残りのプロセスを自動化するかなり前から、同社の運用インフラへの導入を管理している。

　NetEntで運用の専門家として働くアロイージオ・ロシャ氏は次のように語る。「導入の速度を上げ、他のボトルネックを見つけられるように、サーバの作成、アプリケーションの導入とアップグレードに必要な全てのコンポーネントを結び付けている。当社は、他の工程にもElectricFlowを導入することを検討している。開発者やテスターが運用環境への導入を目の当たりにして、同じような自動化を望んでいるためだ」

　今後、NetEntはMicrosoftの「Microsoft SQL Server」データベースに対する更新の作成を自動化するため、ElectricFlowを使ってVMware仮想マシンとのAPIの統合を行う予定だ。このように構造化されたアプリケーションは、OSの種類とは無関係に、DevOpsにとっては共通の課題になる。

　「当社が現在使用しているのは『PowerShell』スクリプトだ。つまり、ElectricFlowからVMwareのAPIまでをこのスクリプトがつないでいる。こうしたPowerShellスクリプトを利用しないで、直接VMwareのAPIを使用できるようになることを望んでいる」（ロシャ氏）

Windows DevOpsの状況を練り直すMicrosoft製品

　自動化の波に乗り遅れた他のWindows DevOpsユーザーにとって朗報は、最新バージョンのMicrosoftソフトウェアが、REST APIを使ってサードパーティー製ツールと密接に統合されるようになっていることだ。その上、多くのネイティブ機能も提供される。

　2017年、TFSなどのWindows DevOps製品は、アプリケーションの運用環境への継続的デプロイのサポートが向上している。一部の企業IT部門がこうした製品を使い始めている。

　例えば、Microsoftの「Team Foundation Server 2015」ではUpdate 3まではリリースパイプラインがなかった。これが、「Team Foundation Server 2017」から変わった。こう語るのは、法律事務所でソフトウェアアーキテクチャおよび開発マネジャーを務めるアントニー・テラ氏だ。

　「これで同社のリリースパイプラインが完全に整うことになる。プロジェクトを運用環境にリリースするタイミングをビジネスアナリストが決めることができる。リリースに手がかからないため、必要ならば1日に3～4件のプロジェクトを運用環境にリリースできる」（テラ氏）

　Microsoftのクラウドサービス「Microsoft Azure」のDevOps部分には、Microsoftの最新バージョン「Visual Studio Team Services（VSTS）」の新しいオプションが含まれる。VSTSは、TFSのSaaSバージョンで、VSTSユーザーの大多数は1日に何度もデプロイを行う。こう語るのは、MicrosoftのVSTS製品担当のサム・ガッケンハイマー氏だ。

　最新リリースのWindowsでは、Windows用VMのフットプリントを減らすため、サーバアプリケーションの軽量化を目的として大幅な改善が行われた。コンテナ化もこうしたプロセスの一端を担う。

　Microsoftは、VSTSをAzureのPaaSプラットフォームとIaaSプラットフォームにおけるCI/CD向けの最適ツールにするため、ここ半年から1年の間に機能を追加している。また、同社はコードレビュー、テスト、品質保証のため、バージョン管理システムの「Git」を利用するワークフローを補強し、VSTSに“カンバン”などのDevOpsテクノロジーのサポートも追加している。今後のアップデートでは、チーム全体の調整が容易になり、より高いレベルから開発チームの状況と資産を見渡すことができるようになるだろう。