Recomendações para padronizar ferramentas e processos

  • Artigo

Aplica-se a esta recomendação de lista de verificação de Excelência Operacional do Azure Well-Architected Framework:

OE:04 Otimize o desenvolvimento de software e os processos de garantia de qualidade ao seguir as práticas comprovadas pela indústria para desenvolvimento e teste. Para uma designação de função inequívoca, uniformize práticas entre componentes, como ferramentas, controlo de código fonte, padrões de conceção de aplicações, documentação e guias de estilo.

Guia relacionado: Melhorar a velocidade de compilação | Utilizar a integração contínua

Este guia descreve as recomendações para definir normas para ferramentas e processos de desenvolvimento de software. Definir práticas consistentes leva a uma equipa de carga de trabalho eficiente e a um trabalho de alta qualidade. As equipas de alto desempenho utilizam ferramentas e processos comprovados pela indústria para minimizar o esforço desperdiçado e potenciais erros de código.

Principais estratégias de conceção

O primeiro passo para otimizar as práticas de desenvolvimento é uniformizar ferramentas e processos. Sempre que possível, utilize soluções comprovadas pela indústria em vez de desenvolver soluções internas. Para otimizar ainda mais as suas práticas, adote ferramentas de baixo código e sem código. Estas ferramentas permitem-lhe concentrar esforços na sua aplicação e ajudá-lo a poupar tempo. Para todas as ferramentas e processos que uniformizar, implemente formação para que as suas equipas as compreendam e utilizem de forma eficiente. Para definir padrões que ajudam a otimizar as suas práticas de desenvolvimento, considere as seguintes recomendações.

Utilizar ferramentas bem conhecidas e maduras fora da prateleira

Utilize ferramentas bem conhecidas e maduras e uniformize a sua utilização. As equipas de engenharia altamente eficazes adotam as melhores ferramentas de classe. Esta abordagem minimiza a necessidade de desenvolver soluções para planeamento, desenvolvimento, teste, colaboração e integração contínua e entrega contínua (CI/CD). Muitas empresas dão aos programadores uma escolha entre algumas ferramentas, mas todas as opções são ferramentas padrão para a organização e são validadas internamente. Mais importante ainda, escolha ferramentas que cumpram os requisitos da sua carga de trabalho. As ferramentas off-the-shelf devem fornecer as seguintes funções:

  • Planeamento de trabalho e gestão de tarefas pendentes

  • Controlo de versões e repositórios

  • Pipelines CI/CD

  • Testes, como integração, fumo, utilizador sintético, simulação, caos e outros testes de qualidade

  • Desenvolvimento de código

Em alguns casos, uma ferramenta ou um conjunto de ferramentas pode fornecer várias funções. Certifique-se de que compreende as capacidades das suas ferramentas e as respetivas limitações para que cumpram os seus requisitos em todas as funções.

Determine se deve investir em ferramentas dispendiosas ou versões premium de ferramentas. Considere o tempo e o esforço de desenvolvimento das suas próprias soluções em comparação com as funcionalidades fornecidas pelas ferramentas premium. Considere os custos únicos em comparação com os custos recorrentes. Na maioria dos casos, as ferramentas off-the-shelf fornecem um valor mais elevado à sua equipa.

Utilize ferramentas de pouco código, sem código e IA quando for prático. As ferramentas com pouco código e sem código poupam tempo aos programadores experientes, permitindo-lhes ligar facilmente a funcionalidade em vez de executarem todo o processo de desenvolvimento de código. Estas ferramentas também permitem que os membros da equipa de carga de trabalho que podem não ser programadores preparados contribuam para o funcionamento da carga de trabalho. As ferramentas de IA podem ajudar no desenvolvimento, revisões e otimização de código.

Uniformizar a estratégia de ramificação

Escolha um modelo baseado em ramal sempre que possível. A ramificação baseada em ramal mantém a equipa de desenvolvimento da carga de trabalho sincronizada e incentiva a entrega contínua. Defina políticas de ramo para proteger ramos importantes, como o ramo principal. Para obter mais informações, veja Adotar uma estratégia de ramificação do Git e Políticas e definições do Ramo.

Avaliar as métricas para quantificar a eficácia do desenvolvimento

As equipas de desenvolvimento de software e garantia de qualidade só podem melhorar se conseguirem quantificar a sua eficácia. Para quantificar a eficácia, têm de identificar as métricas que medem a velocidade do programador e definem os KPIs. Exemplos destas métricas incluem:

  • Frequência de implementação: o número de implementações que cada programador implementa diariamente.

  • Tempo de execução: o tempo necessário para uma tarefa ou história de utilizador passar do registo de tarefas pendentes para uma implementação de produção.

  • Tempo médio para a resolução: o tempo médio que é gasto a corrigir erros ou defeitos no código.

  • Taxa de falhas de alteração: a percentagem de alterações que resultam numa falha.

