過去にもいくつかのPowerShell DSCリポジトリでやりとりをやっているのですが、先日xTimeZoneにあった結構困ったバグ修正のPRをおくったところマージされました。

日本語はもろに影響を受けるので良かったよかった、とともに軽くメモに残しておきます。

あと、最近になってPowershellチームによるDesired State Configurationの開発に変化が出てきているのでその辺も。

PowerShell Desired State Configuration の開発状況
- バージョニングの改善
- xPSDesiredStateConfiguration を High Quality Resource Moduleへ
xTimeZone リソースのバグ
まとめ

PowerShell Desired State Configuration の開発状況

ビルトインリソースと言われるのが、Windows 8.1/10/2012 R2/2016に同梱の標準リソースです。

それに対して、x(エクスペリメンタル) なリソースが、GitHub上で開発されています。

https://github.com/PowerShell

バージョニングの改善

このx付というやり方は、冷静に考えても当時から現在まで多くの問題を起こしています。バージョニングを持たない当時、「互換性を維持するためにモジュール名を変える」ことを推奨することで無理やり実現しようとしたのです。日頃の感覚では、バージョニングを用いて利用者に負担を少なく行うのが一般的な開発シーンなので、わざわざ名前の変更をするガイドラインは違和感にあふれます。*1

現在は、当時と異なっています。多くの面で、バージョン管理が重要になってきました。

GitHub上でのオープンな開発
PowerShellでバージョンのサイドローディングが可能に
PowerShellGetでのモジュールの公開、展開

これらを受けて、PowerShell Moduleやxなりソースのバージョンを良くしようとしています。Semantic Versioningもその具体例の1つです。xがどうなるかはまだ不透明です。

https://github.com/PowerShell/PowerShell-RFC/blob/master/1-Draft/RFC 0004-PowerShell-Module-Versioning.md

フィードバックをどしどし受け付けているので、ぜひぜひご意見してください。

https://github.com/PowerShell/PowerShell-RFC/issues/10

xPSDesiredStateConfiguration を High Quality Resource Moduleへ

High Quality Resource Module (HQRM) の意味を先に。Issueにおいて、次のように明言されています。

willing to use this module in production.

https://github.com/PowerShell/xPSDesiredStateConfiguration/issues/160

そのための要素として、次を挙げています。

Fix PSSA issues per the DSC Resource Kit PSSA Rule Severity List (not yet published publicly, sorry)

Ensure unit tests are present for each resource with more than 70% code coverage

Ensure examples run correctly, work as expected, and are documented clearly

Ensure clear documentation is provided

Ensure the PSDesiredStateConfiguration module follows the standard DSC Resource Kit module format

Fix code styling to match the DSC Resource Kit Style Guidelines

この内容は、Nano ServerとFull Serverで利用できるコンポーネントの違いにも起因しており、かなり注目です。

https://github.com/PowerShell/xPSDesiredStateConfiguration/blob/dev/HighQualityResourceModulePlan.md

このような動きもありつつ、さて本題に行きましょう。

xTimeZone リソースのバグ

Issueに概要、原因、解決方法をまとめています。

https://github.com/PowerShell/xTimeZone/issues/20

原因

シンプルで、TimeZoneの適用(SET) 時にはTimeZoneInfoのIdを用いているのに、TEST/GETではTimeZoneInfoのIdを用いていることです。StandardNameは.NETの外でローカライズされてしまうので、英語以外の環境ではTESTが必ずFAILEDになってしまいます。マサカの英語OS以外全滅！ *2