Agreed.
Software Engineering is many times about risk management. Many projects leave
understanding the deployment model of an application until just before it
ships, and then because MSI often isn't well understood and the product wasn't
written to work well with MSI people run into problems that cause the ship date
to fall back because of an installer issue.
If you reverse it, and do the install up front, this allows you to make
updating the installer a development responsibility and include the install in
your integration test suite. Doing an MSI integration test is trivially easy:
just spawn the MSIEXEC.EXE process passing your .msi file and properties w/o a
GUI in the way (msiexec /i x.msi /quiet ADDLOCAL=features MYPROPERTY=1
MYOTHERPROPERTY=2 is what I'm using, I think). Now, if a developer breaks the
install, your automated tests should pick that up and that developer can fix it
long before the ship date.
Re. COM+ etc, I ran into exactly that problem and ended up writing a whole CA
system in MSI to deploy our 20+ COM+ applications at my last job. It took
weeks of effort to write deployment operations for our applications. We
started with .vbs and .zip files, but soon progressed to needing the full
functionality of MSI. It turns out that MSI really is quite simple, as long as
you work within what it does well from the beginning rather than trying to
back-port your existing application to be installed via MSI. We would have
chosen a different software model that would have cost a little more coding
time but a lot less deployment effort time if we had spent the time to
understand the deployment model up front.
The moral of the story is that deployment procedures really are part of the
source code for an application. They are also risky, so implement them first
to minimize risk.
jmr
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Sleightholm
Sent: Tuesday, May 13, 2008 12:51 PM
To: Scott Palmer; WiX Users
Subject: Re: [WiX-users] yep - back to being 100% frustrated
As this was my comment I thought I should respond.
>"I believe you should write the install then the code - if you can't install
>it, don't code it."
>>That's simply not the way it works, and that isn't going to change. I get
>>where you are coming from though... the general installation layout of the
>>product does need to be >>understood sooner rather than later. The reason
>>that the installer isn't "done first" or in parallel with other development
>>is simple - everyone hates it. Getting anyone to do it >>is like pulling
>>teeth. Nobody on the team wants to be the "installer guy", for good reason.
>>(There is also the fact that it is intuitively backwards to write an
>>installer for >>something that doesn't exist yet.)
I like doing installs!
I know it is a bit flippant to say write the install first but in my experience
no one considers the install when choosing the latest and greatest development
code. If they did (and I feel Microsoft is to blame here) they wouldn’t touch a
lot of the technologies. COM+ was never properly supported for installs, moving
up to date some of the WFP stuff is incredibly completed to configure. SQL
server it still not properly scriptable without writing you own code.
I don’t think it is intuitively backwards to write an installer first – my
analogy is – hydrogen powered cars might be a good idea but if you can’t buy
hydrogen or aren’t going to put the infrastructure in place there is no point
building them. I think the same is true of code, make sure you can deploy it
before you write any code. Together we can make it happen ☺
Neil
Neil Sleightholm
X2 Systems Limited
[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
