1

I am still struggling to find an efficient way to handle deployment in SharePoint 2010. It seems as if this wasn't thought throught very well by Microsoft.

I've had a look at the ideas here. These work OK if your goal is to move a whole site collection to a new environment. However, in my case, I have a single site with lots of subsites which must be moved to a different site collection. Importantly, there is also a somewhat complicated SharePoint Solution which was deployed from Visual Studio and needs to be moved to the new environment.

The SharePoint Content Deployment Wizard doesn't seem able to connect an SPWeb to a different site collection. Is there something I am just misunderstanding here? The second problem is deploying the code from Visual Studio, which the SPCDW does not do.

If I export my SPWeb using STSADM -o export -url [url] -filename [filename] and then run the corresponding import command, I seemingly get the expected behavior of moving an SPWeb to a different site collection. However, the deployed Solution is not included. Trying to export this as a .wsp in Visual Studio targeted to the new Web and then after deployment installing it with STSADM -o addsolution does not work either.

I'm stuck. Anyone have any good ideas? Is there a simple way to do this, or do these deployments always require a huge amount of custom PowerShell scripts, digging through the log files for errors and gnashing your teeth? The workaround thus far has been to install Visual Studio in the production environment, import site with STSADM and debug from there. But obviously, this isn't very elegant and probably breaks most "best practices".

Improve this question
3
  • The answer depends on how your solution is architected. You have a single site you say, is this a subsite as part of a site collection already, and not the root site? Do you have Features that are being deployed? Do you have any customised/unghosted files? You'll often find that content (exported sites) and solutions (wsps) are almost always, and by design, mutually exclusive, and are always deployed as separate entities.
    – James Love
    Jan 26, 2012 at 15:21
  • Well, in this case it is the root site of a site collection (with lots of subsites), but it might be different for another project. It has one feature which is deployed from Visual Studio. Deploying the exported site and code separately seems fair enough, but is there a reasonable way to ensure that the test and prod environments are similar enough to not cause problems when the code is deployed? If deploying to an existing site collection, they will be different. Installing Visual Studio on Prod to debug things seems like a terrible hack.
    – Geir Smestad
    Jan 27, 2012 at 10:25
  • Nah, never install VS onto a prod box. You'll have to set up a manual process of ensuring that code and content is pushed to test and actually tested before it goes to prod.
    – James Love
    Jan 27, 2012 at 10:30

1 Answer 1

Reset to default
2

You are deploying two different things and trying to deploy them as one which Microsoft does not recommend.

Content (all the stuff that originates in SharePoint) needs to be created on an Authoring environment first then published using Content Deployment jobs to the Production server (or even backward to a QA server if desired). You can also do all of this on the same site collection and just use the SharePoint Publish abilities but that is considerably less flexible.

Code (the stuff that originates in Visual Studio) needs to be deployed up as normal, dev -> qa -> authoring -> prod. This is done as a Solution and deployed via the Admin Shell on each environment.

It does mean that you have some duplication of effort when it comes to content creation as you need to create the content in your dev environment in order to test your code, but usually you only need a very small subset of the content to do this.

One of the extremely compelling reasons for not pushing content from Dev to QA to Authoring to Prod is that Dev environments tend to get filled with all sorts of test pages and other junk; things that have no place anywhere other than dev. By pushing content the same way as you do code, you would push all of this junk right through to prod. Originating content in Authoring ensures stricter controls over what is done as usually devs do not have permissions to do anything in that environment.

Improve this answer
4
  • Thanks. By content, do you also mean list definitions, subsites, content types, page layouts and stuff like that? So you'd create this stuff in Authoring (with no code), then manually copy it to dev where the code is developed and tested? This seems very manual-labor intensive if you're doing prototyping work that requires lots of code and making lots of small, frequent changes. Is this process really how Microsoft envisioned it, or am I just misunderstanding something? Coming from a world of Agile software development, this all seems completely backwards to me. Which part don't I get here?
    – Geir Smestad
    Jan 27, 2012 at 10:18
  • List definitions, content types, page layouts and such like that are really structure items and are best defined in Visual Studio so that they can be better maintained and propagated across environments. By Content, I am referring to the final text/copy that an author would create as well as any images, documents and such that end users will be maintaining.
    – Dave Wise
    Jan 27, 2012 at 16:48
  • The complexity comes from the fact that you have two vastly different creators involved in the process. Developers work in code in Visual Studio, Content Authors work largely using the SharePoint site itself. Since these are two radically different sources with completely different needs, a hybrid approach was created. To put it another way, would you want your authors writing code? Or worse, would you want your developers writing final copy?
    – Dave Wise
    Jan 27, 2012 at 16:51
  • 1
    While you can do Agile development with SharePoint, it does take some planning and there are places where SharePoint reacts very poorly to frequent changes (i.e. it really doesn't like changes to Content Types). Working in SharePoint is much more like the Waterfall model.
    – Dave Wise
    Jan 27, 2012 at 17:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.