Cosa definisce esattamente la produzione?

Question

Come quasi tutti quelli che hanno programmato per un po ', ho familiarità con il termine " codice di produzione " e ha un vago senso di ciò che significa. Tuttavia, qualcuno può offrire una definizione semi-rigorosa, dal momento che sembra che Wikipedia e Google non possano? Sembra che ci siano molte aree grigie in ciò che conta come produzione, come strumenti interni che sono usati da un piccolo gruppo di persone e quindi non & Quot; formalized & Quot; in termini di interfaccia utente, documentazione, ecc. e app open source complete di funzionalità, ragionevolmente prive di bug e funzionanti, ma prive di polacco, interfaccia utente e test approfonditi.

Answer 1

Produzione significa tutto ciò di cui hai bisogno per lavorare in modo affidabile e coerente.

Che si tratti di uno script di build o di un server Web pubblico.

Quando altri fanno affidamento sul tuo codice, in particolare le persone che potrebbero non capirlo (cioè anche " smart " sviluppatori ma forse non nel tuo gruppo, ma usando una libreria che hai scritto), quel codice è codice di produzione.

È produzione perché " il lavoro si ferma " e " il denaro è perso " quando il codice di produzione fallisce.

Answer 2

Quando il codice viene eseguito su un sistema di produzione, significa che viene utilizzato dal pubblico previsto in una situazione del mondo reale.

Codice di produzione, tuttavia, non significa necessariamente codice robusto, affidabile o stabile. Il WTF giornaliero fornisce numerose prove al riguardo.

Answer 3

La definizione, a quanto ho capito, è che il codice di produzione è qualsiasi codice installato o in uso su un sistema live, senza banco di prova. Un server utilizzato internamente a un'azienda è un sistema di produzione se è il sistema attivo utilizzato dai dipendenti dell'azienda. Il punto qui è che il codice in esecuzione su un server interno all'azienda che scrive il codice può essere codice di produzione.

Di solito, una buona distinzione quando si guarda al codice interno è se il gruppo che mantiene il codice è separato dal gruppo usando il codice. Se i gruppi sono separati, le probabilità sono che il codice sia codice di produzione. Se la gestione dell'azienda dipende dal codice, è sicuramente un codice di produzione, anche se sviluppato e gestito internamente.

Answer 4

EDIT: la risposta breve: se stai " puntando la fattoria su di esso " ;, è " produzione " .

Questa è una grande domanda: una distinzione assolutamente critica che di routine mette tutti nei guai a causa di incomprensioni. La domanda su cosa sia & Quot; produzione & Quot; è un sottoinsieme della domanda correlata di cos'è un " ambiente " ;.

  

Quindi parte della risposta è che " produzione " è IL " ambiente " questo è il più    importante ed è più attendibile come IL " reale " cosa.

Quindi ora dobbiamo definire " ambiente " (e quindi rivisitare " produzione "). Siamo ancora lontani da una risposta soddisfacente.

Noi programmatori usiamo il termine " ambiente " fare costantemente riferimento a sistemi informatici costituiti da hardware che esegue software. Quel software è il codice che abbiamo scritto più il software da cui dipende, che è stato scritto da altri. Scriviamo il nostro codice e lo integriamo con l'altro software, quindi di solito eseguiamo il software integrato attraverso una serie crescente di test (test unitari, test di integrazione, test funzionali, test di accettazione, test di regressione, ecc.), Fino a quando non eseguiamo finalmente il software integrato nel modo in cui era previsto.

Naturalmente, non tutto è completamente automatizzato. Di solito ci sono numerose persone coinvolte e hanno processi manuali da eseguire. Noi programmatori cerchiamo modi per automatizzare il maggior numero possibile di questi processi, ma c'è sempre un & Quot; limite uomo / macchina & Quot; nei sistemi su cui lavoriamo. Spesso ci sono molti di questi limiti in ogni caso particolare.

D'altra parte, potrebbe non esserci alcuna automazione significativa. Ad esempio, abbiamo parlato di & Quot; produzione & Quot; molto tempo fa quando avevamo una stanza piena di persone che svolgevano lavoro manuale che produceva un prodotto . Quindi, non ci deve essere alcuna automazione presente nella nostra & Quot; produzione & Quot; quot &; & ambiente quot ;. C'è anche una via di mezzo, in cui l'automazione coinvolta non include software, come nel caso di una persona che esegue un telaio per tessere tessuti.

