On Thu, Mar 26, 2009 at 03:12:08PM -0400, David Golden wrote: > On Thu, Mar 26, 2009 at 2:59 PM, Ovid <publiustemp-perl...@yahoo.com> wrote: > > That's the main reason why our tests don't run on production right now. I > > would like, at the very least, to have a './Build sanity' target to ensure > > that guaranteed non-destructive tests are run, but the strange argument I'm > > facing is that "production should be an exact copy of staging and thus > > tests on staging should be enough". > > The word "should" makes my trigger finger itch. > So test the assertion that production is an exact copy of staging. > E.g. md5sum of a manifest of files. If there's a concern about > processor load, use a cheaper checksum and bump up if there is a > collision. > Or handle it via process -- who's on the hook if the assertion fails > and make them sign something affirming it. Pass the buck. :-)
Live and staging aren't the same and never will be. They probably have different IPs, probably are on different networks, probably have different data in their databases, (eg where I work, live will have patient data on it, staging won't, because the whole point of staging is that it's there to catch errors in the code like sending SMSes to the wrong people at the wrong time telling them to take their drugs), and they certainly have different loads, hence different running processes, and different interesting ways in which processes trample on each others' temp files. But the software should be the same. That's what a package manager is for, and why you don't 'Makefile.PL;make;make install' on live, you do that in dev and test, create a package, install that on staging, test to buggery again, then install on live. I wish. -- David Cantrell | Hero of the Information Age Longum iter est per praecepta, breve et efficax per exempla.
