Windows Server 2016のサポート終了に伴うCIの対応について

[ghost]

来る1月11日をもって、Windows Server 2016のメインストリームサポートが終了します。
これに伴い、Azure DevOpsのvs2017-win2016エージェントと、GitHub Actionsのwindows-2016ホストランナーの利用が非推奨となり、3月15日に削除されることになりました。

これに先立って、各CIの実行時に警告メッセージが表示されるほか、次の時間帯に各エージェント・ホストランナーが一時的に無効化されます。

• Azure DevOps
  • 2021-12-15 3:00 PM UTC - 4:30 PM UTC （終了済み）
  • 2022-01-11 3:00 PM UTC - 4:00 PM UTC （終了済み）
  • 2022-01-21 3:00 PM UTC - 5:00 PM UTC
  • 2022-02-02 2:00 PM UTC - 6:00 PM UTC
  • 2022-02-14 2:00 PM UTC - 8:00 PM UTC
  • 2022-02-24 2:00 PM UTC - 8:00 PM UTC
  • 2022-03-09 2:00 PM UTC - 8:00 PM UTC
• GitHub Actions:
  • 2021-12-01 4:00 PM UTC – 10:00 PM UTC （終了済み）
  • 2022-02-07 4:00 PM UTC – 10:00 PM UTC

サクラエディタではAzure Pipelinesでvs2017-win2016エージェントを使用しているため、影響を受けます。
対策として最も簡単なのはwindows-2019エージェントへ移行することであり、現時点ですでに利用しているので特段の作業も必要ないでしょう。
しかし、CIでVisual Studio 2017を利用したビルドを確認できなくなるため、今後も「正式版はVS2017でビルドする」のであれば、VS2017を使用しているAppVeyorの利用を廃止できないことになります。
（※AppVeyorにおける古い開発環境の取り扱いは不明です。）

【2022-01-14 追記】
GitHub Actionsで使用しているwindows-latestの指し先が、3月6日までにwindows-2019からwindows-2022へ変更されることが発表されました。
windows-latest workflows will use Windows Server 2022
【追記ここまで】

※参考資料：

• Windows-2016 environment will be removed on March 15, 2022 actions/runner-images#4312
• Azure DevOpsのホストイメージ更新案内（2021年12月6日付）
  https://docs.microsoft.com/en-us/azure/devops/release-notes/2021/sprint-196-update

[ghost]

一方で、Windows Server 2022対応も実施されました。
actions/virtual-environments#4488

昨年11月15日よりAzure DevOpsとGitHub Actionsでwindows-2022エージェント・ホストランナーが利用できます。
インストールされているのはVisual Studio 2022です（その他のコンポーネントはこちら）。
また、AppVeyorでも時期は不明ですが対応がなされたようで、インストール済みコンポーネントの一覧ページに記載があります。

Windows Server 2022のエージェント・ホストランナーにはInno Setupが含まれないため、インストーラーのビルドに先立ってchocolateyを利用してインストール作業が必要になります。
（AppVeyorではv6.1.2が含まれています。）

また、ヘルプファイルのビルドで使用しているLocale Emulatorについては、v2.5.0.0でWindows 11対応が行われたことから、Windows Server 2022もv2.5.0.0以降が対応すると思われます。しかし、現時点でchocolateyではv2.4.1.0から更新されていません。

手元で確認した結果は次の通りです。

• VS2022 on AppVeyor … ビルド成功
• VS2022 on Azure Pipelines/GitHub Actions … ビルド失敗（ヘルプファイルのビルドが終わりません）

[ghost]

警告メッセージが表示される

今日時点ではこんなメッセージが出ていました。
https://dev.azure.com/sakuraeditor/sakura/_build/results?buildId=3192&view=results

##[warning]A brownout will take place on January, 11 3:00 PM - 4:00 PM UTC to raise awareness of the upcoming windows-2016 environment removal. For more details, see https://github.com/actions/virtual-environments/issues/4312

[berryzplus]

