Definir "pronto para produção"

Estou curioso sobre isso há um tempo. O que exatamente se entende por "pronto para produção" ou suas variantes? Mais recentemente, eu estava procurando informações sobre o sqlite e encontrei esse segmento , onde muitas pessoas sugerem que o sqlite não está pronto para produção.

Eu sei a diferença entre desenvolvimento / teste e produção; minha definição de produção é qualquer coisa que seja fornecida ao cliente ou que seja usada por não programadores.

No entanto, parece haver muitos itens que não estão definidos como prontos para produção. Mas, na realidade, eles podem ser perfeitamente adequados e as pessoas têm uma predujice contra eles, por exemplo, sqlite, python, produtos que não são da Microsoft, etc.

Escritório pequeno vs. empresa? Usuário único x multiusuário? Cliente x servidor? Onde você desenha a linha?

Depende de quem você é.

Definição do programador de "pronto para produção":

• corre
• satisfaz os requisitos do projeto
• seu design foi bem pensado
• é estável
• é sustentável
• é escalável
• está documentado

Definição da gerência de "pronto para produção":

• corre
• vai dar lucro

Desculpe refazer esta pergunta antiga, mas eu a encontrei e simplesmente não pude resistir.

Geral, "X não está pronto para produção" significa que há problemas com recursos ausentes, estabilidade e / ou escalabilidade, de modo que é utilizável em cenários menos exigentes, mas pode falhar em implantações em grande escala (implantações em nível de empresa e Internet).

Existem muitas definições que podem ser usadas para "produção pronta".

Meus dados pessoais estão listados abaixo - e todos são um tanto práticos e muito dependentes do contexto - em alguns contextos a mesma solução exata pode ser considerada "pronta para produção", enquanto em outro contexto a mesma solução será - às vezes literalmente - " produção pronta sobre o meu cadáver ".

As definições abaixo assumem que "produção" tem um contexto de "algum resultado sério depende da execução bem-sucedida do produto".

• Em outras palavras, o software que executa o seu fórum gratuito "melhores orquídeas para crescer em Nevada", ganhando US $ 3 / mês em receita do AdSense, fica muito fora do contexto de produção ", enquanto o firmware do ônibus espacial está firmemente nesse contexto.

• Tudo em uma escala, com algumas coisas um pouco cinzentas (por exemplo, alguns softwares fazendo pesquisas acadêmicas - por um lado, não há impacto óbvio na produção se ocorrer uma situação genérica; por outro lado, decisões políticas multibilionárias são sendo feitos pelos governos com base em pesquisas específicas).

As duas definições que posso apresentar agora são:

1. Pode ser usado para fins que, quando as coisas quebram, implicam perdas materiais, sob uma análise de risco padrão.

   Isso não significa uma garantia de falta de falhas / bugs - nenhum software pode fazer isso - mas um nível razoável de certeza na estabilidade para a finalidade pretendida.

   Por exemplo, o benefício de usar esta solução supera a magnitude das perdas em potencial resultantes da quebra multiplicada pela probabilidade de quebra.

   Portanto, o infame aviso "infame de Java para uso em usinas nucleares".

2. Pode-se razoavelmente esperar que tenha passado a Due Diligence por seus colegas.

   Por exemplo, se, no caso de uma ação judicial, for perguntado a um conjunto de N especialistas aleatórios de um determinado campo "dados esses detalhes, essa produção está pronta?", Você tem certeza razoável de que a maioria desses especialistas concordaria com você que era pronto, com base nos esforços de investigação e trabalho que você poderia ter razoavelmente feito nessas circunstâncias. Se você não conseguiu escrever mais de 10% dos casos de teste, falhou na Due Diligence. Se o seu programa falhou devido a um bug anteriormente desconhecido no compilador gcc, você provavelmente não falharia, a menos que o seu software estivesse executando algo de importância vital que justificasse um nível de escrutínio necessário para detectar esse bug.

O SQLite não deve ser usado para bancos de dados de produção porque foi projetado explicitamente sem muitos dos recursos considerados "necessários". Por exemplo, os bloqueios afetam o banco de dados inteiro, não há chaves estrangeiras e, até o SQLite3, não havia nenhum tipo de dado.

De maneira mais geral, significa que um sistema que funciona bem para um número muito pequeno de usuários (1-5) em desenvolvimento travará e queimará quando exposto a cargas mais pesadas.

Devo mencionar que isso depende do ambiente em que o aplicativo também é usado. Voltando ao exemplo do SQLite, é perfeito para uso em produção se houver apenas um cliente. O Mac OS X usa o SQLite extensivamente através da estrutura CoreData - acredito que lida com coisas como o banco de dados de músicas do iTunes do usuário e a caixa de correio do iMail. Apenas não tente usá-lo como um banco de dados cliente-servidor real.

Como você sugere na parte final da pergunta, "Production Ready" não é necessariamente uma definição do tamanho das implantações, mas é adequado para o uso e os requisitos pretendidos. Por exemplo, para um aplicativo cliente de usuário único, o SQLite pode estar pronto para produção. O mercado pretendido geralmente determina se um aplicativo ou sistema está pronto para produção no uso do aplicativo ou sistema.

Nossa definição interna de uma compilação que enviaremos para produção é muito simples ...

• Nenhum problema de gravidade 1 está pendente; e,
• Não há problemas de gravidade 2 pendentes que não estejam marcados como "expedível conhecido"

A decisão da KS é tomada por mim e mais uma pessoa.

Bem, minha opinião sobre a produção pronta é que foi assinada pela gerência. Ele roda, atende aos requisitos ou sua escalabilidade etc. já foram cumpridos antes que possamos dizer a palavra p. A assinatura é um ponto de saída acordado mutuamente do ponto de vista do gerenciamento. Ps. Não considerarei nada de produção pronto com set 4 bugs restantes em aberto.