Matt Mossholder on 25 Jan 2012 15:23:13 -0800


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] dev vs production environments


My take is that it depends on what you are trying to build... something that works everywhere, or something that caters to a specific set of constraints.

If you want it to work everywhere, then you may actually want a disparate Dev environment, so that devs catch nuances early. Otherwise, your QA is going to be where you catch things,and you will need to have your processes set up to account for it.

If you are developing for a tailored environment, then development should be targetting a VM that is as close to that environment as possible, and different of a "finished" VM should be used to find all changes the dev made to the system.

If the devs insist on doing builds out of the sandbox, then it should be a requirement for them to provide a report of the system passing all QA tests in the target environment before the code can be considered complete/commuted/checked-in.

ÂÂÂÂ --Matt

On Jan 25, 2012 5:22 PM, "JP Vossen" <jp@jpsdomain.org> wrote:
Arguably at least semi-OT, but it's all about Linux & Java & stuff, so... Â(Warning, I'm *not* a Java fan.)

I'm having a problem at work convincing some developers that the dev and testing environments should match production as close as possible. Since this is all Linux stuff, and we have machines and virtualization, this seems like it should be a no-brainer to me. ÂIn fact, this is so blindingly obvious that I'm having trouble making a stronger argument for this than "because it's so blindingly obvious."

Also, much of the dev work is Java, which is "write once, run anywhere," right? ÂUmmm. ÂNo. ÂI'll agree with "write once, debug everywhere" but that's about it. Â*Running* a Java app in a production-quality way is a *tad* different on Linux and (the horror) Windows... ÂEven if the "Java code" part works, all the rest of the surrounding infrastructure and environment (init script, ulimit, user perms, SELinux, ports < 1024 (like 443)) has to work and be in sync too. ÂThat isn't gonna happen on Windows. Â(Hell, it's not even happening on Linux, which is part of my point.) ÂAnd don't get me started on the JBoss part of it...

So... ÂAm I wrong? ÂOr is this as blindingly obvious as I think it is? And if so, can anyone make a better argument, or point me at some "best practices" and/or horror stories I can beat people with? Â(I'm Googling badly as I can't find anything good. ÂOK, besides just about everything at thedailywtf.com :)

FWIW, we're trying to be "Agile" though we just started and have a *long* way to go...

Thanks,
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
___________________________________________________________________________
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