Re: developer privs in development (old thread inaccessible)

> 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.

-- 
Galen Boyer