On Tuesday 06 January 2004 22:45, adam@thebowery.co.uk wrote:
Updates should come from the head of the IT dept, or whoever is given large amounts of dosh to put their head on the line.
I'm with Adam on this one, you give six people the responsibility of "voting" the release and you'll get the 5 lazyest ones clicking on the "yes button" hoping to god that the 6th does a good job of checking the update. Then when it goes wrong who's accountable ?
Also peer/team pressure will come into it, who would want to be the guy whos vote clogged up the update and caused a deadline to be missed/ project delayed/customers angered whatever. only to come in the next day and find out that the fault he thought he saw was his error ?
How about something like this-
Assuming there is some sort of QA procedure/team, they sign off the final build and at the point of sign off they package the files (assuming the update is more than one file) as a tar archive or something, and create an MD5 sum
The archive is transfered to the update mechanism by whatever means and the MD5 sum is presented to the head of IT (or whoever we are going to make responsible) during a process where the QA personell or team head confirm that the packaged build is "ready for launch" The head of IT then makes the final decision, checks the package against the MD5 sum, assuming a match untars it and launches the update process.
Scenarios
If the build or source tree is tampered with, hopefully the QA team will pick up on it.
If the build is tampered with between the QA sign-off and the update mechanism, then the sums won't match
You could even perhaps have a well protected script that uses the Md5 sum as part of a launch key/password. So the update can't be initiated until the correct Md5 sum is presented by the head.
Ok it's getting late so I am not sure this makes sense................ Replace Md5 sums with encryption if you want.