Developer Environment Setup Opinions // Seeking your opinion


G

granadaCoder

I was having a discussion with a colleague earlier today about the
development environment.

I am seeking opinions, and to avoid slanting the input one way or the other,
I am not even going to label which opinion I hold.

The question on the table is about the database location for the DEVELOPMENT
environment.

The development team would typically consist of 4-5 people. With the
potential to be up to 10 developers on a single team.

1. Opinion A

Each developer is either given his/her own database to work with/on during
development.
The database is isolated per developer during development.
While developing, any data in the database is there because a single
developer has put it there (inserted it) (or updated it or deleted it).
The developer is free to drop (and usually re-add) tables, udf's (user
defined functions), usp's (user stored procedures), triggers, views, as
needed.
If the developer ever needed to "start from scratch" (for the Northwind
metaphor, something like deleting all customers, all orders, and all order
details), he/she would be free to do this without group permission.

After a particuliar feature is developed, all code (dotnet) is checked in,
along with any .sql (tsql,ddl) changes as well.
At certain intervals, code is compiled and deployed, database is redeployed
on a staging server for (usually) QA testing.
(The QA setup is on db servers, web server...which the developers don't
really get involved with as far as development goes)

The practical setup would be 1 of 2 scenarios.
Scenario 1 would be each developer is given a copy of Sql Server Developer
Edition. Thus he/she would be "sa" on his/her own development machine.

Scenario 2 would be each developer is given an (isolated for the single
developer) database on a common (development) Sql Server. Thus instead of a
single common Northwind database ( Northwind as an example), there would be
databases deployed for each developer:
NorthwindBob
NorthwindEd
NorthwindSue
NorthwindJoe
NorthwindJane
database.



2. Opinion B
All developers on a single team share a common development database.
While developing, data is seen by all team members on this single team
database.
In order to provide some order, team members will be given rules for
segmenting data while developing and testing.
The Northwind methaphor would be something along the lines of:
Bob, you can deal with customers with the LastName of A,B,C.
Ed, you can deal with customers with LastName of D,E,F.
Sue, you can deal with customers with LastName of G,H,I.
Joe, you can deal with customers with LastName of J,K,L.
Jane, you can deal with customers with LastName of M,N,O.

If the developer ever needed to "start from scratch" (for the Northwind
metaphor, something like deleting all customers, all orders, and all order
details), he/she would either have to stay in their segment (only delete
"his/her" customers of ABCor DEF, etc) or get group-approval from all other
team members to do a "clear all".



