はじめに

システム本部デベロッパーエクスペリエンス室（以下DevX室）の三谷です。

DevX室ではSaaS製品の管理を令和最新にしたり、今回取り上げるアプリケーションのアップデートを令和最新にする仕掛けを提供することで、開発者の生産性を向上させる取り組みを行なっています。
アプリケーションは、必ずしもすべて最新バージョンにしておけばよい、ということではありませんが、
一般的にはバージョンアップによって機能追加やバグ対応、脆弱性への対処などが行なわれているため、
必要なアップデートかを判断したうえで効率的にアップデートを行なえる環境にしておく必要があります。

弊社ではセキュリティ上の理由から通常利用するログインアカウントに管理者権限は付与されておらず、一部のアプリケーションのアップデートを行なう際には管理者権限が必要になります（最小権限の原則）。
そのため、管理者権限が必要なアプリケーションのアップデートフローとしては、所定の申請手続きを経て一時的な管理者権限を付与してもらったのち、利用者側でアップデート作業を実施するというものになります。
アップデート頻度があまり高くないアプリケーションであればさほど問題にはなりませんが、それなりに更新頻度があるものに関しては、
申請手続きを行なうこと自体がハードルになってしまい、どうしてもアップデートが後回しになってしまう状況がありました。

対応策

基本的に業務で利用するアプリケーションはだいたい同じタイミングでアップデートすることが多いため*1 、皆が一斉にアップデートしやすくなるような仕掛けを検討しました。

社内で共通利用されているツール*2として、ホワイトリスト形式で事前に登録しておいたコマンドを管理者権限で実行する仕掛けがあり、今回はそちらを利用して問題解決を図りました。
具体的には該当のツールにアップデート用コマンドを登録することで、管理者権限申請不要でアップデートが行なえる状態にしました*3。

今回は該当のツールにコマンドを登録する際に検討したことやWindowsの開発環境で利用しているアップデート用のコマンドを紹介いたします。
同様の一時管理者権限付与ツールは各社から提供されているかと思いますので、コマンド部分や考え方をぜひ参考にしていただければと思います。

検討する内容

闇雲にツールにアップデート用コマンドを登録するのではなく、以下を基準に対象とするアプリケーションを選択しました。

アップデートに管理者権限が必要であること(大前提)

Chromeなど、自動アップデートが提供されておりアップデートに管理者権限が不要なものは対象外とした（各自が更新する）
Visual Studio Codeのように、System Installer（要管理者権限）とUser Installer（管理者権限不要）が提供されているものは、
利用者側でUser Installerを利用することで管理者権限申請不要でアップデートが行なえるため、今回の対象外とした
ただしUser Installerに対応していても過半数がSystem Installerで入れているアプリケーションは対象とした（Git for Windows等）

コマンドベースでアップデートを行なう方法が提供されていること

ユーザーの迷いなくアップデートが行なえるようにサイレントインストール可能なものが望ましい
ただし利用者側でインストールするコンポーネントを選択する必要があるものについてはGUI経由のアップデートも許容する（Visual Studio等）

利用者が多く需要の高いソフトウェアを優先すること

利用者が少ない場合は管理者権限申請手続きを行なってもらう方のコストが低い
アップデート頻度が極端に低いものは対象外とした

バージョンアップによる影響が少ないものを優先すること

バージョンアップによって動作が変わってしまうと、利用者が混乱したり動かなくなる可能性がある
例えば開発言語のランタイムなどはバージョンアップによって動作が変わってしまうことが多いため、対象外とした

これらを踏まえて、アップデート対象とするアプリケーションを選定しました。

アップデートの方法および登録しているコマンド

アップデートの方法として、弊社ではアプリケーションの特性に応じて以下の方式でアップデートをしています。
※一般的な名称ではなく自分自身が対応した際に名付けた便宜上の呼称になります。

パッケージマネージャー方式
Self Update方式
アップデートインストーラ方式
カスタムスクリプト方式

これらは利用するアプリケーションがどのように公開されているかや、アップデートの実装によって適切に使い分ける必要があり、
どれか1つを使えばすべてアップデートできるということではありません。それぞれの詳細については以下で紹介します。

パッケージマネージャーでアップデートする（パッケージマネージャー方式）

Linuxと同様にWindowsにおいてもパッケージマネージャーがいくつか存在しており、代表的なものは以下の通りです。

どのパッケージマネージャーを選択するかについては以下の要素で検討しました。

パッケージマネージャーのインストールが容易か
パッケージマネージャー自体のアップデートが容易か
アップデートしたいソフトウェアをサポートしているか（≠対応しているソフトウェアが多いか）
アップデートしたいソフトウェアのパッケージマネージャーへの反映が早いか

検討の結果、以下の点よりWinGetを利用することにしました。

WindowsクライアントOS（10, 11）に標準で搭載されていること
- パッケージマネージャー自体をインストールしなくて済む
Microsoft Store経由でアップデートが提供されること
- 利用者が意識せずにアップデートが行なわれる
Microsoft系のアプリケーションの更新に対応していること
- 価格.comの開発で利用しているアプリケーションの多くがMicrosoft系のため

WinGetについてはインストール可能なアプリケーション（パッケージ）の一覧をmicrosoft/winget-pkgsから確認可能です。
また、パッケージの登録自体もPRを送ることで行なうことができますので、公開されているアプリケーションで登録されていないものに関しても追加可能となっています。

