[ACCEPTED]-What exactly defines production?-production

Accepted answer
Score: 26

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.

Score: 20

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.

Score: 8

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.

Score: 3

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
  • an intent requires an intender, so there must be a sponsor (a person or group, but not a machine) that specifies the intent
  • that intent is pursued through various processes that are performed by various actors
  • those actors may 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.

An 83 environment consists of all the processes and their actors that collaborate 82 to pursue a particular intent on 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 intent that primarily defines 77 an environment, not its processes or its actors.

Furthermore...

If the 76 intent being pursued in a particular environment is the sponsor's ultimate 75 goal, which usually involves producing a 74 product or providing a service in exchange for money, then 73 we refer to that environment as production.

Now we can go a 72 bit further.

If the intent being pursued in an 71 environment is the verification of processes and their actors in 70 preparation for production, we call that a test environment.

We 69 further call it an integration environment if that testing involves 68 the initial joining together of significant 67 individuals or groups of processes and their actors.

If 66 that preparation involves the "programming" of 65 human actors to perform new processes, or the subsequent 64 verification (evaluation), then we call 63 that a training environment.

Armed with these distinctions 62 and definitions, we can now understand several 61 common scenarios.

An environment can be mislabeled with 60 a name that does not match its intent, such as 59 when a training environment is used as test.

An environment can 58 be grossly misused, such as when integration or training is 57 done in production.

An environment can be misrepresented, such 56 as when key processes or actors are left unidentified (e.g., manual 55 reconciliations, or even by ignoring the 54 people altogether).

An environment can be retasked, by 53 repurposing its processes and 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 production, test, training, and 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 test or training functions.

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 test process on a server that 36 also supports production 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 actors and 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 intent.

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 actors and processes involved 3 in its development/release efforts that 2 result in that product.

I said it could get quite 1 complex...

Score: 1

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.

G-Man

Score: 1
  • 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

0

Score: 1

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.

Score: 0

In simple words "Production code which is 1 live and in use by its intended audience"

More Related questions