Re: Deployment Strategies

Hi Brian,

I think deployment strategies partially go hand in hand with development
strategies. Some suggestions.

(1) Assign responsibilities for different sections of the site to specific
people e.g. dev1 (Browse), dev2 (Search), dev3 (Checkout). This makes it
easier to coordinate development and prevent toe-stepping during development
and build.

(2) Use partial classes as a means of reducing code contention where more
than one developer is working on the same class. These are a new feature of
.NET 2 and allow you to split a class across multiple files. I wouldn't do
this too much but when needed these can be checked out and worked on by
different people.

(3) Centralise your builds through one person with a backup if they're away.
Give advance notice of build time and require developers work to be all
checked-in, buildable, and to some extent tested by a specific time. From
this time you put a halt on code-progression until you are happy with the
build. We usually deploy to a dev server and all double-check our work then.
The only code-progression at that stage is to fix bugs that are as a result
of code changes since the last build.

(4) Under normal circumstances builds should happen weekly or fortnightly at
the most. Any more frequently is too disruptive to being productive and
getting things done. Just after a major code release you may need to build
more frequently but if you need to do this all the time it's probably an
indication of a buggy system that just needs you to have a good patch of
dedicated time to sort it out, or a system that has elements that could best
be dealt with by some form of content management i.e. sticking it in the DB
and letting someone non-technical manage it.

I think this sometimes can be just about organisation. A good task tracker
like FogBugz helps for this sort of thing so you can tell what's going into
a particular build and what everyone's been up to.

Hope that helps in some way.

Nick

-----Original Message-----
From: Discussion of building .NET applications targeted for the Web
[mailto:[email protected]] On Behalf Of Brian Vallelunga
Sent: 13 February 2007 02:32
To: [email protected]
Subject: [DOTNET-WEB] Deployment Strategies

I'm being put in charge of a fairly good sized web site and a small team of
developers. I'm trying to develop a strategy for organizing the submission
of new web site code and content and then distribution to the live site. I'm
curious what other people have found as best practices in these areas.

We have a staging server and are currently using Vault as our source code
repository. Right now we're using ASP.NET 1.1, but will be moving to 2.0 in
the near future. This brings with it another set of questions.

I've had quite a bit of experience developing sites, but generally with only
one or two people at a time. Now we're likely to have four or five managing
the content. It's also not likely we'll have set releases, but instead will
have to be dealing with small changes occurring frequently and in different
parts of the page.

So what do people do in this sort of situation? How do you get your files
where they need to be without having everyone step on each other's toes?

Thanks,
Brian

===================================
This list is hosted by DevelopMentor(r)  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com