Para ajudar os intervenientes e a equipa de carga de trabalho a controlar facilmente a velocidade, visualize KPIs com dashboards ou outras ferramentas de relatórios.

Uniformizar a forma como a sua equipa de carga de trabalho escreve, revê e documenta código

Uniformize a forma como a sua equipa de carga de trabalho escreve, revê e documenta código com um guia de estilo. Um estilo padrão facilita a colaboração e ajuda com a integração de novos programadores. Para trabalhar eficazmente, os novos programadores precisam de saber como funciona a equipa de carga de trabalho. Um guia de estilo com padrões claramente definidos pode facilitar o processo de preparação. No guia de estilo, defina normas para linguagens de desenvolvimento, bibliotecas, arquiteturas e outras convenções.

Quando for prático, utilize as ferramentas para impor padrões de formatação de código. Por exemplo, o Visual Studio oferece várias ferramentas que procuram código para estilo, qualidade, manutenção, design e outros problemas. Para infraestrutura como código (IaC), pode utilizar Checkov ou Terrascan para Terraform.

Para garantir a consistência e evitar potenciais confusões, o guia de estilo deve incluir convenções de nomenclatura padrão para artefactos, ambientes, ramos, compilações e execuções.

Também deve definir diretrizes e normas para o grau de variância permitido nos seus ambientes. Se existirem novas linguagens, arquiteturas ou outras tecnologias que os membros da equipa de carga de trabalho pretendam adicionar à lista padrão, implemente um processo para utilizar essas ferramentas num sandbox ou num ambiente inferior. Teste a viabilidade e substitua as tecnologias existentes quando adequado.

Utilize os registos de decisão de arquitetura (ADRs) para manter um registo histórico das decisões de conceção da sua equipa de carga de trabalho. Os ADRs ajudam as suas equipas a manter uma nova compreensão da carga de trabalho. Também ajudam os novos membros da equipa a saber mais sobre as decisões de conceção tomadas durante o ciclo de vida da carga de trabalho. Certifique-se de que os ADRs são controlados pela versão.

No seu ADR, inclua:

  • Ferramentas e tecnologias específicas, por exemplo, com SQL ou NoSQL, que a sua equipa escolhe.

  • As razões das decisões da sua equipa.

  • Outras opções que foram consideradas, o que ajuda a contextualizar a decisão final.

  • Requisitos funcionais e não funcionais que são considerados em decisões.

  • O contexto do processo de tomada de decisão, como o problema que foi resolvido.

Implementar normas para fazer face à dívida técnica

Adote uma mentalidade de que a dívida técnica é intencional e necessária para os materiais a entregar da sua equipa de carga de trabalho. Esta mentalidade motiva a sua equipa a considerar e a lidar regularmente com dívidas técnicas para evitar a acumulação. Resolva a dívida técnica como uma tarefa regularmente periódica no atraso.

Por exemplo, suponha que a sua equipa padronizou numa biblioteca. Ao longo do tempo, tem de mudar para uma biblioteca diferente para obter novas funcionalidades na carga de trabalho. Essa transição pode resultar em dívidas técnicas. Muitas vezes, transições como esta podem deixar a equipa de carga de trabalho a suportar duas tecnologias, uma vez que não conseguem fazer a transição totalmente sem problemas. A equipa de cargas de trabalho tem de dar prioridade à conclusão da transição, porque quando a carga de trabalho atinge a nova funcionalidade, os intervenientes são satisfeitos e têm menos probabilidades de considerar a dívida técnica.

Uniformizar a forma como aplica o controlo de versões aos artefactos

Uniformize a forma como aplica o controlo de versões aos artefactos e como o controlo de versões é exposto interna e externamente. Por exemplo, os sistemas destinados ao cliente devem expor a respetiva versão em execução na interface de utilizador. Esta técnica é útil quando a equipa de cargas de trabalho resolução de problemas porque o cliente consegue comunicar facilmente a versão que utiliza. As interfaces REST podem expor versões para determinados componentes ou bases de dados. Pode utilizar uma tabela específica nos metadados de um esquema para expor a versão do esquema.

Utilize padrões de conceção de aplicações comprovados pela indústria para garantir que a sua aplicação é fiável, eficaz e segura. Utilize estes padrões para poupar tempo e esforço em comparação com o desenvolvimento das suas próprias soluções para a sua aplicação. Escolha os padrões que beneficiam a carga de trabalho. Reveja regularmente os padrões de conceção para garantir que utiliza os padrões certos à medida que a carga de trabalho evolui.

Implementar uma abordagem shift-left para testar

