|
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 -Application bundling with ant, maven, groovy, scripts, whatever that also includes parallel check-ins to Chef code? -CI testing of an application that builds an artifact but also has configurations in Chef? My current client is moving away from keeping any application information in Chef at all but the problem is still an interesting one to me. If I tell a dev team to put their config files into chef templates, how do I help them combine build triggers for application code as well as configuration code? Part of the trick I'm learning is to get them to think of Chef as part of their code base at all and not just provisioning scripts maintained by their release engineer. Also, how do you ensure that dependent config/code changes are built together and not deployed in such a way as to break the app? I'm not terribly concerned about production at the moment, my main interest is around CI testing, although ultimately that would be the goal. If you are doing anything like this, I would love to hear about. Currently my team has Jenkins-driven workflow CI around our key Chef repositories and some common application components but it's not something we've rolled out to dev teams and it's not triggered by java/app code check-ins, but rather by us checking in Chef code. It's decoupled at the moment. TL;DR I'm looking for ways to make it easy for dev teams to regard Chef as a natural part of their development cycle as opposed to a weird third arm. Sascha |
Archive powered by MHonArc 2.6.16.