Desenvolvendo com confiança sem um ambiente de desenvolvimento real

12

Recentemente, fui contratado para um projeto que envolve trabalhar com e em torno de vários sistemas "empresariais" de terceiros. Devido ao que eu imagino que seja o custo e o esforço astronômico necessários para construir uma réplica suficientemente fiel do ambiente de produção, a perspectiva de ter um ambiente de desenvolvimento real parece muito pequena.

Obviamente, isso não é o ideal. Pelo lado positivo, imagino que deve haver pessoas por aí testando e implantando software com segurança em ambientes não replicáveis como esse, e provavelmente posso seguir seus passos.

Como aqueles que efetivamente lidam com esse tipo de situação fazem isso?

testing development-process

— Jason Swett
fonte

1

Virtualização, tendo ambientes "tão parecidos com", etc ... Em essência, tente replicar o que é possível, em menor escala, para cobrir pelo menos a maioria das "partes móveis" do sistema.

— Oded

6

Você precisa confiar na correção da API do sistema corporativo e fazer muitos testes de integração, talvez com algumas contas de teste.

— Robert Harvey

@RobertHarvey está morto aqui. Alguém deve explicar isso em uma resposta, mas é exatamente isso que você precisa. Na ausência de um ambiente para testar manualmente o sistema, tudo o que você pode fazer é testar automaticamente o código.

— Jimmy Hoffa

1

Ok, talvez seja um bom ponto de partida, se você não puder ter um ambiente de desenvolvimento completo, as contas de teste em produção podem ser a próxima melhor coisa.

— Jason Swett

9

Isso acontece o tempo todo no mundo real. Conheço um cara que escreve aplicativos que controlam gigantescas estufas agrícolas - ventilação, aquecimento, controle de umidade, etc. Ele não possui uma "estufa de teste", mas possui um programa de simulador fornecido pela empresa que constrói os sistemas de hardware reais. Se o código funcionar corretamente com o simulador, presume-se que funcione corretamente com o equipamento real. Em raras ocasiões, o simulador parece estar errado, mas esse é o problema da empresa de hardware de estufa, porque não está simulando corretamente.

— Ross Patterson
fonte

O OP parece não ter a garantia de um 'simulador'. Além disso, no seu caso, o empregador do seu colega provavelmente poderá solicitar uma indenização se o simulador falhar. O que o OP pode fazer em uma situação semelhante? Incomoda a companhia de seguros?

— precisa saber é o seguinte

4

Se o OP não tiver um simulador, ele precisará adquirir um - implorar / roubar / emprestar / construir - não importa realmente. Quão bom um simulador precisa ser - isso é algo que ele precisa decidir e, se sentir necessidade, pode / deve conversar com uma companhia de seguros sobre uma coisinha chamada indenização.

— mattnz

3

Essas são situações em que a documentação da API, os documentos de controle da interface e os emuladores são fundamentais. Em uma empresa para a qual trabalhei anteriormente, isso realmente aconteceu. Isso acontecia frequentemente em um projeto durante certas fases de integração em que um segmento estava pronto, mas outros estavam atrasados, com outro recurso sendo trabalhado ou por alguma outra razão pela qual não puderam implantar. a versão mais recente do segmento para o nosso sistema de teste. Então, sim, na verdade tínhamos uma réplica fiel do ambiente de produção em que testamos; no entanto, na prática, todos os segmentos nunca estavam prontos dentro do cronograma, mas as interfaces haviam sido acordadas e bloqueadas antes do início do desenvolvimento, e foram criados emuladores que, em grande parte, poderiam imitar o comportamento de outros segmentos.

Como outra resposta afirmou, o emulador é o que permitirá que o teste ocorra antes da implantação. Um bom emulador; no entanto, depende de interfaces e documentação bem definidas.

— Fred Thomsen
fonte

1

Eu estou nessas situações o tempo todo.

Você certamente não precisa interagir com o aplicativo inteiro, mas provavelmente com algumas interfaces de algum tipo. Certifique-se de ter confirmado e detalhado a documentação das interfaces e configure simulações dessas interfaces apenas para verificar se o código adicionado / alterado funciona da maneira que você pretendia.

Você também pode fazer um híbrido. Tente replicar as partes que você pode fazer com facilidade e, em seguida, "conecte" aos sistemas reais (se isso for possível na sua situação). Fiz isso com algum sucesso - em alguns casos em que minha lógica e o software do servidor eram executados localmente, mas eu ainda tinha conexões com o sistema ERP real para verificar as invocações etc. Não é o ideal, mas as coisas raramente são.

Como você tem apenas um sistema de produção para trabalhar - observe que você não pode contar apenas com o tempo de desenvolvimento economizado na configuração de uma réplica, mas é necessário levar em consideração o risco comercial de usar código amplamente não testado com dados comerciais ativos. Seu código será menos confiável do que o código testado em uma réplica. Os sistemas podem ficar inativos por algum tempo? Eles podem ser restaurados em caso de corrupção de dados? Quanto aquilo custa?

Uma prática recomendada nas empresas é colocar uma réplica (ou talvez mais de uma) da produção no momento em que o ambiente de produção estiver configurado. Nesse momento, o custo adicional não será tão grande.

— Petter Nordlander
fonte

1

Nosso sistema trabalha com vários sistemas externos grandes. Combinamos as seguintes abordagens ao testá-las se não tivermos uma configuração completa de ponta a ponta:

Grave a reprodução de dados reais. Registre dados reais (solicitações / respostas de sistemas externos reais), parametrize-os, se necessário, e reproduza-os
Construa ou compre um simulador que atue como um sistema externo
DSL para geração de dados de teste. Para sistemas controlados por dados, escreva DSL de alto nível para gerar dados de teste.

— dzieciou
fonte