きよくらの備忘録

「三日坊主と呼ばせない!日記」改め。主にソフトウェア開発関連の話題。

SSDTを使ったDBユニットテストのメモ:プロジェクト指向のデータベース開発の概要

SQL Server Data Tools (SSDT) ってなんだ

SQL Server Data Tools (SSDT) とはMicrosoft から無償で提供されているVisual Studio用のアドオンです。名前から推測できる通り、SQL Server を対象としてデータベースの開発のための機能を提供してくれます。

SSDTについてのオフィシャルな日本語情報はとりあえずここからたどっていくのが正解…だと思います(たぶん)。

 

非常に多機能でそのすべてを一言で表すのは難しいと思っていますが、とりあえず私の理解を端的に挙げてみると以下のような感じです。

  • DBのオブジェクトのコーディング支援(インテリセンスやGUI
  • デバッグ機能
  • スキーマやデータの比較と同期
  • DBのオブジェクトに対するユニットテスト
  • DBのオブジェクトのデプロイ
  • オブジェクトのソース管理(これはSSDTの機能ではないがやりやすくなるという意味で)
  • これらの機能を活用した包括的な『プロジェクト指向のオフライン データベース開発』

なんだかわかるようなわからないような、特に最後のが何を指してるかちょっとピンと来ない、という方もいるのではないでしょうか。少なくとも、私はそうでした。

 

また、これらは非常に強力な機能……なのですが、実際に手を付け始めてみると、以下の点でそれなりに、頑張らないといけないあたりも出てきました。

  • 独特の用語や概念があり直感的にわかりにくい(と感じた)*1
  • MSDNのドキュメントが微妙にカオス(特に単体テスト周り)
    • 恐らくはもともとVisual Studio(のPremium以上)に内臓されていた機能だったものが、ある時期から独立した無償の拡張になってProでも使えるようになった為だと思うのですが、VS内臓のもの*2と分離後のもの*3とそれぞれ同じような内容がのドキュメントが別々に存在してたり…
    • 日本語のほうがある時期から全然更新されてなかったり……
    • 分離後のドキュメントからリンクをたどっていると、気が付いたらVS内臓時のもにたどり着いて迷子になったり……などなど。
  • 解説記事やblogなどもチュートリアルから先のものがあまり見当たらない(まあこれは仕方がない)
  • そもそも日本語の情報が少ない
  • それ以前にも英語でもあまり情報がヒットしない(多少のblogやフォーラム、SOあたりがヒットする程度)

 

このSSDTを活用したデータベース開発を、少しずつですが手さぐりで進めていて、なんとなくわかった(と勝手に思ってること)などを、メモ半分、ご指摘やご意見をいただいたり情報交換等したいの半分で*4、しばらくblogに書いていってみようと思います。

 

『プロジェクト指向のオフライン データベース開発』 とは

単体テストの話題に触れる前に、そもそものところで『プロジェクト指向のオフライン データベース開発』という言葉についてクリアにしておきます。

これはおそらくですが、マイクロソフトの(それもSQL Server Data Tool Team*5)が言っている用語で、おそらくあまり一般的な用語ではないと思います。…ですよね?

このあたりについて、つい先日、SQL Server Data Tool TeamのKevin Cunnane氏が教えてくれた*6 SQL Server Data Tool Teamのblogのエントリ、『 Presentation on Visual Studio Database Projects Integration with Visual Studio Team Foundation Server 』 から引用しつつ、簡単に軽くまとめて(?)おきたいと思います(※画像を資料から引用させていただいています)。

 

従来型の『接続指向のデータベース開発』開発とその欠点

この資料では、まず従来型の『接続指向のデータベース開発(Connected Database Development / connected based development)』に触れ、その特徴や問題点を確認しています。代表的なパターンとして、以下の図のように二つを例示しています。 詳細は資料を読んでいただくとして、ざっくり抜粋すると……。 f:id:kiyokura:20150611002149p:plain

 

一つ目は、

タイプの開発スタイル。 二つ目はもう少し改善された(?)もので、

というスタイルです。どちらも(本番用とは区別されているにしろ)共有のデータベースサーバに対して接続を行いデータベースサーバ上で開発を進めていくという点が共通しています。

 

それぞれ利点などはあるものの、ミスや手戻りが発生した時のリカバリ、仕様や変更点の把握、オブジェクト同士の依存関係による変更時の安全性、バージョンでの正しい姿の把握、デプロイ等の点で欠点があると述べています。ほかにも複数人で作業していれば変更がバッティングするなども普通に発生しえますよね。

 

『プロジェクト指向のオフライン データベース開発』

これに対して彼らが解決策として提示しSSDTで実現しようとしているのが『プロジェクト指向のオフライン データベース開発』です。 (先のblogの資料では「project-based development 」と書いていますが、MSDNのSSDTの項では『プロジェクト指向のオフライン データベース開発 / Project-Oriented Offline Database Development』となっているのでこっちで統一しようと思います)

f:id:kiyokura:20150611002150p:plain

先に例示したConnected Database Developmentの二つ目のパターンとの違いは、以下になると思います。

  • データベースオブジェクトを定義するスクリプトを、スクリプトの断片ではなくプロジェクトという単位で管理する
  • (共有のサーバではなく)開発者ごとに独立したデータベースで開発・テストを行ったうえで共有サーバデプロイする
  • オブジェクトのスクリプトは差分ではなく定義そのものを管理していく(例えばALTER文ではなくCREATE文ということ)

 

SSDTは、このようなスタイルでの開発を支援するための、プロジェクトテンプレートや各種ツール、多くの機能を含んだものとなっています。

SSDTが備える機能や仕組みを活用し、さらにTFSと連携してCIやDevOpsを…といったシナリオも考慮されていて、むしろ先の資料はそれについての入り口となる資料のようです。

 

余談:SSDTを使って『接続指向のデータベース開発』をいい感じにやるパターンも

私も初めは誤解していたのですが、SSDTを利用する場合でも必ずしもプロジェクト指向の開発を行う必要はありません。接続型の開発を行いつつ、使いたいところだけピンポイントでSSDTの機能を使うのもアリだと思います*7

 

例えば、『接続型開発を行いつつ、オブジェクトの定義はしっかりソース管理したい』という場合は、『スキーマ比較』という機能を使ってこれを行うこともできます。 これは『DB同士のスキーマを比較し、差分があればそれを取り込む(反映する)という機能』です。これを利用して、共有のデータベースサーバ開発をしつつ、ポイントポイントでプロジェクト側に取り込みソース管理を行うことが比較的簡単に可能です。 ごく少人数で開発しているなら、こちらのパターンが適するケースもあるのではないかと思っています。

f:id:kiyokura:20150611002151p:plain

そのほかにも、データ比較という機能を利用してデータを同期することもできるので、共有サーバ上でやりにくいデバッグを一時的にローカルのデータベースに取り込んで行うなども可能です。

 

ちなみに、現時点ではSQL Server 2014のSSMSよりも、Visual Studio 2013 + SSDTのほうが少なくともインテリセンス周りの挙動はストレスが少ないように思います。

そういった点でも、SSMSによる接続型開発を主に採用している場合であっても、使えるところでピンポイントでSSDTを積極的に使っていくのはアリだと思っています。

 

次回?

次回から、実際にユニットテストを書いていく場合で、チュートリアル記事やドキュメントでは少しわかり辛かったこと等を中心に、メモを公開していきたいと思います。

*1:個人差があるかと思いますが

*2:https://msdn.microsoft.com/ja-jp/library/dd172118(v=vs.100).aspx

*3:https://msdn.microsoft.com/ja-jp/library/hh272686(v=vs.103).aspx

*4:むしろメモ2割ツッコミが欲しいの8割かもしれません

*5:SSDTを作っているチーム

*6:Twitterで「SSDTの情報が全然見つかんねーよ」と愚痴めいたことつぶやいていたら、Mentionしてくれた https://twitter.com/kevcunnane/status/606986715346010112

*7:それがいいかどうかはまた別の論点