Design your Application to Fit Your Shipping Container
This post has moved here.
Comments
Anonymous
May 22, 2008
PingBack from http://www.doctordeploy.com/blog/uncategorized/design-your-application-to-fit-your-shipping-container.htmlAnonymous
May 23, 2008
The comment has been removedAnonymous
May 25, 2008
DDD sounds good to me. I've thought about that as well. I would call it Deployment Driven Development to make it mesh with TDD (Test Driven Development). It would also make sense to plug it right in to TDD where your unit tests run only on an application that is deployed and not on the binaries in the bin folder.Anonymous
May 27, 2008
The comment has been removedAnonymous
May 30, 2008
"But by the time they call me, that's what needs to be done." but isn't that the point, we need to encourage this to be discussed up front. I know it is a hard struggle but by trying may be it will start to get through. I even think it should happen before developers get involved, the product design should be thinking about deployment.Anonymous
May 30, 2008
The comment has been removedAnonymous
June 04, 2008
The comment has been removedAnonymous
June 04, 2008
Ah, and in comes App Virtualization. I dont want to change the subject of this post but I should start another post about App Virt.Anonymous
June 04, 2008
Hehehe, change away! I was in Chicago a year ago meeting with InstallShield and one of their people gave a presentation on AppVirt to a roomful of ISV types. They asked for questions and my reaction was something along the lines of: "If we all write and package properly behaving applications per logo guidelines, why would we as ISV's need this? I can understand Corp Repackager types seeing this as less risk, but will we really expect to see demand from our customers for this format?" In a sense, at worst, AppVirt seems to me like a big collective admission of failure at making our cars fit on the truck. At best, it seems like a way of solving our integration problems without all of the complexity of setup ( but trading for other complexities no doubt. )Anonymous
June 04, 2008
I guess its too late now :) I agree with what you said to InstallShield. AppVirt up until now is all about the repackagers. In order to get it to work without producing an initial setup to repackage, you need a declarative install that will work on all your customers machines regardless of their machine state. If you get to the point where your deployment is declarative, Windows Installer does a fine job of laying files and reg keys down on a machine. You kind of brought the conversation full circle. Maybe application virtualization is the buzz term that people want to say their app can do. In order to play well, they have to consider it as part of thier initial design such that deployment is declarative. It drives the deployment discussion upstream such that they design their app to fit their shipping container. In this case the shipping container is [Put your virtualization solution here].Anonymous
June 10, 2008
The comment has been removedAnonymous
July 31, 2008
I agree with the sentiment. It seems common for developers to (almost arbitrarily) leave something aside under the heading "oh, the install will do that" whether it's appropriate or not. By the time people start building the install they don't want to go back and reconsider because, after all, they're finished with all that. A list of these things would be too long, but it includes writing registry entries to all the user profiles on the system, being sloppy with file versions, wanting uninstall shortcuts in the Start Programs menu, wanting to disable MSI repair, blocking the install for transient reasons (removeable software like service packs, removeable hardware), services that don't stay shut down and cause reboots during updates (and describing it as an install problem). The MSI framework really is a framework, and the better you fit into it the more reliable your installs will be.Anonymous
October 07, 2008
While I agree with your principle, I see WiX as going too far in the opposite direction. I currently build an installer for an open source product that I don't control the source of. I've put in a lot of work to make sure that I COULD build the entire installer declaratively. But now I'm stuck in the position that I can't use Wix, because Wix expects me to have installer fragments integrated into the source version. So while application developers can be attracted to the idea that custom stores are so important that the installer has to support them, WiX seems to be attracted to the idea that declarative installer build files are so important that automated installer generation becomes close to impossible...Anonymous
October 08, 2008
Christopher Painter makes a very compelling point. I've worked in this field for 12 years, and I've seen things become more and more complicated as things move along. The installation is arguably an equally important part of the process - What do customers see first? The product or the installation thereof? It's the installation. If that goes smoothly, and the uninstallation is just as smooth, it already gives a good impression. Install developers (setup/deployment engineers/developers - pick your favourite job title) are often brought in in the middle of the development process when functional specifications have been written up and require change control for amendments, where things are simply assumed (as pointed out by other commenters - "oh the installer will do that" - really? That's news to me) and the process falls apart because no-one bothered to speak to those who know deployment best. That said, my pet peeves are things like having to write code to create users and shares, and modify XML (not just read it), and the setup engine could have provided that. Why didn't it? It is irrelevant which tool you use (Wix, Wise, InstallShield, Orca - All irrelevant) because all of them have try to make sense of the more and more complex requirements foisted on those using them. Perhaps it is a return to simplicity, perhaps it's up to the biggest vendors to lead the way (ahem Microsoft ahem).Anonymous
October 08, 2008
The basic premise of this post seems to be the lack of developer awareness during the design and/or development process of the need to reduce the cost of deployment. Minimising installation complexity makes perfect common sense and something that is not a new requirement, rather one that existed since the early days of Windows. Whilst the concept sounds easy enough, putting it into practice is far from plain sailing. If all that were required of modern complex applications were to copy files, create registry data and the odd shortcut here and there, application deployment would a piece of cake. Unfortunately software has developed beyond the point of no return, requiring infinitely more complex systems than ever before. Sure there are some aspects of installation that could be simplified, for example reduced cross application dependency and the increased use of side-by-side private assemblies, all with aim of producing, to a degree, an isolated application. Will any of this happen? Ha!