Hi Miguel, This is in-line with discussions related to db changes we are having at [1] and [2]
I think it would be better to use existing tools like [liquibase] or [flyway] instead of writing a new one. A good comparison of the both is available at [3]. Also, how do we join the efforts? Is there any design doc? Are you working on a separate branch or as separate project? [1] http://markmail.org/message/r7wv36o356nolq7f [2] http://markmail.org/message/wlua3l4o5shayidf [liquibase] http://www.liquibase.org/ [flyway] http://flywaydb.org/ [3] http://stackoverflow.com/a/8489144/201514 ~Rajani On 10-Mar-2014, at 8:35 pm, Miguel Ferreira <mferre...@schubergphilis.com<mailto:mferre...@schubergphilis.com>> wrote: Hi all, At Schuberg Philis we are interested in upgrading our running installation of ACS more frequently than the current release cycle. To that end, we are working on tooling to detect potentially conflict introducing changes to the ACS database and upgrade software. By conflict introducing change I mean a change to ACS that requires a clean database to start with. Thus, rendering a database of a running installation useless. Once we can detect the changes that introduce conflicts, we will start to monitor them to better understand how to mitigate and possibly work around the conflicts. One thing we can already foresee as problematic is the way the upgrade software (SQL scripts and Java classes) are being maintained. It is part of the current way-of-working to make all kinds of changes to the upgrade software in the master branch. Say, if a create statement was introduced in a SQL script in commit C1, then the same create statement might be changed in commit C2, or even further down the line. If we want to continuously upgrade our running installation, we would not be able to upgrade past C1 without at least losing some data. One possible way out of this problem is to add an alter statement in C2 instead of changing the create statement introduced in C1. We are in favor of all changes to the upgrade software being made in such a way that they can be applied independently and incrementally. We do realize that this entails more effort from developers, but we also see the benefit of enabling continuous delivery: we basically get a shorter feedback loop on the quality of ACS in a real-world scenario. We are making all tools related to this open source, so anyone that shares the same interest is welcome to join the effort. Lastly, we would like to hear your opinions about the issue I described, as well as, the proposed solution and any other solutions you might come up with. Kind regards, Miguel Ferreira Mission Critical Engineer Schuberg Philis Boeingavenue 271 1119 PD Schiphol-Rijk schubergphilis.com<http://schubergphilis.com> +31 207506617 +31 610907106 _____________________