Inoltre, potrebbe non esserci un prodotto , poiché abbiamo adattato la nostra lingua di " produzione " quot &; & ambiente quot; per includere fornitori di servizi senza prodotto.

Allo stesso modo, i test potrebbero non riguardare software, dal momento che potremmo testare una macchina non guidata da software (ad esempio il telaio) o persino le persone (formazione e valutazione).

Ora abbiamo toccato tutti gli elementi cruciali di un "ambiente":

• c'è uno scopo, un intent , perseguito
• un sponsor richiede un intender, quindi deve esserci un processes (una persona o gruppo, ma non una macchina) che specifica il actors
• che environment è perseguito attraverso vari sponsor's che sono eseguiti da vari product
• quelle service potrebbero essere persone, potrebbero essere software in esecuzione su hardware o loro potrebbero essere macchine non basate su software, quindi potrebbe essere presente o meno l'automazione

Ora possiamo definire correttamente e completamente i nostri termini originali.

  

Un production è composto da tutti i test e dai loro integration che   collaborare per perseguire un particolare training per conto del suo actor . Quello   indica l'esecuzione di software su hardware, ovvero macchine non basate su software e così via   significa che le persone eseguono i loro vari duties. È il environments principalmente   definisce un intents , non il suo process o il suo development .

Inoltre ...

  

Se il testing perseguito in un particolare tests è il   <=> obiettivo finale, che di solito comporta la produzione di un <=> o   fornendo un <=> in cambio di denaro, quindi ci riferiamo a quello   <=> come <=> .

Ora possiamo andare un po 'oltre.

  

Se il <=> perseguito in un <=> è la verifica di   <=> e il loro <=> in preparazione a <=> , chiamiamo   che un <=> <=> .

     

Lo chiamiamo inoltre <=> <=> se il test prevede   unione iniziale di individui o gruppi significativi di <=> e   loro <=> .

     

Se quella preparazione implica il " programmazione " di <=> umani per esibirsi in nuovi   <=> o la successiva verifica (valutazione), quindi chiamiamo a   <=> <=> .

Armati di queste distinzioni e definizioni, ora possiamo capire diversi scenari comuni.

Un <=> può essere etichettato erroneamente con un nome che non corrisponde al suo <=> , come quando un <=> l'ambiente è usato come <=> .

Un <=> può essere utilizzato in modo grave, ad esempio quando <=> o <=> viene eseguito in < => .

Un <=> può essere travisato, ad esempio quando la chiave <=> o <=> non viene identificata (ad es. manuale riconciliazioni, o addirittura ignorando del tutto le persone).

Un <=> può essere ridisegnato, riutilizzando i suoi <=> e <=> in un nuovo <= > . Una tecnica di grande successo per alcune organizzazioni è quella di eseguire & Quot; capovolgere & Quot; diverse serie di <=> (server che ospitano software) tra <=> , <=> , <=> e <=> su ogni versione.

Nella maggior parte dei casi, un singolo <=> (persona o hardware) può eseguire più <=> che possono partecipare a più <=> . Ad esempio, un singolo server di computer può ospitare software che esegue transazioni <=> mentre ospita anche altri software che esegue <=> o <=> funzioni.

Normalmente, una singola istanza di un <=> dovrebbe partecipare a un solo <=> . In occasioni molto rare, è possibile condividere un singolo <=> su <=> se i <=> sono reciprocamente compatibili. Il più delle volte, è molto imprudente tentare tale condivisione perché i <=> non sono realmente compatibili. Un esempio perfetto è l'esecuzione di un <=> <=> su un server che supporta anche <=> <=> , con conseguente downtime perché il <=> ha causato il fallimento dell'intero server.

Pertanto, il <=> di un <=> deve essere interpretato con una latitudine molto ampia, per includere concetti come disponibilità , affidabilità , prestazioni , disaster recovery , accuratezza , precisione , ripetibilità , longevità , ecc. Ciò significa che <=> e <=> devono spesso essere interpretati per includere elementi come < em> fornire energia , raffreddamento , backup e ridondanza .

