The story of one artefact.

Post #373,706 by static 4/10/13 6:51:36 AM Reply	The story of one artefact. I inadvertantly pioneered the single-artefact deployment in our company. That means once the artefact is built, it will work in any of the environments. We have either per-environment files to override production defaults, or a parameter to tell the artifact which environment it is. Operations loved this idea. Most other development groups were creating one artefact for Testing, then built another for Staging, then a third for Production. Many bugs were released into Production because the code artefacts always had unique code. Ours didn't. :-) I learnt this in a previous employer where we had to provide and support installs for a number of clients. We had releases so frequently that it was very annoying keeping the customisations, so I came up with a way we could leave the customisations out of the way of a code drop. But what really sold it was that it made it so much easier to support multiple development environments, too! Wade. Just Add Story http://justaddstory.wordpress.com/
Post #373,709 by drook 4/10/13 10:48:56 AM Reply	Been trying to push that here It's the only sane way to do it. All environment info MUST be in a separate file ... which yes, MUST be version controlled. Every time I see a sysadmin hand-edit a config file my eye starts twitching. -- Drew
Post #373,710 by malraux 4/10/13 11:13:57 AM Reply	Yep Regards, -scott Welcome to Rivendell, Mr. Anderson.
Post #373,712 by boxley 4/10/13 12:20:23 PM Reply	edit the config, check that it works, check it in Any opinions expressed by me are mine alone, posted from my home computer, on my own time as a free American and do not reflect the opinions of any person or company that I have had professional relations with in the past 58 years. meep
Post #373,738 by static 4/10/13 9:01:32 PM Reply	Yep. It's a robust solution. We currently have an Ops guy who made all his colleagues put everything in Puppet and all of that in a Subversion repo. Us devs also have read access to the prod boxes so we can verify things like config changes have been done. We've caught Ops out a few too many times to relinquish that! Unfortunately, I currently work with a senior developer who doesn't believe in external configuration files, mostly because they have an ownership problem and if they're missing the app crashes (to which my solution is to make the internal defaults Production so that it at least Works). He's been batting for wrapping them up into the code-artefact and select them via per-environment invocation. The attraction is that we get to version-control the settings. The downside is that you need to do a full code-deploy to override any of them. Theoretically, of course, we can make some step of the build or deploy process pull in external configuration files from another repo. But it all seems inordinately complicated to me. Wade. Just Add Story http://justaddstory.wordpress.com/

Welcome to IWETHEY!