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)
"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...