DevOps on Windowsがここ数ヶ月，オペレーションフレンドリなWindowsサービスを開発する方法についての記事を掲載している。オペレーションの視点から見て最も大きなハードルである，Windowsサービスのインストレーションとスタートアップフェーズを克服するにはどうすればよいかを解説する連載記事だ。
ハードルのある部分は，InstallUtilの一般的な使用方法に関連している。InstallUtilは，.NeｔベースのWindowsサービスをインストールするための非ネイティブなWindowsツールである。障害が発生したときに明確なエラーメッセージが提供されるため，あるいはデータベースからのデータのローディングやキャッシュといった長期間実行されるオペレーションをサポートするため，スタートアップの段階において注意すべき点がいくつかある。
DevOps on Windowsではそのような問題に対して，Windowsサービスを構築するための極めてシンプルなフレームワークによる解決を提案している。このフレームワークは，基本的に自己充足(self-containment)の考え方に基づいている。Windowsサービスが自分自身のインストール方法に関する情報を備えて，起動時の障害を適切に処理する，という発想だ。フレームワークの中心をなすのは，BasicServiceInstaller, BasicService, BasicServiceStarterという３つのクラスである。
BasicServiceInstallerは，先述した自分自身のインストーラを所持するという要件に対して，自己インストールと自己アンインストールの機能を提供することにより，独自のインストレーションのベースを構成する.Netクラスである。この自己インストール機能には，オペレーションチームにとって，scあるいはInstallUtilといった外部ツールを利用する必要なくなる，という意義がある。
BasicServiceは，スタートアップフェーズにおけるSCM (Service Control Manager)とのインタラクションに関して，ベストプラクティスに従った処理が行われることを保証する。SCMは，登録されたすべてのWindowsサービスが従うべきルールを規定することによって，サービスのライフサイクルを管理するWindowsプロセスだ。BasicServiceによる支援には２つの方法がある。ひとつはWindowsサービスが起動しない場合に，SCMに対して有意なエラーコードが返されることの保証であり，もうひとつは起動時処理に長い時間必要な場合に，SCMによって途中で強制終了されることのない実装の支援である。
最後のBasiceServiceStarterはサービスのインストール，サービスのアンインストール，コンソールからの実行，あるいはWindowsサービスとしての実行といった，アプリケーションのオペレーションモード決定に対して責任を持っている。同時に，Windowsサービスの起動時などに発生する任意のバックグラウンドスレッドの例外メッセージが，Windowsのイベントログに報告されることを保証する役割もある。
連載はこのフレームワークの背景にある理由を説明しながら，７番目のアーティクルまで続いている。サイトの方針は，"オートメーションではなく，ソフトウェアの一貫性や単純性に重きを置く"というものだ。