Ooops, looks like I did not clear the last paragraph before sending :) BTW: I was one of the developers too, so I tested it all by myself in practice.
P.S. One advice: if you plan unit/integration/e2e tests, stick to the most important rule: do not duplicate unit tests in integration tests and unit+integration tests in e2e tests. This is one rule I can see broken very often and it really makes development hard and and it becomes harder and harder after each sprint. It's no wonder that after bad experience like that, teams come to conclusion that all that testing thing is a waste of time. 2014-04-12 23:07 GMT+02:00 Witold Szczerba <[email protected]>: > In my previous project I was thinking about this and finally I have > came to conclusion that the best option is to let CI server access a > real database to build project. My build was prepared for a database > details to be provided easily, so CI builds had theirs own databases > (in fact two, one for deployment and one for integration tests). > > So, the database part of build system worked like this: > 1) destroy databases (let's call them DEV and DEV_TEST) > 2) build database module, this is: > a) Liquibase, as part of mvn build, recreates databases from scratch, > b) JOOQ, as later part of mvn build, generates code, > c) mvn compiles everything, > d) mvn install > 3) compile, run integration tests (using DEV_TEST), > 4) deploy to JEE server, > 5) run e2e tests. > > Staging builds are almost the same, but they do not destroy the > database, Liquibase just upgrades schema to new version. > > At the beginning I was not sure if this is OK to couple the project > building process to a running database, but it really worked well. > Every developer had it's own database (either locally, in virtual > machine or an account on our development server). What's important > here is that developers didn't have to build database module on each > code change, but only when they actually altered the schema. It was > separated from a web application maven project. Building it did not > take long though, I don't remember, but I think it was something like > less than 2 minutes. > > I was thinking: what's wrong with this? And finally came to conclusion > that there is absolutely nothing wrong with this. In fact, it is even > better, because everyone, from developers, CI DEV builds to CI STAGING > and PRODUCTION builds work on the same database engine. There is no > excessive abstraction above database between Liquibase and JOOQ: > what's in there is what gets used to generate schema and it's what > gets used to run integration and e2e tests. I liked it. > > You might think that tying building process to > > Regards, > Witold Szczerba > > 2014-04-12 22:23 GMT+02:00 Mohit Jaggi <[email protected]>: >>> >>> >>> Already today, you can implement your own jOOQ-Meta Database that supplies >>> schemas, tables, columns, etc. to the code generator. This custom Database >>> could read any sort of XML file, e.g. an external one by Flywaydb or >>> Hibernate. >>> >>> How you generate that external file would then be entirely up to you. >>> >>> >> Lukas, >> I did not understand. Could you please point me to an example or section of >> jooq documentation please? >> >> Rob, >> For the time being I am adding generated code to git repo, which I don't >> like much. >> >> Thanks, >> Mohit. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "jOOQ User Group" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
