Comments on Chris O'Brien: SharePoint dev strategies - it's not all about Fea...

@Kieran, Sorry, I should have been clearer/suppli...

2009-06-07T22:28:34.141+01:00

@Kieran,

Sorry, I should have been clearer/supplied full details in my previous comment. It won't overwrite if you:

- Leave the 'retain object IDs and locations' checkbox unchecked
- Create the new site that you want to 'duplicate into' using the blank site template. Specify this URL in the 'Import web URL' textbox on the import

If you need any more help, just ask..

Thanks,

Chris.

So if I use the wizard to create a .cmp of an exis...

2009-06-07T20:08:59.675+01:00

So if I use the wizard to create a .cmp of an existing web called 'hr', then I want to duplicate this but with a different name in the same parent site. You think the wizard will handle the import? Or will it just overwrite the existing 'hr' web?

:) Cheers

@Kieran, This should be entirely possible, though...

2009-06-07T18:37:17.085+01:00

@Kieran,

This should be entirely possible, though I have a niggling doubt since I don't think I've ever tried to duplicate a web within the same parent site collection. I think it should be OK though, so long as you tell the Content Deployment Wizard not to 'retain object IDs and locations'.

Happy to help if you run into any issues!

Cheers,

Chris.

Hi Chris If using the deployment wizard approach ...

2009-06-02T11:25:49.505+01:00

Hi Chris

If using the deployment wizard approach described how do you go about duplicating an existing publishing web if for example you need another one creating that is almost identical but under the same parent site? Does the deployment wizard help with this, given that the save site as template option is unsupported?

Would appreciate your thoughts.

Kieran

I think we all are on the same page here, my
2008-10-01T08:46:00.000+01:00
I think we all are on the same page here, my article on change sets and deploying v2.0 on top of what is in production as v1.0 is not easily catered for AT ALL.

Most people seem to be creating new sites and migrating the old "content"/artifacts into it. But there's a grey line on what's content and what is inside the scope of the development of v2.0.

I'm going to have a further look at your Content Deployment Wizard as I am presenting for our company Readify in Perth in a few weeks on best approaches to this stuff.

Keep up the good work mate! Saving us all hours of pain!

@Matt,

Interesting comments :-)

Yep,...

2008-10-01T00:18:00.000+01:00

@Matt,

Interesting comments :-)

Yep, I probably would say that understanding how different artifacts work together and are best deployed is very useful in the current SharePoint landscape - it just feels unfortunate sometimes that SharePoint projects seem to require this.

In terms of whether using one approach implies more documentation or more dependency on specific deployment knowledge, that's an interesting question. From a personal perspective I'd obviously hope I'm part of the solution and not the problem (;-)), but interestingly a similar situation has come up on my current project where we're using Kivati to help with deployment. It's early days but whilst being very powerful, it does seem to tie you in to a certain vendor-specific knowledge and approach.

I guess like any other area of SharePoint, "the more you know, the more you know", and that can only be a good thing.

On a final note, I do agree Visual Studio will have a greater role in SharePoint packaging/deployment than it does today. I've seen some things, and it's being taken seriously at Microsoft. It still strikes me though, that MS have already implemented much of the code to simplify this situation in the Content Deployment API ("I want that environment to look like that environment"), and the beauty of it is that knowledge of the actual Content Deployment API itself is not required - it does the hard work if you use the Wizard or standard CD.

Cheers,

C.

Really interesting reading Chris, made all the mor...

2008-09-30T23:20:00.000+01:00

Really interesting reading Chris, made all the more so by the fact it's galvanised from so much 'front line' experience. For me, your experience is actually the key factor here –very few SharePoint deployments have access to a Chris O’Brien i.e. someone with enough experience to determine the optimum deployment model for each artefact in the context of the target site(s) and, more essentially, the knowledge and ability to put a complex mix of content and structural deployment into practice and ensure 100% integrity.

Looking ahead from there, once a solution has been delivered how do you hand over to your clients? Does your approach create a higher dependency on you or your company? Does it require more documentation?

The other thing that you touch on in your reply to Tyler’s comments is future iterations of SharePoint. If nothing else, sticking to recommended best practice should ensure the best chances of supported migration of what you are producing now.

Just like you I have often wondered if the time I have taken to develop a feature/solution can really be justified particularly when it has been a site definition for a one-off site. I absolutely believe that Visual Studio will catch up eventually and 90% of this debate will become obsolete but as for how far down the line that will be – it may well be worth skilling up to your level of knowledge with the CD API...

