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]
Paul wrote:
> 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
> "Paul" wrote:
>> 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?
