Abe Timmerman wrote:
> Hi all,
>
>
> I'm looking into running part of our test-suite in parallel.
> TAP::Harness understands the way we'd like the tests ordered:
>
> { seq => [
> { seq => [ glob 't/0*.t' ] },
> { par => [ glob 't/1*.t' ] },
> { par => [
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
Ovid wrote:
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?
We don't for a couple of reasons. Like your #2 our tests are very CPU/memory/DB
intensive so they would be extremely disruptive if
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
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 minim
On Thursday 26 March 2009 11:27:13 Michael G Schwern wrote:
> 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.
That's the only reason I wouldn't do it, either -- and in tha
--- On Thu, 26/3/09, chromatic wrote:
> From: chromatic
> That's the only reason I wouldn't do it, either --
> and in that case, I'd try
> to find a way to make screwing up production data
> impossible. Some people see
> reasons why you can't or shouldn't run tests on
> production machines.
On Thu, Mar 26, 2009 at 2:59 PM, Ovid 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 "
# from Ovid
# on Thursday 26 March 2009 11:59:
>The word "should" makes my trigger finger itch.
>I want those tests, but the people arguing are huge Java fans and
> argue that "Java is safe to deploy, why not Perl?"
I'll guess that "should" is "is" often enough that the extra effort and
risk is
On Thu, Mar 26, 2009 at 11:59:34AM -0700, Ovid wrote:
> --- On Thu, 26/3/09, chromatic wrote:
>
> > From: chromatic
>
> > That's the only reason I wouldn't do it, either -- and in that case,
> > I'd try to find a way to make screwing up production data
> > impossible. Some people see reasons
Ovid 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
On Thu, Mar 26, 2009 at 03:12:08PM -0400, David Golden wrote:
> On Thu, Mar 26, 2009 at 2:59 PM, Ovid 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-destr
12 matches
Mail list logo