OSバージョン	対応SDK	公開日	サポート終了日	利用可否
Windows 10 21H1	10.0.20348.0	2021年05月18日	2022年12月13日	○
Windows 10 20H2	-	2020年10月20日	2022年05月10日	○
Windows 10 2004	10.0.19041.0	2020年05月27日	2021年12月14日	×
Windows 10 1909	-	2019年11月12日	2021年05月11日	×
Windows 10 1903	10.0.18362.1	2019年05月21日	2020年12月08日	×
Windows 10 1809	10.0.17763.0	2018年11月13日	2020年11月10日	×

【参考】
https://docs.microsoft.com/ja-jp/lifecycle/products/windows-10-home-and-pro
https://developer.microsoft.com/ja-jp/windows/downloads/sdk-archive/

vs2017で利用できるSDKの最終バージョンは 10.0.17763.0 です。
10.0.17763.0(Windows 10 1809)のOSサポートは 2020年11月10日 に終了しているため、
現状は、メーカーがサポートを終了したOSをターゲットにしている感じです。

vs2017そのものの製品ライフサイクルが尽きるまでにはまだかなり期間が残っていますが、
CIのホストランナーが利用できなくなるなら
vs2017のサポート終了は「やむなし」と考えられます。

[ghost]

OSバージョン 対応SDK 公開日 サポート終了日 利用可否
Windows 10 21H1 10.0.20348.0 2021年05月18日 2022年12月13日 ○
Windows 10 20H2 - 2020年10月20日 2022年05月10日 ○
Windows 10 2004 10.0.19041.0 2020年05月27日 2021年12月14日 ×
Windows 10 1909 - 2019年11月12日 2021年05月11日 ×
Windows 10 1903 10.0.18362.1 2019年05月21日 2020年12月08日 ×
Windows 10 1809 10.0.17763.0 2018年11月13日 2020年11月10日 ×

【参考】 https://docs.microsoft.com/ja-jp/lifecycle/products/windows-10-home-and-pro https://developer.microsoft.com/ja-jp/windows/downloads/sdk-archive/

細かい指摘で恐縮ですが、20348はWindows Server 2022に対応するSDKです。
Windows 10 21H1は引き続き19041が対応します。同様に1909は18362が対応します。
参考：https://blogs.windows.com/windowsdeveloper/2019/10/16/what-windows-10-version-1909-means-for-developers/

設定アプリよりシステム詳細情報のコピーを載せておきます。2004/20H2からビルド番号がほぼ変わっていません。
1903/1909も同様に、識別のために1つだけ進めた番号になっていて、ほぼ変わりはありません。

エディション	Windows 10 Pro
バージョン	21H2
インストール日	‎2020/‎10/‎23
OS ビルド	19044.1415
エクスペリエンス	Windows Feature Experience Pack 120.2212.3920.0

ちなみに、

• Windows 11 は「Windows SDK for Windows 11 (10.0.22000.194)」として用意されています。
• 20348/22000もオプションではありますが、VS2019のインストーラで入れられます（＝.vsconfigに書けます）。
• VS2022の現時点での既定は19041です。

[berryzplus]

VS2022の現時点での既定は19041です。

なぬっ！
※19041のOSサポートは2021年12月14日で終了済み。

年2回のリリースで1年半周期だと、製品サイクルが短すぎるのかもしれないです。
linuxディストリビューションみたいに、LTSバージョンを明示してくれると嬉しい気がします。
※商用OSなので、金を積めばサポート延長してくれる場合がある・・・

[ghost]

…???

Windowsのサポート期限は、機能更新プログラムに対して設定されるものであり、SDKに対して設定されるものではありません。
また、機能更新プログラムでAPIの変更などが行われなかった場合は、新しいSDKは提供されません。

