Como a Microsoft fornece software com DevOps

A Microsoft tem décadas de experiência no fornecimento de serviços altamente escaláveis para ambientes de produção. À medida que os serviços e ambientes da Microsoft se expandiram, suas práticas de fornecimento 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 seguintes princípios e processos básicos de DevOps podem ser aplicados a qualquer esforço moderno de fornecimento de software.

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

• Concentre a mentalidade organizacional e o ritmo na entrega.
• Forme equipes autônomas e responsáveis que possuam, testem e forneçam recursos.
• Mude 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 uma 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 lançar o maior número possível de funcionalidades durante o sprint, então acumularam dívida de teste que tiveram de pagar durante a estabilização. As equipas que geriram a sua dívida durante o sprint tiveram então de apoiar as equipas que acumularam dívidas. Os custos extras foram distribuídos através dos canais de entrega até à produção.

A remoção do período de estabilização melhorou rapidamente a forma como as equipas geriram as suas dívidas. Em vez de empurrar o trabalho de manutenção fundamental para o período de estabilização, as equipes que acumularam dívida tiveram que passar o próximo sprint alcançando suas metas de dívida. As equipas aprenderam rapidamente a gerir a sua dívida de teste durante os sprints. As funcionalidades são disponibilizadas quando são comprovadas e justificam o custo de implementação.

Automatize totalmente os pipelines

Grande parte dos melhoramentos que as equipas podem alcançar imediatamente é automatizar completamente os pipelines do repositório de código até à produção. A automação inclui pipelines de entrega 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 menos freqüentemente implantam, mais difícil é. Quanto mais tempo entre as implantações, mais problemas se acumulam. Se o código não for novo, há uma dívida de implantação.

É mais fácil trabalhar em partes menores, implementando com frequência. Esta ideia pode parecer óbvia em retrospetiva, mas na altura 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.

Use ferramentas internas

A Microsoft usa o sistema de gerenciamento de versão que eles criam e o envia para os clientes. Um único investimento melhora a produtividade da equipe e os produtos Microsoft. O uso de um sistema secundário reduziria a eficácia do desenvolvimento e entrega.

Autonomia e responsabilização da equipa

Nenhum indicador-chave de progresso (KPIs) 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 com os objetivos organizacionais.

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

Priorize funcionalidades

Um objetivo importante é focar na entrega de funcionalidades. Os cronogramas podem avaliar o quanto as equipes e os indivíduos podem razoavelmente concluir durante um determinado período de tempo, mas alguns recursos serão entregues mais cedo e outros virão mais tarde. As equipes podem priorizar o trabalho para que as funcionalidades 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 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. 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 no ramo principal

Os engenheiros costumavam trabalhar em ramos separados. A dívida de fusão em cada ramo cresceu até que o engenheiro tentou integrar seu ramo no ramo principal. Quanto mais equipes e engenheiros houvesse, maior se tornava 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 no ramo principal. Uma grande razão 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 dos ramos e seus desperdícios. Todo o tempo anteriormente gasto na integração agora é direccionado para a entrega.

Utilizar sinalizadores de funcionalidades

Alguns recursos não estão completamente concluídos para uma implementação durante um sprint, mas ainda podem 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 primeiros usuários. 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 se e como concluir o recurso.

Testes em produção

A mudança para testar diretamente 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 evolução estejam prontos para lidar com os lançamentos.

Testes e métricas de instrumentos

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

Testar padrões de resiliência

Um risco para implantações complexas são as falhas em cascata, nas quais uma falha de componente faz com que os componentes dependentes falhem, e assim por diante até que todo o sistema quebre. É 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.

Escolha as métricas certas

Projetar métricas pode ser difícil. Um erro comum é incluir muitas métricas, para evitar 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 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.

Use métricas para orientar o trabalho

A Microsoft inclui métricas com avaliações 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 do cliente. As organizações discutem as métricas com os executivos e com suas equipes.

Equipes em toda a organização examinam métricas de usuários engajados para determinar o significado de seus recursos. As equipas não enviam apenas funcionalidades, mas procuram ver se e como as pessoas as estão a utilizar. As equipes usam essas métricas para ajustar as listas de pendências e determinar se os recursos precisam de mais trabalho para atingir as metas.

Diretrizes de entrega

• Nunca é uma linha reta para ir de A a B, nem B é o fim.
• Sempre haverá contratempos e erros.
• Veja os contratempos como oportunidades de aprendizagem para mudar táticas para 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.