Como a Microsoft fornece software com o DevOps

A Microsoft tem décadas de experiência no fornecimento de 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 beneficiam dessas práticas de entrega eficientes. Os princípios e processos básicos de DevOps a seguir podem ser aplicados a qualquer esforço atual de entrega de software.

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

• Foco no mindset organizacional e cadência na entrega.
• Formação de equipes autônomas e responsáveis que possuem, testam e fornecem recursos.
• Deslocamento para a direita para testar e monitorar sistemas em produção.

Foco na entrega

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

Temendo a falta de estabilidade do produto com sprints curtos, algumas equipes compensaram com períodos de estabilização no final de seus ciclos de sprint. Os engenheiros queriam enviar o maior número possível de recursos durante o sprint, então contraíram dívidas de teste que tiveram que pagar durante a estabilização. As equipes que administraram suas dívidas durante o sprint tiveram que apoiar as equipes que acumularam dívidas. Os custos extras passaram pelos pipelines de entrega e entraram na produção.

A eliminação do período de estabilização melhorou rapidamente a forma como as equipes gerenciavam sua dívida. Em vez de empurrar o trabalho de manutenção para o período de estabilização, as equipes que acumularam dívidas tiveram que passar o próximo sprint tentando atingir suas metas de dívida. As equipes aprenderam rapidamente a gerenciar suas dívidas de teste durante os sprints. Os recursos são fornecidos quando são comprovados e valem o custo de implantação.

Automatizar totalmente os pipelines

Grande parte da melhoria que as equipes podem obter imediatamente é automatizar totalmente os pipelines do repositório de código para a produção. A automação inclui pipelines de liberação com integração contínua (CI), testes automatizados e entrega contínua (CD).

As equipes podem evitar a implantação porque é difícil, mas quanto menor for a frequência das implantações, mais difícil fica. Quanto mais tempo entre as implantações, mais problemas se acumulam. Se o código não for novo, há dívida de implantação.

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

Usar ferramentas internas

A Microsoft usa o sistema de gerenciamento de liberação criado por eles 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 a velocidade de desenvolvimento e entrega.

Autonomia e responsabilidade da equipe

Nenhum KPI (Key Progress Indicators, indicadores chave de progresso) específico mede 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 pendências, enquanto encontram 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 conversar é a forma mais transparente de se comunicar.

Priorizar recursos

Um objetivo importante é focar na entrega de recursos. Os cronogramas podem avaliar o quanto as equipes e os indivíduos podem concluir razoavelmente em um determinado período de tempo, mas alguns recursos serão entregues mais cedo e outros 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. Os microsserviços também fornecem limites naturais para a propriedade da equipe. Quando uma equipe tem autonomia sobre o investimento em um microsserviço, ela pode priorizar como implementar recursos e gerenciar dívidas. As equipes podem se concentrar em planos para fatores como controle de versão, independentemente dos serviços gerais que dependem do microsserviço.

Trabalhar na principal

Os engenheiros costumavam trabalhar em filiais separadas. A dívida de fusão em cada filial cresceu até que o engenheiro tentou integrar sua filial à filial principal. Quanto mais equipes e engenheiros houvesse, maior era a integração.

Para que a integração aconteça de forma mais rápida, contínua e em partes menores, os engenheiros agora trabalham na filial principal. Um grande motivo para mudar para o Git foi a ramificação leve que o Git oferece. O benefício para a engenharia interna foi eliminar a hierarquia profunda das filiais e seus desperdícios. Todo o tempo que antes era gasto integrando agora é dedicado à 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 dos testes em produção. As equipes podem 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 usuários iniciais. Os sinalizadores de recursos controlam a exposição sem correr o risco de problemas com a base geral de usuários e podem ajudar as equipes a determinar a possibilidade e a maneira de concluir o recurso.

Testando em produção

O deslocamento para a direita para testar na produção ajuda a garantir que os testes de pré-produção sejam válidos e que os ambientes de produção em constante mudança estejam prontos para lidar com implantações.

Instrumentar testes e métricas

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 em seguida.

Testar padrões de resiliência

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

Escolher as métricas certas

Projetar métricas pode ser difícil. Um erro comum é incluir muitas métricas para não perder nada. Mas isso pode levar a ignorar ou desconfiar do valor de métricas que não atendem a uma necessidade específica. Em vez disso, as equipes da Microsoft levam tempo para determinar os dados de que precisam para medir o sucesso. As equipes podem adicionar ou alterar métricas, mas entender o propósito desde o início facilita esse processo.

Além da base de uma métrica, as equipes consideram o que precisam que a métrica meça. 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 conduzir decisões de negócios.

Usar métricas para orientar o trabalho

A Microsoft inclui métricas com análises nos mais altos níveis de liderança. A cada seis semanas, as organizações apresentam como estão se saindo em saúde, negócios, cenários e telemetria de clientes. 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 usuários engajados para determinar o significado de seus recursos. As equipes não apenas enviam recursos, mas procuram ver se e como as pessoas os estão usando. As equipes usam essas métricas para ajustar as pendências e determinar se os recursos precisam de mais trabalho para atingir as metas.

Diretrizes de entrega

• Não é possível ir de A a B em uma linha reta, e B não é o fim.
• Sempre haverá contratempos e erros.
• Veja os contratempos como oportunidades de aprendizado para mudar as táticas e completar 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 constante mudança.
• A chave é focar na entrega de valor, tanto para os usuários finais quanto para o próprio processo de entrega.