9

これは (実際にはいくつかあります) F# Type Providers and Continuous Integrationに関する以前の質問に対するフォローアップの質問です。

SqlDataConnection機能ブランチ駆動型の開発でコード/データベースの整合性が損なわれていないことをコンパイル時のチェックとして型プロバイダーを使用することは良い考えだと思います。データベースの構築もCIプロセスの一部であると仮定すると、データベースにも適用されていないコードに変更が加えられていないことをコミット/ビルドごとに知ることができます。

ただし、いくつかの疑問が生じます。

  1. 構成ファイルの名前 (および場所) は、コンパイル時と実行時では同じではありません (例: app.config -> MyApp.exe.config)。これを使用しようとすると実行時エラーが発生します。

    SqlDataConnection<ConnectionStringName="DbConnection", ConfigFile="app.config">
    

    (実際ConfigFile="app.config"はデフォルト値なので指定する必要はありません。)

    実行時エラーは、app.config ファイルを出力ディレクトリにコピーすることで回避できますが (そのための設定があります)、出力ディレクトリに app.config ファイルと MyApp.exe.config ファイルの両方が存在することになります。あまりきれいではありません。タイププロバイダー用に別の構成ファイルを追加することも別の解決策ですが、それもあまりきれいではありません。

    質問:この問題に対するより洗練された解決策を思いついた人はいますか?

  2. 次の問題は、ビルド サーバーに来るときに発生します。開発中に行ったのと同じデータベースに対してコンパイルしたくない可能性が最も高いため、別の接続文字列が必要になります。はい、本番環境では、さらに別のものが必要になります。

    質問:これを最も便利な方法で解決するにはどうすればよいですか? ソリューションは、CI プロセスの一部として機能する必要があることを忘れないでください。

  3. この戦略では、おそらくいくつかの機能/スプリント更新スクリプトを含むベースライン スクリプトから、ビルド サーバーでビルドごとにデータベースを生成する必要があります。

    質問:誰かがこれを試しましたか?ビルド時間にどのように影響しましたか? はいの場合、このステップをどのように作成しましたか?

4

2 に答える 2