..........
Other information:
The db is not a simple thing like the Northwind metaphor. It has 80
tables....and only one of those is a lookup/code table. (Aka, the majority
of the tables are not lookup tables like "States", "ZipCodes"...these are
consolidated into 1 table...with a CodeCategory(Key) to put the lookups into
separate categories. The majority of tables are their to allow the system
to do what it needs to do.


To ease initial setup...there are helper scripts to populate an empty
database with some baseline data. In the Northwind metaphor, this would be
the equivalent of adding Products,Suppliers,etc.
The db would be empty of Customers,Orders,OrderDetails.....but the more
"lookup" type data would be contained in a single script.
(Aka, when the developer needs a fresh database to work with, they don't
have to manually go in and "Create Products", "Create Supplies").

The Northwind methaphor is of course a metaphor, we are not making the best
darned NorthwindManager in the world.


There are times when developers are focused on certain aspects of the
project.
Sometimes its purely logic, and being able to make sure the system works.
And being able to add/edit/delete customers/orders/order details (in the
Northwind metaphor) is what is being focused on.
Other times, there are scalability things going on. Like inserting
(1,000,000 customers, 2,000,000 Orders, 4,000,000 OrderDetails) into the
database, and then seeing how fast (tweaking tsql, indexes, usp's) an
application user can bring up the Orders/OrderDetails for one particuliar
customer. (Please reread OpinionA and OpinionB at this point as well from
above).


The team members are routinely involved with table/usp/udf/views creation.
While I know in some environments the dba is more heavily involved in these
areas, our dba's are more maintenance type dba's. Our developers pretty
much are involved with the entire process of the application development.
What is right or wrong here, I don't know. But this is the reality of the
current environment.
Aka, an opinion along the lines of "that's the dba's job" won't really help
out here. Please feel free to express that opinion, I'm just relaying the
reality that it won't actually go-down that way in my current environment.



The best metaphor I can come up with (without taking 3 pages to explain what
this system does) would be a HelpDeskTicket system.
Roll with me here...this is a metaphor........
There is workflow type stuff, where if the HelpDeskTicketWorker doesn't know
how to answer a question, it can be promoted to a hierarchy of advanced
HelpDeskTicketWorkers.
The HelpDeskTicketWorker will do N number of items at a time (usually
10)....and he/she is allowed to review the 10 items before actually
(officially) submitting them. Aka, while the 10 items are in this temporal
state...the HelpDeskTicketWorker can edit their suggestions and these edits
are updated to the database.
Another "rule" would be that something like 50% (configurable value) of all
HelpDeskTicket items are actually processed TWICE to ensure quality
assurance. So when a HelpDeskTicketWorker submits the 10 items....5 of them
will actually be marked as "Still Incomplete" so another
HelpDeskTicketWorker will do them again (without any knowledge it has
already been addressed the first time).
Advanced HelpDeskTicket workers will actually come in and look at the 2
responses from 2 different people and give them "Ok" or "The FirstGuy is
Nuts" type evaluations.

I mention the HelpDeskTicket metaphor to paint a small picture of the
system. It is not a HelpDeskTicket system....so please don't lose focus and
start picking holes at the HelpDeskTicket metaphor.

.......

While still learning and getting better, the team does strive to incorporate
NUnit testing.
Right now, to build deployment scripts (.dll and .sql), there are some poor
man's versions of MSBuild, but the eventual goal (this summer?) is to get to
MSBuild and automate alot of this stuff.

.......


The big question is the database setup environment for a multiple developer
team.
Aka, what do you think about OpinionA, OpinionB....or perhaps your own
OpinionC.
I've tried to paint an objective representation of both opinions.
Scenario1 and Scenario2 (under OpinionA) aren't really the focus of my
post....but if you have a small comment on that...that's ok as well.
OpinionA and OpinionB are the crux of the issue.

Please express your opinion...alternate setup ideas are welcome as well.

If you don't actually work in a team environment the majority of time, and
are expressing an opinion....please at least acknowledge that.
I will value your opinion, but to be honest...working in a team environment
is something that needs a little first-hand experience to empathize with I
think.
...........

As always...thanks for any input.

...
 
Ad

Advertisements

G

granadaCoder

Eliyahu,

Unforunately, we're in VS2005 land right now.
And the expense of the "better than Pro" versions of VS2005 is a limiting
factor.

So to clear up the actual tools....

VS2005 Pro.
2.0./3.0 Framework
Sql Server 2005. (Standard Edition for the production servers).


........





Eliyahu Goldin said:
First look at Visual Studio Team System database projects aka DataDude and
see if you can benefit from them.

--
Eliyahu Goldin,
Software Developer
Microsoft MVP [ASP.NET]
http://msmvps.com/blogs/egoldin
http://usableasp.net


granadaCoder said:
I was having a discussion with a colleague earlier today about the
development environment.

I am seeking opinions, and to avoid slanting the input one way or the
other, I am not even going to label which opinion I hold.

The question on the table is about the database location for the
DEVELOPMENT environment.

The development team would typically consist of 4-5 people. With the
potential to be up to 10 developers on a single team.

1. Opinion A

Each developer is either given his/her own database to work with/on
during development.
The database is isolated per developer during development.
While developing, any data in the database is there because a single
developer has put it there (inserted it) (or updated it or deleted it).
The developer is free to drop (and usually re-add) tables, udf's (user
defined functions), usp's (user stored procedures), triggers, views, as
needed.
If the developer ever needed to "start from scratch" (for the Northwind
metaphor, something like deleting all customers, all orders, and all
order details), he/she would be free to do this without group permission.

After a particuliar feature is developed, all code (dotnet) is checked
in, along with any .sql (tsql,ddl) changes as well.
At certain intervals, code is compiled and deployed, database is
redeployed on a staging server for (usually) QA testing.
(The QA setup is on db servers, web server...which the developers don't
really get involved with as far as development goes)

The practical setup would be 1 of 2 scenarios.
Scenario 1 would be each developer is given a copy of Sql Server
Developer Edition. Thus he/she would be "sa" on his/her own development
machine.

Scenario 2 would be each developer is given an (isolated for the single
developer) database on a common (development) Sql Server. Thus instead
of a single common Northwind database ( Northwind as an example), there
would be databases deployed for each developer:
NorthwindBob
NorthwindEd
NorthwindSue
NorthwindJoe
NorthwindJane
database.



2. Opinion B
All developers on a single team share a common development database.
While developing, data is seen by all team members on this single team
database.
In order to provide some order, team members will be given rules for
segmenting data while developing and testing.
The Northwind methaphor would be something along the lines of:
Bob, you can deal with customers with the LastName of A,B,C.
Ed, you can deal with customers with LastName of D,E,F.
Sue, you can deal with customers with LastName of G,H,I.
Joe, you can deal with customers with LastName of J,K,L.
Jane, you can deal with customers with LastName of M,N,O.

If the developer ever needed to "start from scratch" (for the Northwind
metaphor, something like deleting all customers, all orders, and all
order details), he/she would either have to stay in their segment (only
delete "his/her" customers of ABCor DEF, etc) or get group-approval from
all other team members to do a "clear all".



.........
Other information:
The db is not a simple thing like the Northwind metaphor. It has 80
tables....and only one of those is a lookup/code table. (Aka, the
majority of the tables are not lookup tables like "States",
"ZipCodes"...these are consolidated into 1 table...with a
CodeCategory(Key) to put the lookups into separate categories. The
majority of tables are their to allow the system to do what it needs to
do.


To ease initial setup...there are helper scripts to populate an empty
database with some baseline data. In the Northwind metaphor, this would
be the equivalent of adding Products,Suppliers,etc.
The db would be empty of Customers,Orders,OrderDetails.....but the more
"lookup" type data would be contained in a single script.
(Aka, when the developer needs a fresh database to work with, they don't
have to manually go in and "Create Products", "Create Supplies").

The Northwind methaphor is of course a metaphor, we are not making the
best darned NorthwindManager in the world.


There are times when developers are focused on certain aspects of the
project.
Sometimes its purely logic, and being able to make sure the system works.
And being able to add/edit/delete customers/orders/order details (in the
Northwind metaphor) is what is being focused on.
Other times, there are scalability things going on. Like inserting
(1,000,000 customers, 2,000,000 Orders, 4,000,000 OrderDetails) into the
database, and then seeing how fast (tweaking tsql, indexes, usp's) an
application user can bring up the Orders/OrderDetails for one particuliar
customer. (Please reread OpinionA and OpinionB at this point as well from
above).


The team members are routinely involved with table/usp/udf/views
creation. While I know in some environments the dba is more heavily
involved in these areas, our dba's are more maintenance type dba's. Our
developers pretty much are involved with the entire process of the
application development. What is right or wrong here, I don't know. But
this is the reality of the current environment.
Aka, an opinion along the lines of "that's the dba's job" won't really
help out here. Please feel free to express that opinion, I'm just
relaying the reality that it won't actually go-down that way in my
current environment.



The best metaphor I can come up with (without taking 3 pages to explain
what this system does) would be a HelpDeskTicket system.
Roll with me here...this is a metaphor........
There is workflow type stuff, where if the HelpDeskTicketWorker doesn't
know how to answer a question, it can be promoted to a hierarchy of
advanced HelpDeskTicketWorkers.
The HelpDeskTicketWorker will do N number of items at a time (usually
10)....and he/she is allowed to review the 10 items before actually
(officially) submitting them. Aka, while the 10 items are in this
temporal state...the HelpDeskTicketWorker can edit their suggestions and
these edits are updated to the database.
Another "rule" would be that something like 50% (configurable value) of
all HelpDeskTicket items are actually processed TWICE to ensure quality
assurance. So when a HelpDeskTicketWorker submits the 10 items....5 of
them will actually be marked as "Still Incomplete" so another
HelpDeskTicketWorker will do them again (without any knowledge it has
already been addressed the first time).
Advanced HelpDeskTicket workers will actually come in and look at the 2
responses from 2 different people and give them "Ok" or "The FirstGuy is
Nuts" type evaluations.

I mention the HelpDeskTicket metaphor to paint a small picture of the
system. It is not a HelpDeskTicket system....so please don't lose focus
and start picking holes at the HelpDeskTicket metaphor.

......

While still learning and getting better, the team does strive to
incorporate NUnit testing.
Right now, to build deployment scripts (.dll and .sql), there are some
poor man's versions of MSBuild, but the eventual goal (this summer?) is
to get to MSBuild and automate alot of this stuff.

......


The big question is the database setup environment for a multiple
developer team.
Aka, what do you think about OpinionA, OpinionB....or perhaps your own
OpinionC.
I've tried to paint an objective representation of both opinions.
Scenario1 and Scenario2 (under OpinionA) aren't really the focus of my
post....but if you have a small comment on that...that's ok as well.
OpinionA and OpinionB are the crux of the issue.

Please express your opinion...alternate setup ideas are welcome as well.

If you don't actually work in a team environment the majority of time,
and are expressing an opinion....please at least acknowledge that.
I will value your opinion, but to be honest...working in a team
environment is something that needs a little first-hand experience to
empathize with I think.
..........

As always...thanks for any input.

..
 
E

Erland Sommarskog

granadaCoder said:
The question on the table is about the database location for the
DEVELOPMENT environment.
...
1. Opinion A

Each developer is either given his/her own database to work with/on during
development.

2. Opinion B
All developers on a single team share a common development database.
While developing, data is seen by all team members on this single team
database.

I would suggest that the best is to use a common database as the "standard"
place of development, but you should use individual databases as needed.

Having a common database means that there will be more test data available,
and there may be test data with cases that the developer did not think of.
It also makes it a little easier for developers to benefit from the
achievements of other colleagues.

But sometimes a developer may need to work with changing existing features
in a way that he would prevent his colleauges from doing their job. In this
case, it's a good idea to take a backup of the common database and let
him work in a copy.

Having different databases is also good for version-control discipline.
Some developers seems to think that since it's the database their job
is done. But if there are multiple datbases, it becomes obvious that
it does not work, but that they have to put things in a common place,
so it can be deployed everywhere.

--
Erland Sommarskog, SQL Server MVP, (e-mail address removed)

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
 
J

Jon Skeet [C# MVP]

I was having a discussion with a colleague earlier today about the
development environment.

<snip>

Personally I favour the "each dev gets their own database" - with a
common database as well. When each dev gets their own database:

1) They should easily be able to test db upgrade scripts
2) It's possible to write automated tests which do stuff with the
database without screwing everyone else
3) You don't have to keep everyone in sync the whole time - if I'm
writing a feature which needs an extra column, I want it in my
database but don't want it in yours until I'm ready to check in.

Jon
 
B

bruce barker

use scripts to create the database, and create a msbuild script to do the
build. you can add bcp files, that msbuild uses to initial default and test
data.

so to start, a developer checks out the database scripts and runs a local
build. to check in, they update the scripts, do a build and test, then check
in.

hint: you can make a utility project that has all the sql script, so you can
edit in studio, or include the sql scritps with the datalayer dll.


-- bruce (sqlwork.com)
 
Ad

Advertisements

S

sloan

Just a few followup comments:

Outside of the database being designed well and performing well........
SourceControl on the .sql files is one of my highest priorities.
That sounds perhaps trivial...but having a place where I can look at the
history of each
usp, udf, vw, trigger, tableDDL is important in my book.


And:
And I try to teach/live by the motto "If you can't deploy your code, its
worthless".

...
 
C

Crash

1) They should easily be able to test db upgrade scripts
2) It's possible to write automated tests which do stuff with the
database without screwing everyone else
3) You don't have to keep everyone in sync the whole time - if I'm
writing a feature which needs an extra column, I want it in my
database but don't want it in yours until I'm ready to check in.