Infine, nota che la situazione può diventare piuttosto complessa. Ad esempio, un computer desktop ( <=> ) può essere incaricato dal team di sviluppo ( <=> ) di ospitare il controllo del codice sorgente ( <=> ), su cui il team fa affidamento per i loro lavori principali ( <=> ). Tuttavia, lo staff IT vede lo stesso computer desktop come una semplice workstation per sviluppatori ( <=> , non <=> ) e lo tratta con disprezzo e nonchalance quando sviluppa un problema hardware. Ma gli sviluppatori stanno producendo <=> , quindi non fanno anche parte di <=> ? Le prospettive contano.

EDIT: qualità della produzione

Una solida metodologia di verifica ( <=> ) dovrebbe prendere il codice impacchettato da <=> ed eseguirlo attraverso una serie di <=> (integrazione, TQA, funzionale, regressione, accettazione, ecc.) fino a quando non viene visualizzato " timbrato " per <=> uso. Tuttavia, ciò rende il pacchetto <=> qualità , ma in realtà non <=> . Il pacchetto diventa <=> quando un <=> lo distribuisce effettivamente in un <=> con l'ultimo livello di < => .

Tuttavia, se la tua organizzazione produce semplicemente quel pacchetto (il suo <=> ) per il consumo di altri, tale rilascio si avvicina al <=> come l'organizzazione sperimenterà rispetto a quel <=> , quindi è comune allungare il termine <=> da applicare anziché chiarire che è <= > qualità . In realtà, l'ambiente <=> di quell'organizzazione è costituito dai <=> e <=> coinvolti nei suoi sforzi di sviluppo / rilascio che si traducono in che <=> .

Ho detto che potrebbe diventare piuttosto complesso ...

Answer 5

Qualsiasi codice che verrà utilizzato dalla base utente prevista si adatterà alla mia definizione di "codice di produzione".

Ovviamente, l'area grigia in quella definizione definirebbe chiaramente chi è la tua base di utenti.

G-Man

Answer 6

• Il software di produzione può funzionare al carico di lavoro necessario senza interruzione o degrado del servizio
• Il software è stato testato con successo in diversi scenari di produzione
• Trasformazione del prototipo funzionante in software di produzione che funziona su un'architettura ridondante a prova di errore che può funzionare in affari reali, ovvero ambiente di produzione, necessità di tempo, refactoring del codice e attenzione ai dettagli
• Il codice di produzione ha un livello accettabile di manutenibilità ed è ragionevolmente ben commentato
• Il manuale della documentazione spiega la funzionalità, tutte le caratteristiche e facilita la manutenzione
• Se il software di produzione è un servizio o un'applicazione internazionale, deve essere localizzato
• Il codice di produzione viene utilizzato dagli utenti finali, spesso clienti nelle condizioni descritte nel Contratto di servizio
• Software di produzione non significa necessariamente software affidabile mission-critical
• Il software funziona bene, cosa doveva fare
• I file di registro forniscono una descrizione accurata delle prestazioni di runtime e metriche e rapporti sull'affidabilità del software che facilitano il debug e la manutenibilità del software

Answer 7

Penso che il modo migliore per descriverlo sia come qualsiasi codice che " conduce a " distribuzione e " follow-up " distribuzione. La distribuzione stessa è definita come tutte le attività che rendono un sistema software disponibile per l'uso. Se il tuo codice è pronto per essere utilizzato da persone, internamente o meno, allora è un codice di produzione.

Answer 8

In parole semplici " Codice di produzione che è attivo e in uso dal pubblico previsto "

Answer 9

Il termine " codice di produzione " mescola due concetti diversi. Uno è la gestione della distribuzione e l'altro è rilascia il ciclo di vita .

Nel senso stretto della parola, un sistema è in produzione quando viene utilizzato come parte di operazioni aziendali o di servizio. Ciò che non è in produzione sono lo sviluppo, i test, il QA, la demo e il sistema di gestione temporanea. Il sistema di produzione non implica immediatamente la qualità.

Dal punto di vista del ciclo di vita del rilascio, un " produzione " build è la build rilasciata al pubblico o ai clienti. È il palcoscenico dopo pre-alfa, alfa, beta, (funzione completa, codice completo, ecc.) E rilascio candidato. Per i prodotti termoretraibili che non sono in grado di distribuire facilmente gli aggiornamenti, il raggiungimento della fase di produzione implica probabilmente una serie di test e correzioni di errori.