Paul Johnson wrote: > On Thu, Mar 26, 2009 at 08:46:37AM -0700, Ovid wrote: > >> We have someone arguing that when our Perl apps move from staging to >> production, we must not run "make test" because: >> >> 1. It's guaranteed to be 'bit-by-bit' identical to staging. >> 2. Downtime must be minimized and we can't waste CPU or I/O on "make test". >> >> These are often heavily loaded boxes and downtime really is a crucial issue. >> >> For those of you in large environments, do you run "make test" or an >> equivalent when you push your code out to a production server? Why or why >> not?
Personally I'd err on the side of running the tests, but I don't have any strong feelings one way or the other. I haven't put much thought into it. Acceptance of argument #1 would come down to how good the staging process is and how much I trust the admins to not bypass it and hot patch the production system. And if they do, how good the process is for normalizing things after the hot patch. > The downtime is also something to consider, but that would only be > important on installations which were near the limit of the allowable > time, and in general isn't a consideration for me. This is my thinking on #2, too. If your production systems are running so close to red line that the tests will push them over, you have a problem. If you can't spare bringing a server in the cluster offline to run tests, you have a problem. > The real reason is that the production system has a production database > running, and I don't want to do anything which might compromise that > database. Similarly for the filesystem etc. If I was to come up with a good argument as to why not to run the tests in production that would be it. The possibility of screwing up the production data is too great. Always mount a scratch monkey. http://edp.org/monkey.htm -- ...they shared one last kiss that left a bitter yet sweet taste in her mouth--kind of like throwing up after eating a junior mint. -- Dishonorable Mention, 2005 Bulwer-Lytton Fiction Contest by Tami Farmer
