Thanks for sharing this, Michael!
On Thu, Aug 15, 2013 at 1:00 AM, Michael Gentry <mgen...@masslight.net>wrote: > 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 > > -- Dmitry Gusev AnjLab Team http://anjlab.com
