Before I dive deeper into the using SPSD, let let me make a point that the concepts discussed here are primarily used on Server Side full trust code on SharePoint Platform. Theoretically, similar concepts can be applied to any Development Model but SPSD is not meant for that, as far as I can tell.
All seasoned SP Developers have one way or another to deploy custom WSP solutions. Very popular approach is to use a tool or script to deploy all WSPs put in a specific folder and he script/tool would uninstall existing WSPs or upgrade existing WSPs with new one. Initially, I downloaded SPSD for the same purpose but soon realized that deploying WSPs is just a fraction of functionality of SPSD and that it supports PowerShell based extensions which can be executed before and after WSP deployments. Basically, all my creative antennas got activated and I was immediately convinced that this thing is powerful!
In this article, I will throw the ideas that makes it a very appealing tool. This blog is not to learn to use SPSD, for that please refer to the Documentation tab of SPSD tool. Even after watching the presentation, it took be few more hours before I could fully grasp the functionality and start writing my own extension.
So at this point, I assume you are already familiar with SPSD or you have referred the documentation of it. I will begin with some useful tips and ideas here.
Idea # 1 – Automate .. Automate .. Automate
While I am a huge fan of automation, I don’t put extra ordinary efforts to achieve that. SPSD is a perfect balance and I think once you put efforts in SPSD automation, you can reuse them over and over again in other projects (again, don’t forget that we are talking about Server Side Development).
In one of my project, I used this tool towards the end of the project to deploy to QA/STAGE/PROD environments. For each target environment, I knew the server name so I created SERVERNAME.XML file under the SPSD Environments Directory and all environment specific variables were defined in the XML file.
The entire SPSD folder was added to source control and entire folder was given to Administrators and they were instructed to run deploy.bat and follow on-screen instructions.
WSPs must have been copied to Solutions directory, before the build was prepared. You can automate this using MSBuild if you want to get fancier but for my purpose, I write a simple .bat file and dropped it into SPSD’s solutions directory, and right before the build, I would run it to copy all my WSPs in that folder.
xcopy/y "..\..\lib\*.wsp" "."
I wrote quite a few custom extensions and was able to cut down initial build installation from 2.5 hours (of manual and automated combination) to 10 minutes (with nearly 99% automation via SPSD).
Idea # 2 – Use it from Day 1 in Development and integration
Building upon my previous experience, I thought of using SPSD from day – even in the development environment and no wonder, it was promising and successful experiment.
This time, on a separate project, I set it up such that a developer can get started with creating site collection, deploying wsps, activating features, creating term sets, building search schema and so on right from deploy.bat. So in this kind of setup, follow this guidelines:
1. Setup Regular SharePoint Projects (with WSP output) – Use this to deploy standard SharePoint artifacts such as Site Columns, Content Types, Page Layouts, Master Pages, Lists etc.
2. Add SPSD files to Source control and write scripts for things such as: create site collection (dev only), activate feature, create term sets, extend user profiles properties, search schema, configure permissions, Create SP Groups, create test or real content so on and so forth. Well, you got it – things that are one time in nature or things that can be overridden by users should go here.
Now, working in a team always a challenge in custom SharePoint projects, so tool like SPSD can help a lot. Every day morning, or sometime several times in a day I would run deploy.bat and delete my site collection, create new one, deploy latest WSPs, activate features etc. – so I know that our code is 100% integrated – if there are any issues they will be caught as part of this process. I even created which creates publishing pages and provision web parts on the pages so I don’t have to worry about losing the momentum by recreating my development site collection every day.
Well, only this process gave me 100% confidence (I know this is a very string statement – but I really mean it) that when we are deployed to QA/PROD, things are **just** going to work. I don’t like surprises.
Tip – Create extensions.. and a lot of extensions
Writing an SPSD extension is one time investment but you can rip the benefits for many many months to come, I can guarantee that. SPSD comes with some extensions, test them well before using them. I had bad experience with an extension that creates crawled and managed properties. It did not work as I expected so I modified it – don’t hesitate to do that.
I may post several extensions that I wrote in a separate blog posts. But below are a few examples:
1. Create Term Groups and Term Sets
2. Search Schema
3. Create Publishing Pages and provision web parts
4. Activate Features
5. Create SP Groups and Put people in it
If have client/project specific things, you can just throw in a one time extensions with some hard coded values and scripts – like I say I like to strike a balance and not go too crazy if I don’t expect to reuse it. For instance, creating a project specific folder structure in document library or setting up versioning settings in project specific lists and libraries.
Tip – Ask Permissions
Before my extension is executed, my extension supports showing message to the user – describing what will happen next (any warning in yellow color) and ask the user to specify y/n – if answer is y only then the extension would execute. Of course, whether to prompt or not is also configurable in extension input. But this proved very handy during development when I can skip certain extensions that don’t truly belong to my own development effort. This is also handy for SP Administrators because they know what exactly will happen next when they say ‘y’ against the prompt. So installation becomes interactive and informative for administrators and developers.
Idea # 3 – think outside the box
I don’t believe SPSD provides a way to do versioning. So every time you run deploy.bat –everything specified in XML file is executed. Now this may not fit well into overall Application Life Cycle Management where v1 of application is deployed using SPSD but now you want to implement v1.1 of it. Well, with SPSD you can comment out the original extensions and just keep the v1.1 related extensions. I find this very inconvenient, ideally I would like it to be smart enough to bring me to v1.1 no matter if I start from beginning or from v1.0.
So what can we do about it? Feel free to leave your comments. I have some ideas about it but have not implemented it yet, if I do – expect another blog post for sure.
No comments:
Post a Comment