The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Internal deployment

I have application that we developed to use internally and also ship to customers.
Engineers in house use this application for development of  hardware.
I am one of those that like to internally release software often this way it will get tested internally before it is released to the customers.
The way I have done this in the past was, I would put it on a network drive and send email notifying people that new version is available. The problem is not everybody upgrades.

Question is:
1.) How to deploy in house application internally and make sure people have latest application installed?

2.) How do you deploy in house written applications internally?
norbi Send private email
Monday, March 03, 2008
 
 
i've used "launcher" programs to do this in the past.

this is just a small program whose job it is to launch the real executable. before it launches the main program, have it check your network for a newer version. it its found, update the .exe, then shell to it.

or something like that.

-don
Don Dickinson Send private email
Monday, March 03, 2008
 
 
+1 for the launcher idea.

We did this with the launcher based on the version number.  A  major version required the setup program to run again.  Minor versions just copied the new EXE down.

But that was a pretty controlled app, strictly in-house.  But something similar could work.. even just using a config file.  No point in rerunning a setup that could be slow, if all you have to do is copy the main EXE down and that's it.
Eric D. Burdo Send private email
Monday, March 03, 2008
 
 
You can run the program from a shared network drive.

There's a flag in Visual Studio somewhere that i believe you should click in this case. It's called something like "Run from CD-ROM". (It directs Windows to load the image into memory and use that, rather than the file on disk, as the backing for the CPU-visible image.) This prevents the file being locked when people are using it.

Disclaimer: it wasn't me that did this, and it was a while ago I saw this done, so pinch of salt and all that. Mostly worked fine though, as I recall: you simply "upgraded" by restarting the program. Explorer would however get in a bit of a tiff at times if the server was down, and you had to have access to the network to run the program of course... so whether it's suitable for your particular situation I couldn't say.
Tom_
Monday, March 03, 2008
 
 
Consider:

http://www.windowsnetworking.com/articles_tutorials/Group-Policy-Deploy-Applications.html

There are things like SMS and 3rd party offerings as well.

These assume Windows of course.
Codger
Monday, March 03, 2008
 
 
If it's a .NET application, you could use clickonce
Ruatara P Send private email
Monday, March 03, 2008
 
 
Thank you to all that responded.
I will research what Codger presented. This seems like most transparently way of doing it. Meaning production code is the same as in house. I will also look into "launcher" idea and see what option fits best for us.
Thanks.
norbi Send private email
Tuesday, March 04, 2008
 
 
You've hit a nerve here.  I'll come right out and say it: you sound like a bunch of windows guys.  That's not intended as a compliment.

I am speaking here from the point of view of the recipient of your code. I *hate* being forced to upgrade; and the one thing I hate even more, is having an upgrade done to me behind my back.  The suggestions here, like much windows programmer philosophy, take the attitude that the programmer knows best, screw the user.  One day he clicks and gets rev x, next day he gets rev x+1.

Having inhouse testing is great.  The way to get people to pick up your new code is to frigging *communicate*.  Let them know why they should do so (bug fixes, enhancements, whatever), then let them decide when and how to pick it up.  If it's any good, they will.

Will
Will Dowling
Tuesday, March 04, 2008
 
 
all due respect, will, he is talking about an in-house application. one that might have bad consequences if run when out of date. perhaps there are data structure changes that require a new version of the app in order to run. the old version might well crash. who knows? (certainly the ts does:) ). in-house apps are a completely different animal than apps with "real customers". in-house apps are more likely to evolve to meet current business needs. with some in-house apps, business may dictate an "instant" change. one that requires immediate updates. certainly your points are not lost on those that ship software to customers, but probably not applicable to this thread.

-don
Don Dickinson Send private email
Tuesday, March 04, 2008
 
 
Will Relax..

It is a Windows application and as I said it is for IN_HOUSE use and testing.
I would never force end user to upgrade.
Main reason I need people to upgrade is to help me test the code before outside customers get it. We are a small company and any additional set of eyes helps.

As far as communication. I have done it and it does not work. People put if off, forget, busy doing something else etc.
norbi Send private email
Tuesday, March 04, 2008
 
 
Actually, Don, I know that the topic is "inhouse deployment" but I don't see a relevant difference from external deployment wrt the point I was making. You suggest running the current version "might have bad consequences if run when out of date. perhaps there are data structure changes that require a new version of the app in order to run. the old version might well crash."  Well then, why not just let the affected users know that.  Again, from the point of view of the consumer, I think if I am told the app I am using "might well crash" I have enough information to decide whether to upgrade.

I am arguing that a pull model of software distribution is better than a push; and that holds whether it's a 10M LOC commercial app, or a 100 line utility script written by the guy in the next cube.  Two reasons it is better are 1) it lets the consumer decide when to do the upgrade, 2) and it allows the consumer to factor in the relative likelihood that the fix might be worse than the problem when making the decision to upgrade.  Broadly, it treats the consumer with respect.  The push model does not.

