Sorry, I have only really given you part of the story haven't I. We have a puppet class hierarchy that we use to specify the various components that need to go on a particular type of host - e.g app server or web server or db server. A dev machine includes several roles (machines are identified by a -dev suffix on the hostname but maybe we could do it based on the environment variable?).
We use the puppet environment variable to say which environment the machine is in. That in turn decides the config variables and package versions. Dev machines do require additional manual intervention. The deb packages get installed as normal (version "latest" or whatever) but the app component deb installers install themselves plus a symlink pointing to the deb install location ( e.g. /usr/lib/myapp/current -> /usr/lib/myapp/deb). Because the deb installers won't overwrite files that have been modified externally, the developers can point the symlink (/usr/lib/myapp/cuurent) for the relevant component to point to their local checkout/ compile directory and they can be working on the code while the rest of their installation keeps up to speed with other package versions and configs. They need to copy the puppet-created config file for the particular app into their working directory and symlink from its normal /etc/myapp location) but then they can modify it etc as part of the dev process. I know I'm making a mess of explaining this, sorry - feel free to point out bits that either aren't clear or where we could improve our process! ----- Reply message ----- From: "Schofield" <dbschofi...@gmail.com> To: <puppet-users@googlegroups.com> Subject: [Puppet Users] Re: How to do release managment integration with puppet? Date: Mon, Dec 3, 2012 8:18 pm On Monday, December 3, 2012 2:32:15 PM UTC-5, j4m3s wrote:Though we have lots of automated testing we still rely on the human touch for checking UI look and feel, and doing exploratory testing (in the pre production environment). Once it has passed this step the human can approve it for production deployment by updating the version number in hiera. I guess we could have a button on a web screen or something to make it easier to promote it, but editing hiera directly is easy enough. If you have a central change management system, it could update hiera - but you'll still want it approved for promotion by a human won't you, to take into account live service stability/ load, etc? Do you use hiera to define not only the versions but also which applications should be on which environments? How do you introduced application version 1.0 to dev for the first time? -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/5n3FDDQjhlYJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
