Desenvolvendo em um servidor de produção

Hoje fui criticado por desenvolver um aplicativo em um servidor de produção. Citação, "o desenvolvimento em um servidor de produção não é aceitável - nunca! "

Aqui está a situação.

1. Eu configurei uma instância de desenvolvimento: http://example.com:3000
2. A instância de produção é: http://example.com
3. Concluo todo o meu trabalho de desenvolvimento http://example.com:3000e, quando o cliente está satisfeito com as alterações, eu as passo para http://example.com.

O aplicativo em que estou trabalhando é um aplicativo antigo do Ruby on Rails , e devo dizer que, inicialmente, tentei configurar um ambiente de desenvolvimento localmente, mas nunca consegui executá-lo. Depois de tentar por um tempo, desisti e decidi desenvolver no servidor de produção.

Mais uma vez, eu sou um idiota? Provavelmente sim, mas estou desenvolvendo web há alguns anos e nunca encontrei uma situação como essa. Quem está certo e por quê?

Eu costumava desenvolver no servidor de produção. Pode funcionar bem, mas é desaconselhável por pelo menos dois motivos:

1. O código de desenvolvimento pode causar loops infinitos, vazamentos de memória ou outros problemas que bloqueiam a CPU, consomem toda a memória ou afetam o servidor de uma maneira que afeta o código de produção.
2. Se você precisar fazer alterações nos componentes do ambiente do servidor como parte do seu trabalho de desenvolvimento, como a versão do Ruby ou MySQL ou qualquer outra coisa, você estará em uma situação complicada.

Como outros já declararam, a codificação no ambiente PROD expõe seus usuários a seus erros. Mesmo se você iniciou uma instância diferente, ainda possui recursos de hardware compartilhados e ainda pode acessar arquivos e bancos de dados de produção. E, como alguns comentários apontam, se sua instância de desenvolvedor for invadida (por exemplo, porque você se esquece de limpá-la e alguém descobrir uma enorme exploração de segurança no Rails), agora você terá uma máquina acessível ao público com seu aplicativo em funcionamento como uma entrada. O que seria ... lamentável.

Empresas diferentes têm respostas diferentes para isso, mas geralmente pode ser dividido assim:

• Ocorreu um erro?
• Quanto tempo levaria para reverter uma alteração (eu trabalho principalmente em C ++, portanto, reverter um binário pode demorar significativamente mais do que em Ruby, especialmente quando você "perdeu" o binário antigo e precisa recompilar)
• Qual o efeito da mudança (guia áspero: estragar os dados armazenados é assim muito pior do que não armazenar ou exibir dados, que por sua vez é pior do que não mostrando a página em tudo)
• Se você estragou tudo e saiu pela porta, alguém saberia o que você fez?
• Havia outra opção de implantação que teria evitado / minimizado / detectado a falha antes do impacto?

Isso fornece o cálculo final:

• Quanto custaria esse negócio completamente evitável?

Agora, é assim que menos toda a sua estrutura de gerenciamento vale para quem toma decisões de orçamento. Daí shouty.

Se você estiver trabalhando na página interna "Sobre nós" da empresa e digitar seu próprio nome como L. "Deus", Thomas, problema de apelido embaraçoso; se você estiver trabalhando no aplicativo de compras essencial para os negócios e acabar acidentalmente em texto sem formatação, depurando os detalhes do cartão de crédito na página inicial ... problema de ação judicial. Entre esses extremos, há tudo, desde descargas incorretas, produtividade debilitante e todas as outras coisas que podem afastar os clientes.

O motivo para não permitir isso, mesmo para a página "Sobre nós", é que a codificação diretamente na produção é viciante . Você começa fazendo isso apenas para menores de idade, mas, com o tempo, é muito mais rápido não ter que colocar o DEV em risco.

Além disso, o tamanho da empresa pode ter um grande efeito. Em uma equipe de dois homens, quando algo dá errado, você se inclina sobre o ombro e diz "Oi, idiota, coloque de volta". Em uma empresa de 300 pessoas, você deve começar a se preocupar se isso é incompetência ou malícia, os gerentes podem ser responsabilizados por coisas sobre as quais não têm controle, etc.

No final do dia, se você seguir o procedimento e estragar tudo, eles verificam o que há de errado com o procedimento. Se você evitar o procedimento e estragar tudo, agora é sua responsabilidade, mesmo que a culpa se espalhe um pouco. Se você deseja jogar os dados, isso é com você.

Tentei configurar um ambiente de desenvolvimento localmente, mas nunca consegui executá-lo. Depois de tentar por um tempo, desisti e decidi desenvolver no servidor de produção.

Apoio as declarações para EVITAR o desenvolvimento em um servidor de produção. Você só pode justificá-lo sob a GUN, se for uma correção de erro de digitação no arquivo de configuração e insistido pelo seu gerente.

