Environment Variables - Dev/Test/Production? 77
Woody asks: "It's common knowledge that the development environment should be the same as the test environment which should mimic the production environment whenever possible. I'm currently working on a project where we develop on Dell, test on IBM, and the production system is up in the air. For embedded systems the differences can be running on a VM versus running on the actual hardware. What I want to know is what kind of problems have Slashdot readers been faced with because of different environments being used for different phase of their projects, and how have they been overcome?"
Apropos (Score:2)
There are plenty of issues however, the breakdown is as such:
Dev: Development only. New code, new app, etc.
Systems Test: Dev+/Integration testing
UAT: Pre-production. Used for 'User Acceptence Testing' (Prod with stale data)
DR: Full mirror of production located 50 miles away.
PROD: Full production environment.
Re:Apropos (Score:4, Interesting)
The best approach is to create an environment variable that defines the development environment, example DEVENV=DEV, DEVENV=TEST, DEVENV=IT, DEVENV=QA, DEVENV=PROD (or not needed for production at all), and then elsewhere (controlled and basically kept hidden from the testers or users), other environment variables are set based upon the value of DEVENV. Examples of these environment variables would be your PATH variables, ORACLE_SID, etc.
Then, the final problem is educating the testers what DEVENV means, and more importantly, why that one has to be correct and that they should not mess with any other environment variables.
If the testers can't understand that, you need smarter testers.
Environment variables (Score:1)
Depends on the discipline of the developers (Score:3, Insightful)
Another area is performance. For reasons I have yet to understand, there seems to be a prevalent myth that performance can be bolted on after the fact (the "make it work, then make it work fast" mindset). The truth of the matter is that performance has to be engineered in from the beginning or you simply spend a lot of time and money rewriting code that should never have been written in the first place. Sadly, educational institutions don't appear to place any emphasis on actual performance or teach the principles of performance tuning as part of their curricula.
Re:Depends on the discipline of the developers (Score:4, Funny)
Its not a just myth; its a damned lie that hurts all of society as a whole.
Re:Depends on the discipline of the developers (Score:5, Insightful)
It turns out you rarely know which will bite your face off until you get a representative data set running. If you made the wrong choice, you probably made things *worse* than if you had opted for working code that could be re-factored from "easy to read" to "mostly easy to read and performs where it counts".
When you are working on server based solutions that will be hit hard, all of those could be your bottleneck: or none.
Re:Depends on the discipline of the developers (Score:2)
Thats a good question.
You need to find out that at the start of programming. And yes, its difficult but there are ways to help things. It won't be perfect but it can't be an after thought.
Re:Depends on the discipline of the developers (Score:2)
For every algorithm there are trade offs. The most common are memory vs time
Re:Depends on the discipline of the developers (Score:2)
You need to find out that at the start of programming. And yes, its difficult but there are ways to help things. It won't be perfect but it can't be an after thought.
The problem is, to really know for sure, you have to build an extensive test framework and dataset. So extensive that when done it will look suspiciously like version 1.0
That's what is meant by avoiding premature optimization. Instead, the better approach is to keepit in mind, but focus on correctness and modularization. That way you can
Re:Depends on the discipline of the developers (Score:3, Insightful)
As such, this does not mean to use braindead implementations, but worry about a working product first.
The first setp to a serious project is to work through the design. This means looking at the interfaces that the software will provide. Whether those are UI or API. Those are your targets that your users will work with.
Then you will need to have test cases for the interfaces that you have agreed on. Thes
Re:Depends on the discipline of the developers (Score:4, Insightful)
Re:Depends on the discipline of the developers (Score:2)
Unless your problem is CPU-bound, disks are going to be the big server bottleneck, and disk performance doesn't provide enough improvements to make a huge difference.
Painstakingly engineering an elegant, but slow solution to a business problem only results in that elegant, tested code being ripped out to provide performance benefits later.
Re:Depends on the discipline of the developers (Score:2, Insightful)
This allows the best use of developer time by producing "cheap" code for most work. Then the "expensive" code can be written only in the cases where it is needed. Certainly there will be a certain amount of re
Re:Depends on the discipline of the developers (Score:3, Insightful)
Myth, eh? Personally, I do no "bolting". The steps I happily follow are
The notion here is that
Re:Depends on the discipline of the developers (Score:1)
There is an addendum that I-can't-remember-who added, but it has to do with how a programmer often does most of the important optimizations automatically, anyway. Basic "duh" stuff about reducing nested loops, which data structure to use in which circumstances, etc. Things that experience, if not common sense, illuminate in such a way that making the "optimization" is quick, easy, and so natural that you probably didn't notice you were doing it.
Sure, you might be wrong, or a hidden gotc
Yes...and yet, no. (Score:3, Insightful)
Odds are, if someone is rushing for you to get a project done on an unrealistic timeline, they haven't done their analysis of the project correctly, either. Having _any_ prototype up there can help drive the requirements analysis, so that you can figure out what needs to be changed.
But yes, then you scrap that entire thing, so you can do it correctly.
If you're making minor modifications to an existing system, then yes, you mos
Re:Depends on the discipline of the developers (Score:1)
On the individual machines and with the small sample databases, the system worked fine. However, I was the first one to connect it a development copy of a live database. On the fi
Re:Depends on the discipline of the developers (Score:1)
I partly agree with you. Performance should be implemented from the start through good programming practice and clean development standards - Programmers should be aware of the programming practices resulting in efficient applications and programming practices that result in slow applications.
However, I disagree that this should be a primary concern because if this was the case then all development would be made in assembly. Programmers need to understand how to program continguencies into their code, so i
Cost? (Score:1, Insightful)
Re:Cost? (Score:1)
We called it our Cool R
Re:Cost? (Score:2, Insightful)
About 95% of the time I hear this, it's false economy. Most hardware is pretty cheap these days, and good developers are very expensive. It takes very little time savings to justify the purchase of new hardware.
In the few cases where it's too expensive to duplicate hardware, then you can fall back on careful profiling and simulation. For example, if you know that your production hardware has X times the CPU and Y times t
Re:Cost? (Score:2)
Hardware is a fixed cost that bone-headed managers can wash away and claim a savings. Salaries are harder to get rid of. The result: no hardware, development costs twice as much, and it is easier to talk away labor delays than you might think.
Re:Cost? (Score:2)
About 95% of the time I hear this, it's office politics getting in the way.
To the other extreme with NDEBUG/assert() (Score:1)
No amount of explaining or arguing could do it: the idea just broke their concept of software production, plain and simple.
Just had to pull the assert()s out.
Re:To the other extreme with NDEBUG/assert() (Score:2, Insightful)
If the code were properly designed to fail gracefully in production, a failed assertion isn't very graceful.
Re:To the other extreme with NDEBUG/assert() (Score:3, Informative)
You shouldn't compile with different options between test and production, but you should do so (for things like -DDEBUG) between dev and test... developers need their extra debugging statements, and asserts, but they interfere with appropriate user interfacing in production.
As I see it, the steps are:
1. Develop
2. Test in production mimiced environment with -D
Re:To the other extreme with NDEBUG/assert() (Score:2)
Why wouldn't you have asserts in the production code?
Assert is by design very useful in development and testing, but is the antithesis of desirable production behaviour. In testing/development, you want a failed assert to kill the app dead right there so you can examine the state that lead to the problem. In production, you'd probably rather have it return some sort of error and continue to perform 99.9% of it's functions correctly. Imagine if a server feature used once in 6 months brought the server d
Even worse with custom hardware (Score:2)
There's not really too much to be done about it. We don't want to have the code check to see which hardware it's on, as that would make it easier to have more bugs. In some ways, this can be good,
Agreed (Score:1)
Schedules and design reviews be dammed we have a product to deliver!
Design, document, go over hardware design docs, code, configure simulator to mimic the hardware, test and debug in sim, debug the sim configuration, build various utils that you expect to help test the hardware...It all sounds great and proper by the book but doesn't mean jack until you and the hardware EE get your hands on the real stuff. First you have to pass the smoke t
If you are lucky (Score:2)
I recall one chip that was shipping installed backwards. It happened it worked in most situations too - except for a few corner cases that was blamed on software for a long time. (I'm not an EE, so I can't give you any more detail)
Another time I spent a month chasing down bugs in my code only to discover all the test system was broke, but since it passed all other tests when the work around for my code not being done, they blamed me. It is not a good feeling to find out that your code was bug free afte
lots of issues (Score:2)
Re:environment variables? (Score:2)
Yes, but sometimes that simply isn't possible. Can you imagine trying to replicate the traffic and complexity of a Google or eBay on a dev machine? His question was to uncover some of the problems with testing on a facsimile of the prod environment.
Camel Eye of Needle (Score:2)
Forcing your project to run in different environments is
Tomcat vs JRun and Linux vs HP-UX (Score:1)
We were allocated only one development environment on JRun for this project, but we have to use it as a user test environment, so we develop and do QA on Tomcat 3.3 under Linux. Tomcat 3.3 and JRun 3.1 supposedly implement that same version of the JSP and Servlet specifications, but JRun
Environment meaning what? (Score:2)
The next time the cluster tried to reconfigure, it failed mysteriously. Customer couldn't figure it out, local support people couldn't figure it out, I was one of those people but out of town (I'm convinced given the nature of the problem that I would have figured it out),
Re:Environment meaning what? (Score:1)
-Peter
Re:Environment meaning what? (Score:1)
Re:Environment meaning what? (Score:2, Funny)
-Peter
Re:Environment meaning what? (Score:1)
For reasons I don't understand, I've seen the "su -" syntax not get quite all the user's environment. It still seems to inherit some stuff no matter what.
Re:Environment meaning what? (Score:2)
Sure, I can override with --user=mysql, or I could take the time to track down the issue. I'm just using it as an example that 'su -' is still different from an actual login (and a potential warning for people using Role accounts w/ MySQL CLI).
Although it is handy for slo
Re:Environment meaning what? (Score:2)
Just hard coding /bin/ls is just as suseptible to the problem you are talking about. The real problem here is that you are using
Test/Staging == Backup (Score:1)
If possible, convince management that your Test/Staging env needs to be beefy enough to function as an "emergency backup system" and GET the marginally equivalent hardware.
On the side, if your production DB server is a cluster and your development DB server is not then where is your DBA going to practice
I'm working on something like this. (Score:1)
Tell me about the data, not some minor HW changes. (Score:3, Insightful)
This is of course assuming that the software platform is adequitly compatible not to introduce stupid bugs because of diffrences between servers.
Development environment: India ... (Score:3, Funny)
Re:Development environment: India ... (Score:2)
Production environment? Whats that about?
Use separate databases, please (Score:2)
Please, take the effort to initialize a whole new instance of the database for each environment. Sure, it's a bit of work, but just don't go around stomping on each other's feet thinking it's more convenient. Yes, I have witnessed such stupidity before.
Where I work (Score:2)
All of it's Windows-based (this company drank the MS Kool-Aid), but all three platforms are basically equivalent.
The SQL servers are physically three different machines, but they're all clones of each other.
The web servers are either local machine running XP (Dev) or Web Farms running Win 2K3.
We have a transfer utility to facilitate moving the files back and forth, but it doesn't get everything. This is a mixed blessing, but it's handy when you DON'T want so
CPUs, network and data (Score:2)
Continous integration (Score:4, Informative)
Now we have a number of environment-specific settings, for example database connection details, etc.
All environment-specific stuff goes into
Every successful build is tagged in CVS with an autoincrementing build number. When we have identified a release candidate, it is as simple as instructing anthill to (re)build a deployment bundle for a particular target with a specific build number. That deployment bundle (usually a
An additional benefit is that each environment's individual settings (including development machines) is always available to all developers for comparison and troubleshooting.
I guess the lesson learned is this:
Mixed up process (Score:2)
It's common knowledge that the development environment should be the same as the test environment which should mimic the production environment whenever possible.
This is quite mixed up.
The test environment should always be *identical* to the production environment, in all aspects where it is feasably possible. Running tests in an environment that is in any way significantly different than your production environment is basically a waste of time and can lead to huge amounts of unforseen holes in the softwa
Nope. (Score:2)
Improper testing and QA procedures is a major cause of failure for startups. Your product needs to be *rock solid*. In order to do this, you should **always** be running QA testing on your target platform. Anything else could lead to improper assumptions, w
Character Sets and Scripting (Score:1)
One of the things that you will find as you migrate around different OS's is the default character set. Sometimes it's UTF-8, other's is ISO sets. You may even be Kanji or some other one that you're not prepared for if you distribute yo
Test is the key (Score:1)
My philosophy is to let developpers quite free. Of course, they have to get authorized to run a newer version of the VM (and that version has to be part of the roadmap), but I give them flexibility for their configuration. This is done with the vision of helping innovation through trial and mistake. The key there is to have clear guidelines
Absolute X Relative paths (Score:1)
Moved to production server and it obviously did not work.
Re:Absolute X Relative paths (Score:1)
Different sites have differing conventions about where software should be installed. I'm surprised at how many people seem to have no conception of what it's like to run on anything other than a standalone system.
Sure, on a system like that, it may make sense to install software in /usr/local, and have home directories in /home. But remember that those conventions are nominal at best. The real world is a lot more varied, because it has to be.
not that many. (Score:1)
Embedded systems and blackbox development all have there problems, but you should be able recognise them and compensate, having a few experienced engineers on the team will help everything go smoothly (and tell you when it's not)
First off,
Make sure your procedures are reasonally well
hyperthreading (Score:3, Interesting)
One of the worst problems I had was related to hyperthreading. Turned out an 3rd party component that was a black box was threadsafe, but not multi-processing safe.
When I finally figured it out (of course it happened only once in days, had to write and tune exercisers for weeks to get it to occur within minutes), an update became available.
(we nailed 4 from the 6 spots in that patch already ourselves by then)
what kinds of problems? (Score:2)
- C programs with host names hard-coded in #ifdef...#else...#endif blocks that aren't compiled with the right macro defined for the given environment.
- 20-character wide terminal device that vomited all over itself when the program tried to display a 21 character string, which we only tested on 80 character terms before sending to production
- Intermittent communication failures because of a different version of firmware on a network device in production versus dev/QA.
- WAR fil
Java (Score:2)
This is how we do it (Score:1)
Development
Fully patched Windows XP or Windows 2000 Workstations, installed with all the development tools we need. Developed applications are _NEVER_ executed on the development workstations; this keeps the development platforms from being 'corrupted' by miscoded app
The main problem being...identifying it. (Score:1)
Having to deal with compatiblity issues on my own due to a variety of environments and having this workload not properlly being tagged as part of the development of the product (just-fix-it-don't-want -to-hear-about-it syndrome).
In the embedded arena, powerful+expensive tools like Windriver Tornado tackle this problem quite well. Support..support..support.
Whith less sophisticated tools the amount o
Environment variables? (Score:1)
<sarcasm>You mean the ones besides %windir%, %tmp% and %systemroot%?</sarcasm>
In my case, home, home, and, um...oh yeah, home.
Problems? Well, on Windows, errors, the occasional 0xC0000005 and the occasional total system crash; on Linux? I'm still learning, ask again in a few years...yes, I just program for fun. I'll go now...