Définissez «prêt pour la production»

Cela fait un moment que je suis curieux. Qu'entend-on exactement par «prêt pour la production» ou ses variantes? Plus récemment, je cherchais des informations sur sqlite et j'ai trouvé ce fil , où beaucoup de gens suggèrent que sqlite n'est pas prêt pour la production.

Je connais la différence entre le développement / test et la production; ma définition de la production est tout ce qui est fourni au client ou qui sera utilisé par des non-programmeurs.

Cependant, il semble y avoir de nombreux éléments qui ne sont pas définis comme prêts pour la production. Mais en réalité, ils peuvent être parfaitement adaptés et les gens ont juste un prédujice contre eux, par exemple sqlite, python, produits non MS, etc.

Petit bureau ou entreprise? Utilisateur unique ou multi-utilisateurs? Client vs serveur? Où tracez-vous la ligne?

Ça dépend de qui vous êtes.

Définition du programmeur de "prêt pour la production":

• ça court
• il satisfait aux exigences du projet
• son design a été bien pensé
• c'est stable
• c'est maintenable
• c'est évolutif
• c'est documenté

Définition par la direction de "prêt pour la production":

• ça court
• ça va faire du profit

Désolé de reprendre cette vieille question, mais je suis tombée dessus et je n'ai pas pu résister.

Général, «X n'est pas prêt pour la production» signifie qu'il y a des problèmes de fonctionnalités, de stabilité et / ou d'évolutivité manquantes, de sorte qu'il est utilisable pour des scénarios moins exigeants mais peut échouer pour les déploiements à grande échelle (déploiements de niveau entreprise et Internet).

Il existe de nombreuses définitions qui peuvent être utilisées pour «prêt pour la production».

Les miens personnels sont énumérés ci-dessous - et ils sont tous quelque peu pratiques et très dépendants du contexte - dans certains contextes, la même solution exacte peut être considérée comme "prête pour la production" tandis que dans un autre contexte, cette même solution sera - parfois littéralement - " production prête sur mon cadavre ".

Les définitions ci-dessous supposent toutes que la "production" a un contexte où "certains résultats sérieux dépendent du bon fonctionnement du produit".

• En d'autres termes, les logiciels exécutant votre forum gratuit "Les meilleures orchidées pour grandir au Nevada" vous rapportant 3 $ / mois de revenus AdSense ne se situent pas dans le contexte de la production ", tandis que le firmware de la navette spatiale est fermement dans ce contexte.

• Tout le reste sur une échelle, avec certaines choses un peu grises (par exemple, certains logiciels faisant de la recherche universitaire - d'une part, il n'y a pas d'impact évident sur la production s'il se casse dans une situation générique; d'autre part, des décisions politiques de plusieurs billions de dollars sont par les gouvernements sur la base de recherches spécifiques).

2 définitions que je peux trouver maintenant sont:

1. Peut être utilisé à des fins qui, lorsque les choses se cassent, impliquent des pertes matérielles, dans le cadre d'une analyse de risque standard.

   Cela ne signifie pas une garantie de l'absence de casse / bogues - aucun logiciel ne peut le faire - mais un niveau raisonnable de certitude dans la stabilité pour le but prévu.

   Par exemple, les avantages de l'utilisation de cette solution l'emportent sur l'ampleur des pertes potentielles dues à la rupture multipliée par la probabilité de rupture.

   Par conséquent, la fameuse clause de non-responsabilité de Java «ne pas utiliser dans les centrales nucléaires».

2. On peut raisonnablement s'attendre à ce que vos pairs aient passé le contrôle préalable.

   Par exemple, si, en cas de procès, on demande à un ensemble de N experts aléatoires de votre domaine "étant donné ces détails, cette production était-elle prête?", Vous êtes raisonnablement sûr que la plupart de ces experts conviendraient avec vous que c'était prêt, sur la base des efforts d'enquête et de travail que vous auriez pu raisonnablement faire dans les circonstances. Si vous n'avez pas réussi à écrire plus de 10% de cas de test, vous échouez à la vérification diligente. Si votre programme a échoué en raison d'un bogue auparavant inconnu dans le compilateur gcc, vous n'avez probablement pas échoué à moins que votre logiciel n'exécute quelque chose de vital qui justifie un niveau d'examen nécessaire pour avoir détecté même ce bogue.

SQLite ne doit pas être utilisé pour les bases de données de production car il est explicitement conçu sans la plupart des fonctionnalités considérées comme "requises". Par exemple, les verrous affectent la base de données entière, il n'y a pas de clés étrangères et jusqu'à SQLite3, il n'y avait même pas de types de données.

Plus généralement, cela signifie qu'un système qui fonctionne bien pour un très petit nombre d'utilisateurs (1 à 5) en développement se plantera et brûlera lorsqu'il sera exposé à des charges plus lourdes.

Je dois mentionner que cela dépend également de l'environnement dans lequel une application est utilisée. Pour revenir à l'exemple SQLite, il est parfait pour une utilisation en production s'il n'y a qu'un seul client. Mac OS X utilise largement SQLite via le framework CoreData - je crois qu'il gère des choses comme la base de données musicale iTunes de l'utilisateur et la boîte aux lettres iMail. N'essayez simplement pas de l'utiliser comme une véritable base de données client-serveur.

Comme vous le suggérez dans la dernière partie de la question, «Production Ready» n'est pas nécessairement une définition de la taille des déploiements, mais est plutôt adapté à son utilisation et à ses exigences. Par exemple, pour une application cliente mono-utilisateur, SQLite peut être prêt pour la production. Le marché visé déterminera le plus souvent si une application ou un système est prêt pour la production dans son utilisation de l'application ou du système.

Notre définition interne d'une construction que nous expédierons à la production est très simple ...

• Aucun problème de gravité 1 n'est en suspens; et,
• Aucun problème de gravité 2 n'est en suspens et n'est pas marqué comme «expédiable connu»

La décision KS est prise par moi et une autre personne.

Eh bien, ma vision de la production est prête, elle a été approuvée par la direction. Il fonctionne, répond aux exigences ou son évolutivité, etc. sont déjà remplies avant même de pouvoir dire le mot p. La signature est un point de sortie mutuellement convenu du point de vue de la gestion. Ps. Je ne considérerai rien de prêt pour la production ayant un bug de 4 qui reste ouvert.