WHY NOT?- Porque, é muito arriscado e pron tornar - se um hábito mais tarde que o pegaria muito mal. Porque erros / falhas fatais de produção podem custar a sua demissão do seu trabalho.

Deixe-me repeti-lo novamente, mesmo que você tenha solicitado a correção de erros de digitação no productionservidor, primeiro faça-o Staging. ou em outras palavras, teste suas alterações, teste-as e teste-as novamente antes de iniciar a produção.

Isso é algo que acontece frequentemente em lugares onde a cultura do "faça rápido e sujo " parece ser uma norma.

Editar: Desenvolver no servidor de produção, como um ambiente separado, também NÃO é aceitável . Quaisquer problemas causados ​​no seu trabalho podem simplesmente derrubar o servidor de produção e afetar o desempenho do aplicativo de produção . Como exemplo, lembro-me de um caso em que havia uma falha de segurança, quando meu colega de trabalho anterior tentou usar o servidor de produção WinServer 2003 para fins de desenvolvimento.

Este é realmente um problema de protocolo. Geralmente, isso não é algo que você gostaria de fazer. Você deseja deixar as máquinas de produção em paz. Eles podem conter dados confidenciais e você não deseja comprometer o desempenho ou a estabilidade dos sites de produção com código pronto para não produção.

Dito isto, há momentos em que isso geralmente é feito. Se você estiver em uma posição em que está realizando brouchureware com pouco tráfego ou sites simples do CMS, isso provavelmente será um problema menor. Mas se você estiver trabalhando em algo com dados confidenciais ou processos "críticos para os negócios", não deve se arriscar a ter código de desenvolvimento na mesma máquina.

Outro motivo importante para não se desenvolver diretamente na produção é que uma instância de desenvolvimento geralmente produz e mostra erros detalhados e rastreia a pilha. Você nunca deseja expor isso ao usuário.

Sim, você pode registrá-los em vez de mostrá-los ao cliente, mas isso torna a depuração muito menos divertida do que já é.

Adicionado Resolvendo o problema de ter problemas com sua instância de desenvolvimento: tive grande sucesso ao implantar uma VM baseada em VirtualBox que duplica nosso ambiente de produção (exclusivo de hardware, é claro) com um servidor Ubuntu .

Estou surpreso que ninguém tenha mencionado o motivo mais importante ainda, por que é absolutamente proibido desenvolver em servidores de produção:

Não mexa com dados de produção, o que pode acontecer com tanta facilidade!

Um pequeno erro em um local leva a problemas gigantescos em outros cálculos e, no dia seguinte, todos os dados são lixo e o cliente está chateado. Isso é muito, muito pior do que um bug na interface do usuário ou uma pequena falha aqui e ali.

Para a maioria dos aplicativos, o valor está nos dados e não nas rotinas.

Eu sempre tento perguntar a outros desenvolvedores quais são os procedimentos para uma empresa em particular. Em geral, sim, você deve sempre:

1. Construa localmente.
2. Empurre-o para algum tipo de caixa que imite a produção, tanto quanto possível, para ver se ela é boa lá.
3. Possivelmente, envie-o para uma instância de controle de qualidade ou certificação para passar para a equipe de cliente / controle de qualidade para revisar as alterações.
4. Empurre para a produção.

Você pode usar receitas Capistrano emparelhadas com o GitHub para lidar com todas essas coisas para você. Se você precisar fazer isso manualmente sempre, pode envelhecer rapidamente.

Outro problema com o desenvolvimento do prod é que, às vezes, essas coisas são perdidas no controle de origem e uma versão futura pode desfazer sua alteração de correção rápida.

Se você estiver em uma empresa de capital aberto nos EUA, não deverá nem ter acesso ao prod por motivos regulatórios. Em geral, em nenhuma empresa o desenvolvedor deve ter acesso a produtos (para as resons declaradas em todas as respostas, bem como possíveis razões legais), para que seu gerente também esteja errado ao permitir os direitos para esse servidor.

Regras que usam "sempre" ou "nunca" geralmente são mal definidas. Haverá casos extremos nos quais a quebra de uma prática recomendada será justificada. Um conselho muito melhor será "Não toque nos servidores de produção, a menos que você tenha bons motivos"

Na minha carreira, encontrei apenas dois motivos para alterar o código nos servidores de produção:

1. Erros ou comportamentos que acontecem apenas lá e não são reproduzíveis no ambiente de desenvolvimento. Estes são raros, mas podem ser muito irritantes e difíceis de encontrar.

2. Corrija diretamente um erro crítico que você simplesmente não pode esperar para passar pelo processo normal de implantação, se demorar mais do que alguns minutos. Após isso ter sido limpo com a gerência. Se você tiver sorte, você deve ter apenas alguns deles para toda a sua carreira.

É melhor deixar ambos para desenvolvedores seniores que conhecem os sistemas intimamente.