3

I finally got to the point where my solution does everything that's needed in it's build step:

  • Download NuGet packages.
  • Deploy the database (only if it's not there yet).
  • Build the solution.
  • Run any upgrade scripts (just once, the database keeps track of these).
  • Run unit tests.
  • Succeed.

This works all kinds of wonders locally.

Now I figured I'd integrate my GitHub repository with AppHarbor, since CI was the next logical step for me.

Issue is, the database is being built in two steps:

  • A dbproj is built, generating a .dbschema
  • My database upgrader (sporting all its DbUp awesomeness) builds, with a BeforeBuild target which builds and deploys the dbproj, and an AfterBuild target which self-executes the database upgrader, updating the schema with any SQL scripts that are yet to be run.

The issue is the AppHarbor build servers fail on the .dbproj project, because a required SqlTasks.target is missing in their server configuration.

I tried a quick fix manually adding that target (along with some other targets it depended on), but that yielded an error I can't get past:

The "SqlBuildTask" task could not be loaded from the assembly Microsoft.Data.Schema.Tasks.Sql [...]

Digging a bit I found that apparently you can't build .dbproj projects on environments which do not have either VS nor TFS installed on them.

How should I proceed? I might have a few options:

  • Manually connecting to the AppHarbor database and running the deployment script generated in my dev environment against a fresh production database.
    This one kind of defeats the purpose of one-step building.

  • Instead of using a .dbproj database project, just include all base-install tables in the DbUp "upgrader". This has two issues, although they probably can be resolved. The first one is that I should be creating the database by myself, the second one is that the log4net table I'm using to log the database upgrading process would be created by the process itself, which is all kinds of wrong in my books.

  • Use some custom database project solution where I can deploy a database without this issue.
    I don't really know any solutions like this, do any exist, are they reliable?

Opinions, deployment articles, or any suggestions are welcome, a quick hack to make .dbproj build on AppHarbor would also suffice.

Lastly, is it too far fetched to ask AppHarbor to include TFS and/or VS in their build servers, building .dbproj projects sounds fairly reasonable for a build server to do, right?

bevacqua
  • 47,502
  • 56
  • 171
  • 285
  • You might want to consider a different database deployment approach, such as this one: http://blog.appharbor.com/2012/04/24/automatic-migrations-with-entity-framework-4-3 – friism Sep 07 '12 at 20:31
  • I'm using dapper though. https://github.com/SamSaffron/dapper-dot-net – bevacqua Sep 07 '12 at 21:06
  • Quick hack to build dbproj - grab .target file and all dependent dlls (could be a big bunch, but I think it could be done). Store it along other build tools and inject it manually to your buildscript. This hack obviously violates Visual Studio product license and it's just a theory. Actually I agree with friism and Niko - consider a different deployment approach. Maintainable and not violating anything. Check ecm7Migrator as an option. – Alexey Shcherbak Sep 20 '12 at 09:40
  • I tried that. didn't work out, one of the SQL targets threw exceptions about not being able to load assemblies dynamically (and they were all there) – bevacqua Sep 20 '12 at 14:42
  • You can prob get what you're after with http://www.pabich.eu/2011/03/automated-database-deployments-to.html – Matt Kocaj Mar 22 '16 at 09:51

0 Answers0