Finance

Nov 3 2017

Deployment made simple using Powershell #simple #powershell #script


#

I’ve been using and extending NAnt for 4 years. It has some really nice things and I’ve done some amazing things with it. However, my current strategy is to leave it. – It’s just converting all my existing stuff that will make it painful and slow.

We plan to us MSBuild for Build Control and PowerShell for Deployment. Currently we use NAnt for both of these things.

The worst thing about NAnt and MSBuild is it’s XML. The semantics of the language are limited by XML. XSLT is powerful but painful for the same reason. Neither language supports IF, THEN, ELSE because of the constraints of XML. The most glaring problem with these languages is the lack of Parametrized control. A “Target” has expected input that must be passed by convention, no declaration control, and properties are all “Global”. Even parameters used in a small snippet are Global. Hopefully you can see the ramifications of this without me spelling it out.

While NAnt and MSBuild are both extensible, it can be awkward to Extend in a way providing backwards compatibility (see comments on parameters) if you are trying to build a library of scripts. It’s VERY easy to break dependent scripts.

With this said, MSBuild still has a future with us. If you want to make build processes that execute with Team Build AND when a developer presses F5, MSBuild is what will facilitate it. In short, it the best way to extend Visual Studio for the foreseeable future.

I still have a temptation to use MSBuild for deployments for this simple advantage – it’s part of the Framework starting in 2.0. If a machine has 2.0+ installed, it has the core MSBuild language. This gives you flexibility of pushing scripts to a target server and executing them remotely. Nonetheless, PS is so much more powerful when it comes to working with OS components and it will become standard on the OS, it’s just a matter of time before you’ll be able to count on availability.

Powershell not only provides Parametrized Procedures but is embraces OO with a vengeance. It naively can work will all .Net Classes, but also ADO, WMI, and COM! You don’t have to dance through hoops to get full access to these. If you need to utilize .NET objects, you don’t have to write rapper Tasks like you would in NAnt and MSBuild. You may want isolate the access in scripts and Cmdlets, but it’s not required.

With all that said, Powershell is “scripting”. You don’t get strong typing that comes from a compiled language because these things are resolved at run time. It works really hard to make sense of Types but that leaves it resolution at Run Time. Also, PowerShell has new syntax and parsing rules you’ll have to learn. It won’t be painless to learn and master but it has so much power it will be worth it.

— modified at 13:39 Thursday 7th June, 2007


Written by admin


Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: