[ACCEPTED]-What exactly defines production?-production
When your code runs on a production system, that 5 means it is being used by the intended audience 4 in a real-world situation.
Production code, however, does 3 not necessarily mean robust, reliable, or 2 stable code. The Daily WTF provides plenty of evidence 1 in this regard.
Production means anything that you need 9 to work reliably, and consistently.
Whether 8 is a build script, or a public facing web 7 server.
When others rely on your code, particularly 6 folks who may not understand it (i.e. even 5 "smart" developers but perhaps not in your 4 group, but using a library you wrote), that 3 code is production code.
It's production 2 because "work stops" and "money is lost" when 1 the production code fails.
The definition as I understand it is that 16 production code is any code that is installed 15 or in use on a live, non-test-bed system. A 14 server used internally to a company is a 13 production system if it is the live system 12 used by the employees of the company. The 11 point here is that code running on a server 10 internal to the company writing the code 9 can be production code.
Usually, a good distinction 8 when looking at internal code is whether 7 or not the group maintaining the code is 6 separate from the group using the code. If 5 the groups are separate, odds are that the 4 code is production code. If running the 3 business depends on the code, then it is 2 certainly production code, even if it is 1 developed and maintained in-house.
EDIT: The short answer: If you are "betting 125 the farm on it", it is "production".
This is a great 124 question--an absolutely critical distinction 123 that routinely gets everyone in trouble 122 due to misunderstandings. The question 121 of what is "production" is a subset of the related 120 question of what is an "environment".
So part of the answer is that "production" is THE "environment" that is most important and is most trusted as THE "real" thing.
So now we must 119 define "environment" (and then revisit "production"). We are still far from a satisfactory answer.
We programmers 118 use the term "environment" constantly to refer to computer 117 systems consisting of hardware that is executing 116 software. That software is the code that 115 we wrote plus software that it depends upon, which 114 was written by others. We write our code 113 and integrate it with the other software, then 112 we typically run the integrated software 111 through an escalating series of tests (unit 110 tests, integration tests, functional tests, acceptance 109 tests, regression tests, etc.), until we 108 finally run the integrated software in the 107 full manner in which it was intended.
Of 106 course, not everything is fully automated. There 105 are usually numerous people involved, and 104 they have manual processes to perform. We 103 programmers look for ways to automate as 102 many of these processes as possible, but 101 there is always a "man/machine boundary" in 100 the systems we work on. Often, there are 99 many such boundaries in any particular case.
On 98 the other hand, there may not be any significant 97 automation at all. For example, we spoke 96 of "production" way back when we had a room full of 95 people performing manual labor which produced a 94 product. So, there doesn't have to be any automation 93 present in our "production" "environment". There is also a middle 92 ground, where the automation involved does 91 not include software, such as in the case 90 of a person running a loom to weave cloth.
Also, there 89 may not be a product, since we have adapted our 88 language of "production" "environment" to include product-less 87 service providers.
Likewise, the testing 86 may not involve software, since we may be 85 testing a non-software-driven machine (e.g., the 84 loom) or even the people (training and evaluation).
Now we have touched on all the crucial elements of an "environment":
- there is a purpose, an
intent, being pursued
intentrequires an intender, so there must be a
sponsor(a person or group, but not a machine) that specifies the
intentis pursued through various
processesthat are performed by various
actorsmay be people, they may be software executing on hardware, or they may be non-software-driven machines, so there may or may not be automation present
Now we can properly and fully define our original terms.
environmentconsists of all the
actorsthat collaborate 82 to pursue a particular
intenton behalf of its 81
sponsor. That means software executing on hardware, that 80 means non-software-driven machines, and 79 that means people performing their various 78 duties. It is the
intentthat primarily defines 77 an
environment, not its
If the 76
intentbeing pursued in a particular
sponsor'sultimate 75 goal, which usually involves producing a 74
productor providing a
servicein exchange for money, then 73 we refer to that
Now we can go a 72 bit further.
intentbeing pursued in an 71
environmentis the verification of
actorsin 70 preparation for
production, we call that a
We 69 further call it an
environmentif that testing involves 68 the initial joining together of significant 67 individuals or groups of
If 66 that preparation involves the "programming" of 65 human
actorsto perform new
processes, or the subsequent 64 verification (evaluation), then we call 63 that a
Armed with these distinctions 62 and definitions, we can now understand several 61 common scenarios.
environment can be mislabeled with 60 a name that does not match its
intent, such as 59 when a
training environment is used as
environment can 58 be grossly misused, such as when
training is 57 done in
environment can be misrepresented, such 56 as when key
actors are left unidentified (e.g., manual 55 reconciliations, or even by ignoring the 54 people altogether).
environment can be retasked, by 53 repurposing its
actors to a new
intent. A very 52 successful technique for some organizations 51 is to routinely "flip" several sets of
actors (servers 50 hosting software) between
integration upon 49 each release.
In most cases, a single
actor (person 48 or hardware) can execute multiple
processes which 47 can participate in multiple
environments. For example, a 46 single computer server can host software 45 that performs
production transactions while also hosting 44 other software that performs
Normally, a 43 single instance of an
actor should participate 42 in only one
environment at a time. On very rare occasion, a 41 single
actor can be shared across
environments if the
intents are 40 mutually compatible. Most of the time, it 39 is very unwise to attempt such sharing because 38 the
intents are not really compatible. A perfect 37 example is running a
process on a server that 36 also supports
processes, resulting in downtime because 35 the
test caused the entire server to fail.
Therefore, the 34
intent of an
environment must be construed with very wide 33 latitude, to include concepts such as availability, reliability, performance, disaster recovery, accuracy, precision, repeatability, longevity, etc. This 32 means that the
processes must often be construed 31 to include things like providing power, cooling, backups, and redundancy.
Finally, note 30 that the situation can get quite complex. For 29 example, a desktop computer (
actor) may be tasked 28 by the development team (
sponsor) to host their 27 source control (
process), which the team relies 26 upon for their primary jobs (
production). Nevertheless, the 25 IT staff sees that same desktop computer 24 as simply a developer workstation (
development, not 23
production) and treats it with contempt and nonchalance 22 when it develops a hardware problem. But 21 the developers are producing
production code, so aren't 20 they also part of
production? Perspective matters.
EDIT: Production quality
A 19 solid verification (
testing) methodology should 18 take packaged code from
development and run it through 17 a series of
tests (integration, TQA, functional, regression, acceptance, etc.) until 16 it comes out the other side "stamped" for 15
production use. However, that makes the package
production quality, but 14 not actually
production. The package only becomes 13
production when a
sponsor actually deploys it into an
environment with 12 that ultimate level of
However, if your 11 organization merely produces that package 10 (its
product) for the consumption of others, then 9 such a release comes as close to
production as that 8 organization will experience with respect 7 to that
product, so it is common to stretch the 6 term
production to apply rather than clarify that 5 it is
production quality. In reality, that organization's 4
production environment consists of the
processes involved 3 in its development/release efforts that 2 result in that
I said it could get quite 1 complex...
Any code that will be used by it's intended 4 userbase would fit into my definition of 3 'production code'.
Of course, the grey 2 area in that definition would be clearly 1 defining who your userbase is.
- The production software can perform at the necessary workload without disruption or degradation of the service
- Software has been successfully tested in different production scenarios
- Transforming working prototype into production software which runs on fail-safe redundant architecture that can work in real business, i.e. production environment, needs time, code refactoring, and attention to details
- The production code has acceptable level of maintainability and is reasonably well commented
- The documentation manual explains functionality, all features and facilitates maintenance
- If the production software is an international service or application, it must be localized
- Production code is used by end-users, often customers under conditions described in Terms-of-Service Agreement
- Production software does not necessarily mean reliable mission critical software
- The software does well, what it was intended to do
- Log files provide an accurate description of run-time performance and software reliability metrics and reporting which do facilitate debugging and software maintainability
I think the best way to describe it, is 6 as any code that "leads-to" deployment and 5 "follows-up" deployment. Deployment itself 4 is defined as all of the activities that 3 make a software system available for use. If 2 your code is ready to be used by people, in-house 1 or otherwise, then it is production code.
In simple words "Production code which is 1 live and in use by its intended audience"
More Related questions