Minha equipe do Avance Network conseguiu implementar um processo de trabalho que nos permite enviar novos recursos para a produção sem bugs, um processo que incorpora funções automatizadas com disciplina da equipe.
Por que eu deveria me importar?
Os erros acontecem o tempo todo - e serão encontrados localmente ou em produção. Mas a principal diferença entre prevenir e encontrar o bug em um ambiente de pré-produção é o custo: de acordo com a pesquisa da IBM , corrigir um bug na produção pode custar 5 vezes mais do que descobri-lo em ambientes de pré-produção (durante o design, desenvolvimento local ou fase de teste).
Vamos descrever um dos cenários que ocorrem quando um bug atinge a produção:
- Um cliente encontra o erro e alerta o atendimento ao cliente.
- O bug é registrado pela equipe de produção.
- O desenvolvedor obtém a descrição do bug, abre a especificação e passa um tempo lendo-a.
- O desenvolvedor passará um tempo recriando o bug.
- O desenvolvedor deve se familiarizar novamente com o código para depurá-lo.
- Em seguida, a correção deve passar por testes.
- A correção é então construída e implantada em outros ambientes.
- Por fim, a correção passa pelo teste de controle de qualidade (exigindo recursos de controle de qualidade).
Como impedir que os bugs atinjam a produção
Para capturar e corrigir erros no estágio mais econômico e econômico, seguimos essas etapas, aderindo aos vários
Etapa 1 - Ambiente local e IC
Etapa 1: projete bem. Mantenha simples.
Crie o design antes da codificação: tente dividir problemas difíceis em partes / etapas / módulos menores que você pode resolver um por um, pensando em objetos com responsabilidades bem definidas. Compartilhe os planos com seus colegas de equipe em reuniões de revisão de design. Um bom design é essencial para reduzir erros e melhorar a qualidade do código.
Etapa 2: Iniciar a codificação
O código deve ser legível e simples. Os princípios de design e desenvolvimento são seus melhores amigos. Use SOLID , DRY , YAGNI , KISS e Polymorphism para implementar seu código.
Os testes de unidade fazem parte do processo de desenvolvimento. Nós os usamos para testar unidades de código individuais e garantir que a unidade esteja logicamente correta.
Os testes de unidade são escritos e executados pelos desenvolvedores. Na maioria das vezes, usamos o JUnit como nossa estrutura de teste.
Etapa 3: usar ferramentas de análise de código
Para ajudar a garantir e manter a qualidade do nosso código, usamos várias ferramentas automatizadas de análise de código:
FindBugs - Uma ferramenta estática de análise de código que detecta possíveis erros em programas Java, ajudando-nos a melhorar a correção do nosso código.
Checkstyle - Checkstyle é uma ferramenta de desenvolvimento para ajudar os programadores a escrever código Java que segue um padrão de codificação. Ele automatiza o processo de verificação do código Java.
Etapa 4: executar revisões de código
Todos sabemos que as revisões de código são importantes. Existem muitas práticas recomendadas on-line (consulte 7 maneiras de aprimorar suas habilidades de revisão de código , práticas recomendadas para revisão de código por pares e revisões eficazes de código ), portanto, vamos nos concentrar nas ferramentas que usamos. Todas as nossas confirmações de código são preenchidas no ReviewBoard , e os desenvolvedores podem revisar o código confirmado, ver a qualquer momento os desenvolvimentos mais recentes e compartilhar informações.
Para as equipes mais cruciais, temos uma compilação que garante que todas as confirmações passem por uma revisão de código - no caso de uma revisão não ter sido feita, a compilação alertará a equipe de que houve uma alteração não revisada.
Independentemente de você estar executando uma pós-confirmação, uma solicitação pull ou uma revisão pré-confirmação, você deve sempre procurar verificar e revisar o que está sendo inserido na sua base de código.
Etapa 5: IC
É aqui que todo o código está sendo integrado. Usamos o TeamCity para impor nossos padrões de código e correção, executando testes de unidade, validações de FindBugs, regras de estilo de verificação e outros tipos de políticas.
Etapa 2 - Ambiente de teste
Etapa 1: executar testes de integração
Verifique se o sistema como um todo funciona. O teste de integração também é feito pelos desenvolvedores, mas, em vez de testar componentes individuais, ele visa testar os componentes. Um sistema consiste em muitos componentes separados, como código, banco de dados, servidores Web, etc.
Os testes de integração são capazes de detectar problemas como a fiação de componentes, acesso à rede, problemas no banco de dados, etc. Usamos o Jenkins e o TeamCity para executar testes de IC.
Etapa 2: executar testes funcionais
Verifique se cada recurso foi implementado corretamente comparando os resultados de uma determinada entrada com a especificação. Normalmente, isso não é feito no nível de desenvolvimento.
Os casos de teste são escritos com base na especificação e os resultados reais são comparados com os resultados esperados. Executamos testes funcionais usando Selenium e Transferidor para testes de interface do usuário e Junit para testes de API.
Etapa 3 - Ambiente de preparação
Esse ambiente geralmente é chamado de área restrita de pré-produção, área de teste do sistema ou simplesmente área de preparação. Seu objetivo é fornecer um ambiente que simule o ambiente de produção real o mais próximo possível, para que você possa testar seu aplicativo em conjunto com outros aplicativos.
Mova uma pequena porcentagem de solicitações reais de produção para o ambiente intermediário, onde o controle de qualidade testa os recursos.
Etapa 4 - Ambiente de Produção
Etapa 1: implantar gradualmente
A implantação é um processo que entrega nosso código nas máquinas de produção. Se ocorrerem alguns erros durante a implantação, nosso sistema de Entrega Contínua interromperá a implantação, impedindo que a versão problemática alcance todas as máquinas e nos permita reverter rapidamente.
Etapa 2: incorporar sinalizadores de recursos
Todos os nossos novos componentes são lançados com sinalizadores de recursos, que servem basicamente para controlar o ciclo de vida completo de nossos recursos. Os sinalizadores de recursos nos permitem gerenciar componentes e compartimentar os riscos.
Etapa 3: solte gradualmente
Existem duas maneiras de tornar nossa liberação gradual:
- Testamos novos recursos em um pequeno conjunto de usuários antes de liberar para todos.
- Abra o recurso inicialmente para, digamos, 10% de nossos clientes, 30%, 50% e 100%.
Ambos os métodos nos permitem monitorar e rastrear cenários problemáticos em nossos sistemas.
Etapa 4: Monitorar e Alertas
Usamos a pilha ELK que consiste em Elasticsearch, Logstash e Kibana para gerenciar nossos dados de logs e eventos.
Para dados de séries temporais, usamos mecanismo de armazenamento e alerta de métricas.
Cada desenvolvedor pode configurar suas próprias métricas e criar painéis grafana.
Definir os alertas também faz parte do trabalho do desenvolvedor e é sua responsabilidade ajustar o limite para acionar o alerta PagerDuty.
O PagerDuty é um serviço automatizado de chamadas, mensagens de texto e e-mail, que encaminha notificações entre as partes responsáveis para garantir que os problemas sejam resolvidos pelas pessoas certas no momento certo.
