Sharepoint development/migration process

[Paul]

I'm having incredible problems answering what 'to me' sounds like a very
simple question.

I am developing a sharepoint system on a development server. I am using a
prototyping approach so I will release sites one by one to the test server.
As this is not yet 'live' on the production server the client will be adding
all content to the test server. The migration path is therefore DEV -> TEST
-> PROD

The first time I migrate sharepoint across to the test server I can transfer
the entire site. The client will then populate content on the test site
prototypes as soon as they become available.

QUESTION: How do I migrate modified versions of a site without losing all of
their pre-populated content? It can't possibly be that you have to 'modify'
sites directly on the production server?

Is there something with smigrate, stsadm or SQL server backup/restore that I
can use to achieve this?

[Heather Solomon]

You backup the site on dev/test, then restore it on the production box using
the STSADM tool.

I may understand you wrong, but after the site is in production you intend
to keep making modifications to the dev/test servers with periodic updates to
production, and not allow users to update production?
--
Heather Solomon
http://www.heathersolomon.com/blog

[Dustin Miller]

Unfortunately, and this is one of the ugly secrets about SharePoint,
there is no good way to do what you're trying to do. There's no obvious
way to update content (i.e. page design) separately from data (i.e. list
data, documents uploaded) or metadata (i.e. what web parts are shown
where, list schemas).

This is the #1 reason people edit sites in Production. If you're doing
just design (not changing list schema), and you only work on COPIES of
existing pages, it's not a bad way to do things.

-----
Dustin Miller
SharePoint University [http://www.sharepointu.com]
SharePoint Blogs [http://www.sharepointblogs.com]
SharePoint Experts [http://www.sharepointexperts.com]

[Paul]

Thanks for your responses. I guess I'm having trouble coming to terms with
the development (and maintenance) process used with Sharepoint. In
traditional software development you would have the dev/test/prod server
model, not just for the initial development but ongoing.

I think you've answered the question Dustin, but I can't say I like it. The
result is that you will lose (or need to re-enter) any content added to the
live page after you take a copy to work on. For large scale mods that could
be significant.

We just have to deal with that I guess.

Cheers

[Dustin Miller]

To be honest, most so-called "successful" SharePoint implementations
have little in the way of hard-coded content. Most, if not all, of what
you see is either a: data, b: metadata, or c: properties of a web part
(which are considered, in some regard, metadata). Design is often, when
done "right", limited to CSS/JavaScript changes (some of which aren't
"supported" by Microsoft), and all of what you'd normally consider
content is restructured as, say, custom formatted SharePoint lists, or
documents, or properties of a web part like the Content Editor Web Part.

It takes a different line of thinking when you come to the SharePoint
world. The old staging methods just don't work as well as they do in
typical application development cycles. It's just ... different. Not
bad, not good, just different.

But that's just my opinion; it really is a personal interpretation. I
hope I gave you a few things to think about. :)

-----
Dustin Miller
SharePoint University [http://www.sharepointu.com]
SharePoint Blogs [http://www.sharepointblogs.com]
SharePoint Experts [http://www.sharepointexperts.com]