Hi Dmitry, Part of the risk-factor for us was that it takes about 1 week to do a production deployment here. If the application was running flyway.migrate() itself (reading the scripts out of the WAR) and there was an issue, it would be quite difficult to fix because we'd have to go through the deployment process again (because we'd have to generate a new WAR). Our environment just isn't that agile. Also, we'd have had to fight a battle with the DBAs and SAs to get our application's DB login account to have grants to create/drop/alter/etc tables and it just didn't seem worth the effort given the lack of agility. So we used Maven migrations and do a flyway.validate() on startup, but that can be turned off with a -D JVM parameter if needed. Our last production migration had over 100 scripts which ran without errors, so we manage the risk OK and the DBA loved the fact it was all automated and tested.
For our non-production environments, we were able to get access to the admin DB accounts and set up Jenkins jobs to do automatic builds/migrations there. We could make these environments do flyway.migrate() on startup, but we wanted to keep them similar to the production environment and stuck with Maven for migration. Also, you mentioned doing rollbacks. We learned the hard way that MySQL DDL is not transactional and cannot be rolled back. We now do all DDL (create/drop/alter/etc) one-per-migration in case there is an issue. Flyway runs each migration in a transaction, so we only have to repair the one DDL that gave an error (any previous migrations succeeded). A bit ugly, but functional. Thanks, mrg On Wed, Aug 14, 2013 at 10:31 AM, Dmitry Gusev <dmitry.gu...@gmail.com> wrote: > Hi, > > I think this is a good point to only check if migrations applied if your > risks are high. > > But if something went wrong with migration -- it should be rolled back and > simply won't apply. > So in both cases your application won't be started, whether you stopped > application manually and applied migration from plugin or if you run it > during application start -- isn't it? > > It is great if you have direct access to your database, like, via public IP > or VPN. > In this case you can do some migrations even without updating your codebase > and without restarting your app, just using plugins. > > I'm also using https://github.com/tlberglund/gradle-liquibase-plugin in > some cases where I have direct database access. But I mostly use it to > generate changesets from database schema so I don't have to write them > manually (I prefer setting <property name="hibernate.hbm2ddl.auto" value= > "update"/> for my development machine so that hibernate updated my db > schema first, so I don't even run liquibase on my development machine -- > only on QA, Live environments with few exceptions when it is easier to > quickly write changeset and apply it using the plugin). > > The reason I choose to use automatic migrations in my recent projects is > that I use PaaS hosting environments like OpenShift and Jelastic and you > don't always have direct access to database there. > > For instance, with OpenShift, deployment is done by simply pushing new code > to git repo. I like that if I put new migrations in commit -- they will be > applied on application rebuild-restart. Of course I can SSH to remote > OpenShift instance and apply migrations manually -- for my projects this is > not productive, because I may doing 3-to-5 redeploys per day and some of > them may include db migrations. > > The same with Jelastic, I don't have SSH access to remote instances, but I > may buy public IP to have db access. But for the same reason of often > deploys I prefer to run migrations from within the cloud during application > start. And it works well for me so far. > > > > On Wed, Aug 14, 2013 at 5:22 PM, Michael Gentry <mgen...@masslight.net>wrote: > >> Hi Dmitry, >> >> Like Borut, we have many Maven profiles set up to do Flyway migrations >> in all of our environments and have set up our DBAs with Maven/etc in >> order for them to do our production migrations. On the Tapestry side, >> our AppModule has an @Startup method that does a Flyway validate() to >> ensure the schema is up-to-date or it throws an exception and the >> application fails to start. We initially thought about having the >> @Startup do the Flyway migrate(), too, but thought that might be a bit >> too risky, so we stuck with Maven. >> >> mrg >> >> >> On Wed, Aug 14, 2013 at 5:54 AM, Dmitry Gusev <dmitry.gu...@gmail.com> >> wrote: >> > Just curious, and how do you deliver your migrations to target >> > environments, like production? >> > >> > On Wed, Aug 14, 2013 at 10:39 AM, Borut Bolčina <borut.bolc...@gmail.com >> >wrote: >> > >> >> Hello, >> >> >> >> no reusable modules at the moment, nor any integration, as we use the >> >> flyway as a maven plugin. I do see a potential use, but have no clear >> >> vision on how to use the auto-migration in a more complex >> >> development/runtime environments. Will have to dedicate some time into >> it >> >> and discover safe and clear paths in development cycles in a small >> >> development team. >> >> >> >> There is a live #Tapestry IRC channel, interesting... >> >> >> >> Regards, >> >> borut >> >> >> >> >> >> 2013/8/14 Dmitry Gusev <dmitry.gu...@gmail.com> >> >> >> >> > Hi, >> >> > >> >> > It seems Flyway is popular among tapestry users, we've discussed it >> >> > yesterday on the #tapestry IRC channel. >> >> > >> >> > It seems (the only?) advantage of Flyway against Liquibase is that you >> >> can >> >> > run custom Java code during migrations. >> >> > >> >> > Do you have any reusable modules or, maybe, best practices how you use >> >> > Flyway with tapestry? >> >> > >> >> > On Wed, Aug 14, 2013 at 10:09 AM, Borut Bolčina < >> borut.bolc...@gmail.com >> >> > >wrote: >> >> > >> >> > > Nice Dmitry! >> >> > > >> >> > > I (we) use Flyway for database migrations, but it is always nice to >> >> see a >> >> > > new Tapestry module! >> >> > > >> >> > > Regards, >> >> > > borut >> >> > > >> >> > > >> >> > > 2013/8/12 Dmitry Gusev <dmitry.gu...@gmail.com> >> >> > > >> >> > > > FYI: >> >> > > > >> >> > > > >> >> > > > >> >> > > >> >> > >> >> >> https://github.com/anjlab/anjlab-tapestry-commons/tree/master/anjlab-tapestry-liquibase >> >> > > > >> >> > > > -- >> >> > > > Dmitry Gusev >> >> > > > >> >> > > > AnjLab Team >> >> > > > http://anjlab.com >> >> > > > >> >> > > >> >> > >> >> > >> >> > >> >> > -- >> >> > Dmitry Gusev >> >> > >> >> > AnjLab Team >> >> > http://anjlab.com >> >> > >> >> >> > >> > >> > >> > -- >> > Dmitry Gusev >> > >> > AnjLab Team >> > http://anjlab.com >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> > > > -- > Dmitry Gusev > > AnjLab Team > http://anjlab.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
