[doc] Discuss drawbacks to running Evolutions in production

Play Version (2.5.x / etc)

2.6.x

API (Scala / Java / Neither / Both)

Neither

Actual Behavior

If you read through Evolutions https://www.playframework.com/documentation/2.5.x/Evolutions#Managing-database-evolutions it gives the impression that Evolutions is both for development and production

When you deploy on a production server, you need to have a robust way to upgrade your database schema.

While it's true that evolutions can be run in production and work perfectly fine, there are drawbacks to running scripts automatically in production that may not be obvious to a development team -- Evolutions doesn't deal with database availability, it assumes admin / DDL statements can be run against the database automatically, and the scripts themselves have no throttle or checks against database runtime impact, etc.

In practice, operations will run tools like https://github.com/soundcloud/lhm or https://www.percona.com/doc/percona-toolkit/2.1/pt-online-schema-change.html to manage database migration well in advance of the Play application deploy. The documentation should be updated to reflect the implications behind Evolutions.

Start with the linked 2.5.x Evolutions documentation, especially the “Managing database evolutions” section, and review how production use is described. Update the documentation to explain operational drawbacks such as database availability, automatic DDL execution, and runtime impact, so the implications of using Evolutions in production are clear.