Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

I have a fairly simple SharePoint web application, with a publishing front end, an extranet for customers and an intranet portal.

I want this web app to be easily redeployable -- pretty much a one-off automated process.

All my custom code is packaged up as features, where each feature is a project in a Visual Studio solution.

I have a number of Powershell scripts which take care of the full install of this web application. So the scripts will build the .wsp files, create the web application, create site collections, create sites, install all the solutions with stsadm, populate the publishing pages with initial data, set up navigation, set up anonymous access, setup zones, edit web.config etc. I've tried to make it so everything is automated, no Central Admin required.

The scripts are starting to sprawl a bit now so I'm wondering if Powershell is a good idea for this kind of web application building/installation. Is it a good solution? Are there alternatives? Maybe everything could be moved into a single SharePoint solution that deploy the entire application? Maybe other build systems like NAnt could be used? What are some good practices here?

share|improve this question
    
This post touches on this question: blogs.msdn.com/b/ekraus/archive/2009/01/27/… –  ngm Mar 1 '11 at 13:22
add comment

2 Answers

This sounds like a good solution to me. You could put it in a single SharePoint solution but honestly I like your approach. Are you accounting for updates or only fresh installs? Also do you handle rolling back the deployment if one of the deployment steps fails?

The only thing I noticed that you may want to change is to make the load initial data optional based on a command line switch. The reason I say that is because (depending on the nature of the data) if you are doing disaster recovery you will want to load data from a backup instead. Having everything in one script like you do makes DR less painful too.

share|improve this answer
add comment

I'm doing a similar thing in MOSS, and I'm trying to use PowerShell as little possible - for the simple reason being that I believe (for MOSS2007) command line windows batch scripts (for stsadm) are more terse than powershell (as a coder I go for brevity every time).

My script runs in two stages actually - one goes around and collects WSPs, and separate install scripts (which call stsadm) into a temporary folder, and dynamically generates another script (install_everything.bat) which calls the aforemented install scripts (the ones that call stsadm), and creates service accounts (using dsadd), site collections (using stsadm), publishes & sets up custom web services that I have (using AppCmd), etc. All with not a single iota of powershell.

I fully plan to do everything in PowerShell when I'm on SP2010 projects however, as stsadm is deprecated in 2010.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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