This project is read-only.

Controlling Deploy/Redeploy/Upgrade flow with SPSD

Apr 23, 2013 at 6:04 AM
Hi team,

There are good launchscripts with SPDS: Deploy.bat, Redeploy.bat, Retract.bat and Update.bat. However, the logic and flow behind these script are different (also, it could depend on Environment file setting) - it could be upgrading solution with retracting, retracting and redeploy, etc. Finally, it requires human attention and knowledge to select the appropriate script to be run.

So, I wonder how we can implement next case within SPSD:
  • deploy solutions if they aren't on the farm
  • upgrade solutions without retraction if they are already on the farm (assuming we have post deploy scripts to run feature upgrades)
The idea is to have one starting point for people without wondering "which of four files I should run?". Surely, there could be another one "Retraction" script, but deployment could be trimmed from three scripts (deploy/redeploy/update) to one (just deploy).

It seems that a "custom" launchscripts could be a choice. But without "conditions" and ability to rule the deployment flow via "event" is doesn't seem to be a way. Also, we can call SPSD_Main.ps1 directly with cmd params. And again, can't see any potential extensions point to deliver that "smooth" deployment experience without wondering is that a "deploy" or "upgrade". We call that kind of behavior "one-click-deployment", sort of standard in the team.

Also, there is one more complex scenario related to this case - conditional upgrading of *.wsp packages.

As wsp package doesn't have built in versions (I may be so wrong here!), we have done some scripting around that. For every .wsp package via T4 we create a "metadata file" which is just a PS script. It stores the current version of .wsp package which linked to c# dll version (sort of or Next, during the deployment, we assign and store that "meta info" in the SPSolution property bag for every .wsp package we deploy. This way allows us to understand which .wsp packages have to be upgraded and which don't have to be changed during next deployment routines or upgrades.

The reason behind this is try to avoid upgrading current product on the farm to the previous, lower version. For example, we have a product deployment packages: v1, v1.1, v2, v2.2. Every deployment package contains several .wsp files. So, it would be nice to make sure that v1.1 cannot ever be deployed to the farm with solutions v2.2 (or surely just > v 1.1). Just to prevent "downgrade". However, upgrade from v2.2 to v3.0 could require updating only a few .wsp packages. Some of *.wsp packages weren't changed, so no action would be required at all.

This scenario leads us to have an ability of controlling the deployment flow per every solution deployed by SPSD (sort of this I have already mentioned in the prev discussions).

  • would be nice to understand how SPSD could be utilized to address smooth deployment without wondering is that deploy or upgrade (we can handle that via custom PS script attached to SPSD events)
  • would be nice to have more control over deployment flow to allow "optional" skipping of deployment/upgrade per every *.wsp package defined in the Environments files
Apr 23, 2013 at 4:41 PM
That is a big one! I love your feedback!

So lets see if I get it structured for work items (BTW, you can create these yourself if you like, though it doesn't neccesarily guarantee implementation ;-) )

1. ...deploy solutions if they aren't on the farm...
To prevent deployment if the solutions are already there just set the parameters "Force" and "Overwrite" of the <Solutions> or a specific <Solution> (without s) node to false.
"Force" will just pass the -Force parameter to the Add-SPSolution CmdLet so if you set that to false, then this will fail the deployment. Default is true. (no retraction before)
"Overwrite" actually means that even if you just call the Deploy.bat, the solution will be retracted if it is already there. By default is set to true.

2. ...upgrade solutions without retraction if they are already on the farm
That what the Update.bat is for, though that will mean that no files should be added or removed from the WSP (as it is always with the Update-SPSolution CmdLet)

see here
"The Update-SPSolution cmdlet upgrades a deployed SharePoint solution in the farm. Use this cmdlet only if a new solution contains the same set of files and features as the deployed solution. If files and features are different, the solution must be retracted and redeployed by using the Uninstall-SPSolution and Install-SPSolution cmdlets, respectively."

A more automatic behaviour would require SPSD to acutally get the installed solution from the store, compare the files with the new solution and decide if an update is possible or not.
Doable, but I am not sure if this is really such a common scenario, am I right?

3. ...trimming 3/4 scripts to one :-)
Actually I already started that, but more with a "AskMe.bat" approach. That means, I would ask the required parameters from the user and provide sufficient explanatory text so that the user knows better what happens.
This approach actually means one more batch file of course.

4. ...ruling the deployment flow via event...
Still thinking about that one (see #6). Any ideas appreciated

5. One(double)-Click Deployment
As mentioned above that would require some check on the currently deployed solution in order to decide retract/deploy or update.
One idea could be the versioning aspect you mentioned next.
A change in the 3rd or 4th digit compared to the current solution could mean update, everything else retract/deploy.

6. Versioning of WSPs
Your approach sounds great! The only problem about it is, that I think that this might be too complex for many.
I would have following idea which would keep it simple but allows you the flexibility:

I add a new event called ProcessSolution
On each WSP which is processed this event is called and the following information is passed to it:
  • $solutionName = the name of the solution i.e. Company.Intranet.wsp
  • $target = GAC, WebApplication, SiteCollection
  • $url = empty or the urls if webapp or sandboxed solution
  • $action = Deploy, Retract, Update
If the method is not implemented then SPSD proceeds.
If you return $false then the next step is skipped.

That would mean if you run redeploy the event is called twice for each solution for each url.

A future step could be also to be able to change the $action in the event to as you say "control the deployment flow"

Such an imlementation would allow you to build a "plugin" which does exactly what you like. i.e. checking a version in the solutions property bag. Furthermore we could allow to add custom properties (i.e. version) to the solution node which could also be passed to the event. So you can define that in the XML (through T4 or whatever ;-) )

7. Using the SPSD Environment Editor as a launch tool
You suggested that somwhere but I can't find the quote right now, so I write it here.
Starting a deployment from the EE is not intended. The EE is just meant as a helper to edit the rather big XML files. Especially also assuring correct referencing of other files, if you plan to re-use i.e. the configuration node in several environments.

Ususally you configure all of that on your dev machine. The deployment itself might be executed on multiple other farms (staging, other dev envs etc.)
The whole idea of the PS implementation of SPSD (and moving away from MSBuild custom tasks) was to keep it as transparent as possible for the ITPros. If a closed assembly is again invloved, this might not be appreciated by the admins, don't you think.

And then there is actually the reason that in my case we deploy/stage automatically through custom staging workitems in TFS. So no login on the servers by a human is required :) Unfortunately this staging solution is not open source (yet...)

So what do you think? Piece of cake, right? ;-)
I better get started...
Apr 23, 2013 at 4:43 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.