Padrão DevOps

Codifique de um único local e faça a implantação em vários destinos nos ambientes de desenvolvimento, teste e produção que podem estar no seu datacenter local, em nuvens privadas ou na nuvem pública.

Contexto e problema

A continuidade, a segurança e a confiabilidade da implantação de aplicativos são essenciais para as organizações e essenciais para as equipes de desenvolvimento.

Os aplicativos geralmente exigem código refatorado para serem executados em cada ambiente de destino. Isso significa que um aplicativo não é completamente portátil. Ele deve ser atualizado, testado e validado conforme se move por cada ambiente. Por exemplo, o código escrito em um ambiente de desenvolvimento deve ser reescrito para funcionar em um ambiente de teste e reescrito quando ele finalmente chega em um ambiente de produção. Além disso, esse código está vinculado ao host. Isso aumenta o custo e a complexidade da manutenção do aplicativo. Cada versão do aplicativo está vinculada a cada ambiente. A maior complexidade e duplicação aumentam o risco de segurança e qualidade de código. Além disso, o código não pode ser reimplantado prontamente quando você remove hosts com falha de restauração ou implanta hosts adicionais para lidar com aumentos na demanda.

Solução

O Padrão DevOps permite que você crie, teste e implante um aplicativo executado em várias nuvens. Esse padrão une a prática de integração contínua e entrega contínua. Com a integração contínua, o código é criado e testado sempre que um membro da equipe confirma uma alteração no controle de versão. A entrega contínua automatiza cada etapa de um build até um ambiente de produção. Juntos, esses processos criam um processo de versão que dá suporte à implantação em ambientes diversos. Com esse padrão, você pode elaborar seu código e, em seguida, implantar o mesmo código em um ambiente local, nuvens privadas diferentes e nuvens públicas. As diferenças no ambiente exigem uma alteração em um arquivo de configuração em vez de alterações no código.

Com um conjunto consistente de ferramentas de desenvolvimento em ambientes locais, de nuvem privada e de nuvem pública, você pode implementar uma prática de integração contínua e entrega contínua. Aplicativos e serviços implantados usando o padrão DevOps são intercambiáveis e podem ser executados em qualquer um desses locais, aproveitando as funcionalidades e capacidades tanto de infraestruturas locais quanto de nuvens públicas.

O uso de um pipeline de versão do DevOps ajuda você a:

• Inicie um novo build com base em confirmações de código em um único repositório.
• Implante automaticamente seu código recém-criado na nuvem pública para teste de aceitação do usuário.
• Implante automaticamente em uma nuvem privada depois que o código tiver passado no teste.

Problemas e considerações

O Padrão DevOps destina-se a garantir a consistência entre implantações, independentemente do ambiente de destino. No entanto, os recursos variam entre ambientes locais e de nuvem. Considere os seguintes pontos:

• As funções, os pontos de extremidade, os serviços e outros recursos de sua implantação estão disponíveis nos locais de destino?
• Os artefatos de configuração são armazenados em locais acessíveis entre nuvens?
• Os parâmetros de implantação funcionarão em todos os ambientes de destino?
• As propriedades específicas do recurso estão disponíveis em todas as nuvens de destino?

Para obter mais informações, consulte Desenvolver modelos do Azure Resource Manager para consistência na nuvem.

Além disso, considere os seguintes pontos ao decidir como implementar esse padrão:

Escalabilidade

Os sistemas de automação de implantação são o ponto de controle chave nos Padrões de DevOps. As implementações podem variar. A seleção do tamanho correto do servidor depende do tamanho da carga de trabalho esperada. As VMs custam mais para dimensionar do que os contêineres. Para usar contêineres para dimensionamento, no entanto, seu processo de build deve ser executado com contêineres.

Disponibilidade

A disponibilidade no contexto do DevPattern significa ser capaz de recuperar qualquer informação de estado associada ao fluxo de trabalho, como resultados de teste, dependências de código ou outros artefatos. Para avaliar seus requisitos de disponibilidade, considere duas métricas comuns:

• O RTO (Objetivo de Tempo de Recuperação) especifica por quanto tempo você pode ficar sem um sistema.

• O RPO (Objetivo de Ponto de Recuperação) indica a quantidade de dados que você pode perder se uma interrupção no serviço afetar o sistema.

Na prática, RTO e RPO implicam redundância e backup. Na nuvem global do Azure, a disponibilidade não é uma questão de recuperação de hardware, que faz parte do Azure, mas sim de garantir que você mantenha o estado de seus sistemas DevOps. No Azure Stack Hub, a recuperação de hardware pode ser uma consideração.

Outra consideração importante ao projetar o sistema usado para automação de implantação é o controle de acesso e o gerenciamento adequado dos direitos necessários para implantar serviços em ambientes de nuvem. Quais direitos são necessários para criar, excluir ou modificar implantações? Por exemplo, um conjunto de direitos normalmente é necessário para criar um grupo de recursos no Azure e outro para implantar serviços no grupo de recursos.

Gerenciamento

O design de qualquer sistema com base no padrão DevOps deve considerar automação, registro em log e alertas para cada serviço em todo o portfólio. Use serviços compartilhados, uma equipe de aplicativos ou ambos e acompanhe as políticas de segurança e a governança também.

Implante ambientes de produção e ambientes de desenvolvimento/teste em grupos de recursos separados no Azure ou no Azure Stack Hub. Em seguida, você pode monitorar os recursos de cada ambiente e acumular custos de cobrança por grupo de recursos. Você também pode excluir recursos como um conjunto, o que é útil para implantações de teste.

Quando usar esse padrão

Use esse padrão se:

• Você pode desenvolver código em um ambiente que atenda às necessidades de seus desenvolvedores e implantar em um ambiente específico à sua solução em que pode ser difícil desenvolver um novo código.
• Você pode usar o código e as ferramentas que seus desenvolvedores gostariam, desde que eles possam seguir o processo de integração contínua e entrega contínua no Padrão de DevOps.

Esse padrão não é recomendado:

• Se você não puder automatizar tarefas relacionadas à infraestrutura, provisionamento de recursos, configuração, identidade e segurança.
• Se as equipes não tiverem acesso aos recursos de nuvem híbrida para implementar uma abordagem de CI/CD (Integração Contínua/Desenvolvimento Contínuo).

Próximas etapas

Para saber mais sobre os tópicos apresentados neste artigo:

• Consulte a documentação do Azure DevOps para saber mais sobre o Azure DevOps e ferramentas relacionadas, incluindo o Azure Repos e o Azure Pipelines.
• Consulte a família de produtos e soluções do Azure Stack para saber mais sobre todo o portfólio de produtos e soluções.

Quando estiver pronto para testar o exemplo da solução, continue com o guia de implantação da solução de CI/CD híbrido DevOps. O guia de implantação fornece instruções passo a passo para implantar e testar seus componentes. Você aprenderá a implantar um aplicativo no Azure e no Azure Stack Hub usando um pipeline de CI/CD (integração contínua/entrega contínua) híbrido.