@Finnatic,

Good to hear I'm not alone ;-)
2008-09-30T15:01:00.000+01:00
@Finnatic,

Good to hear I'm not alone ;-)

Interesting comment - I do agree that the data does become more important for scenarios such as disaster recovery, but it should be critical anyway no?

For pieces of data which are key to the running of the site, in my mind the associated .cmp packages should be in source control anyway, since at the time of initially developing the functionality this .cmp would have been deployed alongside the code changes as part of that 'release'. It's certainly true to say, however, that this data will change over time and you may want to restore to the latest version of a certain SharePoint list (but leave everything else intact). The best place to be in for this (IMHO) is to have a good 3rd-party backup tool or DPM 2007 - I'm not an expert on either specifically though.

Something else which might help is that I hope to have scripting (and therefore scheduling) capability integrated into the Wizard soon. This would then provide a free solution to backing up specific lists, so long as the Wizard can be used to import them again. Clearly not a replacement for a fully-featured enterprise backup tool though.

Cheers,

Chris.

Jeremy,

All fair points (also read your pos...

2008-09-30T14:48:00.000+01:00

Jeremy,

All fair points (also read your post), but my thoughts would be:

- agree that tooling is getting better (and will continue to do so), but surely the idea of not having to spend any time whatsoever on Features is fairly compelling?
- to me the Features framework still seems incomplete. I can't update some artifacts by XML once they're deployed, there are still lots of things (e.g. set a property on a web) I can only do in a Feature receiver etc.
- Features to me is all about initial provisioning of artifacts. There is little concept in the platform of how these artifacts might change over their lifecycle. Content Deployment on the other hand, has lots of code to deploy the current state of artifacts on the source over to the target each time - meaning schema changes are 'automatically' applied to the target when you import.

As it goes, I'm currently implementing Features on my current project (since we'll have 100 site collections) but feel it's the right choice for this scenario. We're also trialling a 3rd party tool to help solve the issue of updating artifacts deployed by Features which are in use.

I'll still consider Features on a case-by-case basis in the future, particularly when they'll always be a gap in the effort required to create Features compared to not having to worry about it at all.

Cheers,

C.

Very well said, Chris. My last few projects have ...

2008-09-30T14:22:00.000+01:00

Very well said, Chris. My last few projects have been completed primarily in this fashion, and I owe it in great part to the ease of use and success of your deployment wizard. Thank you so much for taking the time and effort to develop such a great tool.

The one thought I've been struggling with now is that this places much more value on the developer content database, as a great deal more 'source' resides inside it. I'm curious what discoveries/strategies/recommendations you've thought about or used to ensure the safety of this data for both single and multi SPDev teams.

Great post Chris, I've been looking at this from t...

2008-09-30T13:35:00.000+01:00

Great post Chris, I've been looking at this from the other side of the coin trying to push standards across the board rather than having differen approaches for different levels of complexity. I agree that building Features and Solutions isn't the easiest, but in time I think tools will get more sophisticated and take the pain out of it. STSDEV and WSPBuilder have come along way. Anyways check out my posts for more information.

Tyler,

Yes, I'd agree what I'm saying here ...

2008-09-30T10:02:00.000+01:00

Tyler,

Yes, I'd agree what I'm saying here is contrary to a lot of 'accepted wisdom'.

In terms of moving from ASP.Net to SharePoint, I haven't really implemented any projects of this type. I do find myself using SharePoint content for lots of 'configuration'-type items though - my 'Config Store' solution falls into this category. The advantage here is that config can easily be transported between environments via Content Deployment, but I'd be surprised if even SharePoint vNext fully deals with deployment of all possible .Net config/artifacts.

Chris.

Nice post Chris,

It's even slightly provoc...

2008-09-29T19:23:00.000+01:00

Nice post Chris,

It's even slightly provocative given the documentation and tools that encourage you to do feature/solution development. That being said I definitely agree that features/solutions can be difficult and time consuming to develop and maintain.

I wonder if you'd care to weigh in when it comes to getting ASP.NET code into SharePoint. Things like SmartParts also speed development time but are harder to keep in sync across farms (especially if there's web.config keys). When it comes to ASP.NET code do you have a solution/technique that lends itself to content deployment?