何が正確に生産を定義しますか？

Question

はしばらくの間、プログラミングされていますほとんど誰と同じように、私は、用語「製品コード」に精通してると、それが何を意味するかの漠然とした感覚を持っています。それはWikipediaとGoogleはできないようですので、誰かが、半厳格な定義を提供することができますか？そのような人々の小さなグループによって使用されるため、などUI、ドキュメントの用語とされているオープンソースのアプリで「正式に」されていない内部ツールとして、生産としてカウントするもので灰色の領域が多いようです完全に、合理的にバグが無料と作業を備えていますが、ポリッシュ、UIや広範なテストに欠けます。

Answer 1

生産は、あなたが確実に、かつ一貫して動作するために必要なものを意味します。

かどうかは、ビルドスクリプト、または公衆に向けWebサーバです。

他の人があなたのコードに依存している場合には、（すなわちさえ「スマート」の開発者が、おそらくないあなたのグループでは、しかし、あなたが書いたライブラリを使用して）それを理解しないことがあり、特に人々、そのコードは、生産コードです。

「仕事が停止した」と生産コードが失敗したときに、「お金が失われている」ので、

これは、生産です。

Answer 2

あなたのコードは、それが現実世界の状況で意図した観客によって使用されている意味生産システム上で実行するときます。

生産・コードは、しかし、必ずしも、堅牢で信頼性の高い、または安定したコードを意味するものではありません。 デイリーWTF には、この点で証拠の多くを提供しています。

Answer 3

私はそれを理解するような定義は、生産コードは、ライブ、非テストベッドシステムにインストールまたは使用している任意のコードであるということです。それは会社の従業員が使用するライブシステムであれば、会社に内部で使用されるサーバーは、生産システムです。ここでのポイントは、そのコードは、生産コードすることができ、コードを書く社内のサーバー上で実行されてます。

通常、内部コードを見て良い区別コードを維持するグループコードを使用して、グループから分離されているか否かです。グループが分離されている場合は、オッズは、コードは、生産コードであるということです。ビジネスを実行すると、コードに依存している場合、それはそれは、社内で開発され、維持されている場合でも、確かに生産コードです。

Answer 4

EDIT: The short answer: If you are "betting the farm on it", it is "production".

This is a great question--an absolutely critical distinction that routinely gets everyone in trouble due to misunderstandings. The question of what is "production" is a subset of the related 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 define "environment" (and then revisit "production"). We are still far from a satisfactory answer.

We programmers use the term "environment" constantly to refer to computer systems consisting of hardware that is executing software. That software is the code that we wrote plus software that it depends upon, which was written by others. We write our code and integrate it with the other software, then we typically run the integrated software through an escalating series of tests (unit tests, integration tests, functional tests, acceptance tests, regression tests, etc.), until we finally run the integrated software in the full manner in which it was intended.

Of course, not everything is fully automated. There are usually numerous people involved, and they have manual processes to perform. We programmers look for ways to automate as many of these processes as possible, but there is always a "man/machine boundary" in the systems we work on. Often, there are many such boundaries in any particular case.

On the other hand, there may not be any significant automation at all. For example, we spoke of "production" way back when we had a room full of people performing manual labor which produced a product. So, there doesn't have to be any automation present in our "production" "environment". There is also a middle ground, where the automation involved does not include software, such as in the case of a person running a loom to weave cloth.

Also, there may not be a product, since we have adapted our language of "production" "environment" to include product-less service providers.

Likewise, the testing may not involve software, since we may be testing a non-software-driven machine (e.g., the 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 environment consists of all the processes and their actors that collaborate to pursue a particular intent on behalf of its sponsor. That means software executing on hardware, that means non-software-driven machines, and that means people performing their various duties. It is the intent that primarily defines an environment, not its processes or its actors.

Furthermore...

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

Now we can go a bit further.

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

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

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

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

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

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

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

An environment can be retasked, by repurposing its processes and actors to a new intent. A very successful technique for some organizations is to routinely "flip" several sets of actors (servers hosting software) between production, test, training, and integration upon each release.

In most cases, a single actor (person or hardware) can execute multiple processes which can participate in multiple environments. For example, a single computer server can host software that performs production transactions while also hosting other software that performs test or training functions.

Normally, a single instance of an actor should participate in only one environment at a time. On very rare occasion, a single actor can be shared across environments if the intents are mutually compatible. Most of the time, it is very unwise to attempt such sharing because the intents are not really compatible. A perfect example is running a test process on a server that also supports production processes, resulting in downtime because the test caused the entire server to fail.

Therefore, the intent of an environment must be construed with very wide latitude, to include concepts such as availability, reliability, performance, disaster recovery, accuracy, precision, repeatability, longevity, etc. This means that the actors and processes must often be construed to include things like providing power, cooling, backups, and redundancy.

Finally, note that the situation can get quite complex. For example, a desktop computer (actor) may be tasked by the development team (sponsor) to host their source control (process), which the team relies upon for their primary jobs (production). Nevertheless, the IT staff sees that same desktop computer as simply a developer workstation (development, not production) and treats it with contempt and nonchalance when it develops a hardware problem. But the developers are producing production code, so aren't they also part of production? Perspective matters.

EDIT: Production quality

A solid verification (testing) methodology should take packaged code from development and run it through a series of tests (integration, TQA, functional, regression, acceptance, etc.) until it comes out the other side "stamped" for production use. However, that makes the package production quality, but not actually production. The package only becomes production when a sponsor actually deploys it into an environment with that ultimate level of intent.

However, if your organization merely produces that package (its product) for the consumption of others, then such a release comes as close to production as that organization will experience with respect to that product, so it is common to stretch the term production to apply rather than clarify that it is production quality. In reality, that organization's production environment consists of the actors and processes involved in its development/release efforts that result in that product.

I said it could get quite complex...

Answer 5

Any code that will be used by it's intended userbase would fit into my definition of 'production code'.

Of course, the grey area in that definition would be clearly defining who your userbase is.

G-Man

Answer 6

• 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

Answer 7

I think the best way to describe it, is as any code that "leads-to" deployment and "follows-up" deployment. Deployment itself is defined as all of the activities that make a software system available for use. If your code is ready to be used by people, in-house or otherwise, then it is production code.

Answer 8

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

Answer 9

The term "production code" mixes two different concepts. One is deployment management and the other is release life cycle.

In the strict sense of the word, a system is in production when it is being used as part of business or service operation. What's not in production are development, testing, QA, demo, and staging system. Production system does not immediately imply quality.

From release life cycle's point of view, a "production" build is the build that is released to general public or clients. It is the stage after pre-alpha, alpha, beta, (feature complete, code complete, etc.) and release candidate. For shrink-wrap products that cannot easily deploy updates, reaching the production stage likely implies series of testing and bug fixes.