On Fri, Jul 2, 2010 at 5:31 PM, Danilo Šegan <[email protected]> wrote:
> I can imagine it being much easier for simpler schema extensions, but I > ain't gonna go through the effort while there is db-devel around. :) In a lot of ways, the way we have devel/stable/db-devel/db-stable setup we are meeting a lot of the points mentioned in the article. We do deploy trunk (edge and staging), exposing new stuff to a subset of users for testing (edge, while the article prefers configuration and the mess of 'if then else' code and the extra costs that creates with your test suite, which wasn't mentioned - most web applications don't have them). If we want to follow in the direction of the article, the first step would be to drop the production branches and instead update directly from stable. I doubt we want to pay the development, qa and management overhead of writing schema-migration-safe-code. Doubling our test run time would just be the first and most immediate impact as we run the test suite against the current production dbschema and against the trunk dbschema. We should bear in mind that our setup is actually pretty darn good and leagues ahead of what most people are doing. What to a lot of people are improvements can be massive step backwards to us. -- Stuart Bishop <[email protected]> http://www.stuartbishop.net/ _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