WinGetのオプション引数には --exact を指定しており、大文字小文字を区別して誤ったソフトウェアがインストールされないように厳密な判定をしております（WinGetのupgradeオプション）。

SQL Server Management Studio

価格.comではSQL Serverを利用しており、SQL Server Management Studioを利用して開発を行なっています。
更新頻度はそこまで高くありませんが、アップデートがあると起動時に通知が表示されるので利用者側はアップデートがあることに気づきやすくなっています。

winget-pkgs/manifests/m/Microsoft/SQLServerManagementStudioから定義を確認可能です。
アップデートコマンドは以下の通りです。
winget upgrade --id Microsoft.SQLServerManagementStudio --exact

Azure CLI

Azure CLIについては、Azureの開発において必須となるツールです。
Azureに限らずSaaS製品を操作するようなCLIの場合、SaaS側の機能追加に合わせて更新頻度も高いため、迅速にアップデートができる状態にしておくことが望ましいです。

winget-pkgs/manifests/m/Microsoft/AzureCLIから定義を確認可能です。
アップデートコマンドは以下の通りです。
winget upgrade --id Microsoft.AzureCLI --exact

自分自身をアップデートする（Self Update方式）

アプリケーション自体にアップデート機能が組み込まれているものについては、自分自身をアップデートするコマンドを登録しています。
主に開発関連のパッケージマネージャーに同様の仕掛けが多いイメージです（Composer や gcloud 等）
公開元でサポートされているアップデート方式であることが多く、基本的にはアップデートの反映がパッケージマネージャーに比べて早いため、
パッケージマネージャーで公開されているものであっても、対応しているものについてはSelf Update方式を利用しています。

Git for Windows

Gitについては、Git for Windowsに同梱されているupdate-git-for-windowsコマンドを利用してアップデートを行なうため、以下のコマンドを登録しています。

C:\Program Files\Git\cmd\git.exe update-git-for-windows --gui --yes

引数がいくつかあり、弊社ではGUIベース＋自動インストールを行なうように指定しています。
また、あとから見返しやすいく検索しやすいようにオプション引数は極力ショートカットではないものを指定しています。

PS> git update-git-for-windows -h
Usage: git update-git-for-windows [options]
Options:
        -g, --gui Use GUI instead of terminal to prompt
        -y, --yes Automatic yes to download and install prompt
Return code:
         0: no update available
         1: update available and user selected not to update
         2: update available and it was started

アップデート用のインストーラを経由してアップデートする（アップデートインストーラ方式）

アップデート用にインストーラが提供されているものについては、インストーラを経由してアップデートを行ないます。
主にエンタープライズ向けのアプリケーションに多いイメージです（MySQL Installer for Windows等）

Visual Studio

Visual Studio Installerを利用してGUIベースでアップデートを実施します。
アップデートのほかに追加するコンポーネントを選択したり、不要な機能を削除可能で、そちらはGUIでユーザーと対話しながら選択してもらいます。

コマンドにはアプリケーションを起動するためのパスを指定します。
C:\Program Files (x86)\Microsoft Visual Studio\Installer\setup.exe

カスタムスクリプトを作成してアップデートする（カスタムスクリプト方式）

パッケージマネージャーでアプリケーションが公開されていなかったり、GUIのメニューからしかアップデートを行なうことができないアプリケーションについては、
最新版のインストーラーを起動するようなカスタムスクリプトを作成して管理者権限でスクリプトを実行することでアップデートを行ないます。
カスタムスクリプトの代わりにネイティブなアプリケーションを作成しても問題ありませんが、開発環境を構築する必要がないためスクリプト言語を選択しています。
スクリプトの言語はWindows側で追加のランタイム不要で実行できるスクリプトが望ましいです（一例）。

PowerShell（頑張ればGUIも作成可能です:)）
バッチファイル（高度な処理を行なう場合は不向きです）
VBScript（2023年10月で非推奨となったためおススメしません）

上記以外にも全員同じランタイムが導入されている環境であればそちらを利用するのもよいかと思います。
誰でも、追加ランタイム不要で、実行できる言語であるということが重要です。

カスタムスクリプトの処理の流れとしてはおおよそ以下のようになるかと思います。

最新版のインストーラーを取得（またはすでにあるものを指定）
取得したインストーラーを実行

弊社ではこの仕掛けを利用してWrikeのデスクトップアプリケーションのアップデートを行なっています。
アップデート用のコマンドが提供されていない場合も、このような仕掛けを提供することでアップデートが可能になります。

まとめ

ソフトウェアのアップデート自体は割と地味で注目されづらい分野ですが、
アップデートのための手続きが面倒で利用者側に更新頻度が依存してしまったりする状況は多くの企業であるのではないかと思います。
そのような環境を打開するため、アプリケーションごとに異なるアップデートの方法を検討したり、コストをかけずにアップデートできる方法を提供することで、
我々が目指している開発者体験の向上につながると考えています。

一緒にカカクコムのシステム本部の開発者体験を上げてくれる方を募集しています！！

システム本部の開発者体験を上げることをミッションとして、デベロッパーエクスペリエンス室は立ち上がりました。
多様なドメインでサービスを展開していますので、ソフトウェアのアップデート以外も含めてまだまだ取り組めること・取り組みたいことはたくさんあります。
そのため一緒に壁打ちをして、同じ時間を共有して取り組んでくれる仲間を募集しています。
興味を持っていただけた方はぜひご応募ください！

開発者体験（Developer eXprience）を向上させる組織のコアメンバー（開発プロセス最適化、共通ツール導入）