A while back I asked a question about how companies deploy/update Firefox in the corporate environment. I got a fair amount of feedback on the issue. I wanted to post this a while back, but got sidetracked. Anyway here’s what I’ve put together after reading comments and emails about the topic.
Based on what I’ve read, and looking at where apps like Firefox and Thunderbird stand, I see a few possibilities to improve:
Provide MSI’s as a download
From what I’ve read, and some email’s, MSI’s seem to be the vehicle of choice for most looking to deploy an application because it’s fairly easy to use, and pretty common.
Better Documentation for Corporate Deployment
It seems part of the problem is corporate IT departments don’t see clear documentation on “how to”. A fix for this would be some good documentation on “recommended practices”. Some topics to discuss:
- How to disable auto update
- Prohibit installing extensions
- How to deploy updates with popular deployment tools and enterprise tools and technologies like Group Policy
- Discuss how the CCK could be helpful
A big problem seems to be keeping things up to date. There are several complicated issues here. To discuss them briefly:
In some cases, computers are locked down enough that auto update in Firefox won’t work since it can’t update files. This means an admin must interfere, and must know that they need to take some sort of action.
Companies have strong testing policies in place because of internal apps that are business critical. As a result before something like a browser can be updated, it must be tested against these applications. How do we minimize the time from the release of the new version, to when a company actually deploys this. Obviously the less time involved, the better.
With auto-update disabled, how do companies know a new release has been issued? How can they easily keep up to speed, with low noise?
The first step has already been taken. Mozilla products have a very good versioning scheme and maintenance update release pattern. It’s also good that stable branches live for a while. This is essential for corporate deployments. It allows for some time between moving between versions (such as 1.0.x to 1.5.x). The release cycles work rather well.
There seems to be a need for an IT mailing list, that would notify IT professionals when a release reaches the RC (Release Candidate) stage, allowing them time to test the new version against their systems. Such notification should also contain changes made since the last release, but written in terms of “what to look for when testing” or “what impact these changes could have” (for example a change in how plugins are loaded/handled, requiring testing where Java applets are embedded in web pages). By sending these notifications first during the RC stage, it would allow for some time to do testing, and quicker deployment once the release is official. This is important in the case of security bugs being fixed, when exploits could quickly follow an announcement. The low noise of the mailing list would ensure IT professionals get notifications they need.
I’m curious how these proposals would work for IT departments, from what I’ve read and feedback I’ve received I believe this would allow for much easier adoption, without adding too much of a burden.
9 replies on “Better Corporate Deployment”
> It’s also good that stable branches live for a while.
Mozilla’s definition of “a while” and the rest of the world’s definition of “a while” are completely different.
Companies need stable branches that live for years, not months.
Sadly, what you are talking about happens in universities as well as companies. Some schools at Penn (mine) let users manage their own computers. Others feel that people with PhDs and MDs are incompetent and must have their computers administered. Make sure to include universities on your mailing list.
We already have such a list. We just need to convince the people doing the releases to post there.
@Justdave: Yes, that’s step 1. Step 2 is the information within it. For example, if 18.104.22.168 has a security fix that modifies behavior in some way, it should be clearly noted how, and what impacts that may have.
You should probably ask Eric Dorland or Mike Hommey at Debian who pretty much do something similar in terms of removing the auto-update feature, tracking new releases, providing test builds to small groups of users (i.e. to those running Debian Unstable) ahead of major rollouts (i.e. to those running Debian Testing) and even backporting security patches to old branches that even Mozilla has stopped supporting.
(And most security updates shouldn’t modify the behaviour of anything that isn’t an exploit – that’s the point of *security* updates (as opposed to feature releases). The exception to this is security fixes to features which are insecure by design, but Mozilla has never considered incorporating ActiveX into any of their products 🙂
Modified by: robert – obscuring email addresses a little, I don’t want them getting spammed because of my blog 😉
Doh – meant to link something similar above.
I agree with Mark – branches should live longer. If you take a typical IT departement. It will takes months before than can touch something like 10k desktops. Meaning that if they want to deploy Firefox 1.0 they need to :
1) test internal apps
2) test their masters for new install
3) package the fox of rthe internal used deployement tool (most do understand MSI, hence the need for it)
Now all these steps cost money, once done it’s deployed, but Ff 1.0.7 is already out and MoFo/Moco says they are moving to 1.5. Mozilla 1.7 had a good timeframe for its branch from a corporate point of view.
And yes documentation is important – and there is a lack of documentation concerning all the things that can be tuned/selected in Ff’s config.
[…] Read this post first as this is a reply (originally written as a comment on his site, addressed to Robert directly, and moved directly here due to length): […]
I see that you’re already CC’d on bug 231062 but for anyone who is reading this blog and isn’t, that’s the bug for MSI.