Re: developer privs in development (old thread inaccessible)

Daniel Morgan <damorgan_at_x.washington.edu> wrote in message news:<1070758771.453982_at_yasure>...
> Galen Boyer wrote:
>
> >>Slashdot posted a topic similar, based upon the following article.
> >>
> >>http://www.softwarereality.com/lifecycle/role_fragmentation.jsp
> >>
> >>"Somehow over the past 10 years, a cancer has been growing inside
> >>large organisations - called role fragmentation. As the roles have
> >>fragmented, an entire non-industry has bloomed. Network
> >>administration, database administration, security administration,
> >>component administration, deployment administration, tool
> >>administration. The list just goes on and on.
> >>
> >>This fragmentation has had some seriously negative consequences for
> >>the industry."
> >>
> >>I don't pretend to know everything, I do hope that I know what works
> >>best for my employer and our clients. I am certainly open to other
> >>viewpoints that could make the developers more effective, while not
> >>causing grief due to more rework due to a larger number of issues due
> >>to permissions differing in dev and test environments.
> >
> >
> > Could you list the issues you have seen? I'll list the things
> > that our DBA team in my company's headquarters gasp at in the
> > development environments I've overseen for our development.
> >
> > Each developer has his own local instance of Oracle that he
> > develops the application against. This developer has a user
> > which has full control over that database. That user's name
> > and password is the same on all development instances.
> >
> > The application's schemanames and passwords are equal.
> >
> > Each developer checks out the database source code and
> > rebuilds a subsetted version of the full database,
> > completely, from cvs. They are required to do this every
> > update with the mainline. It is accomplished by typing "ant"
> > in the dbms folder of our codebase. If that "ant" task
> > fails, then the database team has done the unthinkable and
> > has checked in broken code.
> >
> > I don't quite understand why any of this is such a huge security
> > risk? But, when I first met the guys from the architecture team,
> > they told me point blank, that I wouldn't be allowed to operate
> > this way. So, from day one, I had to pull the power card. I
> > answered, well, I'm the architect on this project and this is how
> > it is going to be. We've had a huge wall between our departments
> > since. BTW, the local instances actually came about because I
> > didn't have time to wait for the go ahead on how we were going to
> > operate. We originally had it slated that we would have a single
> > Oracle instance for development. But, I started having to spend
> > too much time fighting for what I felt we needed to be able to
> > efficiently develop that I chose to install an Oracle environment
> > on every developer's workstation and totally break ties with the
> > DBA organization. This ended up working out great. I highly
> > recommend this development configuration. Each developer is
> > completely isolated. Any issues they see? Those are directly
> > caused by either their latest checkout of the database tree or
> > their own code. They never have to worry about whether someone
> > else's tests have gotten in the middle of theirs.
> >
> > We also have much more stringent deployment environments.
> >
> > Integrated Development Environment
> > Quality Assurance
> > Quality Assurance HotFix
> > Production (Still demo right now)
> >
> > On those environments, we make the environments look like they
> > will in production. We tag our source code and then build the
> > database and deploy the app from this tag. When we make our
> > first release to production, I will use the scripting mechanism
> > of
> >
> > "ant patch###"
> >
> > I will check this patch set into CVS. Each developer's
> > subsequent build will patch their local instance with this
> > patchset. We will then be able to patch QA and have them bless
> > it. Then, onto production.
> >
>
> You'll have to excuse me but I got stuck at "Each developer has his own
> local instance."

I think this is a great idea. I wanted to do it on a big government job, but never could get the go-ahead to put together a reasonable referential subset of the big database.

Of course, they also looked at me like I was an LGM when I said I wanted a QA database and formal procedures in between development and production.

>
> Someone's got money to burn and is probably in gross violation of their
> license with Oracle Corp.

Neat thing about a government license is it is unlimited. Won't comment on government budgeting.

>
> I've never seen a development project assembled this way ... ever.

I think the downloadable stuff from Oracle does encourage such licensing and it is legal. What's really the difference between this and dividing developers up by schema? I've done that, worked well. Integration & checkout procedures are the key there. Putting it in separate instances would remove some stepping-on-each-others-data issues, particularly with data restores. I think Galen has it just right.

Too bad about the wall, though.

jg

--
@home.com is bogus.
http://www.signonsandiego.com/news/uniontrib/sat/business/news_1b6boeing.html