Definisci "pronto per la produzione"

Dipende da chi sei.

Definizione del programmatore di "pronto alla produzione":

• viene eseguito
• soddisfa i requisiti del progetto
• il suo design era ben pensato
• è stabile
• è gestibile
• è scalabile
• è documentato

Definizione di gestione di "pronto alla produzione":

• viene eseguito
• diventerà un profitto

Mi spiace riprendere questa vecchia domanda, ma mi è capitato di attraversarlo e non ho potuto resistere.

Generale, "X non è pronto per la produzione" significa che ci sono problemi con funzionalità mancanti, stabilità e / o scalabilità, in modo che sia utilizzabile per scenari meno impegnativi, ma potrebbe fallire per distribuzioni su larga scala (implementazioni a livello aziendale e Internet) .

Esistono molte definizioni che possono essere utilizzate per "produzione pronta".

I miei personali sono elencati di seguito - e sono tutti un po 'pratici e molto dipendenti dal contesto - in alcuni contesti la stessa soluzione esatta può essere considerata "pronta per la produzione" mentre in un altro contesto quella stessa soluzione - a volte letteralmente - sarà "produzione pronta sul mio cadavere".

Le definizioni sottostanti presuppongono che la "produzione" abbia un contesto in cui "alcuni risultati seri dipendono dal buon funzionamento del prodotto".

• In altre parole, il software che gestisce il tuo forum "Le orchidee migliori per crescere in Nevada" ti consente di guadagnare $ 3 al mese in entrate AdSense al di fuori del contesto di produzione, mentre il firmware Space Shuttle è saldamente in tale contesto. / p>

• Tutto il resto su una scala, con alcune cose un po 'grigie (ad esempio, alcuni software che fanno ricerca accademica - da un lato non c'è un impatto evidente sulla produzione se si rompe in una situazione generica; le decisioni politiche dei trilioni di dollari vengono prese dai governi sulla base di ricerche specifiche).

2 definizioni che posso venire ora sono:

1. Può essere utilizzato per scopi che, quando le cose si rompono, implicano perdite materiali, nell'ambito di un'analisi di rischio standard.

   Questo non significa una garanzia di mancanza di rotture / bug - nessun software può farlo - ma un ragionevole livello di certezza nella stabilità per lo scopo previsto.

   es. il vantaggio dell'utilizzo di questa soluzione supera l'entità delle potenziali perdite derivanti dalla rottura moltiplicate per la probabilità che si rompa.

   Quindi, il famigerato disconoscimento di "non usare nelle centrali nucleari" di Java.

2. Si può ragionevolmente presumere che abbia passato la Due Diligence dai tuoi colleghi.

   Ad esempio, se, in caso di una causa, viene chiesto un set di N esperti casuali del tuo campo dato "dati questi dettagli, questa produzione era pronta?", sei ragionevolmente sicuro che la maggior parte di questi esperti sarebbe d'accordo con te che era pronto, basato sugli sforzi investigativi e lavorativi che si potevano ragionevolmente fare in base alle circostanze. Se non si è riusciti a scrivere più del 10% dei casi di test, si fallisce Due Diligence. Se il tuo programma è fallito a causa di un bug precedentemente sconosciuto nel compilatore gcc, probabilmente non hai fallito a meno che il tuo software non stia eseguendo qualcosa di vitale importanza che garantisse un livello di controllo necessario per aver catturato anche quel bug.

SQLite non deve essere utilizzato per i database di produzione perché è progettato esplicitamente senza molte delle funzionalità considerate "richieste". Ad esempio, i blocchi influiscono sull'intero database, non ci sono chiavi esterne e fino a SQLite3 non c'erano nemmeno tipi di dati.

Più in generale, significa che un sistema che funziona bene per un numero molto piccolo di utenti (1-5) in fase di sviluppo si bloccherà e brucerà se esposto a carichi più pesanti.

Devo dire che questo dipende dall'ambiente in cui viene utilizzata un'applicazione. Tornando all'esempio SQLite, è perfetto per l'uso in produzione se c'è un solo client. Mac OS X utilizza ampiamente SQLite attraverso il framework CoreData - credo che gestisca cose come il database musicale di iTunes dell'utente e la casella di posta iMail. Basta non provare a usarlo come un vero database client-server.

Come suggerito nell'ultima parte della domanda, "Production Ready" non è necessariamente una definizione delle dimensioni delle distribuzioni, ma piuttosto è adatto per il suo uso e le sue esigenze. Ad esempio, per un'applicazione client per utente singolo, SQLite potrebbe essere pronto per la produzione. Il mercato previsto determinerà molto spesso se un'app o un sistema è pronto per la produzione nell'uso dell'app o del sistema.

La nostra definizione interna di una build che spediremo alla produzione è molto semplice ...

• Nessun problema con Severity 1 è eccezionale; e,
• Nessun problema con Severity 2 è eccezionale che non sono contrassegnati come "conosciuti spedibili"

La decisione KS viene presa da me e da un'altra persona.

Bene, la mia versione della produzione è pronta, è stata firmata dalla direzione. Funziona, soddisfa i requisiti o la sua scalabilità, ecc. Sono già stati raggiunti prima che possiamo persino dire la parola p. La firma è un punto di uscita reciprocamente concordato dal punto di vista gestionale. Ps. Non prenderò in considerazione alcuna produzione pronta con sette bug rimanenti aperti.