Padrão de DevOps

Codifique a partir de um único local e implante em vários destinos em ambientes de desenvolvimento, teste e produção que podem estar em seu datacenter local, 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 à medida que se move em cada ambiente. Por exemplo, o código escrito num ambiente de desenvolvimento deve ser reescrito para funcionar num ambiente de teste e reescrito quando finalmente chegar a um ambiente de produção. Além disso, este código está especificamente ligado ao anfitrião. Isso aumenta o custo e a complexidade da manutenção do seu aplicativo. Cada versão do aplicativo está vinculada a cada ambiente. O aumento da complexidade e da duplicação aumentam o risco de segurança e a qualidade do código. Além disso, o código não pode ser prontamente reimplantado quando você remove hosts com falha de restauração ou implanta hosts adicionais para lidar com aumentos na demanda.

Solução

O Padrão de DevOps permite criar, testar e implantar um aplicativo que é executado em várias nuvens. Este padrão une a prática da integração contínua e da 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 uma construção para um ambiente de produção. Juntos, esses processos criam um processo de liberação que oferece suporte à implantação em diversos ambientes. 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. Os aplicativos e serviços implantados usando o Padrão de DevOps são intercambiáveis e podem ser executados em qualquer um desses locais, aproveitando os recursos e recursos locais e de nuvem pública.

Usar um pipeline de liberação de DevOps ajuda você a:

• Inicie uma nova compilação 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 testes de aceitação do usuário.
• Implante automaticamente em uma nuvem privada assim que seu código passar no teste.

Questões e considerações

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

• As funções, pontos de extremidade, serviços e outros recursos na sua implantação estão disponíveis nas localizações-alvo de implantação?
• Os artefatos de configuração são armazenados em locais acessíveis nas 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 de 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 principal ponto de controle 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 escalar do que os contêineres. Para usar contêineres para dimensionamento, no entanto, seu processo de compilação deve ser executado com contêineres.

Disponibilidade

Disponibilidade no contexto do DevPattern significa ser capaz de recuperar qualquer informação de estado associada ao seu 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 (Recovery Time Objetive, objetivo de tempo de recuperação) especifica quanto tempo você pode ficar sem um sistema.

• O RPO (Recovery Point Objetive, 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 — isso faz parte do Azure — mas sim garantir que você mantenha o estado de seus sistemas de 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. Que 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.

Capacidade de gestão

O design de qualquer sistema baseado 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 rastreie políticas de segurança e 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 os custos de faturamento por grupo de recursos. Você também pode excluir recursos como um conjunto, o que é útil para implantações de teste.

Quando usar este padrão

Use este 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 para sua solução, onde 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 sejam capazes de seguir o processo de integração contínua e entrega contínua no Padrão de DevOps.

Este padrão não é recomendado:

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

Próximos passos

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

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

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