Planejar os processos de compilação, teste e controle de qualidade
Esta unidade revisa processos de desenvolvimento usados para gerenciar os processos de controle de builds, teste e qualidade e fornece informações sobre como planejar o gerenciamento desses processos.
Criar um plano de projeto para builds
Dependendo da metodologia escolhida, você precisará selecionar horas e locais para builds. Também será necessário decidir em que ordem os builds ocorrerão. Por exemplo, você não desejaria criar seu código do ambiente de desenvolvimento para o ambiente de produção sem passar pelo ambiente de teste primeiro.
Você também precisará considerar como tratar o desenvolvimento que não passa no teste, pois esse desenvolvimento precisará ser revertido. Isso impedirá a promoção de erros. Você pode usar o Lifecycle Services para ajudar a gerenciar o build entre ambientes.
Por exemplo, um build pode reverter qualquer código com erros do ambiente de teste para o ambiente de desenvolvimento, promover o código com êxito do teste para produção e, finalmente, promover seu código concluído do ambiente de desenvolvimento para o teste.
Decidir quais ambientes são necessários
A escolha dos ambientes deve ser planejada no início da implementação. Ao planejar os ambientes, você deve:
- Decidir a finalidade do ambiente. Considerar se os ambientes serão usados para desenvolvimento, teste de sistema, teste de aceitação de usuários (UAT) ou operações.
- Considerar a topologia de ambiente, como Desenvolver ou Compilar e testar.
- Considerar o nível de ambiente (nível 1 ou nível 2).
Um ambiente de nível 1 é um ambiente de uma única caixa com todos os componentes instalados no mesmo servidor. Um ambiente de nível 1 usa Microsoft SQL Server e é estruturado para maximizar a eficiência do desenvolvimento. Esse nível não é uma boa opção para teste de desempenho ou UAT.
Um ambiente de nível 2 ou superior é um ambiente de várias caixas com componentes instalados em vários servidores. Em vez do Microsoft SQL Server, os ambientes de nível 2 usam o Banco de Dados SQL do Azure. A arquitetura desse ambiente é a mesma do ambiente de produção, mas ele não usa a recuperação de desastre. Esse ambiente deve ser usado para testes de desempenho e UAT.
A oferta de nuvem padrão para ambientes inclui um ambiente de nível 1 para desenvolvimento e testes, um ambiente de nível 2 para UAT e um ambiente de produção. Esses ambientes são fornecidos em horários diferentes. O nível 2 é fornecido durante a integração. O ambiente de desenvolvimento e teste de nível 1 é fornecido quando a fase de design é iniciada e o Microsoft Azure DevOps foi configurado. Por fim, o ambiente de produção é fornecido durante a prontidão do sistema de produção com a Microsoft. Esse ambiente deve ser solicitado por meio do Lifecycle Services.
Você também pode adicionar outro ambiente de complemento para ambientes de nível 1 e nível 2, se necessário. Ambientes de nível 1 também podem ser implantados como um ambiente hospedado na nuvem ou uma imagem de ambiente. Os ambientes hospedados na nuvem são gerenciados pelo cliente ou parceiro. A imagem de ambiente é um ambiente local que usa um disco rígido virtual.
É possível escolher os ambientes que serão necessários e quando serão necessários. Será necessário resumir as listas de ambientes necessárias em uma matriz para a Microsoft.
Você pode usar o plano de ambiente para ajudar a escolher o fluxo para criar código em todos os ambientes e para estruturar o ALM.
É preciso planejar os testes necessários
Ao implementar aplicativos de finanças e operações, você precisará decidir como testar o desenvolvimento para aprovação, quem testará, quais critérios serão usados para aprovação e como rastrear os testes. Testes de unidade, testes de regressão e testes de desempenho podem ser usados para testar o sistema.
O teste de unidade é útil para testar se determinada função está funcionando. O teste de unidade não verifica se o novo código afeta os recursos existentes no sistema.
O teste de regressão executa um teste em relação a um processo inteiro para verificar se os recursos existentes ainda funcionam com o novo desenvolvimento. Por exemplo, se uma modificação doe feita para adicionar funcionalidade relacionada a clientes, talvez você deseje executar testes de regressão para garantir que a nova funcionalidade não interfira com a funcionalidade existente, como ordens de venda.
Você também pode considerar o teste de desempenho do sistema para verificar se o sistema está estável ao fazer com que vários usuários insiram o sistema e executem processos de tributação de alto volume. Isso pode ajudá-lo a encontrar oportunidades para aumentar o desempenho.
Os aplicativos de finanças e operações incluem a ferramenta Gravador de tarefas para documentar as etapas de um processo que um usuário executará. O Azure DevOps também permite vincular tarefas a uma solução de projeto de desenvolvimento. A tarefa pode ser usada para controlar atualizações, testar documentos e outras anotações.
Controle de origem e controle de qualidade para desenvolvedores
Ocasionalmente, vários desenvolvedores podem trabalhar em aplicativos de finanças e operações ao mesmo tempo. Para evitar que desenvolvedores interfiram no trabalho uns dos outros, o controle do código-fonte pode ser configurado com um projeto do Azure DevOps.
Esse projeto hospedará o código-fonte do modelo, que permite aos usuários verificar e remover objetos. Ao verificar um objeto, você informa ao sistema que está fazendo alterações. Ao verificar o objeto, o sistema criará uma nova versão desse objeto.
O controle de versão permite ver quais alterações anteriores foram feitas. Você pode desfazer alterações pendentes nas alterações verificadas mais recentes. Além disso, você pode selecionar Obter o mais recente em objetos, que serão extraídos da versão mais recente verificada do objeto. Esse recurso deve ser usado regularmente por desenvolvedores para verificar se estão usando o código mais atualizado.
Para garantir a qualidade no desenvolvimento, siga as práticas recomendadas do Microsoft Dynamics X++. Além disso, talvez você queira desenvolver sua própria prática recomendada, como convenções de nomenclatura, para manter todo o desenvolvimento padronizado na organização.