The deployment scenario becomes complex when there are database CHANGES during the upgrade. There can be two different SCENARIOS: 1. database change is backward compatible (e.g. adding a new table column) 2. database change is not compatible with an older version of the application (e.g. RENAMING an existing table column) 

1. Backward compatible change: This scenario is easy to IMPLEMENT and can be fully automated using Flyway. We can add the script to create a new column and the script will be executed at the time of deployment. Now during blue/green deployment, two versions of the application (say v1 and v2) will be connected to the same database. We need to make sure that the newly added columns allow null values (btw that’s PART of the backward compatible change). If everything goes well, then we can switch off the older version v1, else application v2 can be taken off. 
2. Non-compatible database change: This is a tricky scenario, and may require manual intervention in-case of rollback. Let's say we want to rename first_name column to fname in the database. Instead of directly renaming, we can create a new column fname and copy all existing values of first_name into fname column, keeping the first_name column as it is in the database. We can defer non-null checks on fname to post-deployment success. If the deployment goes successful, we need to migrate data written to first_name by v1 to the new column (fname) manually after bringing down the v1. If the deployment fails for v2, then we need to do the otherwise. 

Complexity may be much more in a realistic production app, such discussions are beyond the scope of this book.