Yeah Yeah...

Post #373,663 by folkert 4/9/13 12:24:58 PM Reply	Yeah Yeah... I'm having a HORRIBLE day today. Our weekly (weakly?) code deploy went south today. -- greg@gregfolkert.net PGP key 1024D/B524687C 2003-08-05 Fingerprint: E1D3 E3D7 5850 957E FED0 2B3A ED66 6971 B524 687C
Post #373,669 by malraux 4/9/13 3:05:04 PM Reply	Code deploy on a Tuesday? Did it work in staging? Regards, -scott Welcome to Rivendell, Mr. Anderson.
Post #373,670 by boxley 4/9/13 3:20:58 PM Reply	it always works in staging 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,671 by malraux 4/9/13 3:37:07 PM Reply	Not if yer doin' it right... ;-) Regards, -scott Welcome to Rivendell, Mr. Anderson.
Post #373,705 by static 4/10/13 6:36:57 AM Reply	We tend to have the opposite problem. Our Staging environment has two pieces of permanent breakage: a third-party, block-box server and the fact that most of our external partners do not have Staging environments we can connect to... :-/ Wade. Just Add Story http://justaddstory.wordpress.com/
Post #373,708 by drook 4/10/13 10:46:16 AM Reply	Oh don't get me started on partner test systems -- Drew
Post #373,672 by folkert 4/9/13 3:49:44 PM Reply	Yes... As much as I've tried to get things going. We still have manual deploys and people that don't understand branching. For instance, I have a "Jquery Specialist" that still doesn't under stand stuff. He branched from 1.101 of production and there happened to be an OLD 1.25.4.x branch hanging around from a long time ago. Yeah, well... that brought a whole lot of incompatible with current releases baggage... Needless to say it was "tested and over rode by others that didn't understand why it was busted and why it would bust production... GREAT! We have private Developer stuff. Devel Environment Test-Early Access (had a customer that HAD to have something... well before it made it into QA or prep grr) QA (yes... it actually does) PREP (Pre-Production) Production Unfortunately, since I put things in place to automagically roll things into the next environment once they get the thumbs up... they have been disabled because people don't want to have to do the work to make sure things make it through. I've been over ruled. -- greg@gregfolkert.net PGP key 1024D/B524687C 2003-08-05 Fingerprint: E1D3 E3D7 5850 957E FED0 2B3A ED66 6971 B524 687C
Post #373,673 by drook 4/9/13 3:53:46 PM Reply	No biggie, we'll (they'll) catch it in the next environment -- Drew
Post #373,675 by boxley 4/9/13 4:22:59 PM Reply	and load test it in production 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,676 by drook 4/9/13 4:26:04 PM Reply	Oh, you work here? -- Drew
Post #373,681 by malraux 4/9/13 5:03:02 PM Reply	Yuck... Didn't think it was you. :-) In related news, I'm very pleased with a new configuration management tool I've been using called Ansible: http://ansible.cc Like Puppet or Chef but without the learning curve and requirement for a central server (although you can run it with one if you want). Config tasks can be written in anything that can understand JSON, but Python is native. Regards, -scott Welcome to Rivendell, Mr. Anderson.
Post #373,695 by folkert 4/9/13 11:21:11 PM Reply	Hmmm... Ansible. I've got 16 new machines coming in very soon and they are all going to be running Xen. New I say... newer than even our whizbang grid server nodes... But still used. Cheap... but HP gear. -- greg@gregfolkert.net PGP key 1024D/B524687C 2003-08-05 Fingerprint: E1D3 E3D7 5850 957E FED0 2B3A ED66 6971 B524 687C
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!