Definire "pronto per la produzione"

Sono stato curioso di questo per un po '. Cosa si intende esattamente per "pronto per la produzione" o per le sue varianti? Più di recente stavo cercando informazioni su sqlite e ho trovato questo thread , dove molte persone suggeriscono che sqlite non è pronto per la produzione.

Conosco la differenza tra sviluppo / test e produzione; la mia definizione di produzione è tutto ciò che viene fornito al cliente o sarà utilizzato da non programmatori.

Tuttavia, sembrano esserci molti articoli che non sono definiti pronti per la produzione. Ma in realtà, potrebbero essere perfettamente adatti e le persone hanno solo un predujice contro di loro, ad esempio sqlite, python, prodotti non MS, ecc.

Piccolo ufficio contro impresa? Utente singolo vs. utente multiplo? Client vs. server? Dove disegni la linea?

Dipende da chi sei.

Definizione del programmatore di "pronto per la produzione":

• corre
• soddisfa i requisiti del progetto
• il suo design è stato ben pensato
• è stabile
• è mantenibile
• è scalabile
• è documentato

Definizione del management di "pronto per la produzione":

• corre
• trasformerà un profitto

Mi dispiace riproporre questa vecchia domanda, ma mi è capitato di incontrarla e non ho potuto resistere.

In generale, "X non è pronta per la produzione" significa che ci sono problemi con funzionalità mancanti, stabilità e / o scalabilità, quindi è utilizzabile per scenari meno impegnativi ma potrebbe non riuscire per distribuzioni su larga scala (distribuzioni 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 in qualche modo 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 che seguono presuppongono che la "produzione" abbia un contesto di "alcuni risultati seri dipendono dal buon funzionamento del prodotto".

• In altre parole, il software che esegue il tuo forum gratuito "Le migliori orchidee per crescere in Nevada", guadagnando $ 3 / al mese in entrate AdSense non rientra nella produzione ", mentre il firmware di Space Shuttle è saldamente in quel contesto.

• Tutto il resto su una scala, con alcune cose un po 'grigie (ad esempio, alcuni software che fanno ricerche accademiche - da un lato non vi è alcun evidente impatto sulla produzione se si rompe in una situazione generica; dall'altro le decisioni politiche da svariati trilioni di dollari sono fatto dai governi sulla base di alcune ricerche specifiche).

2 definizioni che posso trovare ora sono:

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

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

   Ad esempio, il vantaggio derivante dall'utilizzo di questa soluzione supera l'entità delle potenziali perdite dovute alla rottura moltiplicate per la probabilità che si rompa.

   Quindi, il famigerato disclaimer di Java "non utilizzabile in centrali nucleari".

2. Si può ragionevolmente prevedere che i tuoi colleghi abbiano superato la Due Diligence.

   Ad esempio, se, nel caso di una causa legale, viene chiesto a una serie di N esperti casuali del proprio campo "dati questi dettagli, questa produzione era pronta?", Sei ragionevolmente sicuro che la maggior parte di tali esperti sarebbe d'accordo con te sul fatto che fosse pronto, in base agli sforzi investigativi e di lavoro che potresti aver ragionevolmente fatto in tali circostanze. Se non si riesce a scrivere più del 10% dei casi di test, non si verifica Due Diligence. Se il tuo programma non è riuscito a causa di un bug precedentemente sconosciuto nel compilatore gcc, probabilmente non hai fallito a meno che il tuo software non eseguisse qualcosa di importante per la vita che garantiva un livello di controllo necessario per aver colto anche quel bug.

SQLite non deve essere utilizzato per i database di produzione perché è esplicitamente progettato senza molte delle funzionalità considerate "obbligatorie". Ad esempio, i blocchi influiscono sull'intero database, non esistono 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 arresta in modo anomalo e si brucia se esposto a carichi più pesanti.

Devo dire che questo dipende anche dall'ambiente in cui viene utilizzata un'applicazione. Tornando all'esempio di SQLite, è perfetto per l'uso in produzione se esiste un solo client. Mac OS X utilizza ampiamente SQLite attraverso il framework CoreData - credo che gestisca cose come il database musicale 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 all'uso e ai requisiti previsti. Ad esempio, per un'app 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 durante l'uso dell'app o del sistema.

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

• Nessun problema di gravità 1 in sospeso; e,
• Non sono presenti problemi di gravità 2 che non sono contrassegnati come "Disponibile per spedizioni"

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

Bene, la mia opinione sulla produzione è pronta, è stata approvata dalla direzione. Funziona, soddisfa i requisiti o la sua scalabilità, ecc. Sono già stati soddisfatti prima ancora di poter dire la parola p. La disconnessione è un punto di uscita reciprocamente concordato dal punto di vista della gestione. Ps. Non prenderò in considerazione nulla di pronto per la produzione con sette bug rimasti aperti.