Does anyone have any strategies/tips/traps for moving to Team System? Should it be done in baby steps, or all at once? Should we migrate our SourceSafe library over, or draw a line in the sand and move forward? Is it worth brining SharePoint into the mix? Any thoughts are appreciated.
I've never had to migrate to TFS, but have used it pretty extensively for the past couple of years.
Regarding your question on Sharepoint, we've found it pretty useful in conjunction with TFS. We use it primarily for documentation management and for storing other "non-technical" artifacts related to the project. Some dev teams advocate keeping documentation in source control alongside source code, which is OK, but in my experience our project stakeholders have an easier time accessing relevent project documentation via the Sharepoint portal than they would having to interface with source control.
I basically was able to distribute the URL to the sharepoint site associated with our TFS team project to the concerned non-technical team members and have been able to avoid constantly e-mailing documents around, so it's been great for us.
It may just be too much work to do it all at once.
I feel that it is easier to divvy out projects to different people one at a time.
That way they can move them across and ensure that each works okay before closing out the SourceSafe.
You will always want a backup of the SourceSafe "database" around just in case.
I do not know how to migrate from SourceSafe to TFS and keep the comments and versions.
By far the easiest it to just add the projects in, but having migrated that way in the past, we always missed the ability to find out what others had done to particular files.
If you find a way to migrate, I would go that way unless it is hideously expensive.
Related
I am starting to do a lot of sharepoint development lately, and some of the things that I have done and I dont like is to use sharepoint designer directly for things like pagelayouts, lists definitions, master pages, etc.
From my point of view I think its more organized to do everything in Visual Studio. In that way you can connect each solution to a source control database and deploy/retract/upgrade easier with scripts.
My idea is to create a vs solution like this:
1. One for list and content type defintions.
2. One for webparts.
3. One for branding
but maybe this approach has any disadvantage, what other approaches are you using?
The real answer is going to be: it depends.
I do not think there is one best way to organize a Visual Studio solution or SharePoint solution packages. In the end, you need to find what works best for your organization and go with that.
The only guidance I have seen is from the SharePoint Online documentation:
If the development team is designing a solution that requires more than 10 WSP files, the team should reconsider its architecture. It is difficult to manage and deploy so many WSP files within a single deployment window, and the solution risks rejection because of the complexity for SharePoint Online of managing it.
A large number of solution packages (WSP files) that need to be tracked and managed pose a challenge for deployment. The more solution packages in a customization, the greater the possibility that something will not be installed correctly, the longer the solution will take to deploy, and the easier it is to mix incompatible versions of solution packages. We recommend that customers scrutinize their deployment plans and keep the number of solution packages to the minimum number needed for the project. Keep in mind that a solution package can contain several features, so there is no necessity to have one solution package for each feature.
And I would agree with this. You seem to be outlining 3 Visual Studio solutions and/or SharePoint solution packages for what really are 3 Features within a single SharePoint solution package.
I tend to create one Visual Studio solution for each project. For a very large project, that single Visual Studio solution might contain several projects where each represents a SharePoint solution package.
For Farm solutions, each SharePoint solution package will contain a number of Features and files that are all related in terms of functionality or application. If two or more SharePoint solution packages share common Features, I will put those shared Features into a separate solution package.
Sandbox solutions tend to be much smaller than Farm solutions. While my Farm solutions usually represent an application, my Sandbox solutions are more focused to solve one particular issue. So my Sandbox solutions usually only contain one Feature that does not rely on other custom Features or solutions.
As I said in the beginning, I do not believe there is one hard or fast rule. It is usually determined by the preferences and style of a particular development team. Try a couple different ways in the beginning and eventually you will find what fits your team best.
I have created a new SharePoint 2007 MOSS Intranet. Our admin people are purchasing backup/restore software and I will eventually have to verify a restore of the farm backup they create. Has anyone got some suggestions on a best practice for this? Ours is a small 2-server farm built with VMWare VMs on SAN. How will I know that the restored version is a duplicate of the original in every way and what should I look out for?
In answer to the remarks:
There's no checklist. The problem is the dynamic nature of SharePoint. Team Sites come and go, as do documents and libraries. Who's to say one of your users didn't delete a document library and then you think after a restore something is missing.
I think the best bet would be to require your users to do a quick scan after a restore, see if they miss anything major, like sites or libraries that are supposed to be there. You yourself could have a "homemade" checklist that you follow to check if all major features deployed by you (features, timerjobs etc.) are still there.
What would make development with SharePoint easier?
A better product.
Right now it is to many things that doesn't behave as a development environment should.
Dispose of objects
Performance of traversing small lists with 3000/4000 items
Lack of support of transactions
Hopefully next version will have the SQLServer based lists where you can have transactional support and better performance......
Bill G raised the question in feb 2008 that it is something strange with Sharepoint that you get problems when you have 3000 items in a list and SQL Server easily supports million of items....
The build and deployment process needs to be simplified. There are numerous tools available to create WSP files, but they are all decent at one thing another, but you ultimately need to extend or rework the solution WSP deployment package for you environment.
Standard HTML and better support for the DOM.
Informative error messages.
While easier debugging and less XML are very tempting (as people suggested), I would settle for something much more modest.
SharePoint usually "swallows" exceptions or other error messages. Very often when a customized page or a web part fails, you get an obscure 'page cannot be displayed' message. With luck, the designer will direct you to the problem, or you might find some details on the logs or the system event viewer. But in many cases you have nothing.
Examples - Business data catalog xml monstrosity that worked on the editor but not on the site, xml web parts that fail randomly, xsl typos or mistakes, etc. All take much longer to find than they should, and some are impossible to debug.
Remote Deployment:
- 1 central Sharepoint, and transparent remote debugging.
Less XML (schema.xml etc).
Making the dev process more like "traditional" asp.net development, in other words making the integration with VS better. You should develop against SharePoint from within VS not from within SharePoint (ie SPD).
SPVisualDev on codeplex has made that process better but I hope (an I say hope) for better support within VS2010 together with SP2010.
Should check out #SPDevWiki's page on this also http://www.sharepointdevwiki.com/pages/viewpage.action?pageId=7340352
Less people trying to abuse the product would make things a lot easier too ;)
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.
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.