tech.guitarrapc.cóm

Technical updates

PowerShell DSC の xTimeZone リソースにPR がマージされたお話し

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

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

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

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

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

  1. Fix PSSA issues per the DSC Resource Kit PSSA Rule Severity List (not yet published publicly, sorry)
  2. Ensure unit tests are present for each resource with more than 70% code coverage
  3. Ensure examples run correctly, work as expected, and are documented clearly
  4. Ensure clear documentation is provided
  5. Ensure the PSDesiredStateConfiguration module follows the standard DSC Resource Kit module format
  6. 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

https://msdn.microsoft.com/ja-jp/library/system.timezoneinfo.aspx

対策

Idでのマッチングが一番簡単なのです。

http://stackoverflow.com/questions/31796766/how-to-get-utc-timezone-displayname-net-4-0

ただ、どうやらPowerShell TeamはCIM Methodを使って現在のTimeZone StandardNameを取得したがっていたので、StandardNameとIdの変換を行うようにしました。

https://gist.github.com/guitarrapc/055acdd7a3a5d9c85a9bead504b43747

あとは判定して終わりです。

PRからマージの流れ

PowerShellチームのコントリビューションガイドに則ります。

https://opensource.microsoft.com/codeofconduct/

https://github.com/PowerShell/DscResources/blob/master/CONTRIBUTING.md

おおよそ次の流れです。

  1. Issueで報告
  2. 対象のリポジトリをFork
  3. ブランチを切る
  4. コードを修正
  5. 関数追加などの場合、Pesterのテストを追加
  6. UpstreamにPRを投げる
  7. この時点でAppVeyorテストが走るのでテスト結果確認
  8. コードレビュー対応
  9. 問題なければマージ

以前、xNetworkingでもやったのですが、直したいのが一行に対してPesterテストの追加が1000行を超える修正になるなど、個人的にはPesterごにょごにょがイヤポヨです。*3

今回は、以前からやり取りある@PlagueHOが反応したので、甘えてPesterだけお願いしちゃいました。

https://github.com/PowerShell/xTimeZone/pull/21

レビューは、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化したけどこの時点では知らなかったのかなhttps://github.com/PowerShell/xTimeZone/issues/5ほんと、この提案者は、そこかしこで発言するはいいけど色々ぐんにょり

*3:それだけ影響のある変更だったのですが流石にあの時は....

*4:なぜかReviewable好きなんですよね、彼ら