Planejar os processos de compilação, teste e controle de qualidade
Esta unidade analisa os processos de desenvolvimento que você pode usar para gerenciar os processos de criação, teste e controle de qualidade. Também 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 precisa considerar como lidar com o desenvolvimento que não passa nos testes, pois precisa reverter esse desenvolvimento. Essa abordagem evita que você promova erros. Você pode usar o Microsoft Dynamics 365 Lifecycle Services (LCS) 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
Você deve planejar a seleção dos ambientes no início da implementação. Ao planejar os ambientes, você deve:
- Decidir a finalidade do ambiente. Considere se você planeja usar os ambientes para desenvolvimento, testes de sistema, UAT (testes de aceitação do usuário) 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 diversos servidores. Em vez do Microsoft SQL Server, os ambientes de nível 2 usam o Banco de Dados SQL do Microsoft Azure. A arquitetura desse ambiente é a mesma do ambiente de produção, mas ele não usa a recuperação de desastre. Você deve usar esse ambiente para UAT e testes de desempenho.
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. O sistema fornece estes ambientes em momentos diferentes:
- Ambiente de Nível 2: durante o processo de instalação.
- Ambiente de desenvolvimento e teste de Nível 1: quando a fase de design é iniciada e após você configurar o Microsoft Azure DevOps.
- Ambiente de produção: durante a preparação do sistema de produção com a Microsoft. Você deve solicitar esse ambiente 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. Além disso, você pode implantar ambientes de Nível 1 como um ambiente hospedado na nuvem ou uma imagem de ambiente. Clientes ou parceiros gerenciam os ambientes hospedados na nuvem. A imagem de ambiente é um ambiente local que usa um disco rígido virtual.
Você pode selecionar de quais ambientes precisa e quando precisa deles. 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. Você pode usar testes de unidade, testes de regressão e testes de desempenho 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 você fizer uma modificação para adicionar funcionalidade relacionada aos clientes, talvez queira realizar testes de regressão para garantir que a nova funcionalidade não interfira na funcionalidade existente, como ordens de venda.
Você também pode considerar testar o desempenho do sistema para garantir que ele é estável. Para isso, faça com que vários usuários entrem no sistema e executem processos de tributação de alto volume. Essa abordagem pode auxiliar a encontrar oportunidades para aumentar o desempenho.
Os aplicativos de finanças e operações incluem a ferramenta Gravador de tarefas para auxiliar a documentar as etapas de um processo executado por um usuário. Com o Microsoft Azure DevOps, você pode vincular tarefas a uma solução de projeto de desenvolvimento. Em seguida, você pode usar a tarefa para rastrear atualizações, testar documentos e outras notas.
Controle de origem e controle de qualidade para desenvolvedores
Às vezes, vários desenvolvedores podem trabalhar simultaneamente em aplicativos de finanças e operações. Para evitar que os desenvolvedores interfiram no trabalho uns dos outros, você pode configurar o controle do código-fonte com um projeto do Azure DevOps.
O projeto do Azure DevOps hospeda o código-fonte do modelo, que permite aos usuários fazer check-in e check-out de objetos. Ao fazer check-out de um objeto, você informa ao sistema que está fazendo alterações. Quando você faz check-in do objeto, o sistema cria uma nova versão desse objeto.
O controle de versão permite que você exiba alterações anteriores feitas por alguém. 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. Os desenvolvedores devem usar esse recurso regularmente para garantir que estão usando o código mais atualizado.
Para garantir a qualidade no desenvolvimento, siga as práticas recomendadas do Microsoft Dynamics 365 X++. Além disso, convém desenvolver suas próprias práticas recomendadas, como convenções de nomenclatura, para manter todo o desenvolvimento padronizado em toda a organização.
Selecionar um sistema de controle de versão
Em aplicativos de finanças e operações, um sistema de controle de versão é obrigatório. O Azure DevOps dá suporte ao TFVC (Controle de Versão do Team Foundation) e ao Git.
Azure DevOps Controle de Versão do Team Foundation
O sistema de Controle de Versão do Team Foundation do Azure DevOps é um sistema de controle de versão único para aplicativos de finanças e operações. É um sistema de controle de versão centralizado, o que significa que os desenvolvedores trabalham em uma ramificação e têm uma versão de cada arquivo em seus computadores de desenvolvimento. Cada ramificação pertence a um espaço de trabalho do servidor e cada desenvolvedor trabalha em um espaço de trabalho local. Quando um desenvolvedor faz check-in do código-fonte, ele deve garantir que fez check-in da versão mais recente e resolveu os conflitos existentes.
Por padrão, os repositórios TFVC estão desativados na área Configurações da organização do Azure DevOps. Você precisa ativar os repositórios antes de criar um novo projeto do Azure DevOps com TFVC como sistema de controle de versão.
Para ativar o TFVC (Controle de Versão do Team Foundation) na organização, siga estas etapas:
- Abra o Azure DevOps acessando dev.azure.com/<your organization>.
- Selecione Configurações da organização no canto inferior esquerdo do painel.
- Abra Repos > Repositórios.
- Desative a opção Desabilitar criação de repositórios TFVC na seção Todas as Configurações do Repositório.
Você pode criar novos Azure DevOps Projects com TFVC como sistema de controle de versão.
Git
O Git é o sistema de controle de versão padrão recomendado pela Microsoft para desenvolvimento.
Embora o TFVC seja um sistema de controle de versão centralizado, o Git é um sistema distribuído. Cada desenvolvedor tem sua própria cópia de um repositório de origem (ou ramificação leve) e pode confirmar alterações nele. Os desenvolvedores podem criar novas ramificações privadas e mudar de uma ramificação para outra. No TFVC, era mais difícil mudar de uma ramificação para outra e, muitas vezes, isso exigia vários ambientes de desenvolvimento.
É importante observar que você pode migrar do TFVC para o Git e vice-versa.