3

私は最終的に、私のソリューションがビルドステップで必要なすべてを行うところまで来ました:

  • パッケージをダウンロードNuGetします。
  • データベースをデプロイします (まだ存在しない場合のみ)。
  • ソリューションをビルドします。
  • アップグレード スクリプトを実行します (1 回だけ、データベースはこれらを追跡します)。
  • 単体テストを実行します。
  • 成功した。

これは、あらゆる種類の驚異をローカルで機能させます。

CI は私にとって次の論理的なステップだったので、 GitHubリポジトリをAppHarborと統合することにしました。

問題は、データベースが 2 つのステップで構築されていることです。

  • Adbprojが構築され、.dbschema
  • 私のデータベース アップグレーダ (すべてのDbUpの素晴らしさを誇示しています) は、BeforeBuildをビルドしてデプロイするターゲットとdbproj、データベース アップグレーダAfterBuildを自己実行するターゲットを使用してビルドし、まだ実行されていない SQL スクリプトでスキーマを更新します。

問題は、サーバー構成に必要なものがないため、プロジェクトでAppHarborビルド サーバーが失敗することです。.dbprojSqlTasks.target

そのターゲットを（依存している他のいくつかのターゲットとともに）手動で追加する簡単な修正を試みましたが、それを乗り越えることができないエラーが発生しました：

「SqlBuildTask」タスクをアセンブリ Microsoft.Data.Schema.Tasks.Sql から読み込めませんでした [...]

少し掘り下げてみると、どちらもインストールされていない環境ではプロジェクトをビルドできないようです。.dbprojVSTFS

どのように進めればよいですか？いくつかのオプションがあるかもしれません：

  • AppHarbor データベースに手動で接続し、開発環境で生成されたデプロイ スクリプトを新しい運用データベースに対して実行します。
    これは、ワンステップ構築の目的を無効にします。

  • .dbprojデータベース プロジェクトを使用する代わりに、すべての基本インストール テーブルをDbUpの「アップグレード」に含めます。 これには 2 つの問題がありますが、おそらく解決できます。1 つ目は、自分でデータベースを作成する必要があるということです。2 つ目はlog4net、データベースのアップグレード プロセスをログに記録するために使用しているテーブルがプロセス自体によって作成されるということです。これは、私の本ではあらゆる種類の間違いです。

  • この問題なしでデータベースを展開できるカスタム データベース プロジェクト ソリューションを使用します。
    私はこのような解決策を本当に知りません。存在しますか、信頼できますか?

意見、展開に関する記事、または提案を歓迎します。AppHarbor で .dbproj をビルドする簡単なハックでも十分です。

最後に、AppHarborにビルド サーバーを含めるように依頼しTFSたりVS、ビルド サーバーに.dbprojプロジェクトをビルドするように依頼したりするのは、あまりにも理にかなっていますか?

4

0 に答える 0