Timeline for For Evolutionary Database Tools like Flyway or LiquidBase, it is better to integrate the tool or left it as a stand alone step in the CI process?

Current License: CC BY-SA 4.0

8 events

when toggle format	what		by	license	comment
Dec 22, 2019 at 8:46	history	edited	Doc Brown	CC BY-SA 4.0	added 80 characters in body
Dec 22, 2019 at 8:26	history	edited	Doc Brown	CC BY-SA 4.0	added 80 characters in body
Dec 18, 2019 at 19:28	comment	added	Doc Brown		@Poutrathor: any of these tools can update your schema to a specific version, right? So if you need non-backwards compatible changes, make two new schema versions, lets say V9 and V9.1 Version V9 is the schema with the backwards-compatible changes (compared to its precedecessor V8), so update first to this. Then update the applications, and finally update the DB to V9.1, where the unneeded columns or tables are deleted.
Dec 18, 2019 at 19:22	comment	added	Poutrathor		Oh, so you advice to use the database migration tool as a stand-alone utility ? These tools tend to run all the new scripts at once. Here we need to break it in 2 parts. If one wants to run scripts one by one, there is almost no benefit to use a FlywayDB rather than having each SQL script insert a record in a versioning table, right ?
Dec 18, 2019 at 18:47	comment	added	Doc Brown		@Poutrathor: don't jump to conclusions. Why not use your favorite DB migrations tool for implementing exactly what I suggested?
Dec 18, 2019 at 16:17	comment	added	Poutrathor		From your answer, one should not use such DB migrations tools at all but rather have a feature-full deployment process, for maximal uptime. However, it seems to me that this way will mathematically lead to more human errors from the many more non-obvious steps, right ? What about trading uptime for reliability : how would the DB Migration Tool be used ?
Dec 18, 2019 at 15:53	history	edited	Doc Brown	CC BY-SA 4.0	added 43 characters in body
Dec 18, 2019 at 15:48	history	answered	Doc Brown	CC BY-SA 4.0