Implemente uma abordagem shift-left para testar ao realizar testes de unidades antecipadamente e, muitas vezes, ao longo do processo de desenvolvimento. Os testes frequentes em cada ambiente de desenvolvimento ajudam os programadores a ganhar confiança nas suas aplicações. Para ajudar a criar a sua estratégia de teste com uma abordagem shift-left, considere os seguintes princípios:

  • Escreva testes no nível mais baixo possível. Favoreça os testes com menos dependências externas e execute testes como parte da compilação.

  • Escreva testes uma vez e execute testes em todo o lado, incluindo produção. Escreva testes que pode executar em todos os ambientes de desenvolvimento sem contabilizar fatores específicos de um ambiente, como segredos ou configurações encriptados.

  • Crie a carga de trabalho para testes. Quando desenvolver a sua aplicação, torne a capacidade de teste um requisito.

  • Tratar o código de teste como código da aplicação. Aplique as mesmas normas de qualidade e desenvolvimento ao código da aplicação e código de teste. Armazene o código de teste juntamente com o código da aplicação. Desenvolver e manter o código de teste com o código da aplicação. Para garantir a qualidade dos testes, elimine os testes que não são fiáveis.

  • Considere a propriedade do teste, que se baseia na propriedade da carga de trabalho. A sua equipa de carga de trabalho é proprietária dos testes e não deve depender de outras equipas para testar o código.

  • Automatize os testes o máximo possível. O código automatizado alivia a carga de trabalho da sua equipa de carga de trabalho e impõe uma qualidade consistente.

Para obter orientações detalhadas sobre a implementação de uma estratégia de teste de DevOps, veja Testes de shift à esquerda com testes de unidades.

Exigir práticas de DevSecOps como parte dos seus procedimentos operacionais padrão. A sua equipa de carga de trabalho deve compreender as práticas de segurança relacionadas com o desenvolvimento de software e a garantia de qualidade. Têm de seguir estas práticas sem exceção. Para obter mais informações, veja Guia do ciclo de vida do desenvolvimento de segurança.

Implementar normas para atribuir nomes e identificar recursos

Implementar convenções de etiquetagem e nomenclatura é uma melhor prática para gerir e organizar recursos do Azure. As convenções de identificação e nomenclatura ajudam a identificar, classificar e agrupar recursos com base em atributos comuns, como ambiente, aplicação, proprietário ou centro de custos. Também permitem segurança, automatização, relatórios e governação de recursos entre subscrições e grupos de recursos.

Algumas das vantagens da utilização de convenções de etiquetagem e nomenclatura padronizadas são:

  • Fornecem consistência e clareza para a identificação e gestão de recursos, facilitando a deteção e pesquisa nas portal do Azure, PowerShell, CLI e APIs.
  • Permitem filtrar e agrupar recursos para fins de faturação, monitorização, segurança e conformidade.
  • Suportam a gestão do ciclo de vida dos recursos, como o aprovisionamento, a desativação, a cópia de segurança e a recuperação.
  • São essenciais para fins de segurança. Se ocorrer um incidente de segurança, é fundamental identificar rapidamente os sistemas afetados, as funções que esses sistemas suportam e o potencial impacto comercial.

Para obter mais informações sobre como utilizar convenções de nomenclatura para os seus recursos na cloud, consulte Definir a convenção de nomenclatura. Para obter mais informações sobre como aplicar etiquetas de metadados aos recursos da cloud, consulte Definir a sua estratégia de identificação.

Facilitação do Azure

  • O Azure DevOps é uma coleção de serviços que pode utilizar para criar uma prática de desenvolvimento colaborativa, eficiente e consistente. O Azure DevOps agrupa as seguintes soluções:

  • GitHub Actions do Azure é uma ferramenta que pode utilizar para automatizar processos de CI/CD. Integra-se diretamente no Azure para simplificar as implementações. Pode criar fluxos de trabalho que compilam e testam todos os pedidos Pull para o seu repositório ou implementar pedidos Pull intercalados para produção.

  • O GitHub Projects é uma ferramenta de gestão de trabalho que pode utilizar para criar quadros, relatórios, dashboards e outras funções kanban.

  • As ferramentas de baixo código e sem código incluem:

  • Os modelos do Azure Resource Manager e o Bicep são ferramentas nativas do Azure que pode utilizar para implementar o IaC. O Terraform é outra ferramenta IaC suportada pelo Azure que pode utilizar para implementar e gerir a infraestrutura.

  • O Visual Studio é uma ferramenta de desenvolvimento robusta que se integra no Azure e suporta vários idiomas.

  • GitHub Copilot é um serviço de IA que atua como programador de pares e fornece sugestões de estilo de conclusão automática à medida que codifica. O Copilot está disponível como uma extensão no Visual Studio e em várias outras ferramentas de desenvolvimento.

  • O Azure Load Testing é um serviço de teste de carga totalmente gerido que pode utilizar para gerar carga de alta escala ao simular o tráfego para as suas aplicações, independentemente do local onde estão alojadas.

Lista de verificação de Excelência Operacional

Veja o conjunto completo de recomendações.

Lista de verificação de Excelência Operacional