|JP Vossen on 29 Jan 2012 13:59:57 -0800|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|Re: [PLUG] dev vs production environments|
Thanks to all who provided feedback on this one too!It sounds like a) I'm not nuts (always a possibility :) and b) I'm not alone in the challenge.
I especially liked Doug's quote: "Unless your dev setup matches testing matches prod as much as possible, the likelihood that you'll catch edge cases goes way down. You want to know those edge cases before go live wherever and whenever possible."
Yup, that's the problem. But I'm a team member, not a manger of these folks, so I can't just require this. Hence my need to make better arguments to both the team and the management than "because I said so." :-)
Matt also had a good point with "it depends on what you are trying to build... something that works everywhere, or something that caters to a specific set of constraints." The context is basically an "appliance" so it's a very specific case. But the hardware isn't cheap. We do have a bunch of real hardware for QA & testing, but we still have contention for hardware for different uses, flavors of the product, etc. That's a big part of my problem; some of that hardware isn't the stock image, but is used for dev/testing/QA anyway, and that causes nothing but problems. Which I've documented and submitted, but still... Also, while VMs are significantly different in some obvious ways, they are still useful in many cases. I'm pushing that as well.
The PCI & legal issues are not directly applicable, but still good food for thought I hadn't considered. I might try to make some points out of that, thanks Sam. Different domain names are a cool idea, but N/A in this case.
Per Sean's point I do also want to push more automation. Aside from one dev though, there is basically no Windows, so .Net stuff is out. Chef (thanks Kyle & Kevin) is a possibility, but thus far I haven't even had time for more basic shell script stuff (due to deadlines and fire-fighting). I *know* that it is time well spent to do that stuff, and I still can't get to it. But I am going to push on it more. (Also, a predecessor automated *nothing* in about 5 years, so I have a lot of catching up to do even for the drop-dead-stupid basics.)
Kevin, I really like '3. Attempting to eliminate the "Well ? it works on my machine" response to the bug report.' and we've already seen at least 2-3 of those (*cough* Windows *cough*)! :-(
Also '2. Being able to test your rollout/release procedure' is a big one, but that's part of the stuff *I* do, and it's automated and documented and QA'd (by folks who are not-me) out the ying-yang. :-)
Douglas mentioned AWS which won't fly and revision control which is another struggle, but that one is mostly under control now. Still CVS though. Yuck. There is more yet to do (note the previous 5 years, as above) but that is getting there. I have more control over that part then the Java part...
Whew. I think that's everything rolling around in my head. Again, thanks for all the feedback, lots to think about!
Later, JP ----------------------------|:::======|------------------------------- JP Vossen, CISSP |:::======| http://bashcookbook.com/ My Account, My Opinions |=========| http://www.jpsdomain.org/ ----------------------------|=========|------------------------------- "Microsoft Tax" = the additional hardware & yearly fees for the add-on software required to protect Windows from its own poorly designed and implemented self, while the overhead incidentally flattens Moore's Law. ___________________________________________________________________________ Philadelphia Linux Users Group -- http://www.phillylinux.org Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug