One of the biggest challenges that I've encountered with SharePoint is that it doesn't lend itself nicely to the typical project environment, which, at minimum, contain development and production environments. The issues I've run into the most are that content and lists are so tightly coupled that it makes it difficult to perform design changes without performing a content freeze on the production environment. For example, if I have a list with calculated columns and wanted to add some new functionality, I would have to do a content freeze on the production server, create a list template (including content) from the production server, restore that list to the development environment, make my changes, then reverse the list template process. The same holds true for pages and just about anything else in SharePoint. It seems as though once the site is deployed, it's best to work directly on the production box, but that breaks a ton of best practices, for obvious reasons.
How are some of you other SharePoint developers handling this limitation?
There are really two (more?) levels to SharePoint "development". You have the code which gets deployed to the server, such as web parts, content types, workflow actions, etc. This works relatively well in terms of deployment and best practices.
Then you have your example, which is more of a customization of site instances. What we've done when we had to customize a calculated field in the Portal's Site Directory list, is to try and tweak the changes in development. Then write up detailed instructions of the customization to be made, and have a separate person with appropriate permissions use those instructions to make the change on an integration (staging) server. Then have the same person makes the changes live on the production.
I'm not sure if your changes are susceptible to this approach, but it's worth considering.
Then we have another site which is heavily customized with SharePoint designer, and that one we work live on.
You can use Content Deployment Wizard (http://www.codeplex.com/SPDeploymentWizard) to migrate things like lists and libraries quickly. You could also take a backup/restore copy of production, then make your changes on that, and then in the early morning hours, do a content freeze (hopefully no one will care then), import all the changed data from production into your copy, and then restore the copy over production. At least the freeze could be put off and would only be necessary for the duration of the export->import->restore procedure.
In practice, I just make my production changes by hand.
Use FeatureActivation code to deploy changes to the lists' fields. After the code updates the fields then you deactivate the feature and remove it. This allows results to be tested in a QA environment before hand.
Related
How do you handle improvements and added functionality to your existing SharePoint code?
Did you deploy your original code as a feature?
Do you create a new feature_V2 and deactivate the original?
What processes have you found that led to problems in the future?
I am specifically interested about WebParts, EventHandlers, and WorkFlows.
From what I can find, MS did not leave a "Best Practices" around updating existing code. (Actually, I'm not sure they left a "Practice" much less a "Best Practices")
You can see other questions around this topic:
how-to-upgrade-a-long-running-sharepoint-workflow-already-in-production
how-to-update-spitemeventreceiver-assembly-version-for-a-list-in-sharepoint
should-i-keep-solutions-and-features-in-a-1-1-ratio
What is your method?
I understand this question may be subjective, but I feel there is a large information gap surrounding this area of SharePoint development.
Thank you,
Keith
We always deploy custom code as features and solutions. When it is time to upgrade the existing code, all you have to do is stsadm -upgradesolution and everything works very nicely. I do not like the idea of having feature_v2 type features around...it makes it extremely difficult to keep track of the current version. I think you should only have one version of each feature in your production environment.
Leave the version control to your source control system.
I'm working at a shop that does a lot of SharePoint development. You want to deploy by feature with a solution package. You can easily upgrade your features as you go along and you will need to upgrade the solution package. This solution package can be created from a TFS Build server with WSPBuilder. As you along, the only thing left is to upgrade the solution and "Force" reactivate your feature to have the new feature of the feature.
Don't forget to do an IIS reset for any new code deployment that is done through the GAC. If you put anything inside like sitemaps and resources inside your 12, you will want to do a stsadm -o copyappbincontent.
If you deploy features that contain application files, you want to unload your application on ALL servers of the farm. It can easily be done by putting an App_Offline.htm at the root of every application on every machine.
When completed, remove App_Offline.htm (or rename it) and you are done. Your site is back online.
My team is working on a project to migrate a .com site into SharePoint.
After all our look and feel assets, master pages, content types, and page layouts are created, we need to actually "move" the actual site pages into SharePoint.
I'm trying to come up with the most effective way to do this. Our topology consists of an Authoring and a Production environment. We plan to use SharePoint Content Deployment to populate Production from Authoring.
However, we obviously need to do some sort of initial population of the Authoring environment. I don't want to use Content Deployment to populate Authoring from a development environment because I don't want to initially create Authoring from a Blank Site definition.
Here are the options I came up with, would love some feedback on which you think would be the best approach:
Create the site content in a development environment and use a tool such as SPDeploy to migrate it into the Authoring environment
Create the content directly in the Authoring environment
Use a technique similar to how you can provision List Item instances in a feature. We would create and populate all of our content using Features
I'm not sure if this is actually doable, but got the idea because of how I know you can create List Item instances when provisioning a List in a feature. After all, our Pages library is a list of Pages - however there are multiple content types involved.
Thank you for your suggestions!
If it is just a matter of migrating files, you could actually use the content migration framework. The core classes of this framework are the SPExport and SPImport classes in the Microsoft.SharePoint.Deployment namespace. You can with fairly little code export individual files to disk and import them again to a new location. Alternatively, try the SharePoint Content Deployment Wizard on CodePlex here: http://www.codeplex.com/SPDeploymentWizard. It will save you the coding.
Backup and restore the content DB.
Can you clarify on why you don't want to use content deployment to create your initial Authoring site? Why do you not want to start with a blank site definition? It would get overwritten in the deployment process anyway. What about stsadm -export / -import?
I'm sorry, but I'm still not clear on the whole situation. You have a development environment (presumably where structure is created, but not any content destined for production), an authoring environment (which I understand as a locked down environment where content is entered and approved), and then a read-only production environment to which approved items are deployed. If this is the case, then I can say that I have a similar setup on one of my projects.
In my case, I initially developed the site structure in my dev environment, then backed up and restored to authoring and prod. Subsequent structural changes to both environments are made by hand. Authoring is structurally almost exactly the same as prod. Only the security is different. Several times per day content is deployed from authoring to prod. We make content changes directly in the authoring environment.
So, maybe I'm a bit old-school, but when we created websites in the past, we'd develop the site on a development server, then publish or promote the pages and files to the production server. This has always seemed to be a good way to go so that users didn't see messed up pages or (God forbid) a downed server because one of us screwed up.
But it doesn't seem that Microsoft had this idea in mind when they created SharePoint...at least, I haven't been able to find a way to do this in the infrastructure as it's defined.
Does anyone know if there's a management strategy for SharePoint development? I've read online that we can make a backup of the development environment and restore to the production server. That might work the first time, but any updates to the production server can't do that without risking data loss on the production server. I've seen some tools out there for migrating list contents, pages and documents from one server to another--although, admittedly, I've not yet investigated them.
But, another concern of mine is custom content types. It seems that once a list is using a content type, you can't update it without deleting the items from the list, disassociating the content type, and reassociating the content type. Shouldn't there be some way to UPGRADE a content type?
Anyway, if you have any suggestions for any of these current dilemas, I would LOVE to hear from you.
Thanks in advance,
Dan
Thank you for your quick reply.
We already have several features created for our site and a solution package bundling features directed at the fundamentals (content types, columns, etc), and another solution for features having to do with branding (page layouts, master pages, etc.)
But it seems like this is a one-time-shot...basically, it gets our server set up, right? Once people have started using the production environment, we're going to have documents, pages, list items all existing in our content database, and it'll be impossible to update things like content types, columns.
Features you have to deactivate and uninstall before you can install and activate the new feature, right? I've seen a Version property on the feature definition, but as near as I can tell, this doesn't do anything. Solutions seem like they can be upgrade by incrementing the version number, but it doesn't seem to modify things like content types and columns--especially if they're in use. Plus, I'm not sure how extensive the upgrade with solutions is.
There's precious-little documentation out there for this sort of thing. It seems like everything I'm reading is how to get your SharePoint server set up initially...not managing it long term.
Do you have any advice or suggestions?
Thank you all for your suggestions.
But we've been working on this site for over a year now. I'm pretty confident that we're already setup according to what most of you are recommending. We already have several features that install things like content types, columns, master pages, page layouts, and workflows. Most of these features are contained within solution packages. We have all of our development environments set up as VPC servers.
So, I have the initial deployment pretty much set. What I'm REALLY hoping to find out is how I can upgrade things like content types and columns and stuff down the road. Is it possible to change content types once they're in use? Because it doesn't seem, based on my initial testing, that this is possible. I'm not to worried about the assemblies because it looks like they swap out just fine, but the only way I've gotten a content type updated is by deleting any items referencing them (i.e. all the pages in my pages library), removing the content type, then re-adding it.
Do any of you know if there's a way to update a content type AFTER the initial deployment? ...when users have already created items based on the content types we've already deployed?
(The other part of my question was actually moving existing pages from the development server to production, but I can live without that. My major worry is the content types.)
The best way to go is developing with features. Once the features are done, you ca deploy them with Solution package (called WSP).
The only thing left to do is to reactivate those features. That way, you can progressively roll-out new features without having to do everything in production.
WSPBuilder is an application that helps you build WSP.
For automating all of this... good luck. There is a lot of work involved.
UPDATE:
Deploying Content Types and Columns are tricky. Once the website has been created, you can't update them anymore through features. You need to go through the code and recursively go through all the sites and modify the specific content type that match the name.
We've tried and it's not possible to do that normally with features. This need to go through something I call "deploying with code".
You really really need to define your content types using a feature because that way each content type will have a set GUID and will be stored in the database using the same name. This becomes important when running CAML queries over the site and there are a few other little gotchas when content types are created "will nilly" if you will.
I prefer STSDev for rolling out solutions using custom content types.
There are two ways to edit pages on the server. You can define the page library to have major and minor versions. This allows editors to edit the page and a defined publisher to publish them. This is good on an internal site, but is not recommended for a public facing site.
For a public facing site you will need to use Content Deployment
I cannot stress enough that before going ahead with a production release you make sure you have features for the content types.
As mentioned here, Chris O'Brian has a post saying that you should not use features unless necessary. One of his reasons is that it slows developement.
I disagree with this. Developement is slower if you are unfamiliar with features, but once a level of knowledge is reached, it is not a major factor.
Do listen to him about the backup and restore method of moving the content.
If you do that, all mess in the content types and fields and webs you may have created during developement (for me that is always quite a bit) will be moved to your production site.
Instead of having a nice clean site where everything is consistent, you will end up with little bugs and some areas of the site behaving differently to others simply because of old development cruft.
I recommend taking a look at Chris O'Briens most recent post, and his great Content Deployment Wizard: it's not all about Features!
Maxim is right in that most items should be deployed via features that are wrapped in solutions (WSP files). Your strategy should be to make sure your solutions and assemblies are broken into related bits of functionality. This is also beneficial in that features can be isolated at certain levels like sites and webs. Feature activation code, deactivation code and feature stapling should be used when updating any content updates. Content deployment can also make sense.
Once thing to remember is that if the updates are only in code then the assemblies can be updated without requiring the feature to be reactivated or the solution retracted and redeployed. All that is required is the Application Pool to be reset.
Microsoft has a couple articles on Dev environments and you can Google many others who recommend environments. We do development on virtual machines and deploy most items to an virtual integration server. Once we smoke test it we then deploy our solutions to QA so on and so forth. The benefit i sthat features and solutions are easy to retract. Once it goes out to production it should be thouroughly tested.
Developing in SharePoint has it's issues, that goes without saying, but so far I have found that the benefits outweight the problems.
Team-Based Development in Microsoft Office SharePoint Server 2007
We developed a custom solution which would update content types and fields for a Site Collection. Underneath the covers, through code, SharePoint allows us to modify the Fields as well as values in the Fields and Site/List Content types.
For moving the actual content from QA to Prod we use Echo
I am total beginner in SharePoint and I need some help in starting a project. I have to develop publishing site that will be delivered to the client. I would like to give client deployment experience like he would get when deploying standard ASP.NET application as much as possible. I plan to use Visual Studio 2008 with SharePoint extensions and maybe WSPBuilder or some other tools.
I also need help in structuring whole project.
Here is what I plan to do:
1. Develop minimal site definition
2. Create site from this defionition. How should I do this from code ? Use SharePoint Feature ? How should I activate it ?
3. Develop all the needed infrastructure for the site (master page, layouts, content types, ...) as SharePoint Features.
Is this correct and how should I develop all those parts so I can make a some kind install script so can client create get complete site with one click ?
Site definitions are complex no question about it, but they are very useful if you need to deploy to unrelated enviornments. If you are staying on the same server farm, maybe site definition is overkill. If you are going between domains (i.e. test & prod, then maybe they are worth looking into).
Another advantage to site definitions, esp. if delivering to a client is it feels more like a traditional deliverable. They will have a bunch of files (hopefully in source control) that are their custom site. I think that gives IT dept's a much warmer feeling than an XML file created from the SharePoint UI.
Another benefit of site definitions are you have a lot more control over the pages that make up the site. IMHO its easier to add master pages & custom CSS via site defintion that site template.
I am curious as to what are the 'moving parts' to the site you are trying to deliver? I think that answering that question will determine how to define the project's structure.
Generally, I think you are on the right track. Features and solutions are a must. I would stay away from VSeWSS, its buggy and clunky and generally terrible if you are trying to do anything complex. It tries to be so smart, that it leaves you no control.
That said, it really depends on what you are trying to do. If you are going to build a solution to deploy to the GAC with one assembly, and only building features supported by vsewss you may be fine.
If however, you want to develop, say a timer job wiring that into the VSeWSS feature framework gets tough. Also, if you need multiple assemblies in the solution. YMMV, but I had to junk it and find of a more flexible solution (hello NANT).
A lot of the work you will end up doing is building and checking, and re-checking XML configuration files. Bookmark the Feature Schema reference page on MSDN, you will be spending a lot of time going through it.
Finally, yes, if you have all of the parts packaged as features you should be able to develop a nice install script. Ultimately the script will need to call the STSADM (there are some really nice STSADM extensions here) commands necessary to create the site structure, add & deploy the solution & activate the features. You can start with a batch file, and get as complicated as you want.
Personally I don't find that creating a site definition is really that useful for the sites I have built. They can be very tricky to set up, because of their complex nature.
What I do is use the standard Publishing Site and then using features to add my additional componets (deployed via a SharePoint solution).
You can use Feature Stapling to connect up the feature to the Publishing Site creation.
I've also just done a blog post on how to programmatically modify the workflow which is created by default: http://www.aaron-powell.com/blog/february-2009/programmatically-modifying-sharepoint-workflows.aspx (that also has a link in the comments off to the Feature Stapling concept).
Then I use a combination of SharePoint Solution Installer (http://www.codeplex.com/sharepointinstaller) and batch files to install the components. SSI for all the SharePoint database level installs and batch files for the file system stuff.
Adding another answer, because I have more than 300 characters worth of stuff to say :(
RE: SharePoint solutions generator, again I would say your mileage may vary.
The biggest issue with SharePoint dev is managing all of the "magic strings" across the various configuration files. GUIDs and Fully Qualified Assembly names are the spit and glue that hold the whole thing together, and although it all makes sense its very difficult to manage.
The current crop of tool all try and alleviate the complexity of managing these things, but they require that you work in a certain way, so the tool knows how to inject the appropriate plumbing.
If you plan on doing a lot of work with SharePoint it really behooves you too learn to manage the plumbing yourself. Its painful up front, but really pays dividends.
Basically, I suggest you spend your time learning the platform and not the tools. Once you know the platform, using the tools will be much easier.
If you are doing this as a one-off engagement and just want to get it done, I'm sure you can get any of the tools you've mentioned to do the trick.
I would agree with the use of the out of the box publishing site definition, and then customizing it using Site Collection features (Master Page, Page Layouts, CSS) and site features (create lists, pages, sub sites, defining master pages of sites, etc...).
Feature stapling is great when you want to customize new sites (allow user to create new sites) of well known site templates, like customize the "My Site" look and feel. In this case I don’t think its very useful.
As a tool to help this task, I personally use STSDEV (http://www.codeplex.com/stsdev) to help in creating, programming, debugging and deploying my Sharepoint solutions.
First it creates a good project for Visual Studio (clean, or with some nice "starting point" definitions). Then it includes some “build configurations” that really helps with install, deploy and upgrade in the development machine.
What is the general feeling amongst developers regarding the changing of files in the 12 hive.
For example if you were asked to remove the sign is a different user menu item, you would need to modify the relevent user control on the filesystem. Now if you just go and modify it via notepad or copy over and then if you go and bring a new server into the farm you will need to remember to do the same on the new server.
Obvouisly you could deploy the changed file as a solution and have that done automatically, but I'm just wondering if people are hesitant to make changes to the default installed files?
I have done a bit of SharePoint development, and I must tell you that messing with the 12-hive is a ticket to a world of pain if you ever want to move the app.
I'd rather hack up some javascript to hide it, at least that can be bound to the master page, which is much more portable.
And remember, you never know when the next service pack comes around and nukes your changes :)
I agree with Lars. Sometimes you will not be able to avoid it, depending on your needs. But, in general the best policy is to avoid modification if at all possible.
I know that some of the other menu items in the current user menu (change login, my settings, etc) can be changed by removing permissions from the user. Under Users and Groups there is an option for permissions. I can't remember the exact setting (develop at work, not at home), but there are reasonable descriptions next to each of the 30+ permissions. Remove it and you start hiding menu options. No modifications to the 12-hive needed.
There is a very simple rule: if you want to keep official support from Microsoft, don't change any of the files in the 12 hive that are installed by SharePoint.
I've never encountered a situation where the only solution was to change such a file. For example if you want to change an out-of-the-box user control of SharePoint, you can do so by making use of the DelegateControl, and overriding it in a feature.
More info:
http://msdn.microsoft.com/en-us/library/ms463169.aspx
http://www.devx.com/enterprise/Article/36628
I know it's tempting to quickly change a file, and I have to admit sometimes I just do that on a DEV box, but don't go there on a production server!
Not sure if there is much use pitching in, as everyone else pretty much has it covered, but I would also say don't do it. As tempting as it is, its just impossible to know the full impact of that little change you have made.
From a support perspective you will make it difficult for Microsoft support (patches/hotfixes).
From a maintenance perspective you are also opening yourself up to long term costs.
Go the javascript route.
The way to go about it is to use a Sharepoint Solution (WSP) file.
To change the user control, create a new Sharepoint feature with the new functionality.
Include this feature in your solution.
Deploy the solution either using the stsadm command line, or through Central Site Admin.
This will then get automatically deployed to all the servers in your farm, and it avoids you overwriting anything default sharepoint files.
For more info, check out Sharepoint Nuts and Bolts blog on http://www.sharepointnutsandbolts.com/ which give an introduction to WSP and Sharepoint Features.
I've done this many times and I will speak from experience: Never ever touch the onet.xml files within the 12 hive under any circumstance. Any error that you make in there, and to make the CAML even more complex the file is largely whitespace sensitive, will have an impact on every part of SharePoint.
You should also consider that aside from the substantial risk to the installation, you may well be building in dependencies upon your changes that are then over-written in a future patch or service pack.
Most of the time, you can accomplish everything you want to using features and solution packages without modifying the files. However, there are a few (rather annoying) rare cases where your only option would be to modify a file on the system. I have used it for two particular cases so far. One was to add the PDF iFilter to the docicon.xml file, and the other was to add a theme to the themes.xml file. In both cases, it seemed to be the only way to achieve the goal. Still, we used a solution package to write those files out to all the servers in the farm.