1903以降、機能更新プログラムの構造が変わり、秋の機能更新プログラムは無効化されている機能を有効化するためのパッケージとして提供されています。
1909リリース時に、「SDKに変更はないので、1903をターゲットにしたまま作業を続けられる」とアナウンスされています。
つまり、18362 SDKで1903と1909の両方に対応できるということです。
20H2と21H1の機能更新プログラムも「有効化パッケージ」として作られており、SDKの提供はありませんでした。
ここから、19041 SDKで2004～21H2に対応できると解釈できます。

各機能更新プログラムは年に1回秋に提供され、Windows 10ではHome/Proが18か月、Enterpriseが18か月（春）または30か月（秋）サポートされ、Windows 11ではHome/Proが24か月、Enterpriseが30か月サポートされます。
（※Win10 21H2までは春と秋の年2回でしたが、Win11に倣って春の機能更新プログラムを提供しないことになりました。更新内容としてはそれまでの春にあたるものが秋に来る感覚だと思われます。）
機能更新プログラムのインストールが自動的に開始されることはないらしいですが、回避する方法はたぶんありません。
Windows Update for Businessのポリシーを構成していればサポート終了日まで遅延させることはできますが、大多数の人はパッチチューズデーのタイミングでインストールすることになるでしょう。

改めて整理すると、現在のWin10/11のバージョンとSDKの対応は次のようになります

OS機能更新プログラム	OSビルド番号	サポート終了日 (Home/Pro)	サポート終了日 (Enterprise)	対応するSDK
Win10 1809	17763	2020-11-10 (終了)	2021-05-11 (終了)	10.0.17763
Win10 1903	18362	2020-12-08 (終了)	2020-12-08 (終了)	10.0.18362
Win10 1909	18363	2021-05-11 (終了)	2022-05-10	10.0.18362
Win10 2004	19041	2021-12-14 (終了)	2021-12-14 (終了)	10.0.19041
Win10 20H2	19042	2022-05-10	2023-05-09	10.0.19041
Win10 21H1	19043	2022-12-13	2022-12-13	10.0.19041
Win10 21H2	19044	2023-06-13	2024-06-11	10.0.19041
Win11 21H2 (初版)	22000	2023-10-10	2024-10-08	10.0.22000

VS2022の現時点での既定は19041

Win11はまだリリースから日が浅く、大抵の開発者はWin10向けの開発に利用するでしょう。VS2022のリリース時点でサポートされているWin10の機能更新プログラムはすべて19041 SDKで対応できることから、これを既定とすることに問題はありません。
まぁ、VS2019もリリース当初は18362が既定で、のちに19041へ変更されていますから、そのうち変更されるでしょう。

※参考資料

• 1909リリース時の開発者向け解説: https://blogs.windows.com/windowsdeveloper/2019/10/16/what-windows-10-version-1909-means-for-developers/
• Win10 機能更新プログラムの方針変更: https://forest.watch.impress.co.jp/docs/news/1367101.html
• Windows Update for Businessの説明: https://docs.microsoft.com/en-us/windows/deployment/update/waas-manage-updates-wufb
• WUfBの機能更新プログラムのバージョン選択ポリシーの解説
  1. https://yamanxworld.blogspot.com/2020/06/windows-update-for-business-from-1803.html
  2. https://yamanxworld.blogspot.com/2020/11/2009-20h2.html

[ghost]

LTSバージョン

そういうのが必要なユーザーのために、LTSCが存在します。
https://docs.microsoft.com/ja-jp/windows/whats-new/ltsc/
現在の最新は「Windows 10 Enterprise LTSC 2021」で、2032年まで使えます。
ただし、たくさんの制約条件があります。

[berryzplus]

最新動向を積極的にウォッチしてないので、自分が書いたのはいいかげんです。
目先の懸案として、windows 10 1903以降で使えるようになった機能の活用を提案しようとしていました。
https://docs.microsoft.com/ja-jp/windows/win32/intl/international-components-for-unicode--icu-

Windows 10 SDKの更新ができるなら、過去のPR #1104 を改良することができるので検討していました。

エディションとサポート期間の関係の話は、いったん了解です。

[ghost]