Will
Will Dowling
Tuesday, March 04, 2008
 
 
OK norbi, I see a little more where you are coming from.  If your inhouse users are aware that the thing might change under them, and they build that expectation into their use of your app, then fine.  I was thinking more in terms of an app that someone might be depending on for their work. In my own context I also want as many people as possible inhouse to use my code before I deploy outside. So I know that desire. But I also know that any change I introduce has the possibility of messing them up (I don't write bugless code).  Thus my preference for communication ("Here are the things that changed and why you should pick the new rev:...") over the push model of deployment.

I'm sorry the communication thing hasn't worked for you.

Will
Will Dowling
Tuesday, March 04, 2008
 
 
I maintain an in-house app.  I am off-site, so I do not deploy it these days, but I used to work on-site.

The app shortcut does not start the app but rather a loader.  The loader checks the iteration on the local machine against the iteration on the network.  If the there is a newer iteration, it replaces the local iteration.  Update or not, the app is then started.

My app takes only a few seconds to update.

There are a few other details (mainly related to table changes), but those are handled by whoever releases the iteration to use.

Sincerely,

Gene Wirchenko
Gene Wirchenko Send private email
Tuesday, March 04, 2008
 
 
A pull-update would be preferable for customers. A push is often used to ensure employees use the latest version.

Employees aren't paid to compare versions, some of them aren't even qualified to make such a decision. If you want to test your dogfood, then push it onto their plate.

You want them to test the *latest* version, not the beta from two years ago. So, you push the software, instead of bothering them with the question if they want to upgrade or not. It's not a home-computer were they can choose what they want to install - the machine, it's software and the configuration are the property of the company. People are getting *paid* to use the latest version.

Most carpenters don't get to choose their nails..

..and yes, I use Windows. Not because it's so awesome, but simply because most of my clients run it. I'm diving into the same crap as they are, and the OS gets on my nerves just as it does with my customers.

OT: ClickOnce is sweet, once configured, but I still prefer the standalone launcher. Shouldn't be too hard to write :)
Eddy Vluggen Send private email
Tuesday, March 04, 2008
 
 
beating a dead horse, but, will ... it all depends on scope and responsibility. some apps i use the launcher technique are updated frequently. the only changes are adjustments to reports and new features requested by users. tested by me and the requester. pushing out the software automatically saves me time, money, and hassle. it is 100% the right approach regardless of my operating system affinity (which is 30% unix, 10% bsd, and 60% windows btw). the software i write for others is almost never pushed out automatically ... in fact, i can think of only one "out-of-house" application i use this technique with and that app is an automated process users don't interact with.

before you go insulting people (your quote: "you sound like a bunch of windows guys and that's not a compliment") it might be better to figure out if you're right in your assumptions (you were not). insulting people trying to help someone with a legit question "hits a nerve" with me:(

-don
Don Dickinson Send private email
Tuesday, March 04, 2008
 
 
beating a dead horse some more.
Yes people are quick to jump to conclusions.
I have spend last 5 years doing 100% Linux development witting code for automation machinery and I did use a script to upload the latest software to the robotic machines from a server. Also as much as I hate bumper stickers my car proudly displays Linux bumper sticker.
Now I am doing Windows development for a job that is life. Windows way of doing things is kind of new to me so I was looking for suggestions.
I was going to ramble on, but in fear of starting some religious war I will stop.

Thanks to all that responded.
norbi Send private email
Wednesday, March 05, 2008
 
 
Will Dowling: "I don't see a relevant difference from external deployment wrt the point I was making. You suggest running the current version "might have bad consequences if run when out of date. perhaps there are data structure changes that require a new version of the app in order to run. the old version might well crash."  Well then, why not just let the affected users know that.  Again, from the point of view of the consumer, I think if I am told the app I am using "might well crash" I have enough information to decide whether to upgrade."

Nothing personal, but this is absolutely wrong when you're talking about deploying updates *internally*.

In my "day job", most of my users are all data entry clerks who spend all day entering things like medical claims or client applications. They have no idea what I've fixed in the code, or what new functionality I've implemented, or what's changed to meet the latest Federal or State requirements. The single manager who asked for the new functionality in their applicable section of the app would know, and would be the one to make the decision regarding when their staff would see the change.

Unless you can explain to me how that data entry clerk, whose day consists of keying "4456729123", "01209019", "01/15/2008", "1610", "123.45", <Enter> to create a new claim line, "02938576", "01/18/2008", "2870", "234.53", <Ctrl+Enter> to start a new claim for a different patient, <next patient's ID>, <next provider ID>, <next date of service>, <next ICD9 code>, <next amount billed>, is more qualified than I am (or their supervisor is) to decide when they should update our internal software, you're simply wrong.

If you want to argue that you, presumably a developer working in that capacity, should decide about internally-used stuff, again you're wrong. If it's part of the technology used for internal functionality, and it's software used by other than the developer who wrote it, it's not your choice. It's the choice of the person responsible for that software, or for system software (OS, AV,etc.) it's the person responsible for the infrastructure.

Now, for commercially distributed software, I'd agree. I don't auto-update Windows, and when I run auto updates I review each individual patch that it wants to apply, and reject those I don't want. That's why I don't have IE7 on any of my systems; I use Firefox, use IE6 to access a single website on our intranet that doesn't play nice with FF and nothing else, and have no need for IE7 whatsoever.
Ken White Send private email
Thursday, March 06, 2008
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz