Even though my team is doing both: developing application features as well as
Chef cookbooks we see the disconnect. We've two separate repositories and
developers do _not_ work on Chef configured Vagrant boxes all the time. They
only use Vagrant when they're changing cookbooks.
Additionally we've split configuration values between our Rails app (in
environments) and Chef.
The only place where app and infrastructure mingle is our staging environment
so far.
We're planning to setup a CI using Chef to create the VMs to run the tests.
But we're not there yet :-(
Interesting that you say that about Noah. My current client is looking at a
service management model to deal with configuration files, eliminating Chef
entirely from the mix. I have also discussed with a dev team shipping in
config files from artifact repository and we did it with overrideable
attributes, allowing someone else to use either a default template in the
library cookbook or supply their own in another cookbook or drop a template
on the server from elsewhere. I guess my preference would be to eventually
have the templates parametrized so that anyone could use the same template.
But then the question arises, how do you deal with changing data? For this
we have been using a combination of attributes and data bags. Chef solo would
be a viable option for workstation testing, but they'd still have to check
these things in and have build scripts that dealt with getting them into the
Chef server/org. We have a lot of this now and it's just not connected.
Maybe this is something that would actually work if you could get in front of
the development and build process and hand a dev team a working CI process
that involved Chef. Lately I only get involved when it's too late to do
anything besides panic.
Sascha Bates |
| 612 850 0444 |
|
|
On 1/27/13 9:14 AM, John E. Vincent (lusis) wrote:
One idea that EJ (your cohort on the podcast had) that I thought was
brilliantly simple is to have the applications ship ERB templates for any
conf files by default and let chef do its template magic with a local file
instead of one in the repo.
The disconnect is always going to exist unless your dev team is willing to
work with the chef repo. Frankly it's pretty unfair to ask that out id the
gate and keeping the two in sync is painful.
The first motivation I had for the (sadly languishing) Noah was this exact
use case.
On Jan 27, 2013 1:14 AM, "Sascha Bates"
< >
wrote:
Thanks. I'm in an environment where we use jenkins and maven for a lot of
this at the moment. There's also some Vagrant/vbox in the mix as well as
Eclipse/STS. I'm not looking for pointers so much as being interested in what
others have found to be successful.
One of the problems I see is that Chef code and Application code are
decoupled: different repos, different teams managing collections of
cookbooks, diverse environments. Dev teams don't think of Chef as part of the
code base and I believe that this has led to some dysfunctional attitudes and
behaviors. At the moment I'm noodling on methodology for introducing a tool
like Chef that decouples configuration code from application logic.
So I guess I'm maybe not looking for deployment solutions so much as
wondering what people are doing to get their chef and app code working
together and how it's working out for them.
Sascha Bates |
| 612 850 0444 |
|
|
On 1/26/13 9:59 PM, Gourav Shah wrote:
Is anyone here doing application builds (either yourself or for devs) that
involve any of the following:
-Local (workstation) testing of a developed app with Chef housing
configuration files
For local development with chef managing configs, you could try using vagrant
+ chef
-Application bundling with ant, maven, groovy, scripts, whatever that alsoI have used Jenkins + chef. You could also add capistrano in the mix for
includes parallel check-ins to Chef code?
-CI testing of an application that builds an artifact but also has
configurations in Chef?
deployment.
Thanks
Gourav
Archive powered by MHonArc 2.6.16.