I HUGELY conquer with this opinion - to the point that I have been the
driving force behind and am currently living in the "I own my own and
the group has one too" world.

4) When (not if) you insert bad data into the database during
development it is easier to restore your own backup than it is to stop
everyone in their tracks to restore the group's backup...

5) You need a group database around, and you should be working in it,
for impromptu "dog and pony" shows - a right that both the customer
and management enjoy...
 
S

sloan

//use scripts to create the database//
I agree.

//create a msbuild script to do the
That's where I want to get to.

//> so to start, a developer checks out the database scripts and runs a
local
build. to check in, they update the scripts, do a build and test, then
check
in.//
That's where I'm at now.

//you can make a utility project that has all the sql script, so you can
edit in studio//
If you're speaking of a .dbp (database project)...I've been doing that
already for 5-6 years.
If its something else, let me know.
 
S

Stuart Ainsworth

Eliyahu,

Unforunately, we're in VS2005 land right now.
And the expense of the "better than Pro" versions of VS2005 is a limiting
factor.

So to clear up the actual tools....

VS2005 Pro.
2.0./3.0 Framework
Sql Server 2005.  (Standard Edition for the production servers).

.......

message

First look at Visual Studio Team System database projects aka DataDude and
see if you can benefit from them.
--
Eliyahu Goldin,
Software Developer
Microsoft MVP [ASP.NET]
http://msmvps.com/blogs/egoldin
http://usableasp.net
"granadaCoder" <sloanh__at____g____mail____dot___youKnowThe3Letters> wrote
in messagenews:[email protected]

- Show quoted text -

I think you need to give each database developer their own sandbox,
mainly because database developers deal with schema more than data.
So, while isolating data based on criteria may be useful for testing
applications or data retrieval, it doesn't help when developing new
database objects. I also think you should have a single group
database where individual changes are applied (from source control &
change scripts, of course); this gives your development team an
opportunity to make sure their code interacts well with others before
deploying to QA.

Just my .02.

Stu
 
Ad

Advertisements

S

sloan

//
2) It's possible to write automated tests which do stuff with the
database without screwing everyone else
//
I agree.


//
3) You don't have to keep everyone in sync the whole time - if I'm
writing a feature which needs an extra column, I want it in my
database but don't want it in yours until I'm ready to check in.
//
I agree.

I agree with #1 as well, its just not a huge factor for me. While the db
changes over time....the projects that use the system are short lived.
So the db schema is fairly concrete from one production deployment to the
next.
At a previous job...I'd definately say #1 was the case.

............
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top