MinGWビルドですが、windows-2022環境でプリコンパイルヘッダーのコンパイル中に既知の問題が顕在しました。
参照している標準ライブラリ（<filesystem>など）がインクルードできずコンパイルできないというものです。
この問題はGCC9ですでに修正されているため、GCC8からの移行が必要です。
現在の最新バージョンはGCC11です。
（※MinGWとGCCのバージョンはリンクしています。）

方法としては次の二つがあります。

1. MSYS2環境上でpacmanを使ってビルド環境を構築する（バグ報告の中で推奨されている解決策）
2. chocolateyでより新しいMinGWにアップグレードする

[berryzplus]

MinGWビルドは #1740 の問題により「事実上利用不可」な認識です。
いま、新しい PR を出してない主要因なので、なにかしら結論を出したいと思っています。

chocolateyやpacmanを使わなくなったのは、単に必要がなかったからだと思っています。
必要になるなら復活させたらいいような。

[ghost]

VS2022でのビルド対応自体は何とかなりそうです。
今月中ごろを目標にいったんCI対応の実験PRを出す予定ではいますのでよろしくお願いします。
#1755 (comment)

既存ジョブのwindows-2019およびwindows-2022への載せ替えについては引き続き確認を進めていきます。

[ghost]

#1755 がなかったら出すのはもっと先になるはずでした。

[ghost]

#1767

[ghost]

VS2017以外のジョブについて、一通りの確認が終わりました。
Windows Server 2019環境への移行する場合は特に対応すべきことはなさそうです。
Windows Server 2022環境へは、次の2点を対応することで移行できます。

• Python 2.7を利用したコンパイルチェックの廃止
• MinGWビルドを行う前にMSYS2経由で最新のMinGW-w64をインストール

上記対応を実施したうえで、2022へ移行させる方向でPRを出そうと思います。

ところで、GitHub Actionsに引っ越してからスケジュールが無効化され、実行されなくなったSonarQubeのジョブはどうしましょうか。

[ghost]

Python 2.7を利用したコンパイルチェックの廃止

#1766 を出しました。

[ghost]

MinGWビルドを行う前にMSYS2経由で最新のMinGW-w64をインストール

#1771

[ghost]

GitHub Actionsで使用しているwindows-latestの指し先が、3月6日までにwindows-2019からwindows-2022へ変更されることが発表されました。
windows-latest workflows will use Windows Server 2022

現在GHAではVS2019でのビルドのみが実行されていますが、指し先が変わることでVS2022でのビルドに変わります。
#1764 をマージ済みなのでGHAのVSビルドに関しては特に対応は不要ですが、VS2019でのビルドを残すかは考えないといけませんね。

[ghost]

#1773 を投げました。このPRでAzure Pipelines側はいったん対応完了となります。

[ghost]

ひとまず対応完了です。ご協力ありがとうございました。

• VS2017-Win2016およびwindows-2016の廃止 → Azure PipelinesにおけるWindows Server 2016環境の利用を廃止する #1773
• windows-latestの指し先変更（≒CIのVS2022対応） → CIでVS2022を利用したビルドを行うようにする #1777

[berryzplus]

サポート終了に向けての対応は完了したつもりです。
サポート終了日を迎えるまではクローズせず放置でよいように思ています。

ただ、discussionってクローズできなくね？という素朴な疑問があります。
調べたらやり方あるんだろうけど、調べていないとか。。。

[ghost]

discussionは閉じられないので、どうしても邪魔ならば削除するしかなさそうです。

ただ、Q&Aカテゴリのdiscussionは、「回答としてマーク」されたコメントが付くことで解決したものとみなせますし、「Create issue from discussion」を押しておけばこのdiscussionにリンクされたissueができるようです。
community/community#2861 (comment)
リンク済みissueを作っておけばよかったですね😔。

ちなみに、ここで扱ったのはOSのメインストリームサポートが終了することへの対応です。
Visual Studio 2017のメインストリームサポートはまだ残っていますので、VS2017対応の廃止は4月に入るまで口に出さないつもりでいます。