Peter Schott (1/22/2012)
Along those lines, ones you have a decent Continuous Delivery system in place, this shouldn't be as much of a problem. You have your downstream environment(s) that are exact copies of your production ones, gen up the change script(s) using your automated tools, then just hand them off to the team doing the changes in Prod. They should have sufficient permissions to do the changes needed and ideally you have at least one downstream environment that's a duplicate of your production environment so the testing and notes about other pieces of the equation can be handled. We've been using the VS2010 DB Projects to store and push our changes and are pretty close to having the ability to just build/deploy all the way up the chain.
Build and deployment of new modules aren't really my concern there. The equivalent of adding a scoring system to the existing inventory system isn't where Agile starts to breakdown, at least in my mind, from a database perspective.
However, allow me an actual example that I walked headfirst into a few years ago.
A simple e-sales system had started with a solid core scope and understanding. Products were included, carts were built, etc etc. It worked very well. Attached to this were additional modules. Eventually, a catalog system was built in for custom client pricing. Certain deals were to be offered to certain clients. For example, students at particular schools could order things cheaper by being a student.
So overrides were put in place in certain places, the cart was modified, etc etc. Eventually this cart proc became about 30 pages long, and was so convoluted that processing a cart to completion could take up to 10 seconds. This was unacceptable due to ever increasing volume order.
A full redesign of the structure, incorporating the new modules into the core structure, allowed for a much fuller and less intricate system of maintaining the data. This took 3 months of pure dev work, no new features, no ... you get the drift. It wasn't possible to do this in small doses, we had to redesign basically from scratch for all the new modular components that had been included.
I'm all for agile as long as the time is taken every few years to clean up the mess it leaves behind.
It's not because you can't plan for the scope, it's because the very NATURE of Agile is planned scope creep.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA