Re: developer privs in development (old thread inaccessible)

On 8 Dec 2003, joel-garry_at_home.com wrote:

> What's really the difference between this and dividing
> developers up by schema? I've done that, worked well.

Nothing. We actually have the build parameterized so that we can work on the same instance with multiple schema suites. Either suites per developer or, as we are using it right now, multiple tagged versions of the database build on one instance. Allows us to move forward with the subsequent builds without bringing QA down.

The problem was that the DBA team didn't even want different schemas for each developer, plus, they thought the rebuild idea wasn't needed. After a few of those conversations, I could tell that getting to a productive level for a development effort wasn't going to involve that team, and certainly wasn't going to be achieved by working on a database instance under the control of that team. Too bad. Sure could have used whatever expertise they were actually going to bring to the table. It was the control baggage that I had to forgo.

> Integration & checkout procedures are the key there.

Yes. We spent awhile early on creating and massaging the build.xml and folder structures to allow for full rebuilds so that checkout and then "ant" did something useful.

> Putting it in separate instances would remove some
> stepping-on-each-others-data issues, particularly with data
> restores.

It just makes sure that nothing, but what is going on in your environment is related to whatever anyone else might be doing. It is related to what you checked out and what you modified locally and then what you have done since.

> I think Galen has it just right.

Thanks.

-- 
Galen Boyer