Joe, Cheers for the response...
N yeh, part of me almost doesn't want to relinquish control, as I know how it should work etc... However I am only 1 man, and cant keep up with current demands... ;) With regards to code deployment, the typical model is J2EE apps deployed into Glassfish 3 domains, so the applications would be sourced from Maven, and dropped into Glassfish... So i'm actually fairly confident with that... Plus it means we can actually start to get a degree of control over what's where in our env... Any other comments welcome... Cheers Gavin On Friday, 26 April 2013 06:04:11 UTC+1, joe wrote: > > One thing you certainly need to do is define a clear line of what puppet > will and will not do in your environment. > > Puppet is not well suited to code deployment. It is extremely good at > maintaining the environment in which code runs. > > I would allow contributions from your dev team liberally, as long as they > are only using puppet to maintain the environment and do so in a way that > the rest of the organization can make use of their work. > > On Thursday, April 25, 2013 2:45:51 PM UTC-6, Gavin Williams wrote: >> >> Afternoon/Evening all >> >> It looks like Puppet is starting to get some traction within my >> organisation, with several other teams asking what Puppet can do for them >> :-) >> >> The main use I'm getting asked about is one touch deployment of our >> products by Dev teams... >> >> On the surface it shouldn't be too hard, and I've already got a model in >> mind. >> >> However one of the considerations is making the Puppet code maintainable >> by Dev aswell as me in Ops/Implementation... >> >> Currently, I've got one model that does all our Puppet stuff, such as >> based configuring servers, installing oracle, installing monitoring, >> configuring databases, etc. I do hook in some common modules as and when >> needed. >> >> So i can either continue this model and build it out to handle product >> deployments aswell. >> Or I can turn it on its head, and write modules specific to the product >> deployment, pulling in stuff from our core model where useful... >> This means that Dev can maintain their own product modules, and with a >> liberal spread of continuous integration testing, should be able to handle >> new product module requirements separately to core model changes :-) >> >> So, thoughts welcome. >> Any pros/cons to above? Or any better way of handling it? >> >> Thanks in advance for any responses. >> >> Regards >> Gavin >> >> -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
