On Mon, Sep 7, 2009 at 3:57 AM, Brian Candler< "> > wrote:> (3) In the environment where I work, the most likely need for chef is inTesting recipes without taking the actions described is basically an
> distributing config files [*].
>
> So I'm looking as to ways we can make this as safe and simple as possible
> for the sysadmins to use.
>
> Have you any pointers to best practices on *testing* new recipes? I don't
> really want to set up a whole dev/test environment just for developing and
> testing each recipe change - it would be too cumbersome. But equally I don't
> want invalid recipes being pushed out, or worse, ones which destroy data.
impossible task to get 100% correct. You can do dry runs, but any
time you check the run-time state of the system and that state could
have been modified previously in the run, you're going to get a false
positive.
We've been working on ways to let you write real integration tests,
which would go a long way towards allowing you to do real testing in a
VM. As it stands, the best practice is to have a staging environment
that gets your new changes first, and only prop changes to production
when you are comfortable.
Archive powered by MHonArc 2.6.16.