Como a Microsoft fornece software com o DevOps

A Microsoft tem décadas de experiência fornecendo serviços altamente escalonáveis para ambientes de produção. À medida que os serviços e ambientes da Microsoft se expandiram, suas práticas de entrega também evoluíram ao longo do tempo. Muitos clientes da Microsoft também adotaram e se beneficiaram dessas práticas de entrega eficientes. Os seguintes princípios e processos principais do DevOps podem se aplicar a qualquer esforço de entrega de software moderno.

Para implementar os processos de entrega do DevOps, a Microsoft adotou as seguintes iniciativas:

• Foque a mentalidade organizacional e o ritmo na entrega.
• Forme equipes autônomas e responsáveis que possuam, testem e entreguem funcionalidades.
• Mude para a direita para testar e monitorar sistemas em produção.

Foco na entrega

O envio mais rápido é um benefício óbvio que organizações e equipes podem medir e apreciar facilmente. A cadência típica de DevOps envolve ciclos de sprint curtos com implantações regulares em produção.

Temendo a falta de estabilidade do produto com sprints curtos, algumas equipes compensaram isso implementando períodos de estabilização no final de seus ciclos de sprint. Os engenheiros desejavam lançar o maior número de funcionalidades possível durante o sprint, então eles incorreram em uma dívida técnica relacionada a testes, que precisaram pagar durante a estabilização. As equipes que administraram suas dívidas durante o sprint então tiveram que apoiar as equipes que acumularam dívidas. Os custos extras se refletiram através dos pipelines de entrega e na produção.

A remoção do período de estabilização melhorou rapidamente a maneira como as equipes gerenciavam suas dívidas. Em vez de adiar o trabalho de manutenção essencial para o período de estabilização, as equipes que acumularam dívidas tiveram que dedicar o próximo sprint para reduzir suas dívidas. As equipes rapidamente aprenderam a gerenciar suas dívidas de teste durante sprints. As funcionalidades são entregues quando estão comprovadas e valem o custo da implementação.

Automatizar totalmente os pipelines

Grande parte dos benefícios que as equipes de melhoria podem ganhar imediatamente é ao automatizar completamente os pipelines do repositório de código até a produção. A automação inclui pipelines de versão com integração contínua (CI), testes automatizados e entrega contínua (CD).

Equipes podem evitar implantar porque é difícil, mas, quanto menos frequentemente implantam, mais difícil fica. Quanto mais tempo entre as implantações, mais problemas se acumulam. Se o código não for atualizado, haverá uma dívida de implantação.

É mais fácil trabalhar em partes menores implantando com frequência. Essa ideia pode parecer óbvia em retrospectiva, mas na época pode parecer contraintuitiva. Implantações frequentes também motivam as equipes a priorizar a criação de pipelines e ferramentas de implantação mais eficientes e confiáveis.

Usar ferramentas internas

A Microsoft usa o sistema de gerenciamento de lançamento que eles criam e o envia aos clientes. Um único investimento melhora a produtividade da equipe e os produtos da Microsoft. O uso de um sistema secundário reduziria o fluxo de desenvolvimento e entrega.

Autonomia e responsabilidade da equipe

Não há indicadores chave de progresso (KPIs) específicos que meçam a produtividade ou o desempenho da equipe, ou se um recurso está no caminho certo. As equipes precisam ser capazes de gerenciar seus próprios planos e backlogs, encontrando uma maneira de se alinhar às metas organizacionais.

É importante se comunicar diretamente com as equipes para acompanhar o progresso. As ferramentas devem facilitar a comunicação, mas a conversa é a maneira mais transparente de se comunicar.

Priorizar funcionalidades

Um objetivo importante é se concentrar na entrega de funcionalidades. Os agendamentos podem avaliar quanto as equipes e os indivíduos podem razoavelmente completar durante um determinado período de tempo, mas algumas funcionalidades serão entregues mais cedo e outras virão mais tarde. As equipes podem priorizar o trabalho para que os recursos mais importantes cheguem à produção.

Usar microsserviços

