過去にもいくつかの PowerShell DSC リポジトリでやりとりをやっているのですが、先日 xTimeZone にあった結構困ったバグ修正のPRをおくったところマージされました。
日本語はもろに影響を受けるので良かったよかった、とともに軽くメモに残しておきます。
あと、最近になって Powershellチームによる Desired State Configuration の開発に変化が出てきているのでその辺も。
目次
PowerShell Desired State Configuration の開発状況
ビルトインリソースと言われるのが、Windows 8.1/10/2012 R2/2016 に同梱の標準リソースです。
それに対して、x(エクスペリメンタル Experimental) なリソースが、Github 上で開発されています。
バージョニングの改善
この x 付というやり方は、冷静に考えても当時から現在まで多くの問題を起こしています。バージョニングを持たない当時、「互換性を維持するためにモジュール名を変える」ことを推奨することで無理やり実現しようとしたのです。日頃の感覚では、バージョニングを用いて利用者に負担を少なく行うのが一般的な開発シーンなので、わざわざ名前の変更をするガイドラインは違和感にあふれます。*1
現在は、当時と異なっています。多くの面で、バージョン管理が重要になってきました。
- Github 上でのオープンな開発
- PowerShell でバージョンのサイドローディングが可能に
- PowerShellGet でのモジュールの公開、展開
これらを受けて、PowerShell Module や xなりソースのバージョンを良くしようとしています。Semantic Versioning もその具体例の1つです。xがどうなるかはまだ不透明です。
https://github.com/PowerShell/PowerShell-RFC/blob/master/1-Draft/RFC0004-PowerShell-Module-Versioning.mdgithub.com
フィードバックをどしどし受け付けているので、ぜひぜひご意見してください。
xPSDesiredStateConfiguration を High Quality Resource Moduleへ
High Quality Resource Module (HQRM) の意味を先に。Issue において、次のように明言されています。
willing to use this module in production.
そのための要素として、次を挙げています。
- 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.mdgithub.com
このような動きもありつつ、さて本題に行きましょう。
xTimeZone リソースのバグ
Issue に概要、原因、解決方法をまとめています。
原因
シンプルで、TimeZone の適用(SET) 時には TimeZoneInfoのId を用いているのに、TEST/GET では TimeZoneInfoの StandardName を用いていることです。StandardName は.NETの外でローカライズされてしまうので、英語以外の環境では TESTが必ず FAILED になってしまいます。マサカの英語OS以外全滅！*2
対策
Id でのマッチングが一番簡単なのです。
ただ、どうやら PowerShell Team はCIM Method を使って現在の TimeZone StandardName を取得したがっていたので、StandardName と Id の変換を行うようにしました。
あとは判定して終わりです。
PRからマージの流れ
PowerShell チームのコントリビューションガイドに則ります。
おおよそ次の流れです。
- Issue で報告
- 対象のリポジトリをFork
- ブランチを切る
- コードを修正
- 関数追加などの場合、Pester のテストを追加
- Upstream に PR を投げる
- この時点で AppVeyor テストが走るのでテスト結果確認
- コードレビュー対応
- 問題なければ マージ
以前、xNetworking でもやったのですが、直したいのが一行に対してPester テストの追加が 1000行を超える修正になるなど、個人的にはPesterごにょごにょがイヤポヨです。*3
今回は、以前からやり取りある @PlagueHO が反応したので、甘えてPester だけお願いしちゃいました。
レビューは、PR 上や Reviewable で行われます。*4
問題なくマージされているので、次回のリリースで含まれます。
まとめ
ということで、現在最新の xTimeZone 1.4.0.0 は、英語以外では致命的なバグがあります。1.3.0.0 を使って、1.5.0.0 を待ってください。
最近 C# ばかりで、DSC Resourceあまり書いていませんが、PowerShell の開発も普通のPRのやり取りで楽なものです。
これからもDSC は良くなっていくので、ぜひぜひ使っていってほしいですね。いい加減入門とかはやめて、使って下しあ。
*1:現在ほとんどの利用者は守っていないようです。これは Github や Gist 上で検索したり、各種ブログを見れば容易にわかります。まぁ、守る必要、ないと思います。
*2:ざるというより、tzutil.exe を使っていたところに頑張って .NET化したけどこの時点では知らなかったのかな xTimeZone module should use .NET APIs instead of tzutil.exe · Issue #5 · dsccommunity/xTimeZone · GitHub ほんと、この提案者は、そこかしこで発言するはいいけど色々ぐんにょり
*3:それだけ影響のある変更だったのですが流石にあの時は....
*4:なぜか Reviewable好きなんですよね、彼ら