Os microsserviços oferecem vários benefícios técnicos que melhoram e simplificam a entrega. Microsserviços também definem limites naturais para a responsabilidade da equipe. Quando uma equipe tem autonomia sobre o investimento em um microsserviço, ela pode priorizar como implementar recursos e gerenciar dívidas. O Teams pode se concentrar em planos para fatores como controle de versão, independentemente dos serviços gerais que dependem do microsserviço.

Trabalhar na branch principal

Os engenheiros costumavam trabalhar em ramificações separadas. A dívida de mesclagem em cada ramificação cresceu até que o engenheiro tentou integrar sua ramificação ao branch principal. Quanto mais equipes e engenheiros havia, maior a integração se tornava.

Para que a integração ocorra de forma mais rápida, contínua e em partes menores, os engenheiros agora trabalham no branch principal. Um grande motivo para mudar para o Git foi a ramificação leve que o Git oferece. O benefício da engenharia interna foi eliminar a hierarquia de ramificação profunda e seus resíduos. Todo o tempo que costumava ser gasto na integração agora é direcionado para a entrega.

Usar sinalizadores de recursos

Alguns recursos não estão completamente concluídos para uma implantação de sprint, mas ainda podem se beneficiar de testes em produção. O Teams pode mesclar e implantar esse código com sinalizadores de recursos para ativar o recurso para usuários específicos, como a equipe de desenvolvimento ou um pequeno segmento de adotantes iniciais. Os sinalizadores de recursos controlam a exposição sem arriscar problemas com a base de usuários em geral e podem ajudar as equipes a determinar se e como concluir o recurso.

Teste em produção

Mudar o foco para testar em produção ajuda a garantir que os testes de pré-produção sejam válidos e que ambientes de produção em constante mudança estejam prontos para suportar implantações.

Testes e métricas de instrumentos

Independentemente de onde um aplicativo é implantado, é importante instrumentar tudo. A instrumentação não só ajuda a identificar e corrigir problemas, mas pode fornecer pesquisas inestimáveis sobre o uso e o que adicionar a seguir.

Testar padrões de resiliência

Um risco para implantações complexas é falhas em cascata, nas quais uma falha de componente faz com que componentes dependentes falhem e assim por diante até que todo o sistema seja interrompido. É importante entender onde estão os pontos únicos de falha (SPOFs) e como eles são mitigados e testar os processos de mitigação, especialmente na produção.

Escolher as métricas certas

Criar métricas pode ser difícil. Um erro comum é incluir muitas métricas para evitar a falta de nada. Mas isso pode levar a ignorar ou desconfiar do valor das métricas que não atendem a uma necessidade específica. Em vez disso, as equipes da Microsoft levam tempo para determinar os dados necessários para medir o sucesso. O Teams pode adicionar ou alterar as métricas, mas entender a finalidade desde o início facilita esse processo.

Além da base de uma métrica, as equipes consideram o que precisam da métrica para medir. Por exemplo, a velocidade ou aceleração dos ganhos do usuário pode ser uma métrica mais útil do que o número total de usuários. As métricas variam de projeto para projeto, mas as mais úteis são aquelas com potencial para impulsionar decisões de negócios.

Usar métricas para orientar o trabalho

A Microsoft inclui métricas com revisões nos níveis de liderança mais altos. A cada seis semanas, as organizações apresentam como estão se saindo em saúde, negócios, cenários e telemetria do cliente. As organizações discutem as métricas com os executivos e com suas equipes.

As equipes em toda a organização examinam as métricas de engajamento do usuário para determinar o impacto de suas funcionalidades. As equipes não apenas enviam recursos, mas procuram ver se e como as pessoas estão usando-os. As equipes usam essas métricas para ajustar as listas de pendências e determinar se os recursos precisam de mais trabalho para atender às metas.

Diretrizes de entrega

• Nunca é uma linha reta para ir de A até B, nem B é o destino final.
• Sempre haverá contratempos e erros.
• Veja os contratempos como oportunidades de aprendizado para alterar táticas para concluir uma determinada parte do processo.
• Com o tempo, cada equipe evolui suas práticas de DevOps, aproveitando a experiência e ajustando-se para atender às necessidades em mudança.
• A chave é focar na entrega de valor, tanto para os usuários finais quanto para o próprio processo de entrega.