Dê a sua opinião sobre a experiência de download do PDF.

Centro de recursos de DevOps

Artigo • 11/09/2023

Este centro oferece recursos sobre práticas de DevOps, métodos Agile, controle de
versão Git, DevOps na Microsoft e como avaliar o progresso de DevOps da sua
organização.

Planejar com DevOps

Capacite as equipes para gerenciar seu trabalho com agilidade e visibilidade total sobre
todos os produtos e projetos.

Desenvolver com DevOps

Aproveite as principais ferramentas de DevOps, como o Git, para gerenciar com
eficiência o processo de desenvolvimento.
Forneça com DevOps
Implante aplicativos em qualquer plataforma e forneça valor ao cliente continuamente
por meio de testes automatizados.

Opere com DevOps

Implemente o monitoramento de pilha completa, receba alertas acionáveis e obtenha
insights de logs e telemetria para operar sistemas de produção com facilidade.

Eventos e palestras do DevOps

Veja algumas palestras de conferência recentes sobre Devops no canal do YouTube da
Microsoft.
Ferramentas DevOps
GitHub
Implemente as melhores práticas de DevOps, como controle de versão, codificação
colaborativa, automação, CI/CD, segurança e administração de equipe com o GitHub.

Azure DevOps
Junte PM, design e engenharia com processos integrados e colaborativos para planejar
o trabalho, desenvolver código e entregar aplicativos.

CLI do Desenvolvedor do Azure

Use esses comandos amigáveis para desenvolvedores para obter uma experiência
consistente em seu terminal, editor de código ou ambiente de desenvolvimento
integrado e pipeline do GitHub Actions.

Visual Studio
Utilize este IDE (ambiente de desenvolvimento integrado) para criar aplicações
avançadas e escaláveis do Azure.

Visual Studio Code

Use este editor de código-fonte leve, mas avançado, em seus desktops Windows,
macOS e Linux.
O que é DevOps?
Artigo • 05/10/2023

O DevOps combina desenvolvimento (Dev) e operações (Ops) para unir pessoas,

processos e tecnologia no planejamento, desenvolvimento, entrega e operações de
aplicativos. O DevOps permite a coordenação e a colaboração entre funções
anteriormente isoladas, como desenvolvimento, operações de TI, engenharia de
qualidade e segurança.

As equipes adotam a cultura, as práticas e as ferramentas de DevOps para aumentar a

confiança nos aplicativos que criam, responder melhor às necessidades dos clientes e
atingir as metas de negócios com mais rapidez. O DevOps ajuda as equipes a fornecer
valor continuamente aos clientes, criando produtos melhores e mais confiáveis.

DevOps e o ciclo de vida do aplicativo

O DevOps influencia o ciclo de vida do aplicativo ao longo de todas fases de
planejamento, desenvolvimento, entrega e operações. Cada fase depende das outras, e
as fases não são específicas a uma função. Uma cultura de DevOps envolve todas as
funções em cada fase até certo ponto.

O diagrama a seguir ilustra as fases do estilo de vida do aplicativo de DevOps:

Metas e benefícios do DevOps

Quando uma equipe adota a cultura, as práticas e as ferramentas de DevOps, ela pode
alcançar coisas incríveis:

Acelerar o tempo para colocação no mercado

Com a eficiência potencializada, colaboração aprimorada da equipe, ferramentas de
automação e implantação contínua, as equipes conseguem reduzir rapidamente o
tempo desde o início do produto até o lançamento no mercado.
Adapte-se ao mercado e à concorrência
Uma cultura de DevOps exige que as equipes tenham um foco no cliente em primeiro
lugar. Ao unir agilidade, colaboração em equipe e foco na experiência do cliente, as
equipes podem entregar valor continuamente aos seus clientes e aumentar sua
competitividade no mercado.
Mantenha a estabilidade e a confiabilidade do sistema
Ao adotar práticas de melhoria contínua, as equipes são capazes de aumentar a
estabilidade e a confiabilidade dos produtos e serviços que implantam. Essas práticas
ajudam a reduzir falhas e riscos.
Melhore o tempo médio para recuperação
A métrica de tempo médio para recuperação indica quanto tempo é necessário para se
recuperar de uma falha ou violação. Para gerenciar falhas de software, violações de
segurança e planos de melhoria contínua, as equipes devem medir e trabalhar para
melhorar essa métrica.

Adote uma cultura de DevOps

Para implementar totalmente o DevOps, você deve adotar uma cultura de DevOps.
Cultivar uma cultura de DevOps exige mudanças profundas na forma como as pessoas
trabalham e colaboram umas com as outras. No entanto, quando se lançam a esse
desafio, as organizações podem criar o ambiente ideal para a evolução de equipes de
alto desempenho. Embora a adoção de práticas de DevOps automatize e otimize
processos por meio da tecnologia, se não houver a mudança para uma cultura de
DevOps dentro da organização e de suas pessoas, você não obterá todos os benefícios
do DevOps.

A imagem a seguir captura os principais aspectos da cultura de local ao vivo da

Microsoft.

As práticas a seguir são componentes-chave de uma cultura de DevOps:

Colaboração, visibilidade e alinhamento: uma marca registrada de uma cultura de

DevOps saudável é a colaboração entre equipes. A colaboração começa com a
visibilidade. As equipes de desenvolvimento, TI e outras devem compartilhar seus
processos, prioridades e preocupações de DevOps umas com as outras. Ao
planejar seu trabalho em conjunto, eles estão mais bem posicionados para se
alinhar em metas e medidas de sucesso relacionadas ao negócio.
Alterações no escopo e contabilidade: à medida que as equipes se alinham, elas
assumem a propriedade e se envolvem em outras fases do ciclo de vida, não
apenas naquelas que são essenciais para suas funções. Por exemplo, os
desenvolvedores tornam-se responsáveis não apenas pela inovação e a qualidade
estabelecidas na fase de desenvolvimento, mas também pelo desempenho e
estabilidade que suas alterações trazem a software na fase de operação. Ao
mesmo tempo, os operadores de TI certamente incluirão governança, segurança e
conformidade na fase de planejamento e desenvolvimento.
Ciclos de lançamento mais curtos: as equipes de DevOps se mantêm ágeis
lançando versões de software em ciclos curtos. Ciclos de lançamento mais curtos
facilitam o planejamento e o gerenciamento de riscos, pois o progresso é
incremental, reduzindo também o impacto sobre a estabilidade do sistema. A
 redução do ciclo de lançamento também permite que as organizações se adaptem
melhor e reajam de maneira mais ágil à evolução das necessidades dos clientes e à
pressão da concorrência.
Aprendizagem contínua: as equipes de alto desempenho de DevOps estabelecem
uma mentalidade de crescimento. Elas falham rapidamente e incorporam os
aprendizados em seus processos. Elas se esforçam para melhorar continuamente,
aumentar a satisfação do cliente e acelerar a inovação e a adaptabilidade ao
mercado.

Implementar práticas de DevOps

Você implementa o DevOps seguindo as práticas de DevOps (descritas nas seções a
seguir) durante todo o ciclo de vida do aplicativo. Algumas dessas práticas ajudam a
acelerar, automatizar e melhorar uma fase específica. Outras abrangem várias fases,
ajudando as equipes a criar processos contínuos que ajudam a melhorar a
produtividade.

CI/CD (integração contínua e entrega contínua)

A Integração Contínua (CI) é a prática usada pelas equipes de desenvolvimento para
automatizar, mesclar e testar código. A CI ajuda a capturar bugs no início do ciclo de
desenvolvimento, o que os torna mais baratos de corrigir. Os testes automatizados são
executados como parte do processo de CI para garantir a qualidade. Os sistemas de CI
produzem artefatos e os alimentam para liberar processos para impulsionar
implantações frequentes.

A CD (entrega contínua) é um processo pelo qual o código é criado, testado e

implantado em um ou mais ambientes de teste e produção. Implantar e testar em vários
ambientes aumenta a qualidade. Os sistemas de CD produzem artefatos implantáveis,
incluindo infraestrutura e aplicativos. Os processos de lançamento automatizados
consomem esses artefatos para lançar novas versões e correções para os sistemas
existentes. Os sistemas que monitoram e enviam alertas são executados continuamente
para gerar visibilidade de todo o processo de CD.

Controle de versão
O controle de versão é a prática de gerenciar código por meio de versões –
acompanhando as revisões e o histórico de alterações para facilitar a revisão e a
recuperação do código. Essa prática costuma ser implementada usando sistemas de
controle de versão, como o Git, que permitem que vários desenvolvedores colaborem
na criação do código. Esses sistemas fornecem um processo claro para mesclar
alterações de código ocorridas no mesmo arquivo, gerenciar conflitos e reverter
alterações para estados anteriores.

O uso do controle de versão é uma prática fundamental de DevOps que ajuda as

equipes de desenvolvimento a trabalharem juntas, dividir as tarefas de codificação entre
os membros da equipe e armazenar o código completo para fácil recuperação, se
necessário. O controle de versão também é um elemento necessário em outras práticas,
como a integração contínua e a infraestrutura como código.

Desenvolvimento de software Agile

O Agile é uma abordagem de desenvolvimento de software que enfatiza a colaboração
em equipe, os comentários do cliente e do usuário e a alta adaptabilidade para
mudanças por meio de ciclos de lançamento curtos. As equipes que praticam o Agile
fornecem mudanças e aprimoramentos contínuos aos clientes, coletam seus
comentários e aprendem e se ajustam com base nos desejos e nas necessidades dos
clientes. O Agile é substancialmente diferente de outras estruturas mais tradicionais,
como a cascata, que inclui longos ciclos de versão definidos por fases sequenciais. O
Kanban e o Scrum são duas estruturas populares associadas ao Agile.

Infraestrutura como código

A infraestrutura como código define os recursos e as topologias do sistema de uma
maneira descritiva que permite às equipes gerenciar esses recursos da maneira como
codificariam. Essas definições também podem ser armazenadas e versionadas em
sistemas de controle de versão, onde podem ser revisadas e revertidas – novamente
como código.

A prática de infraestrutura como código ajuda as equipes a implantar os recursos do

sistema de maneira confiável, repetível e controlada. A infraestrutura como código
também ajuda a automatizar a implantação e reduz o risco de erro humano,
especialmente para ambientes grandes e complexos. Essa solução confiável e repetível
para a implantação de ambientes permite que as equipes mantenham ambientes de
desenvolvimento e teste idênticos ao ambiente de produção. Da mesma maneira, a
duplicação de ambientes para diferentes data centers e plataformas em nuvem também
se torna mais simples e eficiente.

Gerenciamento de configuração
O gerenciamento de configuração refere-se ao gerenciamento do estado dos recursos
em um sistema, incluindo servidores, máquinas virtuais e bancos de dados. Usando
ferramentas de gerenciamento de configuração, as equipes podem implementar
alterações de maneira controlada e sistemática, reduzindo os riscos de modificar a
configuração do sistema. As equipes usam ferramentas de gerenciamento de
configuração para acompanhar o estado do sistema e ajudar a evitar desvios de
configuração, já que é assim que a configuração de um recurso de sistema se desvia do
estado desejado ao longo do tempo.

Juntamente com a infraestrutura como código, é fácil criar modelos e automatizar a

definição e configuração do sistema, o que ajuda as equipes a operar ambientes
complexos em escala.

Monitoramento contínuo
O monitoramento contínuo significa ter visibilidade total e em tempo real do
desempenho e da integridade de toda a pilha de aplicativos. Essa visibilidade varia
desde a infraestrutura subjacente que executa o aplicativo até componentes de software
de nível superior. A visibilidade é obtida por meio da coleta de telemetria e metadados
e configuração de alertas para condições predefinidas que merecem atenção de um
operador. A telemetria compreende dados de eventos e logs coletados de várias partes
do sistema e armazenados em um local onde possam ser analisados e consultados.

As equipes de alto desempenho de DevOps garantem a definição de alertas acionáveis

e significativos e a coleta de uma telemetria abundante para que seja possível extrair
insights de grandes quantidades de dados. Esses insights ajudam a equipe a mitigar
problemas em tempo real e a ver como melhorar o aplicativo em ciclos de
desenvolvimento futuros.

Planejamento
Na fase de planejamento, as equipes de DevOps idealizam, definem e descrevem os
recursos e as funcionalidades dos aplicativos e sistemas que planejam construir. As
equipes acompanham o progresso das tarefas em níveis baixos e altos de granularidade,
desde produtos individuais até portfólios de vários produtos. As equipes usam as
seguintes práticas de DevOps para planejar com agilidade e visibilidade:

Crie listas de pendências.

Acompanhe bugs.
Gerencie o desenvolvimento de software Agile com Scrum.
Use quadros Kanban.
 Visualize o progresso com painéis.

Para obter uma visão geral das diversas lições aprendidas e práticas adotadas pela
Microsoft para dar suporte ao planejamento de DevOps nas equipes de software da
empresa, consulte Como a Microsoft faz planejamento com o DevOps.

Desenvolvimento
A fase de desenvolvimento inclui todos os aspectos do desenvolvimento de código de
software. Nesta fase, as equipes de DevOps executam as seguintes tarefas:

Selecionar um ambiente de desenvolvimento.

Escrever, testar, revisar e integrar o código.
Criar o código em artefatos para implantar em vários ambientes.
Usar o controle de versão, geralmente Git, para colaborar no código e trabalhar
paralelamente.

Para inovar rapidamente sem sacrificar a qualidade, a estabilidade e a produtividade, as

equipes de DevOps:

Usam ferramentas altamente produtivas.

Automatizam etapas cotidianas e manuais.
Iteram em pequenos incrementos por meio do teste automatizado e integração
contínua (CI).

Para obter uma visão geral das práticas de desenvolvimento adotadas pela Microsoft
para dar suporte à sua migração para o DevOps, consulte Como a Microsoft desenvolve
com o DevOps.

Fornecimento
A entrega é o processo de implantação consistente e confiável de aplicativos em
ambientes de produção, de preferência por meio de entrega contínua (CD).

Na fase de entrega, as equipes de DevOps:

Definem um processo de gerenciamento de versões com etapas claras de

aprovação manual.
Defina portões automatizados para mover aplicativos entre estágios até a
liberação final para os clientes.
Automatize os processos de entrega para torná-los escaláveis, repetíveis,
controlados e bem testados.
A entrega também inclui a implantação e a configuração da infraestrutura fundamental
do ambiente de entrega. As equipes de DevOps usam tecnologias como infraestrutura
como código (IaC), contêineres e microsserviços para fornecer ambientes de
infraestrutura totalmente governados.

As práticas de implantação segura podem identificar problemas antes que eles afetem a
experiência do cliente. Essas práticas ajudam as equipes de DevOps a realizar entregas
frequentes com facilidade, confiança e tranquilidade.

Os princípios e processos mais importantes de DevOps que a Microsoft evoluiu para

fornecer sistemas de entrega eficientes são descritos em Como a Microsoft fornece
software com o DevOps.

Operações
A fase de operações envolve manutenção, monitoramento e solução de problemas de
aplicativos em ambientes de produção, incluindo nuvens híbridas ou públicas, como o
Azure . As equipes de DevOps visam a confiabilidade do sistema, alta disponibilidade,
segurança forte e tempo de inatividade zero.

A entrega automatizada e as práticas de implantação segura ajudam as equipes a

identificar e mitigar problemas rapidamente quando eles ocorrem. Manter esse nível de
vigilância requer telemetria avançada, alertas acionáveis ​e visibilidade total sobre os
aplicativos e o sistema subjacente.

As práticas que a Microsoft usa para operar plataformas online complexas são descritas
em Como a Microsoft opera sistemas confiáveis com o DevOps.

Próximas etapas
Planejar cargas de trabalho eficientes com DevOps
Desenvolver software moderno com o DevOps
Fornecer serviços de qualidade com o DevOps
Operar sistemas confiáveis com DevOps

Outros recursos
Soluções de DevOps no Azure
O percurso de DevOps na Microsoft
Comece a fazer DevOps com o Azure
Segurança em DevOps (DevSecOps)
Treinamento e certificações
Introdução ao Azure DevOps
Introduza o DevOps Dojo: crie eficiências que dão suporte à sua empresa
AZ-400: Começar um percurso de transformação no DevOps
facilitar a comunicação e a colaboração
Exame AZ-400: Designing and Implementing Microsoft DevOps Solutions
AZ-400: Implementar segurança e validar bases de código para conformidade
Planejar cargas de trabalho eficientes
com DevOps
Artigo • 05/10/2023

A fase de planejamento do DevOps é muitas vezes vista como o primeiro estágio do

DevOps, o que não está totalmente correto. Na prática, as equipes de software
modernas trabalham em ciclos apertados, onde cada fase informa continuamente as
outras por meio de lições que são aprendidas.

Às vezes, essas lições são positivas. Às vezes são negativas. E, às vezes, são informações
neutras de que a equipe precisa para tomar decisões estratégicas sobre o futuro. Todo o
setor se uniu em torno de um único adjetivo para descrever a capacidade de se adaptar
rapidamente às circunstâncias dinâmicas que essas lições criam: Agile. O termo se
tornou tão onipresente que agora é sinônimo da maioria das formas de planejamento
de DevOps.

O que é Agile?
Agile descreve uma abordagem pragmática ao desenvolvimento de software que
enfatiza a entrega incremental, a colaboração em equipe, o planejamento contínuo e o
aprendizado contínuo. Não se trata de um conjunto específico de ferramentas ou
práticas, mas sim de uma mentalidade de planejamento sempre aberta a mudanças e
concessões.
As equipes que empregam práticas de desenvolvimento Agile encurtam seu ciclo de
desenvolvimento para produzir software utilizável em um cronograma consistente. O
foco contínuo em fornecer qualidade aos usuários finais possibilita que o projeto geral
se adapte rapidamente às necessidades em evolução. Para começar a ver esse tipo de
retorno, as equipes precisam estabelecer alguns procedimentos ao longo do caminho.

Adotar uma cultura Agile

Implantar e nutrir uma cultura Agile dentro de uma organização é um investimento
fundamental para um DevOps eficaz. Embora o resultado final possa ser um conjunto
específico de software e serviços, os recursos humanos necessários para produzir e
manter esses ativos merecem consideração especial. As equipes têm os melhores
resultados quando investem tempo para adaptar sua cultura aos valores do mindset
Agile.

Selecionar um método Agile

Métodos Agile, que são frequentemente chamados de frameworks, são abordagens
abrangentes para as fases do ciclo de vida de desenvolvimento de software. Eles
prescrevem um método para realizar o trabalho com orientações e princípios claros. Um
dos frameworks Agile mais populares é o Scrum. A maioria das equipes que são novas
no Agile começam com o Scrum, devido à sua comunidade e ecossistema maduros. Mas
existem muitas alternativas, por isso vale a pena reservar um tempo para rever
diferentes opções antes de se estabelecer.

Abraçar as ferramentas Agile

Há um setor considerável que é gira em torno de ferramentas para o planejamento de
DevOps. Essas ferramentas geralmente se integram com vários métodos e plataformas
Agile que são usados no desenvolvimento de software. Uma ferramenta comum é o
Kanban, que ajuda as organizações e suas equipes a visualizarem o trabalho para
planejar melhor a entrega.

Criar equipes Agile

As equipes funcionam melhor quando todos têm uma direção clara. Adotar um método
Agile pode ajudar muito nessa área, pois ele melhora a transparência no DevOps. Mas
também existem outras técnicas eficazes que você pode aplicar para melhorar a função
das equipes em todos os marcos do projeto. Qualquer organização pode se beneficiar
da criação de equipes produtivas e focadas no cliente.
Dimensionar o Agile à medida que sua organização
cresce
À medida que o Agile ganhou popularidade, muitos estereótipos e interpretações
equivocadas lançaram uma sombra negativa sobre a sua eficácia. É fácil dizer "Sim,
estamos usando Agile" sem qualquer responsabilidade. Com o passar do tempo, é
comum que se formem maus hábitos por vários motivos, incluindo mal-entendidos
sobre o propósito do Agile. Pequenas organizações podem achar fácil ignorar alguns
desses equívocos. Mas, em operações maiores, esses problemas podem se tornar
verdadeiras dores de cabeça se você não os resolver. Felizmente, existem diretrizes úteis
para dimensionar o Agile para grandes equipes.

Próximas etapas
A Microsoft foi uma das primeiras grandes empresas a adotar o DevOps para o
planejamento de projetos de software em grande escala. Saiba mais sobre como a
Microsoft faz planejamentos no DevOps.

Está procurando uma experiência prática de DevOps? Confira o roteiro de

aprendizagem Evoluir suas práticas de DevOps. Ele apresenta o Azure DevOps como
tema principal, mas os conceitos e a experiência aplicam-se igualmente ao
planejamento em outras plataformas de DevOps, como o GitHub.
O que é Agile?
Artigo • 05/10/2023

Agile é um termo que descreve abordagens de desenvolvimento de software que

enfatizam a entrega incremental, a colaboração em equipe, o planejamento contínuo e
o aprendizado contínuo. O termo Agile foi cunhado em 2001 no Manifesto Agile . O
manifesto pretendia estabelecer princípios para orientar uma melhor abordagem ao
desenvolvimento de software. Em sua essência, o manifesto faz quatro declarações de
valores que representam a base do movimento Agile. Conforme escrito, o manifesto
afirma:

Passamos a valorizar:

Indivíduos e interações em vez de processos e ferramentas.

Software em funcionamento em vez de documentação abrangente.
Colaboração com o cliente em vez de negociação de contratos.
Responder a mudanças em vez de seguir um plano.

O manifesto não insinua que os itens do lado direito destas declarações não sejam
importantes ou necessários. Em vez disso, os itens à esquerda são simplesmente mais
valorizados.

Métodos e práticas Agile

É importante entender que Agile não é uma coisa. Você não faz Agile. Em vez disso, o
Agile é uma mentalidade que impulsiona uma abordagem para o desenvolvimento de
software. Como não há uma abordagem única que funciona para todas as situações, o
termo Agile passou a representar vários métodos e práticas que se alinham com as
declarações de valor no manifesto.

Os métodos Agile, que geralmente são chamados de frameworks, são abordagens

abrangentes para as fases do ciclo de vida do DevOps: planejamento, desenvolvimento,
entrega e operações. Eles prescrevem um método para realizar o trabalho com
orientações e princípios claros.

O Scrum é o framework ágil mais comum e com o qual a maioria das pessoas começa.
Já as práticas Agile são técnicas que são aplicadas durante as fases do ciclo de vida de
desenvolvimento de software.

O Planning Poker é uma prática de estimativa colaborativa projetada para

incentivar os membros da equipe a compartilhar sua compreensão do que
concluído significa. Muitas pessoas acham o processo divertido, e já é comprovado
que ele ajuda a promover o trabalho em equipe e estimativas melhores.
A integração contínua (CI) é uma prática comum de engenharia Agile que envolve
a integração de alterações de código no branch principal com frequência. Uma
compilação automatizada verifica as alterações. Como resultado, há uma redução
na dívida de integração e um branch principal continuamente pronto para enviar.

Essas práticas, como todas as práticas Agile, carregam o rótulo Agile, porque são
consistentes com os princípios do manifesto Agile.

O que o Agile não é

À medida que o Agile ganhou popularidade, muitos estereótipos e interpretações
equivocadas lançaram uma sombra negativa sobre a sua eficácia. É fácil dizer "Sim,
estamos usando o Agile" sem qualquer responsabilidade. Com esse ponto em mente,
considere algumas coisas que o Agile não é.

O Agile não é codificação de cowboy . O Agile não deve ser confundido com
uma abordagem de "vamos descobrir à medida que avançamos" para o
desenvolvimento de software. Essa concepção é completamente equivocada. O
Agile requer uma definição de concluído e valor explícito que é entregue aos
clientes em cada sprint. Enquanto o Agile valoriza a autonomia para indivíduos e
equipes, ele enfatiza a autonomia alinhada para garantir que o aumento da
autonomia produza maior valor.
O Agile não dispensa rigor e planejamento. As metodologias e práticas Agile
normalmente enfatizam a disciplina no planejamento. A chave é o planejamento
contínuo durante todo o projeto, não apenas o planejamento antecipado. O
planejamento contínuo garante que a equipe possa aprender com o trabalho que
 executa. Por meio dessa abordagem, a equipe maximiza o retorno sobre o
investimento (ROI) do planejamento.

"Planos não valem nada, mas planejamento é tudo." — Dwight D. Eisenhower

O Agile não é uma desculpa para a falta de um roteiro. Essa concepção equivocada
provavelmente fez mais mal ao movimento Agile em geral. As organizações e
equipes que seguem uma abordagem Agile sabem absolutamente para onde
estão indo e os resultados que querem alcançar. Reconhecer a mudança como
parte do processo é diferente de girar em uma nova direção a cada semana, sprint
ou mês.
O Agile não é desenvolvimento sem especificações. Em qualquer projeto, é
necessário manter sua equipe alinhada sobre por que e como o trabalho
acontece. Uma abordagem Agile para especificações inclui garantir que as
especificações sejam dimensionadas corretamente e que reflitam adequadamente
como a equipe sequencia e entrega o trabalho.
O Agile não é incapaz de acomodar o trabalho não planejado e outras
interrupções. É importante concluir os sprints dentro do prazo. Mas só porque
surge um problema que atrapalha o desenvolvimento não significa que um sprint
tenha que falhar. As equipes podem planejar interrupções designando recursos
com antecedência para problemas inesperados. Elas podem então resolver essas
questões, mas permanecer no caminho certo com o desenvolvimento.
O Agile não é inadequado para grandes organizações. Uma queixa comum é que a
colaboração, um componente-chave das metodologias Agile, é difícil em grandes
equipes. Outro problema é que as abordagens escaláveis para o Agile introduzem
estrutura e métodos que comprometem a flexibilidade. Apesar desses equívocos, é
possível escalar os princípios Agile com sucesso. Para obter informações sobre
como superar essas dificuldades, consulte Como escalar o Agile para grandes
equipes.
O Agile não é ineficiente. Para se adaptar às necessidades em constante mudança
dos clientes, os desenvolvedores investem tempo a cada iteração para demonstrar
um produto funcional e coletar feedback. É verdade que esses esforços reduzem o
tempo que eles gastam no desenvolvimento. Mas incorporar as solicitações dos
clientes logo no início economiza um tempo significativo depois. Quando os
recursos permanecem alinhados com a visão do cliente, os desenvolvedores
evitam grandes revisões no futuro.
O Agile não é uma opção ruim para os aplicativos atuais, que geralmente se
concentram no streaming de dados. Esses projetos normalmente envolvem mais
cargas de trabalho de modelagem de dados e ETL (extract-transform-load) do que
interfaces de usuário. Isso dificulta a demonstração de software utilizável em um
 cronograma consistente e apertado. Mas, ao ajustar as metas, os desenvolvedores
ainda podem usar uma abordagem Agile. Em vez de trabalhar para realizar tarefas
a cada iteração, os desenvolvedores podem se concentrar na execução de
experimentos de dados. Em vez de apresentar um produto funcional a cada
intervalo de semanas, eles podem ter como objetivo entender melhor os dados.

Por que o Agile?

E então, por que alguém consideraria uma abordagem Agile? É claro que as regras da
criação de software mudaram fundamentalmente nos últimos 10 a 15 anos. Muitas das
atividades são parecidas, mas o cenário e os ambientes onde as aplicamos são
visivelmente diferentes.

Compare como é comprar software hoje com o início dos anos 2000. Com que
frequência as pessoas dirigem até a loja para comprar software comercial?
Considere como o feedback é coletado dos clientes sobre os produtos. Como uma
equipe entendia o que as pessoas pensavam sobre seu software antes das mídias
sociais?
Considere a frequência com que uma equipe deseja atualizar e melhorar o
software que ela fornece. As atualizações anuais não são mais viáveis contra a
concorrência moderna.

Diego Lo Guidice, da Forrester, diz isso melhor em seu blog, Transforming Application
Delivery (outubro de 2020).

"Tudo mudou drasticamente. Sustentabilidade, além de verde e limpa, significa que

aquilo que criamos hoje tem que ser fácil e rapidamente mudado amanhã. Os
planos estratégicos são de curto prazo, e o planejamento e a mudança são
contínuos." — Diego Lo Guidice, Forrester

As regras mudaram, e as organizações em todo o mundo agora adaptam sua

abordagem ao desenvolvimento de software de acordo. Os métodos e práticas Agile
não prometem resolver todos os problemas. Mas eles prometem estabelecer uma
cultura e um ambiente onde as soluções surgem por meio da colaboração,
planejamento e aprendizado contínuos e o desejo de lançar software de alta qualidade
com mais frequência.

Próximas etapas
A decisão de seguir o caminho Agile para o desenvolvimento de software pode
apresentar algumas oportunidades interessantes para aprimorar seu processo de
DevOps. Algumas das considerações principais concentram-se em como o
desenvolvimento Agile se compara e se diferencia da atual abordagem de uma
organização.
O que é o desenvolvimento Agile?
Artigo • 05/10/2023

O desenvolvimento Agile é um termo usado para descrever o desenvolvimento iterativo

de software. O desenvolvimento iterativo de software encurta o ciclo de vida do DevOps
ao concluir o trabalho em pequenos incrementos, geralmente chamados de sprints. Os
sprints normalmente duram de uma a quatro semanas. O desenvolvimento Agile
costuma se diferenciar do desenvolvimento tradicional ou em cascata, que planeja
projetos maiores antecipadamente e os conclui de acordo com o plano.

O fornecimento de código de qualidade de produção a cada sprint exige que a equipe

de desenvolvimento Agile seja responsável por um ritmo acelerado. Todas as
verificações de codificação, teste e qualidade precisam ser feitas a cada sprint. A menos
que uma equipe esteja devidamente configurada, os resultados podem ficar aquém das
expectativas. Embora essas decepções ofereçam ótimas oportunidades de aprendizado,
é interessante aprender algumas lições importantes antes de começar.

Este artigo apresenta alguns fatores-chave de sucesso para equipes de desenvolvimento

Agile:

Refinamento diligente da lista de pendências

Integração antecipada e frequente
Minimização da dívida técnica

Refinamento diligente da lista de pendências

ma equipe de desenvolvimento Agile livra-se de uma lista de pendências de requisitos,
que costumam ser chamada de histórias de usuários. A lista de pendências é priorizada
com as histórias de usuários mais importantes no início. O proprietário do produto tem
a lista de pendências e adiciona, altera e estabelece novas prioridades para as histórias
de usuários de acordo com as necessidades do cliente.
Um dos maiores problemas para a produtividade de uma equipe Agile é uma lista de
pendências definida de maneira inadequada. Não se pode esperar que uma equipe
forneça um software de alta qualidade consistentemente a cada sprint, a menos que ela
tenha requisitos claramente definidos.

O trabalho do proprietário do produto é garantir que, a cada sprint, os engenheiros

tenham histórias de usuário claramente definidas para trabalhar. As histórias de usuários
no topo da lista de pendências devem estar sempre prontas para a equipe começar.
Essa noção é chamada de refinamento de lista de pendências. Manter uma lista de
pendências pronta para uma equipe de desenvolvimento Agile requer esforço e
disciplina. Felizmente, o investimento vale a pena.

Ao refinar uma lista de pendências, lembre-se das principais considerações a seguir.

1. Refinar histórias de usuários geralmente é uma atividade de longo prazo.

Interfaces de usuário elegantes, designs de tela belíssimos e soluções que
encantam o cliente levam tempo e energia para criar. Os proprietários de produtos
diligentes refinam as histórias dos usuários com dois a três sprints com
antecedência. Eles respondem por iterações de design e avaliações de clientes. Eles
trabalham para garantir que cada história de usuário seja algo que a equipe Agile
tenha orgulho de entregar ao cliente.

2. Uma história de usuário não está refinada a menos que a equipe diga que está.
A equipe precisa revisar a história do usuário e concordar que ela está pronta para
ser usada. Se uma equipe não vir a história do usuário até o primeiro dia de um
sprint, é provável que ocorram problemas.

3. As histórias de usuários mais abaixo na lista de pendências podem permanecer

ambíguas. Não perca tempo refinando itens de prioridade mais baixa. Concentre-
se no topo da lista de pendências.
Integrar antecipadamente e com frequência
A integração contínua e a entrega contínua (CI/CD) preparam sua equipe para o ritmo
acelerado do desenvolvimento Agile. Assim que possível, automatize os pipelines de
compilação, teste e implantação. Configure essa automação como uma das primeiras
tarefas que sua equipe atacará quando você iniciar um novo projeto.

Com a automação, a equipe evita processos de implantação manual, que são propensos
a erros e demorados. Como as equipes fazem lançamento a cada sprint, não há tempo
para fazer essas tarefas manualmente.

O CI/CD também influencia sua arquitetura de software. Ele garante que você forneça
software construível e implantável. Quando as equipes implementam um recurso difícil
de implantar, elas ficam cientes imediatamente se a compilação e as implantações
falharem. O CI/CD força uma equipe a corrigir problemas de implantação à medida que
eles ocorrem. Dessa forma, o produto está sempre pronto para ser enviado.

Existem algumas atividades-chave de CI/CD que são extremamente importantes para

um desenvolvimento Agile eficaz.

1. Teste de unidade. Os testes de unidade são a primeira defesa contra o erro

humano. Considere os testes de unidade como parte da codificação. Verifique os
testes com o código. Faça do teste de unidade uma parte de cada compilação.
Testes de unidade com falha significam uma compilação com falha.

2. Automação de compilação. O sistema de compilação deve extrair

automaticamente o código e os testes diretamente do controle do código-fonte
quando as compilações são executadas.
 3. Políticas de branch e compilação. Configure políticas de ramificação e compilação
para criar automaticamente à medida que a equipe faz check-in do código em um
branch específico.

4. Fazer implantação em um ambiente. Configure um pipeline de lançamento que

implante automaticamente projetos criados em um ambiente que imita a
produção.

Minimizar a dívida técnica

Com as finanças pessoais, é mais fácil evitar dívidas do que pagá-las. A mesma regra se
aplica com a dívida técnica. A dívida técnica inclui qualquer coisa que a equipe precisa
resolver por causa de atalhos que foram tomados anteriormente. Por exemplo, se o seu
cronograma está apertado, você pode sacrificar a qualidade para cumprir um prazo. A
dívida técnica é o preço que você paga depois, quando você tem que refatorar o código
para compensar essa falta de qualidade. Os exemplos incluem correções para resolver
problemas de design, bugs, problemas de desempenho, problemas operacionais,
problemas de acessibilidade e outros.

Manter-se em dia com a dívida técnica exige coragem. Há muitas pressões para atrasar
o retrabalho do código. É satisfatório trabalhar em recursos e ignorar dívidas.
Infelizmente, alguém precisa pagar a dívida técnica mais cedo ou mais tarde. Assim
como a dívida financeira, a dívida técnica se torna mais difícil de pagar quanto mais o
tempo passa. Um proprietário de produto inteligente trabalha com sua equipe para
garantir que haja tempo para pagar a dívida técnica a cada sprint. Equilibrar a redução
da dívida técnica com o desenvolvimento de recursos é uma tarefa difícil. Felizmente,
existem algumas técnicas simples para criar equipes produtivas e focadas no cliente.

Seja sempre Agile

Ser Agile significa aprender com as experiências e melhorar continuamente. O
desenvolvimento Agile fornece mais ciclos de aprendizado do que o planejamento de
projeto tradicional devido aos ciclos de processo mais apertados. Cada sprint fornece
algo novo para a equipe aprender.

Por exemplo:

Uma equipe fornece valor ao cliente, recebe comentários e modifica a lista de

pendências com base neles.
Ela descobre que testes importantes estão faltando em suas compilações
automatizadas. Ela inclui trabalho em seu próximo sprint para resolver essa
 questão.
Ela descobre que certos recursos têm um desempenho ruim na produção, então
fazem planos para melhorar o desempenho.
Alguém da equipe ouve falar de uma nova prática. A equipe decide experimentá-la
por alguns sprints.

As equipes que estão apenas começando com o desenvolvimento Agile devem esperar
mais oportunidades de aprendizado. Elas são uma parte inestimável do processo,
porque levam ao crescimento e à melhoria.

Próximas etapas
Há muitas maneiras de estabelecer um processo de desenvolvimento Agile adequado
para uma equipe. O Azure DevOps fornece vários modelos de processo. As equipes que
estão procurando estruturas de linha de base diferentes para seu planejamento podem
usar esses modelos como pontos de partida. Para obter informações sobre como
selecionar um modelo de processo que melhor se adapte à cultura e às metas de uma
equipe, consulte Escolher um fluxo de processo ou modelo de processo para trabalhar
no Azure Boards.

À medida que as organizações crescem, manter a disciplina pode ser um desafio. Saiba
mais sobre como escalar o Agile para grandes equipes.
O que é Scrum?
Artigo • 05/10/2023

Scrum é uma estrutura usada por equipes para gerenciar o trabalho e resolver
problemas de forma colaborativa em ciclos curtos. O Scrum implementa os princípios
do Agile como um conjunto concreto de artefatos, práticas e funções.

O ciclo de vida do Scrum

O diagrama abaixo detalha o ciclo de vida iterativo do Scrum. Todo o ciclo de vida é
concluído em intervalos de tempo fixos chamados sprints. Um sprint geralmente dura
de uma a quatro semanas.

Funções do Scrum
Existem três funções principais no Scrum: o proprietário do produto, o Scrum master e a
equipe do Scrum.

Proprietário de produto
O proprietário do produto é responsável pelo que a equipe cria e por que ela o cria. O
proprietário do produto é responsável por manter a lista de pendências de trabalho
atualizado e em ordem de prioridade.

Scrum master
O Scrum master garante que o processo Scrum seja seguido pela equipe. Os Scrum
Masters estão sempre buscando como a equipe pode melhorar, ao mesmo tempo em
que resolvem impedimentos e outros problemas de bloqueio que surgem durante o
sprint. Os Scrum Masters são, ao mesmo tempo, coaches, membros da equipe e
animadores de torcida.

Equipe do scrum
Os membros da equipe do scrum constroem o produto de fato. A equipe é dona da
engenharia do produto e da qualidade que o acompanha.

Lista de Pendências do Produto

A lista de pendências do produto é uma lista priorizada de trabalho que a equipe pode
entregar. O proprietário do produto é responsável por adicionar, alterar e repriorizar a
lista de pendências, conforme necessário. Os itens no topo da lista de pendências
devem estar sempre prontos para a equipe executar.

Planejar o sprint
No planejamento do sprint, a equipe escolhe os itens da lista de pendências do produto
nos quais trabalhará no próximo sprint. A equipe escolhe os itens da lista de pendências
do produto com base na prioridade e no que ela acredita que pode concluir no sprint. A
lista de pendências do sprint é a lista de itens que a equipe planeja entregar no sprint.
Muitas vezes, cada item na lista de pendências do sprint é dividido em tarefas. Uma vez
que todos os membros concordam que a lista de pendências do sprint é alcançável, o
sprint começa.

Executar o sprint
Uma vez que o sprint começa, a equipe executa a lista de pendências do sprint. O scrum
não especifica como a equipe deve executar. A equipe decide como gerenciar seu
próprio trabalho.

O scrum define uma prática chamada scrum diário, muitas vezes chamado de reunião
diária. O scrum diário é uma reunião diária limitada a quinze minutos. Os membros da
equipe geralmente ficam de pé durante a reunião para garantir que ela seja breve. Cada
membro da equipe relata brevemente seu progresso desde ontem, os planos para hoje
e qualquer coisa que impeça seu progresso.

Para ajudar o scrum diário, as equipes costumam revisar dois artefatos:

Quadro de tarefas
O quadro de tarefas lista cada item da lista de pendências em que a equipe está
trabalhando, dividido nas tarefas necessárias para concluí-lo. As tarefas são colocadas
em colunas Iniciar, Em andamento e Concluído com base em seu status. O quadro
fornece uma maneira visual de acompanhar o progresso de cada item da lista de
pendências.

Saiba mais sobre os quadros de tarefas Kanban.

Gráfico de Burndown do sprint

O burndown de sprint é um gráfico que plota o total diário de trabalho restante,
normalmente mostrado em horas. O gráfico de burndown fornece uma maneira visual
de mostrar se a equipe está no caminho certo para concluir todo o trabalho até o final
do sprint.

Revisão de sprint e retrospectiva de sprint

Ao final do sprint, a equipe realiza dois ações:

Revisão de sprint
A equipe demonstra o que realizou para as partes interessadas. Eles demonstram o
software e mostram seu valor.

Retrospectiva do sprint
A equipe reserva um tempo para refletir sobre o que deu certo e quais áreas precisam
melhorar. O resultado da retrospectiva são ações para o próximo sprint.

Incremento
O produto de um sprint é chamado de incremento ou incremento possivelmente
lançável. Independentemente do prazo, o resultado de um sprint deve ser de qualidade
lançável, mesmo que seja parte de algo maior e não possa ser entregue por si só. Ele
deve atender a todos os critérios de qualidade estabelecidos pela equipe e pelo
proprietário do produto.

Repetir, aprender, melhorar

Todo o ciclo se repete para o próximo sprint. O planejamento do sprint seleciona os
próximos itens na lista de pendências do produto e o ciclo se repete. Enquanto a equipe
executa o sprint, o proprietário do produto garante que os itens na parte superior da
lista de pendências estejam prontos para serem executados no sprint seguinte.

Esse ciclo mais curto e iterativo oferece à equipe muitas oportunidades de aprender e
melhorar. Um projeto tradicional geralmente tem um longo ciclo de vida, digamos 6 a
12 meses. Embora uma equipe possa aprender com um projeto tradicional, as
oportunidades são muito menores do que uma equipe que executa sprints de duas
semanas, por exemplo.

Esse ciclo iterativo é, em muitos aspectos, a essência do Agile.

O scrum é muito popular porque fornece estrutura suficiente para orientar as equipes,
dando-lhes flexibilidade na forma como elas trabalham. Seus conceitos são simples e
fáceis de aprender. As equipes podem começar rapidamente e aprender à medida que
avançam. Tudo isso faz do Scrum uma ótima opção para equipes que estão começando
a implementar os princípios Agile.

Próximas etapas
Encontre mais informações sobre recursos, treinamento e certificação do Scrum:

[Link]
[Link]

Aprenda a gerenciar seu processo do Scrum.

Organizações maiores e mais complexas podem achar que o Scrum não atende às suas
necessidades. Para esses casos, confira Estrutura escalada do Agile.
O que é Kanban?
Artigo • 05/10/2023

Kanban é um termo japonês que significa letreiro ou outdoor. Um engenheiro industrial

chamado Taiichi Ohno desenvolveu o Kanban na Toyota Motor Corporation para
melhorar a eficiência de fabricação.

Embora o Kanban tenha sido criado para a fabricação, o desenvolvimento de software

compartilha muitos dos mesmos objetivos, como aumentar o fluxo e a produtividade.
As equipes de desenvolvimento de software podem melhorar sua eficiência e entregar
valor aos usuários mais rapidamente usando princípios e métodos de orientação do
Kanban.

Princípios Kanban
A adoção do Kanban requer a adesão a algumas práticas fundamentais que podem
variar dos métodos anteriores das equipes.

Visualizar trabalho
Entender o status da equipe de desenvolvimento e o progresso do trabalho pode ser
um desafio. O progresso do trabalho e o estado atual são mais fáceis de entender
quando apresentados visualmente em vez de como uma lista de itens de trabalho ou
um documento.

A visualização do trabalho é um princípio fundamental que o Kanban aborda

principalmente por meio de quadros Kanban. Esses quadros usam cartões organizados
por progresso para comunicar o status geral. Visualizar o trabalho como cartões em
diferentes estados em um quadro ajuda a ver facilmente o panorama geral de onde um
projeto está atualmente, bem como identificar possíveis gargalos que podem afetar a
produtividade.

Usar um modelo de pull

Historicamente, as partes interessadas solicitavam funcionalidade empurrando o
trabalho para as equipes de desenvolvimento, muitas vezes com prazos apertados. A
qualidade sofria se as equipes precisassem usar atalhos para entregar a funcionalidade
dentro do prazo.

O Kanban concentra-se em manter um nível acordado de qualidade que deve ser

atendido antes de considerar o trabalho como realizado. Para apoiar esse modelo, as
partes interessadas não empurram o trabalho para equipes que já estão trabalhando na
capacidade. Em vez disso, as partes interessadas adicionam solicitações a uma lista de
pendências que uma equipe puxa para seu fluxo de trabalho à medida que a
capacidade se torna disponível.

Impor um limite de WIP

As equipes que tentam trabalhar em muitas coisas ao mesmo tempo podem sofrer com
a redução da produtividade devido à troca frequente e dispendiosa de contexto. A
equipe está ocupada, mas o trabalho não é feito, resultando em prazos de entrega
inaceitavelmente altos. Limitar o número de itens da lista de pendências nos quais uma
equipe pode trabalhar por vez ajuda a aumentar o foco e, ao mesmo tempo, reduz a
mudança de contexto. Os itens em que a equipe está trabalhando atualmente são
chamados de trabalho em andamento (WIP).
As equipes decidem um limite de WIP ou o número máximo de itens em que podem
trabalhar ao mesmo tempo. Uma equipe bem disciplinada garante que o seu limite de
WIP seja excedido. Se as equipes excederem seus limites de WIP, elas investigarão o
motivo e trabalharão para abordar a causa raiz.

Medir o aprimoramento contínuo

Para praticar a melhoria contínua, as equipes de desenvolvimento precisam de uma
maneira de medir a eficácia e o rendimento. Os quadros Kanban fornecem uma visão
dinâmica dos estados de trabalho em um fluxo de trabalho, para que as equipes
possam experimentar processos e avaliar mais facilmente o impacto nos fluxos de
trabalho. As equipes que adotam o Kanban para melhoria contínua usam medidas como
prazo e tempo de ciclo.

Quadros kanban
O quadro Kanban é uma das ferramentas que as equipes utilizam para implementar as
práticas Kanban. Um quadro Kanban pode ser um quadro físico ou um aplicativo de
software que mostra cartões organizados em colunas. Os nomes típicos das colunas são
Iniciar, Em andamento e Concluído, mas as equipes podem personalizar os nomes para
corresponder aos estados do fluxo de trabalho. Por exemplo, uma equipe pode preferir
usar Novo, Desenvolvimento, Teste, UAT e Concluído.

Os quadros Kanban baseados em desenvolvimento de software exibem cartões que

correspondem a itens da lista de pendências do produto. Os cartões incluem links para
outros itens, como tarefas e casos de teste. As equipes podem personalizar os cartões
para incluir informações relevantes para seu processo.

Em um quadro Kanban, o limite de WIP se aplica a todas as colunas em andamento. Os

limites de WIP não se aplicam à primeira e à última colunas, porque essas colunas
representam o trabalho que não foi iniciado ou foi concluído. Os quadros Kanban
ajudam as equipes a se manterem dentro dos limites de WIP, chamando a atenção para
colunas que excedem os limites. As equipes podem então determinar um curso de ação
para remover o gargalo.

Diagramas de fluxo cumulativo

Uma adição comum aos quadros Kanban baseados em desenvolvimento de software é
um gráfico chamado diagrama de fluxo cumulativo (CFD). O CFD ilustra o número de
itens em cada estado ao longo do tempo, normalmente ao longo de várias semanas. O
eixo horizontal mostra a linha do tempo, enquanto o eixo vertical mostra o número de
itens da lista de pendências do produto. As áreas coloridas indicam os estados ou
colunas em que os cartões estão atualmente.

O CFD é particularmente útil para identificar tendências ao longo do tempo, incluindo

gargalos e outras interrupções na velocidade de progresso. Um bom CFD mostra uma
tendência ascendente consistente enquanto uma equipe está trabalhando em um
projeto. As áreas coloridas no gráfico devem ser aproximadamente paralelas se a equipe
estiver trabalhando dentro de seus limites de WIP.

Uma protuberância em uma ou mais das áreas coloridas geralmente indica um gargalo
ou impedimento no fluxo da equipe. No CFD seguinte, o trabalho concluído em verde
está fixo, enquanto o estado de teste em azul está crescendo, provavelmente devido a
um gargalo.
Kanban e Scrum no desenvolvimento Agile
Embora se encaixem amplamente sob o guarda-chuva do desenvolvimento Agile, Scrum
e Kanban são bem diferentes.

O Scrum se concentra em sprints de comprimento fixo, enquanto o Kanban é um

modelo de fluxo contínuo.
O Scrum tem funções definidos, enquanto o Kanban não define nenhuma função
de equipe.
O Scrum usa a velocidade como métrica chave, enquanto o Kanban usa o tempo
de ciclo.

As equipes geralmente adotam aspectos do Scrum e do Kanban para ajudá-los a

trabalhar de forma mais eficaz. Independentemente das características que escolherem,
as equipas podem sempre rever e adaptar-se até encontrarem o melhor ajuste. As
equipes devem começar simples e não perder de vista a importância de entregar valor
regularmente aos usuários.

Kanban com o GitHub

O GitHub oferece uma experiência Kanban por meio de quadros de projeto (clássico).
Esses quadros ajudam você a organizar e priorizar o trabalho para o desenvolvimento
de recursos específicos, roteiros abrangentes ou listas de verificação de lançamento.
Você pode automatizar quadros de projeto (clássico) para sincronizar o status do
cartão com problemas associados e solicitações pull.
Kanban com o Azure Boards
O Azure Boards fornece uma solução Kanban abrangente para planejamento de
DevOps. O Azure Boards tem uma integração profunda entre o Azure DevOps e
também pode fazer parte da integração do Azure Boards-GitHub.

Para obter mais informações, consulte Motivos para usar o Azure Boards para
planejar e controlar seu trabalho.
O módulo de aprendizagem Escolher uma abordagem Agile para o
desenvolvimento de software fornece experiência prática de Kanban no Azure
Boards.
Adotar uma cultura Agile
Artigo • 05/10/2023

Se há uma lição a ser aprendida com a última década de "transformações ágeis" é que
não há uma solução única para adotar ou implementar uma abordagem Agile. Cada
organização tem diferentes necessidades, restrições e requisitos. Seguir uma prescrição
cegamente não resultará em sucesso.

O movimento Agile tem como foco descobrir continuamente maneiras de aprimorar a

prática da criação de software. Não se trata de uma reunião diária rápida e perfeita ou
retrospectiva. Em vez disso, trata-se de criar uma cultura em que a coisa certa acontece
com mais frequência do que o contrário. Atividades como reuniões e retrospectivas têm
seu valor, mas não mudarão a cultura de uma organização.

Este artigo detalha elementos fundamentais de que toda organização precisa para criar
uma mentalidade e cultura Agile. As recomendações não devem ser seguidas
cegamente. Cada organização deve aplicar o que faz sentido em um determinado
ambiente.

Agenda e ritmo
Não há um comprimento perfeito de sprint. As equipes têm obtido sucesso com
durações de sprint que variam de uma a quatro semanas. O que mais importa é a
consistência.

Selecione uma duração de sprint que funcione para a cultura, o produto e o desejo de
fornecer atualizações da sua organização. Por exemplo, a divisão de Ferramentas para
Desenvolvedores da Microsoft (cerca de 6.000 pessoas) trabalha em sprints de três
semanas. A equipe de liderança não escolheu essa duração de sprint; ela veio com o
feedback diretamente das equipes de engenharia. Toda a divisão opera neste
cronograma de sprint de três semanas. Desde então, os sprints tornaram-se o coração
da organização. Agora, todas as equipes marcham ao ritmo do mesmo tambor.

É importante escolher uma duração de sprint e segui-la. Se houver várias equipes Agile,
todas elas devem usar a mesma duração de sprint. Se o feedback impulsiona uma
mudança, seja receptivo. Quando a duração certa for aplicada, ficará claro.

Uma cultura de envio

Peter Provost , Gerente Principal de Programas de Grupo da Microsoft, disse: "Não há
como trapacear no envio". A simplicidade e a verdade dessa afirmação são um
elemento fundamental da cultura Agile. O que o Peter quer dizer é que o envio do seu
software ensinará coisas que você não pode e não vai entender a menos que você
esteja realmente enviando o seu software.

A natureza humana é atrasar ou evitar fazer as coisas até que seja absolutamente
necessário. Isso acontece especialmente quando se trata de desenvolvimento de
software. As equipes detectam bugs até o final do ciclo, não pensam em configuração
ou atualização até que sejam forçadas a fazê-lo e, normalmente, evitam coisas como
localização e acessibilidade sempre que possível. Quando surge esse padrão, as equipes
acumulam dívidas técnicas que precisarão ser pagas posteriormente. O envio exige que
toda a dívida seja paga. Não há como trapacear no envio. Para estabelecer uma cultura
Agile, comece tentando enviar o produto no final de cada sprint. Não será fácil no início,
mas quando uma equipe tenta fazer isso, ela rapidamente descobre todas as coisas que
deveriam estar acontecendo, mas não estão.

Equipes saudáveis
Não existe uma receita para a equipe Agile perfeita. No entanto, algumas características
importantes tornam o sucesso muito mais fácil de alcançar.

Colocalizar equipes sempre que possível

Uma equipe pode obter sucesso com pessoas espalhadas em diferentes regiões? Sim,
mas é mais difícil. Quando as pessoas estão localizadas e sentadas na mesma sala, as
conversas certas tendem a acontecer. Ainda é possível ter sucesso com equipes
localizadas ao redor do mundo e em diferentes fusos horários. Mas não seria uma
vantagem para essa equipe se ela não tivesse todos esse obstáculos?
Manter as equipes intactas por um intervalo de tempo
razoável
Permita que as equipes dominem a arte de criar software juntas. Quando as equipes são
espalhadas, qualquer química que elas tiverem desenvolvido é interrompida. Às vezes, é
necessário se reorganizar, mas as equipes normalmente são mais produtivas quando
têm tempo para aprender a trabalhar juntas. Como regra, tente manter as equipes
intactas por pelo menos 12 meses.

Equilibre a carga de trabalho, não as pessoas

Às vezes, as equipes se atrasam e precisam de ajuda. Uma tática comum para resolver
isso é emprestar uma pessoa de uma equipe para outra. No entanto, isso pode ser
contraproducente. Uma solução melhor é balancear a carga de trabalho para outra
equipe, em vez de balancear a carga de pessoas entre elas. Emprestar uma pessoa de
uma equipe para ajudar outra atrapalha ambas as equipes e pode frustrar a pessoa que
está sendo transferida, mesmo que temporariamente. Tudo isso afeta a produtividade
da equipe e, muito provavelmente, impacta negativamente a capacidade de voltar ao
cronograma.

Ao balancear a a carga de trabalho e não as pessoas, é possível que uma equipe já

estabelecida intervenha e ajude. Torna-se uma conversa sobre prioridades, não uma
conversa sobre pessoas.

Permitir que as equipes possuam áreas de

recursos, não camadas de arquitetura
Esforce-se para criar equipes verticais que possuam áreas de recursos. Essas equipes são
responsáveis por todo o trabalho necessário para adicionar recursos à sua área, desde o
banco de dados até as alterações na interface do usuário. A equipe está capacitada para
oferecer e possuir uma experiência completa.

Quando equipes horizontais possuem camadas de arquitetura, nenhuma equipe é

responsável pela experiência completa. A adição de um recurso requer a coordenação
de várias equipes e exige um nível mais alto de gerenciamento de dependências. A
resolução de bugs requer que várias equipes investiguem se possuem o código
necessário para corrigir o bug. Os bugs são combatidos à medida que as equipes
determinam que o bug não é delas e o atribuem a outra equipe.

As equipes de recursos não têm esses problemas. A propriedade e a responsabilidade

são claras. Pode haver espaço para algumas equipes baseadas em arquitetura. Porém,
equipes focadas verticalmente são mais eficazes.

Próximas etapas
À medida que as equipes embarcam em sua própria transformação Agile, tenha esses
princípios fundamentais em mente. Lembre-se, não há uma receita pronta que funcione
para todas as organizações. As transformações Agile são uma jornada. Faça mudanças e
aprenda com elas. Com o tempo, a organização desenvolverá a cultura Agile de que
precisa.

A Microsoft é uma das maiores empresas Agile do mundo. Saiba mais sobre como a
Microsoft adotou uma cultura Agile para o planejamento de DevOps.

Saiba mais sobre como o Azure DevOps permite que as equipes adotem e dimensionem
uma cultura Agile.
Construindo equipes produtivas
Artigo • 05/10/2023

Os engenheiros prosperam em ambientes onde podem se concentrar e entrar no fluxo

de produtividade. As equipes geralmente enfrentam distrações e prioridades
concorrentes que forçam os engenheiros a mudar o contexto e dividir sua atenção. Eles
lutam para equilibrar o tempo de foco com o tempo de alerta. A adição de novos
recursos exige que os membros da equipe estejam focados. Responder aos problemas
dos clientes e resolver problemas do local em tempo real requer que a equipe esteja
alerta e ciente do que está acontecendo.

Para mitigar as distrações, uma equipe pode se dividir em duas equipes: uma para
recursos e outra para a integridade do local ao vivo.

A abordagem de duas equipes traz maior produtividade e previsibilidade. A

implementação bem-sucedida depende destes elementos-chave:

Funções da equipe claramente definidas

Um processo de rotação de equipe bem definido
Ajustes frequentes no tamanho da equipe

Equipe de recursos
A equipe de recursos, ou equipe F, concentra-se no futuro. Ela funciona como uma
unidade eficaz que tem uma missão e objetivo claros: criar e lançar recursos de alta
qualidade.
A equipe F é protegida do caos diário do serviço ao vivo para garantir que eles tenham
tempo para projetar, criar e testar seu trabalho. Ela pode contar com o mínimo de
distrações e não precisa corrigir problemas que surgem aleatoriamente. Ela é
incentivada a verificar seus emails raramente e evitar ser arrastada para outros
problemas, a menos que sejam críticos.

Quando um membro da equipe F se junta a uma conversa ou ocasionalmente é sugado

para uma conversa de email, outros membros da equipe devem repreendê-lo: "Você
está na equipe F, o que você está fazendo?" Se um membro da equipe F precisar resolver
um problema crítico, ele é incentivado a delegá-lo à equipe do cliente e retornar ao
trabalho de recurso.

A equipe F opera como uma equipe unida que se concentra em um pequeno conjunto
de recursos. Um bom limite de trabalho em andamento (WIP) é dois recursos em
andamento para 4-6 pessoas. Trabalhando em estreita colaboração, elas criam um
contexto compartilhado profundo e encontram bugs críticos ou problemas de design
que uma revisão superficial de código perderia. Uma equipe dedicada permite uma taxa
de transferência e um prazo de entrega mais previsíveis. Os membros da equipe
costumam se referir à equipe F como serena e focada. Eles acham pacífico e
rejuvenescedor se concentrar profundamente em um recurso e dedicar total atenção a
ele. As pessoas encerram o expediente na equipe F se sentindo renovadas e realizadas.

Equipe do cliente
A equipe do cliente, ou equipe C, concentra-se no agora e fornece suporte de linha de
frente para problemas do cliente e do local ao vivo, bugs, telemetria e monitoramento.
A equipe C muitas vezes se amontoa em torno de um computador, depurando um
problema crítico do local ao vivo. Sua prioridade número um é a integridade do local ao
vivo. Totalmente focados nesse ambiente, eles desenvolvem habilidades especializadas
de depuração e análise. A equipe do cliente é muitas vezes chamada de equipe de
escudo, porque ela protege o resto da equipe de distrações. Em vez de trabalhar em
recursos futuros, a equipe C é a ponte entre os clientes e o produto atual. Os membros
da equipe são ativos no email, Twitter e outros canais de feedback. Os clientes querem
saber que são ouvidos, e o trabalho da equipe C é ouvi-los. A equipe C organiza os
problemas relatados pelo cliente imediatamente e rapidamente engaja e auxilia os
clientes bloqueados.

Com uma enxurrada de tarefas recebidas, trabalhar em uma equipe C de ritmo

acelerado pode, às vezes, ser emocionante. Em uma semana movimentada, eles
abordam vários emails, investigações ao vivo e bugs. À medida que as operações se
acalmam, eles trabalham para melhorar a telemetria e os relatórios, investindo seu
tempo para facilitar a manutenção do serviço.

As equipes C permitem que a equipe resolva problemas sem tirar os membros da

equipe de outras prioridades e garantir que os clientes e parceiros sejam ouvidos. A
capacidade de resposta a perguntas e questões torna-se um ponto de orgulho para as
equipes C. No entanto, esse ritmo pode ser desgastante, exigindo um rodízio frequente
entre as equipes.

Rotação da equipe
Um processo de rotação bem definido faz o sistema de duas equipes funcionar. Você
poderia simplesmente trocar as equipes (a equipe F torna-se a equipe C e vice-versa),
mas isso limita o compartilhamento de conhecimento entre e dentro das equipes. Em
vez disso, opte por um rodízio semanal.

No final de cada semana, realize uma pequena reunião de troca onde a equipe decide
quem troca de equipe. Você pode usar um gráfico de quadro de comunicações para
acompanhar quem está atualmente em cada equipe e quando a pessoa foi trocada. As
pessoas com mais tempo de permanência em cada equipe normalmente devem trocar
umas com as outras. No entanto, em uma determinada semana, alguém pode querer
permanecer para concluir o trabalho em uma investigação ou recurso ao vivo. Embora
haja flexibilidade, quanto mais tempo alguém estiver em uma equipe, maior a
probabilidade de ser trocado.

Rotações semanais ajudam a evitar silos de conhecimento na equipe e garantem um

fluxo constante de informações e perspectivas entre as equipes. O movimento frequente
dos engenheiros cria conhecimento compartilhado do trabalho da equipe, o que ajuda
a equipe C a resolver problemas sem a ajuda de outras pessoas. Muitas vezes, os novos
membros da equipe F encontrarão rapidamente uma falha de design ou código que foi
negligenciada anteriormente.

Tamanho da equipe
O tamanho da equipe varia para manter a saúde da equipe. Se uma equipe tem uma
alta taxa de entrada de problemas no local ao vivo ou tem muita dívida técnica, a
equipe C fica maior e vice-versa. Ajustar tamanhos semanalmente aumenta a
previsibilidade nas entregas e dependências da equipe. Em algumas semanas, uma
equipe pode mover todos para a equipe C para abordar o feedback de um grande
lançamento.
Essa estratégia simplifica a comunicação com a gerência. Sem um sistema de duas
equipes, os engenheiros geralmente trabalham em várias coisas simultaneamente.
Quando várias distrações ocorrem em uma única semana, os recursos em andamento
geralmente são atrasados. Como resultado, uma equipe pode não conseguir dar
cronogramas com confiança para o trabalho futuro de recursos.

Uma equipe F dedicada leva a um rendimento e tempo de execução previsíveis. A

divisão de recursos entre as equipes aumenta a responsabilidade dentro da equipe e
com a gerência sobre o que a equipe pode realizar a cada semana e a cada sprint.

Próximas etapas
O sistema de duas equipes pode ajudar as equipes a entender onde os engenheiros
devem gastar seu tempo e a progredir em muitas prioridades concorrentes.

Além de melhorar a produtividade e a previsibilidade, o sistema de duas equipes pode

aumentar o moral da equipe. Os engenheiros de cada equipe entendem claramente
seus papéis e responsabilidades e funcionam de forma mais independente e com muito
mais responsabilidade. Essa abordagem é ideal para equipes de DevOps, aquelas
responsáveis tanto pelo desenvolvimento quanto pelas operações. No entanto, essa
abordagem pode ser aplicada a praticamente qualquer equipe Agile que lida com
prioridades concorrentes.

A Microsoft é uma das maiores empresas Agile do mundo. Saiba como a Microsoft
organiza equipes no planejamento de DevOps.
Colocar o Agile em escala para grandes
equipes
Artigo • 05/10/2023

As palavras grande e Agile não costumam ser usadas na mesma frase. Grandes
organizações ganharam a reputação de serem lentas. Porém, isso está mudando. Muitas
grandes organizações de software estão fazendo a transformação para o Agile com
sucesso. Elas estão aprendendo a escalar princípios Agile com ou sem estruturas
populares, como SAFe, LeSS , ou Nexus .

Na Microsoft, uma dessas organizações usa o Agile para criar produtos e serviços
fornecidos com a marca Azure DevOps. Esse grupo tem 35 equipes de recursos que
entram em produção a cada três semanas.

Cada equipe no Azure DevOps possui recursos do início ao fim e além. Elas são donas
do relacionamento com o cliente. Elas gerenciam sua própria lista de pendências de
produtos. Elas escrevem e verificam o código no branch de produção. A cada três
semanas, o branch de produção é implantado e o lançamento torna-se público. Em
seguida, as equipes monitoram a integridade do sistema e corrigem problemas no local
ao vivo.

De acordo com os princípios Agile, as equipes autônomas são mais produtivas. Uma
organização Agile quer que suas equipes tenham controle sobre a execução diária.
Porém, a autonomia sem alinhamento resultará em caos. Dezenas de equipes
trabalhando de forma independente não produziriam um produto unificado e de alta
qualidade. O alinhamento dá às equipes seu propósito e garante que elas atinjam as
metas da organização. Sem o alinhamento, mesmo as equipes com melhor desempenho
falhariam.

Para escalar o Agile, você deve habilitar a autonomia para a equipe, garantindo o
alinhamento com a organização.

Para gerenciar o equilíbrio delicado entre alinhamento e autonomia, os líderes de

DevOps precisam definir uma taxonomia, definir um processo de planejamento e usar
chats de recursos.

Definir uma taxonomia

Uma equipe Agile, bem como a organização Agile maior a qual ela pertence, precisam
de uma lista de pendências claramente definida para serem bem-sucedidas. Será difícil
para as equipes obterem sucesso se as metas organizacionais não forem claras.

Para definir metas claras e informar como cada equipe contribui para elas, a organização
precisa definir uma taxonomia. Uma taxonomia definida claramente cria a nomenclatura
de uma organização.

Uma taxonomia comum é épicos, características, histórias e tarefas.

Épicos
Os épicos descrevem iniciativas importantes para o sucesso da organização. Para que os
épicos sejam realizados, podem ser necessárias várias equipes e vários sprints, mas tudo
isso tem fim. Os épicos têm um objetivo claramente definido. Uma vez alcançado, o
épico é encerrado. O número de épicos em andamento deve ser gerenciável para que a
organização se mantenha focada. Os épicos são divididos em recursos.

Recursos
Os recursos definem a nova funcionalidade necessária para alcançar o objetivo de um
épico. Os recursos são a unidade de lançamento; eles representam o que é liberado
para o cliente. As notas de versão publicadas podem ser criadas com base na lista de
recursos concluídos recentemente. Os recursos podem levar vários sprints para serem
concluídos, mas devem ser dimensionados para garantir um fluxo de valor consistente
para o cliente. Os recursos são divididos em histórias.

Histórias
As histórias definem o valor incremental que a equipe deve entregar para criar um
recurso. A equipe divide o recurso em partes incrementais. Uma única história concluída
pode não fornecer valor significativo ao cliente. No entanto, uma história completa
representa um software com qualidade de produção. As histórias são a unidade de
trabalho da equipe. A equipe define as histórias que são necessárias para concluir um
recurso. Como alternativa, as histórias podem se dividir em tarefas.

Tarefas
As tarefas definem o trabalho necessário para concluir uma história.

Iniciativas
Esta taxonomia não é um sistema único para todos os casos. Muitas organizações
introduzem um nível que está acima dos épicos, chamado iniciativas.

Os nomes de cada nível podem ser adaptados à sua organização. No entanto, os nomes
definidos acima (épicos, características, histórias) são utilizados amplamente no setor.

Linha de autonomia
Quando a taxonomia for definida, a organização precisará traçar uma linha de
autonomia. A linha de autonomia é o ponto em que a propriedade do nível passa da
gerência para a equipe. A gerência não interfere nos níveis que pertencem à equipe.

O exemplo a seguir mostra a linha de autonomia traçada abaixo dos recursos. A

gerência é dona dos épicos e recursos, que proporcionam alinhamento. As equipes são
donas das histórias e tarefas e têm autonomia sobre como elas são executadas.

Neste exemplo, a gerência não diz à equipe como decompor histórias, planejar sprints
ou executar trabalhos.

No entanto, a equipe deve garantir que sua execução esteja alinhada com os objetivos
da gerência. Embora uma equipe possua sua lista de pendências de histórias, ela deve
alinhar sua lista de pendências com os recursos atribuídos a ela.

Planejamento
Para escalar o planejamento Agile, uma equipe precisa de um plano para cada nível da
taxonomia. No entanto, é importante iterar e atualizar o plano. Esse processo é
chamado de planejamento em ondas sucessivas.

O plano fornece a direção por um intervalo fixo de tempo com a calibração esperada
em intervalos regulares. Por exemplo, um plano de 18 meses poderia ser calibrado a
cada seis meses.

Aqui está um exemplo de métodos de planejamento para cada nível de uma taxonomia:
épicos, recursos, histórias e tarefas.
Visão
A visão é expressa por meio de épicos e define a direção de longo prazo da
organização. Os épicos definem o que a organização quer concluir nos próximos 18
meses. A gerência é dona do plano e o calibra semestralmente.

A visão é apresentada em uma reunião prática. Como se espera que a visão seja
ambiciosa e muita coisa pode mudar ao longo desse intervalo de tempo, espere
concluir cerca de 60% da visão.

Estação do ano
Uma temporada é descrita por meio de recursos e define a estratégia para os próximos
seis meses. Os recursos determinam o que a organização deseja iluminar para seus
clientes. A gerência é dona do plano sazonal e apresenta a visão e os planos sazonais
em uma reunião prática. Todos os planos da equipe devem estar alinhados com o plano
sazonal da gerência. Espere concluir cerca de 80% do plano sazonal.

Plano de 3 sprints
O plano de 3 sprints define as histórias e recursos que a equipe terminará nos próximos
três sprints. A equipe é dona do plano e o calibra a cada sprint. Cada equipe apresenta
seu plano à gerência por meio do chat de recursos (veja abaixo). O plano especifica
como a execução da equipe se alinha com o plano sazonal de 6 meses. Espere realizar
cerca de 90% do plano de 3 sprints.

Plano de sprint
O plano de sprint define as histórias e recursos que a equipe terminará no próximo
sprint. A equipe é dona do plano de sprint e o envia por email para toda a organização
para fornecer total transparência. O plano inclui o que a equipe realizou no sprint
passado e seu foco para o próximo sprint. Espere realizar cerca de 95% do plano de
sprint.

Linha de autonomia
Neste exemplo, a linha de autonomia é traçada para mostrar onde as equipes têm
autonomia de planejamento.

Como informamos acima, a gerência não estende a propriedade para baixo da linha de
autonomia. A gerência fornece orientação usando a visão e os planos de temporada e,
em seguida, dá às equipes autonomia para criar planos de 1 e 3 sprints.

Chats de recursos: onde a autonomia encontra

o alinhamento
Um chat de recurso é uma reunião de baixa cerimônia onde cada equipe apresenta seu
plano de 3 sprints para a gerência. Essa reunião garante que os planos da equipe
estejam alinhados com as metas da organização. Isso também ajuda a gerência a se
manter informada sobre o que a equipe está fazendo. Enquanto o plano de 3 sprints é
calibrado a cada sprint, os chats de recursos são realizados conforme necessário,
geralmente a cada um a três sprints.

Uma reunião de chat de recurso aloca 15 minutos para cada equipe. Com 12 equipes de
recurso, essas reuniões podem ser agendadas para durar cerca de três horas. Cada
equipe prepara uma apresentação de 3 slides, com os seguintes slides:

Recursos
O primeiro slide descreve os recursos que a equipe destacará nos próximos três sprints.

Dívida
O próximo slide descreve como a equipe gerencia a dívida técnica. Dívida é qualquer
coisa que não atende aos padrões de qualidade da gerência. O diretor de engenharia
define os níveis de qualidade, que são os mesmos para todas as equipes (alinhamento).
Os níveis de qualidade de exemplo incluem o número de bugs por engenheiro, a
porcentagem de testes de unidade aprovados e as metas de desempenho.

Problemas e dependências
Os problemas e dependências listados no slide final incluem qualquer coisa que afete o
progresso da equipe, como problemas que a equipe não pode resolver ou
dependências de outras equipes que precisam de escalonamento.

Cada equipe apresenta seus slides diretamente à gerência. A equipe apresenta como
seu plano de 3 sprints se alinha com o plano sazonal de 6 meses. A liderança faz
perguntas esclarecedoras e sugere mudanças de direção. Ela também pode solicitar
reuniões de acompanhamento para resolver questões mais profundas.

Se o plano de uma equipe não estiver alinhado com as expectativas da gerência, ela
pode solicitar um replanejamento. Neste evento raro, a equipe replanejará e agendará
um segundo chat de recurso para revisá-lo.

Confiança: a cola que une alinhamento e

autonomia
Ao praticar o Agile em escala, a confiança é uma via de mão dupla:

A gerência deve confiar que as equipes farão o que é certo. Se a gerência não
confiar nas equipes, elas não darão autonomia às equipes.

Uma equipe conquista confiança ao entregar código de alta qualidade

consistentemente. Se as equipes não forem confiáveis, a gerência não dará
autonomia a elas.
A gerência deve fornecer planos claros para as equipes se alinharem e, então, confiar
que elas executarão o plano. As equipes devem alinhar seus planos com a organização e
executá-los de forma confiável.

À medida que as organizações procuram escalar o Agile para cenários maiores, a chave
é dar autonomia às equipes e, ao mesmo tempo, garantir que elas estejam alinhadas
com as metas da organização. Os blocos de construção críticos são a propriedade
claramente definida e uma cultura de confiança. Quando organização estabelecer essa
base, ela descobrirá que o Agile pode escalar muito bem.

Próximas etapas
Há muitas maneiras de uma equipe de qualquer tamanho começar a ver benefícios hoje
mesmo. Confira algumas dessas práticas que escalam.

Saiba mais sobre os recursos de DevOps do Azure para gerenciamento de portfólio e

visibilidade entre equipes.

A Microsoft é uma das maiores empresas Agile do mundo. Saiba mais sobre como a
Microsoft escala o planejamento de DevOps.
Como a Microsoft faz planejamentos
com o DevOps
Artigo • 05/10/2023

A Microsoft é uma das maiores empresas do mundo que utiliza metodologias Agile. Ao
longo de anos de experiência, a Microsoft desenvolveu um processo de planejamento
de DevOps que se expande desde os menores projetos até grandes operações como o
Windows. Este artigo descreve muitas das lições aprendidas e práticas que a Microsoft
implementa ao planejar projetos de software em toda a empresa.

Mudanças importantes
As seguintes alterações importantes ajudam a tornar os ciclos de desenvolvimento e
envio mais saudáveis e eficientes:

Promova o alinhamento cultural e a autonomia.

Mude o foco de indivíduos para equipes.
Crie novas estratégias de planejamento e aprendizagem.
Implemente um modelo multiequipe.
Melhore as práticas de integridade do código.
Promova a transparência e responsabilidade.

Promova o alinhamento cultural e a autonomia

Peter Drucker disse: "A cultura come estratégia no café da manhã". Autonomia, domínio
e propósito são as principais motivações humanas. A Microsoft tenta fornecer essas
motivações para PMs, desenvolvedores e designers para que eles se sintam capacitados
para criar produtos de sucesso.

Dois importantes contribuintes para essa abordagem são o alinhamento e a autonomia.

O alinhamento vem de cima para baixo, para garantir que indivíduos e equipes
entendam como suas responsabilidades se alinham com objetivos de negócios
mais amplos.
A autonomia acontece de baixo para cima, para garantir que indivíduos e equipes
tenham impacto nas atividades e decisões do dia a dia.

Há um equilíbrio delicado entre alinhamento e autonomia. Muito alinhamento pode

criar uma cultura negativa em que as pessoas desempenham apenas como o que lhes é
pedido. O excesso de autonomia pode causar falta de estrutura ou direção, tomada de
decisão ineficiente e planejamento ruim.

Mude o foco de indivíduos para equipes

A Microsoft organiza pessoas e equipes em três grupos: PM, design e engenharia.

O PM define o que a Microsoft cria e por quê.

O design é responsável por projetar o que a Microsoft cria.
A engenharia cria os produtos e garante sua qualidade.

As equipes da Microsoft têm as seguintes principais características:

Interdisciplinar
10 a 12 pessoas
Autogerenciado
Carta clara e metas para 12-18 meses
Salas de equipe físicas
Implantação de recursos próprios
Recursos próprios em produção

Buscar equipes verticais

As equipes da Microsoft costumavam ser horizontais, cobrindo toda a interface do

usuário, todos os dados ou todas as APIs. Agora, a Microsoft busca equipes verticais. As
equipes são donas de suas áreas do produto do início ao fim. Diretrizes rígidas em
determinados níveis garantem uniformidade entre as equipes em todo o produto.

O diagrama a seguir explica a diferença entre equipes horizontais e verticais:

Permita a autosseleção de equipes
A cada 18 meses, a Microsoft executa um "exercício amarelo pegajoso", onde os
desenvolvedores podem escolher em quais áreas do produto desejam trabalhar nos
próximos períodos de planejamento. Esse exercício proporciona a autonomia, pois as
equipes podem escolher em quê trabalhar, e o alinhamento organizacional, pois
promove o equilíbrio entre as equipes. Cerca de 80% das pessoas neste exercício
permanecem em suas equipes atuais, mas se sentem empoderadas porque tiveram
escolha.

Crie novas estratégias de planejamento e aprendizagem

Dwight Eisenhower disse: "Planos não valem nada, mas planejamento é tudo". O
planejamento da Microsoft é dividido na seguinte estrutura:

Sprints (3 semanas)
Planos (3 sprints)
Temporadas (6 meses)
Estratégias (12 meses)

Engenheiros e equipes são os principais responsáveis pelos sprints e planos. A liderança

é a principal responsável pelas temporadas e estratégias.

O diagrama a seguir ilustra a estratégia de planejamento da Microsoft:

Essa estrutura de planejamento também ajuda a maximizar o aprendizado durante o

planejamento. As equipes são capazes de obter feedback, descobrir o que os clientes
querem e implementar as solicitações dos clientes de forma rápida e eficiente.
Implemente um modelo multiequipe
Os métodos anteriores fomentaram uma "cultura de interrupção" de bugs e incidentes
ao vivo no local. As equipes da Microsoft criaram sua própria maneira de aumentar o
foco e evitar distrações. As equipes se auto-organizam para cada sprint em duas
equipes distintas: Recursos (equipe F) e Cliente (equipe C).

A equipe F trabalha em recursos comprometidos, e a equipe C lida com problemas e

interrupções ao vivo no local. A equipe estabelece uma cadência rotativa que permite
que os membros planejem as atividades com mais facilidade. Para obter mais
informações sobre o modelo de várias equipes, consulte Criar equipes produtivas e
focadas no cliente.

Melhore as práticas de integridade do código

Antes de mudar para metodologias Agile, as equipes costumavam permitir que os bugs
de código se acumulassem até que o código fosse concluído no final da fase de
desenvolvimento. Depois disso, as equipes descobriram bugs e trabalharam para
corrigi-los. Essa prática criou uma montanha-russa de bugs, que afetou o moral e a
produtividade da equipe quando as equipes tiveram que trabalhar em correções de
bugs em vez de implementar novos recursos.

As equipes agora implementam um limite de bugs, calculado pela fórmula # of

engineers x 5 = bug cap . Se a contagem de bugs de uma equipe exceder o limite de

bugs no final de um sprint, eles devem parar de trabalhar em novos recursos e corrigir
bugs até que estejam abaixo do limite. Agora, as equipes pagam dívidas de bugs à
medida que avançam.

Promova a transparência e responsabilidade

No final de cada sprint, cada equipe envia um email relatando o que realizaram no
sprint anterior e o que planejam fazer no próximo sprint.

Objetivos e resultados principais (OKRs)

As equipes são mais eficazes quando têm clareza sobre os objetivos que a organização
está tentando alcançar. A Microsoft fornece clareza às equipes por meio de objetivos e
resultados-chave (OKRs).

Os objetivos definem as metas a serem alcançadas. Os objetivos são significativos,

concretos, baseados em ação e, idealmente, declarações de intenção inspiradoras.
 Os objetivos representam grandes ideias, não números reais.
Os resultados-chave definem etapas para atingir os objetivos. Os resultados-chave
são resultados quantificáveis que avaliam o progresso e indicam o sucesso em
relação aos objetivos em um intervalo de tempo específico.

Os OKRs refletem os melhores resultados possíveis, não apenas os resultados mais

prováveis. Líderes tentam ser ambiciosos e não cautelosos. Forçar as equipes a buscar
resultados-chave desafiadores impulsiona a aceleração em relação aos objetivos e
prioriza o trabalho que se move em direção a metas maiores.

A adoção de uma estrutura de OKR pode ajudar as equipes a terem um desempenho

melhor pelos seguintes motivos:

Toda equipe está alinhada no plano.

As equipes se concentram em alcançar resultados em vez de concluir atividades.
Toda equipe é responsável pelos esforços regularmente.

Os OKRs podem existir em diferentes níveis de um produto. Por exemplo, pode haver
OKRs de produto de nível superior, OKRs de nível de componente e OKRs de nível de
equipe. Manter os OKRs alinhados é relativamente fácil, principalmente se os objetivos
forem definidos de cima para baixo. Quaisquer conflitos que surjam são indicadores
iniciais valiosos de desalinhamento organizacional.

Exemplo de OKR
Objetivo: cultivar uma base de clientes forte e feliz.

Resultados-chave:

Aumentar o Net Promoter Score (NPS) externo de 21 para 35.

Aumentar a satisfação dos docs de 55 para 65.
O novo fluxo de tubulação tem uma pontuação Apdex de 0,9.
O tempo de fila para trabalhos é de 5 segundos ou menos.

Para obter mais informações sobre OKRs, consulte Medir resultados de negócios usando
objetivos e resultados-chave.

Selecione as métricas certas

Os resultados-chave são tão úteis quanto as métricas em que se baseiam. A Microsoft
usa os principais indicadores que se concentram na mudança. Ao longo do tempo, essas
métricas constroem uma imagem funcional da aceleração ou desaceleração do produto.
A Microsoft geralmente usa as seguintes métricas:
 Variação na taxa de crescimento mensal da adoção
Mudança de desempenho
Mudança no tempo necessário para aprender
Mudança na frequência de incidentes

As equipes evitam métricas que não agregam valor em relação aos objetivos. Embora
possam ter determinados usos, as métricas a seguir não são úteis para acompanhar o
progresso em relação aos objetivos:

Precisão das estimativas originais

Horas concluídas
Linhas de código
Capacidade da equipe
Burndown da equipe
Velocidade da equipe
Número de bugs encontrados
Cobertura de código

Antes do Agile e depois do Agile

A tabela a seguir resume as alterações feitas pelas equipes de desenvolvimento da
Microsoft ao adotarem práticas Agile.

Antes After (após)

Marcos de 4 a 6 meses Sprints de 3 semanas

Equipes horizontais Equipes verticais

Escritórios pessoais Salas de equipe e trabalho remoto

Longos ciclos de planejamento Planejamento e aprendizagem contínuos

PM, Desenvolvimento e Teste PM, Design e Engenharia

Participação anual do cliente Participação contínua do cliente

Branches de recursos Todos trabalham na unidade principal

Equipes de mais de 20 pessoas Equipes de 8 a 12 pessoas

Roteiro secreto Roteiro compartilhado publicamente

Dívida de bug Sem dívidas

Documentos de especificação de 100 páginas Especificações do PowerPoint

Antes After (após)

Repositórios privados Código fonte aberto ou InnerSource

Hierarquia profunda da organização Hierarquia organizacional nivelada

Os números de instalação definem o sucesso A satisfação do usuário define o sucesso

Os recursos são enviados uma vez por ano Recursos enviados a cada sprint

Principais aspectos a serem lembrados

Leve a ciência Agile a sério, mas não seja prescritivo em excesso. O Agile pode se
tornar muito rigoroso. Deixe a mentalidade e a cultura Agile crescerem.
Comemore resultados, não atividades. A implantação da funcionalidade supera as
linhas de código.
Envie a cada sprint para estabelecer um ritmo e cadência e enxergar todo o
trabalho que precisa ser feito.
Crie a cultura que você quer para obter o comportamento que você está
procurando.
Desenvolver software moderno com o
DevOps
Artigo • 05/10/2023

A fase de desenvolvimento de DevOps é onde todo o trabalho principal de

desenvolvimento de software acontece. Como entrada, ele recebe planos para a
iteração atual, geralmente na forma de atribuições de tarefas. Em seguida, produz
artefatos de software que expressam a funcionalidade atualizada. O desenvolvimento
requer não apenas as ferramentas usadas para escrever código, como o Visual Studio,
mas também serviços de suporte como controle de versão, gerenciamento de
problemas e testes automatizados.

Selecionar um ambiente de desenvolvimento

O ideal é que os desenvolvedores gastem a maior parte do tempo em tarefas básicas de
desenvolvimento, como edição e depuração de código. Ter a cadeia de ferramentas
certa pode fazer a diferença entre o pico de produtividade e o desempenho abaixo do
ideal. Os ambientes de desenvolvimento integrados (IDEs) evoluíram além de seu início
humilde como lugares para editar e compilar código. Hoje, os desenvolvedores têm a
capacidade de executar quase todas as suas tarefas de DevOps a partir de uma única
experiência do usuário quando selecionam o ambiente de desenvolvimento certo.
Gerencie código através do controle de versão
e do Git
À medida que as equipes se expandem, o número de stakeholders que dependem e
contribuem com as bases de código pode crescer rapidamente. Sem uma estratégia em
vigor para gerenciar as alterações no código-fonte, as equipes de desenvolvimento
correm um risco significativo de confusão constante, erros e perda de produtividade.
Implementar até mesmo o controle de versão mais básico pode proteger contra essas
armadilhas. A maioria das equipes opta por usar o Git, o sistema de controle de versão
mais popular, para gerenciar seu código.

Automatizar processos
O valor real do estágio de desenvolvimento vem da implementação de recursos.
Infelizmente, há muitas outras tarefas que tiram tempo da equipe de desenvolvimento.
Compilar código, executar testes e preparar a saída para implantação são alguns
exemplos. Para minimizar o impacto, o DevOps enfatiza a automatização desses tipos de
tarefas por meio da prática da integração contínua.

Outra tarefa demorada no ciclo de vida de desenvolvimento é corrigir bugs. Embora os

bugs sejam frequentemente vistos como uma parte inevitável do desenvolvimento de
software, existem passos valiosos que qualquer equipe pode seguir para reduzi-los.
Saiba como deslocar para a esquerda para tornar os testes mais rápidos e confiáveis.

Próximas etapas
A Microsoft é uma das maiores empresas de desenvolvimento de software do mundo
há décadas. Saiba mais sobre como a Microsoft faz desenvolvimentos em DevOps.

Para ter uma experiência prática de DevOps com integração contínua, consulte os
seguintes caminhos de aprendizado:

Gerenciar o controle do código-fonte com o GitHub

Definir e implementar a integração contínua com o Azure DevOps
Gerenciar o ciclo de vida de seus projetos no GitHub
Selecionar um ambiente de
desenvolvimento
Artigo • 05/10/2023

Selecione o ambiente de desenvolvimento certo para oferecer suporte à adoção e ao

desempenho de DevOps. Um ambiente de desenvolvimento de DevOps não deve
apenas editar e depurar código, mas integrar-se ao restante do ciclo de DevOps,
incluindo testes, controle de versão e monitoramento de produção. A Microsoft fornece
dois ambientes de desenvolvimento principais para oferecer suporte a DevOps: o Visual
Studio e o Visual Studio Code.

Usar o Virtual Studio

O Visual Studio é um ambiente de desenvolvimento integrado (IDE) completo. Se
você puder usá-lo, o Visual Studio é ideal para trabalhar no Windows a fim de criar
software para várias plataformas, incluindo .NET ou .NET Core, iOS, Android via Xamarin
e destinos que oferecem suporte a C++.

Historicamente, o Visual Studio oferece benefícios de produtividade e integração de

DevOps. O Visual Studio integra-se nativamente ao GitHub e ao Azure DevOps e tem
um ecossistema robusto de extensões para cada provedor de DevOps do setor.

Usar o Visual Studio Code

O Visual Studio Code é um editor de código gratuito e simplificado que oferece
personalização ilimitada por meio de dezenas de milhares de extensões comerciais e da
comunidade . Essas extensões incluem suporte para praticamente qualquer idioma,
plataforma e serviço de DevOps. Os desenvolvedores podem ser produtivos no
Windows, Mac ou Linux. O Visual Studio Code é a opção ideal para desenvolvedores
que não podem usar o Visual Studio.

Desenvolver para o Azure

Não há um ambiente de desenvolvimento preferencial específico para soluções do
Azure. Graças ao amplo suporte para todas as principais plataformas de aplicativos,
você pode usar praticamente qualquer ferramenta para criar soluções do Azure e
selecionar o modelo de implantação que funciona melhor para você. A melhor maneira
de implantar soluções em produção geralmente é por meio da automação hospedada
no GitHub Actions ou Azure Pipelines .

O Visual Studio e o Visual Studio Code têm recursos nativos e extensões internas que
simplificam o trabalho com processos de DevOps no Azure, GitHub e Azure DevOps.

Próximas etapas
Saiba como a preparar o Visual Studio, Visual Studio Code, Eclipse para Java e IntelliJ
IDEA para desenvolvimento do Azure no módulo Preparar o ambiente de
desenvolvimento para o desenvolvimento do Azure.
O que é controle de versão?
Artigo • 05/10/2023

Os sistemas de controle de versão são programas de software que ajudam a controlar

as alterações feitas no código ao longo do tempo. Conforme o desenvolvedor edita o
código, o sistema de controle de versão tira um instantâneo dos arquivos. Em seguida,
ele salva esse instantâneo permanentemente para que ele possa ser recuperado mais
tarde, se necessário.

Sem o controle de versão, os desenvolvedores ficam tentado a manter várias cópias de

código em seu computador. Isso é perigoso, pois é fácil alterar ou excluir um arquivo na
cópia errada do código, e possivelmente perder o trabalho. Os sistemas de controle de
versão resolvem esse problema gerenciando todas as versões do código, mas
apresentando uma única versão por vez à equipe.

Por que o controle de versão é importante

Há muitas coisas que podem tomar muito tempo para um desenvolvedor. Reproduzir
bugs, aprender novas ferramentas e adicionar novos recursos ou conteúdo são apenas
alguns exemplos. À medida que as demandas dos usuários aumentam, o controle de
versão ajuda as equipes a trabalharem juntas e fazerem entregas no prazo.

Benefícios do controle de versão

O controle de versão beneficia muitos aspectos da produção.

Criar fluxos de trabalho

Fluxos de trabalho de controle de versão impedem o caos de todos usando seu próprio
processo de desenvolvimento com ferramentas diferentes e incompatíveis. Os sistemas
de controle de versão fornecem imposição e permissões de processo, de modo que
todos permaneçam em sintonia.
Trabalhar com versões

Cada versão tem uma descrição para o que as alterações na versão fazem, como corrigir
um bug ou adicionar um recurso. Essas descrições ajudam a equipe a seguir as
alterações no código por versão, em vez de por alterações de arquivo individuais. O
código armazenado em versões pode ser exibido e restaurado a partir do controle de
versão a qualquer momento, conforme necessário. As versões permitem basear novos
trabalhos em qualquer versão do código com mais facilidade.

Codificar em conjunto

O controle de versão sincroniza as versões e garante que as alterações não estejam em

conflito com alterações de outras pessoas. A equipe conta com o controle de versão
para ajudar a resolver e evitar conflitos, mesmo quando as pessoas fazem alterações ao
mesmo tempo.

Manter um histórico

O controle de versão mantém um histórico das alterações à medida que a equipe salva
novas versões do código. Os membros da equipe podem revisar o histórico para
descobrir quem, por que e quando as alterações foram feitas. O histórico dá às equipes
a confiança de experimentar, uma vez que é fácil reverter para uma versão boa anterior
a qualquer momento. O histórico permite que qualquer pessoa trabalhe com base em
qualquer versão do código, como para corrigir um bug em uma versão anterior.

Automatizar tarefas

Os recursos de automação de controle de versão economizam tempo e geram

resultados consistentes. O teste automatizado, a análise de código e a implantação
quando novas versões são salvas no controle de versão são três exemplos.

Próximas etapas
Saiba mais sobre o padrão mundial em controle de versão, o Git.
O que é o Git?
Artigo • 05/10/2023

O Git se tornou o padrão mundial para controle de versão. Mas o que exatamente é
isso?

O Git é um sistema de controle de versão distribuído, o que significa que um clone local
do projeto é um repositório de controle de versão completo. Esses repositórios locais
totalmente funcionais facilitam o trabalho offline ou remoto. Os desenvolvedores
confirmam o trabalho localmente e depois sincronizam a cópia do repositório com a
cópia no servidor. Esse paradigma é diferente do controle de versão centralizado, no
qual os clientes devem sincronizar o código com um servidor antes de criar novas
versões do código.

A flexibilidade e a popularidade do Git o tornam uma ótima escolha para qualquer

equipe. Muitos desenvolvedores e universitários já sabem como usar o Git. A
comunidade de usuários do Git criou recursos para treinar desenvolvedores, e a
popularidade do Git facilita a obtenção de ajuda quando necessário. Quase todos os
ambientes de desenvolvimento têm suporte ao Git e as ferramentas de linha de
comando do Git implementadas em todos os principais sistemas operacionais.

Noções básicas do Git

Toda vez que o trabalho é salvo, o Git cria um commit. Um commit é um instantâneo de
todos os arquivos em um momento específico. Se um arquivo foi alterado de um
commit para outro, o Git usará o arquivo armazenado anteriormente. Esse esquema é
diferente de outros sistemas que armazenam uma versão inicial de um arquivo e
mantêm um registro de deltas ao longo do tempo.

Os commits criam links para outros commits, formando um gráfico do histórico de

desenvolvimento. É possível reverter o código para um commit anterior, inspecionar
como os arquivos foram alterados de um commit para outro e revisar informações,
como onde e quando as alterações foram feitas. Os commits são identificados no Git
por um hash criptográfico exclusivo do conteúdo do commit. Como tudo é
criptografado hash, é impossível fazer alterações, perder informações ou corromper
arquivos sem a detecção do Git.

Ramificações
Cada desenvolvedor salva as alterações em seu próprio repositório de código local.
Como resultado, pode haver muitas alterações diferentes com base no mesmo commit.
O Git fornece ferramentas para isolar as alterações e depois mesclá-las novamente. Os
branches, que são ponteiros leves para o trabalho em andamento, gerenciam essa
separação. Depois que o trabalho criado em um branch é concluído, ele pode ser
mesclado novamente no branch principal (ou no tronco) da equipe.

Arquivos e commits
Os arquivos no Git estão em um dos três estados: modificado, preparado ou
confirmado. Quando um arquivo é modificado pela primeira vez, as alterações existem
apenas no diretório de trabalho. Eles ainda não fazem parte de um commit ou do
histórico de desenvolvimento. O desenvolvedor deve preparar os arquivos alterados a
serem incluídos no commit. A área de preparação contém todas as alterações a serem
incluídas no próximo commit. Quando o desenvolvedor estiver satisfeito com os
arquivos preparados, os arquivos serão empacotados como um commit com uma
mensagem descrevendo o que foi alterado. Esse commit passa a fazer parte do histórico
de desenvolvimento.
A preparação permite que os desenvolvedores escolham quais alterações de arquivo
salvar em um commit para dividir grandes alterações em um grupo de commits
menores. Ao reduzir o escopo dos commits, é mais fácil revisar o histórico de commits
para encontrar alterações específicas de arquivos.

Benefícios do Git
Há inúmeros benefícios no Git.

Desenvolvimento simultâneo
Todos têm sua própria cópia local do código e podem trabalhar simultaneamente em
seus próprios branches. O Git funciona offline, já que quase todas as operações são
locais.

Lançamentos mais rápidos

Os branches permitem o desenvolvimento flexível e simultâneo. O branch principal
contém um código estável e de alta qualidade, com base no qual você lançará versões.
Os branches de recurso contêm trabalhos em andamento, que são mesclados no branch
principal após a conclusão. Ao separar o branch de lançamento do desenvolvimento em
andamento, é mais fácil gerenciar um código estável e enviar atualizações mais
rapidamente.

Integração interna
Devido à sua popularidade, o Git pode ser integrado à maioria dos produtos e
ferramentas. Todos os principais IDEs têm suporte interno ao Git, e muitas ferramentas
oferecem suporte à integração contínua, implantação contínua, testes automatizados,
rastreamento de itens de trabalho, métricas e integração de recursos de relatório com o
Git. Essa integração simplifica o fluxo de trabalho diário.

Forte suporte da comunidade

O Git usa um código aberto e se tornou o padrão de fato para controle de versão. Há
inúmeras opções de ferramentas e recursos disponíveis para as equipes aproveitarem. O
volume de suporte da comunidade para o Git em comparação com outros sistemas de
controle de versão facilita a obtenção de ajuda quando necessário.
O Git funciona com qualquer equipe
Usar o Git com uma ferramenta de gerenciamento de código-fonte aumenta a
produtividade de uma equipe, incentivando a colaboração, aplicando políticas,
automatizando processos e melhorando a visibilidade e a rastreabilidade do trabalho. A
equipe pode se contentar com ferramentas individuais para controle de versão,
rastreamento de itens de trabalho e integração e implantação contínuas. Ou os
membros da equipe podem escolher uma solução como o GitHub ou o Azure
DevOps que ofereça suporte a todas essas tarefas em um só lugar.

Solicitações de pull
Use solicitações pull para discutir alterações de código com a equipe antes de mesclá-
las no branch principal. As discussões em solicitações pull são inestimáveis para garantir
a qualidade do código e melhorar o conhecimento de toda a sua equipe. Plataformas
como o GitHub e o Azure DevOps oferecem uma experiência avançada de solicitação de
pull, em que os desenvolvedores podem procurar alterações de arquivo, deixar
comentários, inspecionar commits, exibir compilações e votar para aprovar o código.

Políticas de branch
As equipes podem configurar o GitHub e o Azure DevOps para aplicar fluxos de
trabalho e processos consistentes em toda a equipe. Eles podem configurar políticas de
branch para garantir que as solicitações pull atendam aos requisitos antes da conclusão.
As políticas de branch protegem branches importantes, evitando transmissões diretas,
exigindo revisores e garantindo compilações limpas.

Próximas etapas
Instalar e configurar o Git
Instalar e configurar o Git
Artigo • 05/10/2023

O Git ainda não é uma opção padrão em computadores, portanto, deve ser instalado e
configurado manualmente. E, assim como outros softwares, é importante manter o Git
atualizado. As atualizações protegem contra vulnerabilidades de segurança, corrigem
bugs e fornecem acesso a novos recursos.

As seções a seguir descrevem como instalar e manter o Git para as três principais
plataformas.

Instalar o Git para Windows

Baixe e instale o Git para Windows . Depois de instalado, o Git está disponível no
prompt de comando ou no PowerShell. Recomendamos selecionar os padrões durante a
instalação, a menos que haja um bom motivo para alterá-los.

O Git para Windows não é atualizado automaticamente. Para atualizar o Git para
Windows, baixe a nova versão do instalador, que atualiza o Git para Windows e mantém
todas as configurações.

Instalar o Git para macOS

O macOS 10.9 (Mavericks) e superior instala o Git na primeira vez que você tenta
executá-lo a partir do Terminal. Embora esse método seja uma maneira fácil de instalar
o Git em um sistema, não permite o controle sobre a frequência com que as
atualizações ou correções de segurança são aplicadas.

Em vez disso, recomendamos instalar o Git por meio do Homebrew e usar as

ferramentas do Homebrew para manter o Git atualizado. O Homebrew é uma ótima
maneira de instalar e gerenciar ferramentas de desenvolvimento de código aberto em
um Mac usando a linha de comando.

Instale o Homebrew e execute o seguinte para instalar a versão mais recente do Git
em um Mac:

> brew install git

Para atualizar a instalação do Git, use a opção de atualização do Homebrew:

> brew upgrade git

Um instalador gráfico para o Git no macOS também está disponível no site oficial do
Git .

Instalar o Git para Linux

Use o sistema de gerenciamento de pacotes nativo da distribuição do Linux para instalar
e atualizar o Git. Por exemplo, no Ubuntu:

> sudo apt-get install git

Configurar o Git no Linux

Configure o nome e o endereço de e-mail antes de começar a trabalhar com o Git. O Git
anexa essas informações às alterações e permite que outras pessoas identifiquem quais
alterações pertencem a quais autores.

Execute os seguintes comandos no prompt de comando depois de instalar o Git para

configurar essas informações:

> git config --global [Link] "<First_name> <Last_name>"

> git config --global [Link] "<user_email_address>"

O Visual Studio oferece uma excelente experiência do Git pronta para uso sem nenhuma
ferramenta adicional. Saiba mais neste tutorial do Git no Visual Studio.
Configurar um repositório GIT
Artigo • 05/10/2023

Um repositório Git, ou repo, é uma pasta na qual o Git controla as alterações. Pode
haver qualquer número de repositórios em um computador, cada um armazenado em
sua própria pasta. Cada repositório Git em um sistema é independente, portanto, as
alterações salvas em um repositório Git não afetam o conteúdo de outro.

Um repositório Git contém todas as versões de cada arquivo salvo no repositório. Ele é
diferente de outros sistemas de controle de versão que armazenam apenas as
diferenças entre arquivos. O Git armazena as versões de arquivos em uma pasta .git
oculta juntamente com outras informações necessárias para gerenciar o código. O Git
salva esses arquivos de forma muito eficiente, portanto, ter muitas versões não significa
usar muito espaço em disco. Armazenar cada versão de um arquivo ajuda o Git a
melhor mesclar o código e facilita e acelera o trabalho com várias versões de código.

Os desenvolvedores trabalham com o Git por meio de comandos emitidos enquanto

trabalham em um repositório local no computador. Mesmo ao compartilhar um código
ou obter atualizações da equipe, isso é feito a partir de comandos que atualizam o
repositório local. Esse esquema com foco local é o que torna o Git um sistema de
controle de versão distribuído. Cada repositório é independente, e o proprietário do
repositório é responsável por mantê-lo atualizado com as alterações de outras pessoas.

A maioria das equipes usa um repositório central hospedado em um servidor que todos
podem acessar para coordenar suas alterações. O repositório central geralmente é
hospedado em uma solução de gerenciamento de controle de origem, como o GitHub
ou Azure DevOps. Uma solução de gerenciamento de controle de origem adiciona
recursos e facilita o trabalho em conjunto.

Criar um novo repositório Git

Você tem duas opções para criar um repositório Git. Você pode criar com base no
código em uma pasta de um computador ou clonar a partir de um repositório existente.
Se você estiver trabalhando com um código que está apenas no computador local, crie
um repositório local usando o código nessa pasta. Mas, na maioria das vezes, o código
já é compartilhado em um repositório Git, portanto, clonar o repositório existente para
o computador local é recomendado.

Criar um novo repositório com base no código existente

Use o comando git init para criar um novo repositório a partir de uma pasta existente
no computador. Na linha de comando, navegue até a pasta raiz que contém o código e
execute:

> git init

para criar o repositório. Em seguida, adicione todos os arquivos na pasta ao primeiro

commit usando os seguintes comandos:

> git add --all

> git commit -m "Initial commit"

Criar um novo repositório a partir de um repositório

remoto
Use o comando git clone para copiar o conteúdo de um repositório existente para
uma pasta no computador. Na linha de comando, navegue até a pasta que armazenará
o repositório clonado e execute:

> git clone

[Link]

Use a URL real para o repositório existente em vez da URL de espaço reservado
mostrada neste exemplo. Essa URL, chamada de URL de clonagem, aponta para um
servidor em que a equipe coordena as alterações. Obtenha essa URL da equipe ou do
botão de clonagem no site em que o repositório está hospedado.
Não é necessário adicionar arquivos ou criar um commit inicial quando o repositório é
clonado, pois ele foi copiado por completo, juntamente com o histórico, a partir do
repositório existente durante a operação de clonagem.

Próximas etapas
O GitHub e o Azure Repos fornecem repositórios Git privados e públicos gratuitos.

Usuário do Visual Studio? Saiba mais sobre como criar e clonar repositórios do Visual
Studio neste tutorial do Git.
Salvar e compartilhar código com o Git
Artigo • 05/10/2023

Salvar e compartilhar versões de código com uma equipe são as coisas mais comuns
feitas ao usar o controle de versão. O Git tem um fluxo de trabalho fácil de três etapas
para estas tarefas:

1. Criar um novo branch para o trabalho

2. Confirmar alterações
3. Transmitir o branch para compartilhá-lo com a equipe

O Git facilita o gerenciamento do trabalho usando branches. Cada correção de bug,

novo recurso, teste adicionado e configuração atualizada começa com um novo branch.
Os branches são leves e locais para o computador de desenvolvimento, portanto, não é
necessário se preocupar com o uso de recursos ou a coordenação de alterações com
outras pessoas até que seja hora de transmitir o branch.

Os branches permitem que você codifique de forma isolada de outras alterações no

desenvolvimento. Quando tudo estiver funcionando, o branch e as alterações serão
compartilhados com sua equipe. Outras pessoas podem experimentar o código em sua
própria cópia do branch sem que isso afete o trabalho em andamento em seus próprios
branches.

Criar um branch
Crie um branch com base no código em um branch atual, como main , ao iniciar um
novo trabalho. É uma prática recomendada verificar qual branch está selecionado
usando git status antes de criar um novo.

Crie branches no Git usando o comando git branch :

 > git branch <branchname>

O comando para trocar branches no repositório é git checkout . Depois de criar o

branch, alterne para ele antes de salvar as alterações.

> git checkout <branchname>

O Git tem um comando abreviado para criar o branch e alternar para ele ao mesmo
tempo:

> git checkout -b <branchname>

Saiba mais sobre como trabalhar com branches do Git no GitHub ou Azure DevOps.

Salvar alterações
O Git não captura um instantâneo do código automaticamente à medida que as edições
são feitas. Você deve informar ao Git exatamente quais alterações devem ser
adicionadas ao próximo instantâneo. Isso chama-se preparação. Depois de preparar as
alterações, crie um commit para salvar o instantâneo permanentemente.

Preparar alterações
O Git rastreia as alterações de arquivo feitas no repositório à medida que elas ocorrem.
Ele divide essas alterações em três categorias:

Arquivos não modificados não foram alterados desde o último commit.

Arquivos modificados têm alterações desde o último commit, mas não foram
preparados para o próximo commit.
Arquivos preparados têm alterações que serão adicionadas ao próximo commit.
Quando você criar um commit, somente as alterações preparadas e os arquivos não
alterados serão usados para o instantâneo. As alterações não preparadas são mantidas
no sistema de arquivos, mas o commit usa o arquivo não modificado em seu
instantâneo.

Confirmar alterações
Salve as alterações no Git criando um commit. Cada commit armazena o conteúdo
completo do arquivo do repositório em cada commit, não apenas alterações de arquivo
individualmente. Esse comportamento é diferente de outros sistemas de controle de
versão que armazenam as diferenças no nível de arquivos da última versão do código.
Históricos completos de arquivos permitem que o Git tome melhores decisões ao
mesclar alterações e acelera muito a alternância entre branches de código.

Prepare alterações com git add para adicionar arquivos alterados, git rm para remover
arquivos e git mv para mover arquivos. Em seguida, use o comando git commit para
criar o commit.

Normalmente, os desenvolvedores desejam preparar todos os arquivos alterados no

repositório:

> git add –all

Em seguida, confirme as alterações com uma breve descrição:

> git commit -m "Short description of changes."

Cada commit tem uma mensagem que descreve suas alterações. Uma boa mensagem
de commit ajuda o desenvolvedor a se lembrar das alterações feitas em um commit.
Boas mensagens de commit também facilitam a revisão do commit por outras pessoas.
Saiba mais sobre como preparar arquivos e confirmar alterações no Visual Studio or
Visual Studio Code .

Compartilhar alterações
Seja trabalhando em uma equipe ou apenas buscando fazer backup de seu próprio
código, os desenvolvedores precisam compartilhar commits com um repositório em
outro computador. Use o comando git push para obter commits do repositório local e
gravá-los em um repositório remoto. O Git é configurado em repositórios clonados para
se conectar à origem do clone, também conhecido como origin . Execute git push para
gravar os commits locais de seu branch atual em outro branch (branchname) nesse
repositório de origem. O Git criará branchname no repositório remoto se não existir.

> git push origin

Se estiver trabalhando em um repositório criado no sistema local com git init , você
precisará configurar uma conexão com o servidor Git da equipe para que as alterações
possam ser transmitidas. Saiba mais sobre como configurar remotos e transmitir
alterações no Visual Studio ou Visual Studio Code .

Compartilhar branches
Transmitir um branch local para o repositório compartilhado da equipe torna suas
alterações acessíveis ao restante da equipe. Na primeira vez que git push for
executado, a inclusão da opção -u informa ao Git a começar a rastrear o branch local
para branchname a partir do repositório origin . Após essa configuração única de
informações de rastreamento, os membros da equipe podem usar git push
diretamente para compartilhar atualizações de forma rápida e fácil.

> git push origin <branchname>

Próximas etapas
Saiba mais sobre branches no GitHub ou Azure DevOps.
Saiba mais sobre como transmitir commits e branches no Visual Studio ou Visual Studio
Code .
Ententendo o histórico do Git
Artigo • 05/10/2023

O Git representa o histórico de uma maneira totalmente diferente dos sistemas de

controle de versão centralizados (CVCS), como o Controle de Versão do Team
Foundation, Perforce ou Subversion. Os sistemas centralizados armazenam um histórico
separado para cada arquivo em um repositório. O Git armazena o histórico como um
gráfico de instantâneos de todo o repositório. Esses instantâneos, chamados de commits
no Git, podem ter vários pais, criando um histórico que se parece com um gráfico, em
vez de uma linha reta. Essa diferença no histórico é muito importante e é a principal
razão pela qual os usuários familiarizados com o CVCS acham que o Git é confuso.

Noções básicas do histórico de commits

Comece com um exemplo simples de histórico: um repositório com três commits
lineares.

A confirmação A é o pai do commit B e a confirmação B é o pai da confirmação C. Esse

histórico é muito semelhante a um CVCS. A seta que aponta para a confirmação C é um
branch. Os branches são ponteiros para confirmações específicas, e é por isso que a
ramificação é tão leve e fácil no Git.

Uma diferença fundamental no Git em comparação com o CVCS é que o desenvolvedor

tem sua própria cópia completa do repositório. Ele precisa manter seu repositório local
sincronizado com o repositório remoto, obtendo os commits mais recentes do
repositório remoto. Para fazer isso, ele pode extrair o branch principal com o seguinte
comando:

git pull origin main

Isso mescla todas as alterações do branch principal no repositório remoto, que o Git
chama de origin por padrão. Essa extração trouxe um novo commit, e o branch
principal no repositório local para para esse commit.
Entendendo o histórico do branch
Agora é hora de fazer uma alteração no código. É comum ter vários branches ativos ao
trabalhar em diferentes recursos em paralelo. Isso contrasta fortemente com o CVCS,
onde novos branches são pesados e raramente criados. A primeira etapa é fazer check-
out para um novo branch usando o seguinte comando:

git checkout -b cool-new-feature

Este é um atalho que combina dois comandos:

git branch cool-new-feature para criar o branch

git checkout cool-new-feature para começar a trabalhar no branch

Dois branches agora apontam para o mesmo commit. Vamos supor que haja algumas
alterações no branch cool-new-feature em dois novos commits, E e F.

Os commits podem ser acessados pelo branch cool-new-feature , uma vez que foram
confirmados para esse branch. Agora que o recurso está pronto, ele precisa ser
mesclado no branch principal. Para isso, use o seguinte comando:

git merge cool-feature main

A estrutura de gráfico do histórico fica visível quando há uma mesclagem. O Git cria um
novo commit quando o branch é mesclado em outro. Isso é uma confirmação de
mesclagem. Não há nenhuma alteração incluída neste commit de mesclagem, já que
não houve conflitos. Se houvesse conflitos, o commit de mesclagem incluiria as
alterações necessárias para resolvê-los.

História no mundo real

Veja a seguir um exemplo do histórico do Git que mais se assemelha ao código no
desenvolvimento ativo em uma equipe. Há três pessoas que mesclam commits de seus
próprios branches no branch main ao mesmo tempo.

Próximas etapas
Saiba mais sobre como trabalhar com o histórico do Git no GitHub e Azure Repos ou
simplificação do histórico do log do Git.
Obter feedback com solicitações de pull
Artigo • 05/10/2023

As solicitações pull oferecem suporte à revisão e mesclagem de código em um único

processo colaborativo. Depois que um desenvolvedor adiciona um recurso ou uma
correção de bug, ele cria uma solicitação pull para iniciar o processo de mesclagem das
alterações no branch upstream. Outros membros da equipe têm a chance de revisar e
aprovar o código antes que ele seja finalizado. Use solicitações de pull para examinar os
trabalhos em andamento e obter comentários antecipados em relação às alterações.
Mas não há compromisso de mesclar as mudanças. Um proprietário pode abandonar
uma solicitação pull a qualquer momento.

Obter código revisado

A revisão de código feita como parte de uma solicitação pull não serve apenas para
encontrar bugs óbvios. Essa é a tarefa dos testes. Uma boa revisão de código encontra
problemas menos óbvios que podem ocasionar problemas dispendiosos
posteriormente.

As revisões de código ajudam a proteger a equipe de mesclagens ruins e builds

corrompidos que minam a produtividade da equipe. As revisões detectam problemas
antes da mesclagem, protegendo branches importantes de alterações indesejadas.

As revisões de código também incentivam e fortalecem a colaboração e a comunicação

entre os desenvolvedores. E a equipe ganha um histórico claro de todas as alterações
feitas entre o branch principal e os branches de recursos.

Dissemine a experiência e distribua estratégias de solução de problemas usando uma

ampla variedade de revisores nas revisões de código. A difusão de habilidades e
conhecimento torna a equipe mais forte e resiliente.

Fornecer ótimos comentários

As revisões de alta qualidade começam com comentários de alta qualidade. Os
fundamentos dos comentários excelentes em uma solicitação de pull são:

Fazer com que as pessoas certas revisem a solicitação de pull.

Certificar-se de que os revisores saibam o que o código faz.
Fornecer comentários úteis e construtivos.
Responda aos comentários em tempo hábil.
Ao atribuir revisores a uma solicitação pull, selecione o conjunto certo de revisores. Os
revisores devem saber como o código funciona, mas também incluir desenvolvedores
que trabalham em outras áreas para que possam compartilhar suas ideias.

Forneça uma descrição clara das alterações e uma compilação do código que tenha a
correção ou o recurso funcionando nela. Os revisores devem fornecer comentários
sobre as alterações com as quais não concordam. Identifique o problema e dê
sugestões específicas sobre o que poderia ser feito de forma diferente. O comentário
deve ter uma intenção clara e ser fácil para o proprietário da solicitação de pull
entender.

O proprietário da solicitação pull deve responder aos comentários, aceitar sugestões ou

explicar por que eles se recusam a aplicá-las. Algumas sugestões são boas, mas podem
estar fora do escopo da solicitação pull. Pegue essas sugestões e crie novos itens de
trabalho e branches de recursos separados da solicitação de pull para fazer essas
alterações.

Proteger branches com políticas

Existem alguns branches críticos em um repositório que as equipes sabem que têm boa
integridade, como o branch main . As equipes podem exigir solicitações pull para fazer
alterações nesses branches com plataformas como GitHub e Azure DevOps. Os
desenvolvedores que efetuam push de alterações diretamente nesses branches terão os
pushes rejeitados.

Adicione mais condições às suas solicitações pull para impor um nível mais alto de
qualidade de código aos principais branches. Um build limpo do código mesclado e a
aprovação de vários revisores são alguns requisitos adicionais que você pode empregar
para proteger seus principais branches.

Saiba mais
O GitHub tem uma extensa documentação sobre como propor alterações no seu
trabalho com solicitações pull .

Leia mais sobre como fornecer ótimos comentários em revisões de código e como usar
modelos de solicitação pull para fornecer orientação aos revisores. O Azure DevOps
também oferece uma experiência avançada de solicitação pull que é fácil de usar e
dimensionada conforme necessário.
Hospedar repositórios Git
Artigo • 05/10/2023

O Git rapidamente se tornou o padrão mundial para controle de versão. Milhões de

projetos confiam no Git para necessidades diárias de colaboração. Embora a natureza
descentralizada do Git forneça benefícios significativos, ainda é necessário que as
equipes transmitam as alterações para um repositório Git centralizado a fim de mesclar
branches e fornecer um hub para outras atividades de DevOps.

GitHub
De longe, o principal host mundial para projetos Git é o GitHub . O GitHub fornece
muito mais do que apenas a hospedagem do Git. O GitHub tem recursos que abrangem
todo o processo de DevOps, incluindo um marketplace de serviços e produtos para
parceiros .

Conheça as noções básicas do GitHub neste laboratório prático .

Auto-hospedar o GitHub
Algumas organizações podem ter requisitos regulatórios ou outros que as impedem de
hospedar o código-fonte e outros ativos fora de sua própria infraestrutura. Para esses
usuários, o GitHub Enterprise Server está disponível. O GitHub Enterprise Server inclui
a experiência do usuário e os recursos familiares, mas pode ser totalmente hospedado
na própria infraestrutura de uma empresa.

Configure uma versão de avaliação do GitHub Enterprise Server .

Azure Repos
Os usuários que já estão no Azure DevOps ou em versões anteriores do Team
Foundation Server têm uma opção de primeira classe na migração para o Azure Repos.
O Azure Repos fornece todos os benefícios do Git, juntamente com uma experiência de
usuário familiar e pontos de integração.

Conheça as noções básicas de como trabalhar com o Git no Azure Repos.

Auto-hospedar o Azure Repos

As equipes que precisam manter seu código-fonte e outros ativos em sua própria
infraestrutura podem usar o Azure DevOps Server para aproveitar todos os benefícios
do Azure Repos.

Baixe a versão mais recente do Azure DevOps Server.

Migrar para o Git do controle de versão
centralizado
Artigo • 05/10/2023

Migrar uma equipe para o Git a partir do controle de versão centralizado requer mais do
que apenas aprender novos comandos. Para oferecer suporte ao desenvolvimento
distribuído, o Git armazena o histórico de arquivos e as informações de filial de forma
diferente de um sistema centralizado de controle de versão. Planejar e implementar uma
migração bem-sucedida para o Git a partir de um sistema centralizado de controle de
versão requer a compreensão dessas diferenças fundamentais.

A Microsoft ajudou a migrar muitas equipes internas e clientes de sistemas centralizados

de controle de versão para o Git. Essa experiência produziu as seguintes orientações
baseadas em práticas que consistentemente são bem-sucedidas.

Etapas para uma migração bem-sucedida

Para uma migração bem-sucedida, as equipes devem:

Avaliar ferramentas e processos atuais.

Escolher uma estratégia de filial do Git.
Decidir se vai migrar o histórico e como.
Manter o sistema de controle de versão anterior.
Remover arquivos binários, executáveis e ferramentas do controle do código-
fonte.
Treinar equipes em conceitos e práticas do Git.
Testar a migração para o Git.

Avaliar ferramentas e processos atuais

A alteração dos sistemas de controle de versão naturalmente interrompe o fluxo de
trabalho de desenvolvimento com novas ferramentas e práticas. Essa interrupção pode
ser uma oportunidade para melhorar outros aspectos do processo de DevOps.

As equipes devem considerar a adoção das seguintes práticas ao migrar para o novo
sistema:

Integração contínua (CI), em que cada check-in aciona uma compilação e

aprovação no teste. A CI ajuda a identificar defeitos precocemente e fornece uma
forte rede de segurança para projetos.
 Revisões de código são necessárias antes de fazer check-in do código. No modelo
de filial do Git, a revisão do código de solicitação de pull faz parte do processo de
desenvolvimento. As revisões de código complementam o fluxo de trabalho de CI.

Entrega contínua (CD) para automatizar processos de implantação. A alteração das

ferramentas de controle de versão requer alterações no processo de implantação,
portanto, uma migração é um bom momento para adotar um pipeline de
lançamento moderno.

Escolher uma estratégia de filial do Git

Antes de migrar o código, a equipe deve selecionar uma estratégia de filial.

No Git, filiais de tópicos de curta duração permitem que os desenvolvedores trabalhem

perto da filial principal e se integrem rapidamente, evitando problemas de mesclagem.
Duas estratégias de filial de tópicos comuns são o GitFlow e uma variação mais
simples, o GitHub Flow .

O Git desencoraja filiais de recursos isoladas e de longa duração, que tendem a atrasar
as fusões até que a integração se torne difícil. Usando técnicas modernas de CD, como
sinalizadores de recursos, as equipes podem integrar o código à filial principal
rapidamente, mas ainda manter os recursos em andamento ocultos dos usuários até
que sejam concluídos.

As equipes que atualmente usam uma estratégia de filial de recursos de longa duração
podem adotar sinalizadores de recursos antes de migrar para o Git. O uso de
sinalizadores de recursos simplifica a migração, minimizando o número de filiais a serem
migradas. Quer usem filiais de recursos ou sinalizadores de recursos, as equipes devem
documentar o mapeamento entre filiais herdadas e novas filiais do Git, para que todos
entendam onde devem confirmar seu novo trabalho.

Decidir se deseja migrar o histórico

As equipes podem ficar tentadas a migrar seu histórico de código-fonte existente para o
Git. Várias ferramentas afirmam migrar um histórico completo de todas as filiais de uma
ferramenta centralizada para o Git. Uma confirmação do Git parece mapear
relativamente bem para o conjunto de alterações ou modelo de check-in que a
ferramenta de controle de versão anterior usava.

No entanto, esse mapeamento tem algumas limitações sérias.

 Na maioria dos sistemas centralizados de controle de versão, as filiais existem
como pastas no repositório. Por exemplo, a filial principal pode ser uma pasta
chamada /trunk e outras filiais são pastas como /branch/one e /branch/two. Em um
repositório do Git, as filiais incluem todo o repositório, portanto, uma tradução
individualizada é difícil.

Em alguns sistemas de controle de versão, uma marcação ou rótulo é uma coleção

que pode conter vários arquivos na árvore, até mesmo arquivos em diferentes
versões. No Git, uma marcação é um instantâneo de todo o repositório em um
ponto específico no tempo. Uma marcação não pode representar um subconjunto
do repositório ou combinar arquivos em versões diferentes.

A maioria dos sistemas de controle de versão armazena detalhes sobre a maneira

como os arquivos mudam entre as versões, incluindo tipos de alteração refinados,
como renomear, cancelar exclusão e reversão. O Git armazena versões como
instantâneos de todo o repositório, e metadados sobre a maneira como os
arquivos foram alterados não estão disponíveis.

Essas diferenças significam que uma migração de histórico completo será, na melhor
das hipóteses, deficitária e, possivelmente, enganosa. Dada essa característica, o esforço
envolvido e a relativa raridade do uso do histórico, recomenda-se que a maioria das
equipes evite importar o histórico. Em vez disso, as equipes devem fazer uma migração
de ponta, trazendo apenas um instantâneo da versão de filial mais recente para o Git.
Para a maioria das equipes, o tempo é mais bem gasto em áreas da migração que têm
um maior retorno sobre o investimento, como a melhoria de processos.

Manter o antigo sistema de controle de versão

Durante e após uma migração, os desenvolvedores ainda podem precisar acessar o
histórico de controle de versão anterior. Embora o histórico de controle de versão
anterior se torne menos relevante com o tempo, ainda é importante poder consultá-lo.
Ambientes altamente regulamentados podem ter requisitos legais e de auditoria
específicos para o histórico de controle de versão.

Especialmente para equipes que fazem apenas uma migração de ponta, é altamente
recomendável manter o sistema anterior indefinidamente. Defina o sistema de controle
de versão antigo como somente leitura após a migração.

Grandes equipes de desenvolvimento e ambientes regulamentados podem colocar

trilhas no Git que apontam para o antigo sistema de controle de versão. Um exemplo
simples é um arquivo de texto adicionado como a primeira confirmação na raiz de um
repositório do Git, antes da migração de ponta, que aponta para o URL do servidor de
controle de versão antigo. Se muitas filiais forem migradas, um arquivo de texto em
cada filial deverá explicar como as filiais migraram do sistema antigo. Trilhas também
são úteis para desenvolvedores que começam a trabalhar em um projeto depois que ele
foi migrado e não estão familiarizados com o antigo sistema de controle de versão.

Remover arquivos binários e ferramentas

O modelo de armazenamento do Git é otimizado para controle de versão de arquivos
de texto e código-fonte, que são compactos e altamente compactáveis. Os arquivos
binários geralmente são grandes e, uma vez adicionados a um repositório, permanecem
no histórico do repositório e em todos os clones futuros. Devido à maneira como o Git
armazena o histórico, os desenvolvedores devem evitar adicionar arquivos binários aos
repositórios, especialmente binários que são muito grandes ou que mudam com
frequência. A migração para o Git é uma oportunidade de remover esses binários da
base de código.

Também é recomendável excluir bibliotecas, ferramentas e saída de compilação dos

repositórios. Em vez disso, use sistemas de gerenciamento de pacotes como o NuGet
para gerenciar dependências.

Ativos como ícones e ilustrações talvez precisem se alinhar a uma versão específica do
código-fonte. Ativos pequenos e pouco alterados, como ícones, não sobrecarregam o
histórico, e você pode incluí-los diretamente em um repositório. Para armazenar ativos
grandes ou que mudam com frequência, use a extensão LFS (Large File Storage) do Git.
Para obter mais informações sobre como gerenciar arquivos grandes no GitHub,
consulte Gerenciar arquivos grandes . Para o Azure Repos, confira Gerenciar e
armazenar arquivos grandes no Git.

Forneça treinamento
Um dos maiores desafios na migração para o Git é ajudar os desenvolvedores a
entender como o Git armazena as alterações e como as confirmações formam o
histórico de desenvolvimento. Não basta preparar uma folha de referências que mapeie
comandos antigos para comandos do Git. Os desenvolvedores precisam parar de pensar
no histórico de controle de versão em termos de um modelo centralizado e linear e
entender o modelo de histórico do Git e o gráfico de confirmação.

As pessoas aprendem de maneiras diferentes, então você deve fornecer vários tipos de
materiais de treinamento. O treinamento ao vivo prático com um instrutor especializado
funciona bem para algumas pessoas. O guia Pro Git é um excelente ponto de partida
que está disponível gratuitamente online.
Os cursos de treinamento prático gratuitos disponíveis incluem:

Introdução ao controle de versão com o caminho de aprendizado do Git.

O início rápido de introdução ao Git no Azure Repos.
Recursos de aprendizagem do Git e do GitHub do GitHub.

As organizações devem trabalhar para identificar especialistas em Git nas equipes,

capacitá-los a ajudar os outros e incentivar outros membros da equipe a fazerem
perguntas a eles.

Testar a migração
Depois que as equipes atualizarem os processos, analisarem o código e treinarem seus
membros, é hora de migrar o código-fonte. Se você fizer uma migração de ponta ou
migrar o histórico, é importante fazer uma ou mais migrações de teste em um
repositório de teste. Antes de fazer uma migração final, certifique-se de que:

Todos os arquivos de código tenham sido migrados.

Todas as filiais estejam disponíveis.
Não haja binários perdidos no repositório.
Os usuários têm as permissões apropriadas para realizar fetch e push.
As compilações foram bem-sucedidas e todos os testes foram aprovados.

Migrar o código
Faça a migração final durante o horário de folga, idealmente entre marcos quando
houver tempo de inatividade natural. A migração no final de uma sprint pode causar
problemas enquanto os desenvolvedores estão tentando concluir o trabalho. Tente
migrar em um fim de semana, quando ninguém precisa fazer check-in.

Planeje uma transição firme do antigo sistema de controle de versão para o Git. Tentar
operar vários sistemas em paralelo significa que os desenvolvedores podem não saber
onde nem como fazer check-in. Defina o sistema de controle de versão antigo como
somente leitura para ajudar a evitar confusão. Sem essa salvaguarda, uma segunda
migração que inclua mudanças provisórias pode ser necessária.

O processo de migração real varia dependendo do sistema do qual você está migrando.
Para obter informações sobre como migrar do Controle de Versão do Team Foundation,
consulte Migrar do TFVC para o Git.

Lista de verificação de migração

Fluxos de trabalho da equipe:

＂ Determine como as compilações serão executadas.

＂ Decida quando os testes serão executados.
＂ Desenvolva um processo de gerenciamento de lançamentos.
＂ Mova revisões de código para solicitações pull.

Estratégias de filiais:

＂ Escolha uma estratégia de filial do Git.

＂ Documente a estratégia de filial, por que ela foi selecionada e como as filiais
herdadas são mapeadas.

Histórico:

＂ Decida por quanto tempo manter o controle de versão herdado em execução.

＂ Identifique filiais que precisam migrar.
＂ Se necessário, crie trilhas para ajudar os engenheiros a navegar de volta para o
sistema herdado.

Binários e ferramentas:

＂ Identifique quais binários e arquivos indistinguíveis devem ser removidos do

repositório.
＂ Decida uma abordagem para arquivos grandes, como o Git-LFS.
＂ Decida uma abordagem para fornecer ferramentas e bibliotecas, como o NuGet.

Treinamento:

＂ Identifique materiais de treinamento.

＂ Planeje eventos de treinamento, materiais escritos e vídeos.
＂ Identifique os membros da equipe para servir como especialistas locais do Git.

Migração de código:

＂ Faça várias execuções de teste para garantir que a migração ocorra sem problemas.
＂ Identifique e comunique um tempo de substituição.
＂ Crie o novo repositório do Git.
＂ Defina o sistema antigo como somente leitura.
＂ Migre primeiro a filial principal e, em seguida, quaisquer outras filiais necessárias.

Próximas etapas
Migrar para o Azure DevOps do Team Foundation Server
Como os comandos do TFVC e o fluxo de trabalho são mapeados para o Git
Importar e migrar repositórios do TFVC
para o Git
Artigo • 26/08/2023

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019 | TFS
2018

Você pode migrar código de um repositório TFVC existente para um novo repositório
Git na mesma organização. A migração para o Git é um processo envolvido para
grandes repositórios E equipes do TFVC. Sistemas de controle de versão centralizados,
como o TFVC, se comportam de forma diferente do Git de maneiras fundamentais. A
opção envolve muito mais do que aprender novos comandos. É uma alteração
disruptiva que requer um planejamento cuidadoso. Você precisa pensar em:

Revisão de ferramentas e processos

Removendo binários e executáveis
Treinar sua equipe

É altamente recomendável ler o controle de versão centralizado para o Git e a seguinte

seção Migrar do TFVC para o Git antes de iniciar a migração.

A experiência de importação é ótima para pequenos repositórios TFVC simples. Também

é bom para repositórios que já foram "limpos", conforme descrito no controle de versão
centralizada para o Git e na seção Migrar do TFVC para o Git a seguir. Essas seções
também recomendam outras ferramentas para configurações mais avançadas do
repositório TFVC.

） Importante

Devido às diferenças na forma como o TFVC e o histórico de controle de versão do

Repositório Git, recomendamos que você não migre seu histórico. Essa é a
abordagem que a Microsoft adotou quando migrou o Windows e outros produtos
do controle de versão centralizado para o Git.

Importando o repositório
1. Selecione Repos, Arquivos.
2. Na lista suspensa do repositório, selecione Importar repositório.

3. Selecione TFVC na lista suspensa Tipo de origem

4. Digite o caminho para o repositório/branch/pasta que você deseja importar para o

repositório Git. Por exemplo, $/Fabrikam/FabrikamWebsite

5. Se você quiser migrar o histórico do repositório TFVC, clique em Migrar histórico e

selecione o número de dias. Você pode migrar até 180 dias de histórico a partir do
conjunto de alterações mais recente. Um link para o repositório TFVC é adicionado
 na mensagem de confirmação do 1º conjunto de alterações que é migrado para o
Git. Isso facilita a localização do histórico mais antigo quando necessário.

6. Dê um nome ao novo repositório Git e clique em Importar. Dependendo do

tamanho da importação, o repositório Git estará pronto em alguns minutos.

Solução de problemas
Essa experiência é otimizada para repositórios ou repositórios TFVC pequenos e simples
que foram preparados para uma migração. Isso significa que ele tem algumas
limitações.

1. Ele migra apenas o conteúdo da raiz ou de um branch. Por exemplo, se você tiver
um projeto TFVC no $/Fabrikam qual tenha 1 branch e 1 pasta sob ele, um
caminho para importar $/Fabrikam importará a pasta enquanto
$/Fabrikam/<branch> importaria apenas o branch.

2. O repositório importado e o histórico associado (se importado) não podem

exceder 1 GB de tamanho.
3. Você pode importar até 180 dias de histórico.

Se qualquer uma das opções acima for um bloqueador para sua importação,
recomendamos que você experimente ferramentas externas como o Git-TFS para
importar e ler nossos white papers – controle de versão centralizado para o Git e a
seção Migrar do TFVC para o Git a seguir.

） Importante

O uso de ferramentas externas como o Git-TFS com produtos, serviços ou

plataformas da Microsoft é inteiramente de responsabilidade do usuário. A
Microsoft não endossa, dá suporte ou garante a funcionalidade, a confiabilidade ou
a segurança dessas extensões de terceiros.

Migrar do TFVC para o Git

Antes de migrar o código-fonte de um sistema de controle de versão centralizado para
o Git, entenda as diferenças entre os dois e prepare-se para a migração.

Requirements
Etapas para migrar
Confira a versão mais recente
Remover binários e ferramentas de build
Converter configuração específica do controle de versão
Verificar as alterações e executar a migração
Migrações avançadas
Atualizar o fluxo de trabalho

Requisitos
Para facilitar as migrações, há vários requisitos antes de seguir o procedimento de
importação do repositório na seção anterior deste artigo.

Migre apenas um único branch. Ao planejar a migração, escolha uma nova

estratégia de ramificação para o Git. Migrar apenas o branch main dá suporte a um
fluxo de trabalho baseado em branch de tópicos, como GitFlow ou GitHub
Flow .
Faça uma migração de gorjeta, como em, importar apenas a versão mais recente
do código-fonte. Se o histórico do TFVC for simples, haverá uma opção para
migrar algum histórico, até 180 dias, para que a equipe possa trabalhar apenas
fora do Git. Para obter mais informações, consulte Planejar sua migração para o
Git.
Exclua ativos binários, como imagens, conjuntos de dados científicos ou modelos
de jogos do repositório. Esses ativos devem usar a extensão git LFS (suporte a
 arquivos grandes), que a ferramenta de importação não configura.
Mantenha o repositório importado abaixo de 1 GB de tamanho.

Se o repositório não atender a esses requisitos, use a ferramenta Git-TFS para fazer a
migração.

） Importante

O uso de ferramentas externas como o Git-TFS com produtos, serviços ou

plataformas da Microsoft é inteiramente de responsabilidade do usuário. A
Microsoft não endossa, dá suporte ou garante a funcionalidade, a confiabilidade ou
a segurança dessas extensões de terceiros.

Etapas para migrar

O processo de migração do TFVC geralmente é simples:

1. Confira a versão mais recente do branch do TFVC em seu disco local.

2. Remova binários e ferramentas de build do repositório e configure um sistema de
gerenciamento de pacotes como o NuGet.
3. Converter diretivas de configuração específicas do controle de versão. Por
exemplo, converta .tfignore arquivos em .gitignore e converta .tpattributes
arquivos em .gitattributes .
4. Verifique as alterações e execute a migração para o Git.

As etapas 1 a 3 são opcionais. Se não houver binários no repositório e não houver

necessidade de configurar um .gitignore ou um .gitattributes , você poderá
prosseguir diretamente para a etapa Verificar alterações e executar a migração .

Confira a versão mais recente

Crie um novo workspace do TFS e mapeie uma pasta de trabalho para o diretório do
servidor que está sendo migrado para o Git. Isso não requer um mapeamento completo
de pasta de trabalho. Apenas pastas de mapa que contêm binários a serem removidos
do repositório e pastas que contêm arquivos de configuração específicos do sistema de
controle de versão, como .tfignore .

Depois que os mapeamentos forem configurados, obtenha a pasta localmente:

prettyprint
 tf get /version:T /recursive

Remover binários e ferramentas de build

Devido à maneira como o Git armazena o histórico de arquivos alterados fornecendo
uma cópia de cada arquivo no histórico para cada desenvolvedor, a verificação de
arquivos binários diretamente no repositório faz com que o repositório cresça
rapidamente e possa causar problemas de desempenho.

Para ferramentas de build e dependências como bibliotecas, adote uma solução de

empacotamento com suporte para controle de versão, como o NuGet. Muitas código
aberto ferramentas e bibliotecas já estão disponíveis na Galeria do NuGet , mas, para
dependências proprietárias, crie novos pacotes NuGet.

Depois que as dependências forem movidas para o NuGet, verifique se elas não estão
incluídas no repositório Git adicionando-as a .gitignore.

Converter configuração específica do controle de versão

Controle de Versão do Team Foundation fornece um .tfignore arquivo , que garante

que determinados arquivos não sejam adicionados ao repositório TFVC. Você pode usar
o .tfignore arquivo para arquivos gerados automaticamente, como saída de build, para
que eles não sejam verificados acidentalmente.

Se o projeto depender desse comportamento, converta o .tfignore arquivo em um

.gitignore arquivo.

Os clientes TFVC multiplataforma também dão suporte a um .tpattributes arquivo que

controla como os arquivos são colocados no disco local ou verificados no repositório.
Se um .tpattributes arquivo estiver em uso, converta-o em um .gitattributes
arquivo.

Verificar as alterações e executar a migração

Verifique as alterações que removem binários, migram para o gerenciamento de
pacotes ou convertem a configuração específica do controle de versão. Depois de fazer
essa alteração final no TFVC, você poderá fazer a importação.

Siga o procedimento Importando o repositório para fazer a importação.

Migrações avançadas
A ferramenta Git-TFS é uma ponte bidirecional entre Controle de Versão do Team
Foundation e Git e você pode usá-la para executar uma migração. O Git-TFS é
apropriado para uma migração com histórico completo, mais de 180 dias aos quais a
ferramenta de Importação dá suporte. Ou você pode usar o Git-TFS para tentar uma
migração que inclua vários branches e relações de mesclagem.

Antes de tentar uma migração com o Git-TFS, observe que há diferenças fundamentais
entre a maneira como o TFVC e o histórico do repositório Git:

O Git armazena o histórico como um instantâneo do repositório a tempo,

enquanto o TFVC registra as operações discretas que ocorreram em um arquivo.
Os tipos de alteração no TFVC, como renomear, cancelar a exclusão e reversão,
não podem ser expressos no Git. Em vez de ver que o arquivo A foi renomeado
para o arquivo B , ele apenas rastreia que o arquivo A foi excluído e o arquivo B
foi adicionado na mesma confirmação.
O Git não tem um analógico direto de um rótulo TFVC. Os rótulos podem conter
qualquer número de arquivos em qualquer versão específica e podem refletir
arquivos em versões diferentes. Embora conceitualmente semelhantes, as marcas
do Git apontam para um instantâneo de todo o repositório em um ponto no
tempo. Se o projeto depender de rótulos TFVC para saber o que foi entregue, as
marcas do Git poderão não fornecer essas informações.
As mesclagens no TFVC ocorrem no nível do arquivo, não em todo o repositório.
Somente um subconjunto de arquivos alterados pode ser mesclado de um branch
para outro. Os arquivos alterados restantes podem então ser mesclados em um
conjunto de alterações subsequente. No Git, uma mesclagem afeta todo o
repositório e ambos os conjuntos de alterações individuais não podem ser vistos
como uma mesclagem.

Devido a essas diferenças, é recomendável que você faça uma migração de gorjetas e
mantenha seu repositório TFVC online, mas somente leitura, para exibir o histórico.

Para tentar uma migração avançada com o Git-TFS, confira Clonar um único branch com
histórico ou clonar todos os branches com histórico de mesclagem .

） Importante

O uso de ferramentas externas como o Git-TFS com produtos, serviços ou

plataformas da Microsoft é inteiramente de responsabilidade do usuário. A
Microsoft não endossa, dá suporte nem garante a funcionalidade, a confiabilidade
ou a segurança dessas extensões de terceiros.
Atualizar o fluxo de trabalho
Mover de um sistema de controle de versão centralizado para o Git é mais do que
apenas migrar código. A equipe precisa de treinamento para entender como o Git é
diferente do sistema de controle de versão existente e como essas diferenças afetam o
trabalho diário.

Saiba mais sobre como migrar do controle de versão centralizado para o Git.
Use a integração contínua
Artigo • 05/10/2023

CI (integração contínua) é o processo de criar e testar automaticamente o código

sempre que um membro da equipe confirma alterações de código no controle de
versão. Uma confirmação de código para a ramificação principal ou de tronco de um
repositório compartilhado dispara o sistema de criação automatizado para criar, testar e
validar a ramificação completa. A CI incentiva os desenvolvedores a compartilhar
códigos e testes de unidade, mesclando as alterações no repositório compartilhado de
controle de versão sempre que concluem uma tarefa.

Os desenvolvedores de software em geral trabalham isolados e precisam integrar as

alterações com o resto da base de código de uma equipe. Esperar dias ou semanas para
integrar o código pode gerar muitos conflitos de mesclagem, bugs difíceis de corrigir,
estratégias de código divergentes e esforços duplicados. A CI evita esses problemas
porque exige que o código da equipe de desenvolvimento seja continuamente
mesclado à ramificação de controle de versão compartilhada.

A CI mantém a ramificação principal atualizada. Os desenvolvedores podem usar

sistemas de controle de versão modernos, como o Git, para isolar o trabalho em
ramificações de recursos de curta duração. Quando o recurso for concluído, o
desenvolvedor enviará uma solicitação de pull da ramificação do recurso para a
ramificação principal. Após a aprovação da solicitação de pull, as alterações são
mescladas na ramificação principal e a ramificação do recurso pode ser excluída.

As equipes de desenvolvimento repetem esse processo para cada item de trabalho. As

equipes podem estabelecer políticas de ramificação para garantir que a ramificação
principal mantenha os critérios de qualidade desejados.

As definições de criação especificam que cada confirmação na ramificação principal

dispara o processo automatizado de criação e testes. Os testes automatizados verificam
se cada criação mantém uma qualidade consistente. A CI detecta bugs no início do ciclo
de desenvolvimento, tornando a correção mais barata.

A CI é um recurso padrão em plataformas de DevOps modernas. Os usuários do GitHub

podem implementar a CI por meio do GitHub Actions . Os usuários do Azure DevOps
podem usar o Azure Pipelines .
Deslocar teste para a esquerda com
testes de unidade
Artigo • 05/10/2023

O teste ajuda a garantir que o código seja executado conforme esperado, mas o tempo
e o esforço para criar testes consomem tempo que poderia ser dedicado a outras
tarefas, como o desenvolvimento de recursos. Em virtude desse custo, é importante
extrair o máximo de valor dos testes. Este artigo discute os princípios de teste do
DevOps, focando o valor do teste de unidade e uma estratégia de teste de
deslocamento para a esquerda.

Testadores dedicados costumavam escrever a maioria dos testes, e muitos

desenvolvedores de produtos não aprenderam a escrever testes de unidade. Pode
parecer difícil ou dar muito trabalho escrever testes. Alguns são céticos quanto à
possibilidade da estratégia de teste de unidade funcionar devido a experiências ruins
com testes de unidade mal escritos ou por medo de que os testes de unidade
substituam os testes funcionais.

Para implementar uma estratégia de teste do DevOps, seja pragmático e concentre-se

na criação de dinamismo. Embora você possa preferir testes de unidade para código
novo ou existente com possibilidade de refatoração correta, talvez faça sentido para
uma base de código herdada permitir um certo nível de dependência. Se partes
significativas do código do produto usarem SQL, permitindo a dependência de testes de
unidade do provedor de recursos SQL em vez de usar simulação, essa camada poderá
ser uma abordagem de curto prazo para o progresso.
À medida que as organizações do DevOps amadurecem, a liderança consegue
aprimorar processos mais facilmente. Apesar da possível resistência à mudança, as
organizações do Agile valorizam os benefícios diretos de mudanças. Deve ser fácil
vender a visão de testes mais rápidos e com menos falhas, pois isso significa mais
tempo para investir na geração de novo valor por meio do desenvolvimento de
recursos.

Taxonomia de teste do DevOps

Definir uma taxonomia de teste é um aspecto importante do processo de teste do
DevOps. Uma taxonomia de teste do DevOps classifica testes individuais por meio de
dependências e do tempo de execução. Os desenvolvedores devem entender os tipos
certos de testes a serem usados em cenários distintos e quais testes são exigidos por
partes distintas do processo. A maioria das organizações categoriza os testes em quatro
níveis:

Os testes L0 e L1 são testes de unidade, ou testes que dependem do código na

montagem em teste e nada mais. L0 é uma classe ampla de testes de unidade
rápidos na memória.
L2 são testes funcionais que podem exigir o assembly mais outras dependências,
como SQL ou o sistema de arquivos.
Os testes L3 são funcionais executados em implantações de serviço testáveis. Essa
categoria de teste exige uma implantação de serviço, mas pode usar stubs para as
principais dependências de serviço.
Os testes L4 são uma classe restrita de testes de integração executados em
produção. Os testes L4 exigem a implantação total do produto.

O ideal seria que todos os testes fossem executados o tempo todo, mas isso não é
viável. As equipes podem selecionar onde executar cada teste no processo do DevOps e
usar a estratégia shift-left ou shift-right para mover diferentes tipos de teste mais cedo
ou mais tarde no processo.

Por exemplo, a expectativa pode ser que os desenvolvedores sempre executem testes L2
antes de confirmar, uma solicitação pull falhe automaticamente se a execução de teste
L3 falhar e a implantação possa ser bloqueada se os testes L4 falharem. As regras
específicas variam de acordo com a organização, mas impor as expectativas para todas
as equipes de uma organização move todos em direção às mesmas metas de visão de
qualidade.

Diretrizes de teste de unidade

Defina diretrizes rígidas para testes de unidade L0 e L1. Esses testes precisam ser bem
rápidos e confiáveis. Por exemplo, o tempo médio de execução por teste L0 em um
assembly deve ser inferior a 60 milissegundos. O tempo médio de execução por teste L1
em um assembly deve ser inferior a 400 milissegundos. Nenhum teste neste nível deve
exceder 2 segundos.

Uma equipe da Microsoft executa mais de 60.000 testes de unidade em paralelo em

menos de seis minutos. Seu objetivo é reduzir esse tempo para menos de um minuto. A
equipe controla o tempo de execução do teste de unidade com ferramentas como o
gráfico a seguir e arquiva bugs em testes que excedem o tempo permitido.

Diretrizes de teste funcional

Testes funcionais devem ser independentes. O conceito-chave para testes L2 é o
isolamento. Testes corretamente isolados podem ser executados de forma confiável em
qualquer sequência, pois eles têm controle total do ambiente em que são executados.
No início do teste, deve aparecer o estado. Se um teste criar dados e os deixar no banco
de dados, isso poderá corromper a execução de outro teste que dependa de um estado
de banco de dados distinto.

Testes herdados que precisam de uma identidade de usuário podem ter chamado
provedores de autenticação externos para obter a identidade. Essa prática apresenta
vários desafios. A dependência externa pode ficar momentaneamente não confiável ou
indisponível, interrompendo o teste. Essa prática também viola o princípio de
isolamento de teste porque um teste pode alterar o estado de uma identidade, como
permissão, resultando em um estado padrão inesperado para outros testes. Considere
evitar esses problemas investindo no suporte de identidade na estrutura de teste.
Princípios de teste do DevOps
Para ajudar na transição de um portfólio de testes para processos modernos do DevOps,
articule uma visão de qualidade. As equipes devem aderir aos princípios de teste a
seguir quando definem e implementam uma estratégia de teste do DevOps.

Desloque para a esquerda para testar antes

A execução dos testes pode ser demorada. Há um crescimento substancial de
quantidades e tipos de testes que acompanha a maior escala de projetos. Quando os
conjuntos de testes levam horas ou dias para serem concluídos, eles podem demorar
ainda mais até a execução no último momento. Você só percebe os benefícios da
qualidade de código de testes muito depois da confirmação do código.

Testes de longa duração também podem gerar falhas cuja investigação é demorada. As
equipes podem criar uma tolerância a falhas, em especial no início de sprints. Essa
tolerância destorce o valor de testes com insights sobre a qualidade da base de código.
Testes de longa duração e de última hora também agregam imprevisibilidade às
expectativas de fim de sprint porque um valor de dívida técnica desconhecido deve ser
pago para que o código seja enviável.

A meta do teste shift-left é mover a qualidade upstream ao executar tarefas de teste

antes no pipeline. Com uma combinação de aprimoramentos de teste e processo, o
shift-left reduz o tempo de execução de testes e o impacto de falhas posteriormente no
ciclo. Deslocar para a esquerda garante a conclusão da maioria dos testes antes que
uma alteração seja mesclada na ramificação principal.
Além de deslocar certas responsabilidades de teste para a esquerda para melhorar a
qualidade do código, as equipes podem deslocar outros aspectos de teste para a
direita, ou mais adiante no ciclo do DevOps, para aprimorar o produto final. Para saber
mais, confira Desloque para a direita para testar em produção.

Escreva testes no nível mais baixo possível

Escreva mais testes de unidade. Privilegie testes com o menor número de dependências
externas e concentre-se na execução da maioria dos testes como parte da compilação.
Considere um sistema de compilação paralela capaz de executar testes de unidade para
um assembly assim que o assembly e testes associados caem. Não é viável testar todos
os aspectos de um serviço nesse nível, mas o princípio aplicado é usar testes de unidade
mais leves quando conseguem gerar os mesmos resultados que testes funcionais mais
pesados.

Busque a confiabilidade de testes

É caro manter um teste não confiável em termos de organização Esse teste não
beneficia a meta de eficiência de engenharia, o que dificulta a tentativa de fazer
mudanças com confiança. Os desenvolvedores devem ser capazes de fazer alterações
em qualquer lugar, com a confiança de que nada foi interrompido. Mantenha um alto
nível de confiabilidade. Desestimule o uso de testes de interface de usuário porque eles
tendem a não ser confiáveis.
Escreva testes funcionais que possam ser executados em
qualquer lugar
Os testes podem usar pontos de integração especializados que visem especificamente
habilitar o teste. Uma das razões para essa prática é a falta de capacidade de teste no
próprio produto. Infelizmente, testes como esses costumam depender de conhecimento
interno e usam detalhes de implementação que não são relevantes de uma perspectiva
de teste funcional. Esses testes se limitam a ambientes com os segredos e a
configuração necessários para executar os testes, o que costuma excluir implantações
de produção. Os testes funcionais devem usar apenas a API pública do produto.

Projetar produtos para capacidade de teste

As organizações em um processo do DevOps em desenvolvimento têm uma visão
completa do significado de entregar um produto de qualidade em uma cadência da
nuvem. Mudar o saldo em favor do teste de unidade e não do teste funcional exige que
as equipes façam escolhas de design e implementação que sustentem a capacidade de
teste. Existem variadas ideias sobre o que constitui um código com projeto e
implementação adequados para ter estabilidade, assim como existem estilos de
codificação distintos. O princípio básico é que o projeto para ter capacidade de teste
deve se tornar parte principal da discussão sobre design e qualidade do código.

Tratar o código de teste como código do produto

Ao declarar explicitamente que o código de teste é o código do produto, você deixa
claro que as qualidades do código de teste e do código do produto são igualmente
importantes para o envio. As equipes devem dar tratamento igual ao código de teste e
ao código do produto, e ter o mesmo nível de cuidado na criação e na implementação
de testes e estruturas de teste. Esse esforço se assemelha ao gerenciamento de
configuração e infraestrutura como código. Para ser completa, uma revisão de código
deve considerar o código de teste e mantê-lo no mesmo nível de qualidade que o
código do produto.

Usar infraestrutura de teste compartilhada

Não seja tão exigente ao usar a infraestrutura de teste para gerar sinais de qualidade
confiáveis. Encare o teste como um serviço compartilhado para a equipe inteira.
Armazene o código de teste de unidade ao lado do código do produto e compile-o
com o produto. Os testes executados como parte do processo de compilação também
devem ser executados em ferramentas de desenvolvimento, como o Azure DevOps. Se
for possível executar os testes em todos os ambientes, desde o desenvolvimento local
até a produção, eles terão a mesma confiabilidade que o código do produto.

Torne os proprietários de código responsáveis pelos

testes
O código de teste deve residir ao lado do código do produto em um repositório. Para
que o código seja testado em um limite de componente, transfira a responsabilidade
pelo teste para a pessoa que está escrevendo o código do componente. Não confie em
outras pessoas para testar o componente.

Estudo de caso: deslocamento à esquerda com

testes de unidade
Uma equipe da Microsoft decidiu substituir os conjuntos de testes herdados por testes
de unidade modernos do DevOps e um processo de deslocamento à esquerda. A
equipe acompanhou o progresso em sprints trissemanais, conforme mostrado no
gráfico a seguir. O gráfico abrange os sprints 78-120, que representam 42 sprints em
126 semanas, ou em torno de dois anos e meio de esforço.

A equipe começou com 27.000 testes herdados no sprint 78, e atingiu zero testes
herdados em S120. Um conjunto de testes unitários L0 e L1 substituiu a maioria dos
testes funcionais anteriores. Novos testes L2 substituíram alguns dos testes, e muitos
dos testes antigos foram excluídos.

Em uma jornada de software que leva mais de dois anos para ser concluída, há muito o
que aprender no próprio processo. Em geral, o esforço para refazer totalmente o
sistema de teste em dois anos foi um investimento em massa. Nem todas as equipes de
recursos realizaram o trabalho simultaneamente. Muitas equipes na organização inteira
investiram tempo em cada sprint, e em alguns sprints, a equipe dedicou a maior parte
do tempo. Embora seja difícil medir o custo da mudança, este foi um requisito
inegociável para atingir as metas de qualidade e desempenho da equipe.

Introdução
No início, a equipe abandonou os antigos testes funcionais, chamados de testes TRA. A
equipe buscava a adesão de desenvolvedores à ideia de escrever testes de unidade,
especialmente para novos recursos. O foco era facilitar ao máximo a realização de testes
L0 e L1. A equipe precisava desenvolver essa capacidade primeiro e ganhar força.

O gráfico anterior mostra que houve um aumento precoce na contagem de testes de

unidade, pois a equipe percebeu o benefício de criar testes de unidade. Era fácil manter
e mais rápido de executar testes de unidade, e eles tinham menos falhas. Foi fácil obter
suporte para executar todos os testes de unidade no fluxo de solicitação de pull.

A equipe não se concentrou em escrever novos testes L2 até o sprint 101. Enquanto
isso, a contagem de testes TRA caiu de 27.000 para 14.000 do Sprint 78 para o Sprint
101. Novos testes de unidade substituíram alguns dos testes TRA, mas muitos foram
excluídos, com base na análise da equipe sobre sua utilidade.

Os testes TRA saltaram de 2100 para 3800 no sprint 110 porque foram descobertos mais
testes na árvore de origem e eles adicionados ao gráfico. Perceberam que os testes
sempre funcionavam, mas eram rastreados incorretamente. Não foi uma crise, mas era
importante ser honesto e reavaliar conforme necessário.

Como agilizar processos

Assim que a equipe obteve um sinal de integração contínua (CI) extremamente rápido e
confiável, ele se tornou um indicador confiável da qualidade do produto. A captura de
tela a seguir mostra a solicitação de pull e o pipeline de CI em ação, e o tempo
necessário para passar por várias fases.
Leva cerca de 30 minutos para passar da solicitação de pull para a mesclagem, incluindo
a execução de 60.000 testes de unidade. Da mesclagem de código até a compilação de
CI leva em torno de 22 minutos. O primeiro sinal de qualidade da CI, SelfTest, vem
depois de cerca de uma hora. A maioria dos produtos são testados com a alteração
proposta. Duas horas após a migração para o SelfHost, todo o produto é testado e a
alteração está pronta para entrar em produção.

Usando métricas
A equipe acompanha um scorecard como o exemplo a seguir. Em alto nível, o scorecard
rastreia dois tipos de métricas: saúde ou dívida e velocidade.

Para métricas de integridade do site em tempo real, a equipe controla o tempo para
detectar, o tempo para mitigar e o número de itens de reparo carregado por uma
equipe. Um item de reparo é o trabalho que a equipe identifica em uma retrospectiva
de site ao vivo para evitar que ocorram incidentes similares. O scorecard também
rastreia se as equipes estão fechando os itens de reparo em um prazo razoável.

Para métricas de integridade de engenharia, a equipe rastreia bugs ativos por

desenvolvedor. Se uma equipe tiver mais de cinco bugs por desenvolvedor, ela deverá
priorizar a correção desses bugs antes do desenvolvimento de novos recursos. A equipe
também rastreia bugs antigos em categorias especiais, como segurança.

As métricas de velocidade de engenharia medem a velocidade em partes distintas do

pipeline de integração e entrega contínuas (CI/CD). O objetivo geral é aumentar a
velocidade do pipeline do DevOps: partir de uma ideia, colocar o código em produção e
receber o retorno de dados de clientes.
Próximas etapas
Roteiro de aprendizagem: Crie aplicações com o Azure DevOps
Use a integração contínua
Desloque para a direita para testar na produção
Simulações não são stubs
Como a Microsoft faz desenvolvimento
com DevOps
Artigo • 05/10/2023

A Microsoft busca usar o One Engineering System para criar e implantar todos os
produtos da Microsoft com um forte processo de DevOps centrado em um fluxo de
lançamento e branch do Git. Este artigo destaca a implementação prática, como o
sistema é escalado desde pequenos serviços até grandes necessidades de
desenvolvimento de plataforma e lições aprendidas com o uso do sistema em várias
equipes da Microsoft.

Adotar um processo de desenvolvimento padronizado é uma tarefa ambiciosa. Os

requisitos de diferentes organizações da Microsoft variam muito, e os requisitos de
diferentes equipes dentro das organizações são escalados com tamanho e
complexidade. Para atender a essas várias necessidades, a Microsoft usa uma estratégia
de branch baseada em tronco para ajudar a desenvolver produtos com rapidez,
implantá-los com regularidade e enviar alterações com segurança à produção.

Fluxo de lançamento da Microsoft

Todas as organizações devem estabelecer um processo de lançamento de código
padrão para garantir a consistência entre as equipes. O fluxo de lançamento da
Microsoft incorpora processos de DevOps desde o desenvolvimento até o lançamento.
As etapas básicas do fluxo de lançamento consistem em branch, transmissão, solicitação
de pull e mesclagem.

Branch
Para corrigir um bug ou implementar um recurso, um desenvolvedor cria um novo
branch fora do branch de integração principal. O modelo de branch leve do Git cria
esses branches de tópico de curta duração para cada contribuição de código. Os
desenvolvedores se comprometem antecipadamente e evitam branches de recursos de
execução prolongada usando sinalizadores de recursos.

Push
Quando o desenvolvedor estiver pronto para integrar e enviar alterações ao restante da
equipe, ele enviará o branch local para um branch no servidor e abrirá uma solicitação
de pull. Repositórios com várias centenas de desenvolvedores trabalhando em muitos
branches usam uma convenção de nomenclatura para branches de servidor a fim de
evitar confusões e a proliferação de branches. Os desenvolvedores geralmente criam
branches chamados users/<username>/feature , em que <username> é o nome da conta.

Solicitação de pull
O branch de tópico do controle de solicitações pull é mesclado no branch principal e
garante que as políticas de branch sejam seguidas. O processo de solicitação de pull cria
as alterações propostas e executa uma aprovação de teste rápido. Os conjuntos de
testes de nível primário e secundário executam cerca de 60.000 testes em menos de
cinco minutos. Essa não é a matriz de teste completa da Microsoft, mas é suficiente para
oferecer confiança rapidamente às solicitações pull.

Em seguida, outros membros da equipe revisam o código e aprovam as alterações. A

revisão de código continua de onde os testes automatizados pararam e é útil
principalmente para detectar problemas de arquitetura. As revisões manuais de código
garantem que outros engenheiros da equipe tenham visibilidade das alterações e que a
qualidade do código permaneça alta.

Mesclar
Depois que a solicitação de pull seguir todas as políticas de compilação e os revisores
aprovarem, o branch de tópico será mesclado no branch de integração principal e a
solicitação de pull será concluída.

Após a mesclagem, outros testes de aceitação são executados e levam mais tempo para
serem concluídos. Esses testes pós-verificação tradicionais fazem uma validação mais
completa. Esse processo de teste oferece um bom equilíbrio entre ter testes rápidos
durante a revisão de solicitação de pull e ter cobertura completa do teste antes do
lançamento.

Diferenças do GitHub Flow

O GitHub Flow é um popular fluxo de lançamento de desenvolvimento para que as
organizações implementem uma abordagem escalável ao Git. No entanto, algumas
organizações acreditam que, à medida que suas necessidades aumentam, elas devem
divergir de partes do GitHub Flow.

Por exemplo, uma parte muitas vezes negligenciada do Flow GitHub é que as
solicitações pull devem ser implantadas na produção para teste para que possam ser
mescladas com o branch principal. Esse processo significa que todas as solicitações pull
aguardam na fila de implantação para mesclagem.

Algumas equipes têm várias centenas de desenvolvedores trabalhando constantemente

em um único repositório, que podem concluir mais de 200 solicitações pull para o
branch principal por dia. Se cada solicitação de pull exigir uma implantação em vários
datacenters do Azure em todo o mundo para teste, os desenvolvedores gastam tempo
esperando que os branches sejam mesclados, em vez de criar softwares.

Em vez disso, as equipes da Microsoft continuam desenvolvendo no branch principal e

agrupam implantações em lotes em versões periódicas, geralmente alinhadas com uma
cadência de sprint de três semanas.

Detalhes de implementação
Veja a seguir alguns dos principais detalhes de implementação do fluxo de lançamento
da Microsoft:

Estratégia de repositório Git

Diferentes equipes têm estratégias diferentes para gerenciar seus repositórios Git.
Algumas equipes mantêm a maior parte de seu código em um repositório Git. O código
é dividido em componentes, cada um em sua própria pasta de nível raiz. Componentes
grandes, principalmente componentes mais antigos, podem ter vários subcomponentes
que têm subpastas diferentes dentro do componente pai.
Repositórios suplementares
Algumas equipes também gerenciam repositórios suplementares. Por exemplo
agentes e tarefas de compilação e lançamento, a extensão do VS Code e projetos
de código aberto são desenvolvidos no GitHub. Alterações de configuração são
armazenadas em um repositório diferente. Outros pacotes dos quais a equipe depende
vêm de outros lugares e são consumidos via NuGet.

Repositórios únicos ou múltiplos

Embora algumas equipes optem por ter um único repositório monolítico, o repositório
único, outros produtos da Microsoft usam uma abordagem de vários repositórios. O
Skype, por exemplo, tem centenas de pequenos repositórios que se agrupam em várias
combinações para criar muitos clientes, serviços e ferramentas diferentes.
Principalmente para equipes que adotam microsserviços, os repositórios múltiplos
podem ser a abordagem certa. Normalmente, os produtos mais antigos que começaram
como monólitos acreditam que uma abordagem de repositório único é a transição mais
fácil para o Git, e sua organização de código reflete isso.
Branches de lançamento
O fluxo de lançamento da Microsoft mantém o branch principal sempre compilável. Os
desenvolvedores trabalham em branches de tópicos de curta duração que são
mescladas em main . Quando uma equipe está pronta para o envio, seja no final de um
sprint ou para uma grande atualização, ela inicia um novo branch de lançamento fora
do principal. Os branches de lançamento nunca são mescladas no branch principal
novamente, portanto, podem exigir alterações importantes de cherry-picking.

O diagrama a seguir mostra branches de curta duração em azul e branches de

lançamento em preto. Um branch com um commit que precisa do recurso de cherry-
picking é exibido em vermelho.

Políticas e permissões de branch

As políticas de branch do Git ajudam a aplicar a estrutura de branch de lançamento e
manter o branch principal limpo. Por exemplo, as políticas de branch podem impedir
transmissões diretas para o branch principal.

Para manter a hierarquia de branch organizada, as equipes usam permissões para

bloquear a criação de branches no nível raiz da hierarquia. No exemplo a seguir, todos
podem criar branches em pastas como users/, features/ e teams/. Somente os gerentes
de lançamento têm permissão para criar branches em releases/, e algumas ferramentas
de automação têm permissão para a pasta integrations/.
Fluxo de trabalho do repositório Git
Dentro da estrutura do repositório e branch, os desenvolvedores fazem seu trabalho
diário. Os ambientes de trabalho variam muito de acordo com a equipe e a pessoa.
Alguns desenvolvedores preferem a linha de comando, outros gostam do Visual Studio,
e outros trabalham em plataformas diferentes. As estruturas e políticas em vigor nos
repositórios da Microsoft garantem uma base sólida e consistente.

Um fluxo de trabalho típico envolve as seguintes tarefas comuns:

Criar um novo recurso

Criar um novo recurso é o núcleo do trabalho de um desenvolvedor de software. Partes
que não são do Git do processo incluem examinar dados de telemetria, criar um
esquema e uma especificação e escrever o código em si. Em seguida, o desenvolvedor
começa a trabalhar com o repositório sincronizando com o commit mais recente em
main . O branch principal é sempre compilável, por isso, com certeza é um bom ponto

de partida. O desenvolvedor verifica um novo branch de recurso, faz alterações de

código, confirma, transmite para o servidor e inicia uma nova solicitação de pull.

Usar políticas e verificações de branch

Após a criação de uma solicitação de pull, os sistemas automatizados verificam se o
novo código é compilado, não quebra nada e não viola nenhuma política de segurança
ou conformidade. Esse processo não impede que outros trabalhos ocorram em paralelo.

As políticas e verificações de branch podem exigir uma compilação bem-sucedida

incluindo aprovação nos testes, aprovação dos proprietários e qualquer código alterado,
várias verificações externas para verificar políticas corporativas antes que uma
solicitação de pull possa ser concluída.
Integrar com o Microsoft Teams
Muitas equipes configuram a integração com o Microsoft Teams , que anuncia a nova
solicitação de pull para os colegas de equipe dos desenvolvedores. Os proprietários de
qualquer código alterado são automaticamente adicionados como revisores. As equipes
da Microsoft geralmente usam revisores opcionais para códigos que muitas pessoas
alteram, como a geração de cliente REST e controles compartilhados, para que
profissionais especializados analisem essas alterações.
Implantar com sinalizadores de recursos
Depois que os revisores, os proprietários de código e a automação estiverem satisfeitos,
o desenvolvedor poderá concluir a solicitação de pull. Se houver um conflito de
mesclagem, o desenvolvedor receberá instruções sobre como sincronizar com o
conflito, corrigi-lo e transmitir novamente as alterações. A automação é executada
novamente no código fixo, mas uma pessoa não precisa aprovar novamente.

O branch é mesclado em main , e o novo código é implantado no próxima sprint ou

lançamento principal. Isso não significa que o novo recurso será exibido imediatamente.
A Microsoft dissocia a implantação e a exposição de novos recursos usando
sinalizadores de recursos.

Mesmo que o recurso precise de um pouco mais de trabalho para estar pronto para ser
exibido, é seguro acessar main se o produto for compilado e implantado. Uma vez em
main , o código se torna parte de uma compilação oficial, onde é novamente testado,

confirmado para atender à política e assinado digitalmente.

Shift left para detectar problemas com antecedência

Esse fluxo de trabalho do Git oferece vários benefícios. Em primeiro lugar, trabalhar a
partir de um único branch principal praticamente elimina o custo de mesclagem . Em
segundo lugar, o fluxo de solicitação de pull fornece um ponto comum para aplicar
testes, revisão de código e detecção de erros no início do pipeline. Essa estratégia shift
left ajuda a encurtar o ciclo de feedback para os desenvolvedores porque pode detectar
erros em minutos, não em horas ou dias. Essa estratégia também dá confiança para a
refatoração, pois todas as alterações são testadas constantemente.
Atualmente, um produto com mais de 200 solicitações pull pode produzir mais de 300
compilações de integração contínua por dia, totalizando mais de 500 execuções de teste
a cada 24 horas. Esse nível de teste seria impossível sem o fluxo de trabalho de branch e
lançamento baseado em tronco.

Lançamento em marcos de sprint

No final de cada sprint, a equipe cria um branch de lançamento o branch principal. Por
exemplo, no final do sprint 129, a equipe cria um novo branch de lançamento
releases/M129 . Depois, a equipe coloca o branch do sprint 129 em produção.

Após o branch do branch de lançamento, o principal permanece aberta para os

desenvolvedores mesclarem alterações. Essas alterações serão implantadas três semanas
depois na próxima implantação do sprint.

Hotfixes de lançamento
Às vezes, as alterações precisam ser enviadas para produção rapidamente. A Microsoft
geralmente não adiciona novos recursos no meio de um sprint, mas às vezes deseja
lançar uma correção de bug rapidamente para desbloquear os usuários. Os problemas
podem ser menores, como erros de digitação, ou grandes o suficiente para causar um
problema de disponibilidade ou incidente no site ativo.

A correção desses problemas começa com o fluxo de trabalho normal. Um

desenvolvedor cria um branch de main , tem o código revisado e conclui a solicitação de
pull para mesclá-la. O processo sempre começa com fazer a alteração em main
primeiro. Isso permite criar a correção com rapidez e validá-la localmente sem ter que
alternar para o branch de lançamento.

Seguir esse processo também garante que a alteração entre em main , o que é
fundamental. Corrigir um bug no branch de lançamento sem trazer a alteração de volta
para main implicaria na repetição do bug durante a próxima implantação, quando o
lançamento do sprint 130 se ramifica de main . É fácil esquecer de atualizar main durante
a confusão e o estresse que podem surgir durante uma interrupção. Trazer mudanças
para main primeiro faz com que as alterações sempre estejam tanto no branch principal
quanto na de lançamento.
A funcionalidade do Git habilita esse fluxo de trabalho. Para enviar as alterações
imediatamente à produção, depois que um desenvolvedor mesclar uma solicitação de
pull em main , poderá usar a página de solicitação de pull para fazer cherry-picking das
alterações no branch de lançamento. Esse processo cria uma nova solicitação de pull
direcionada ao branch de lançamento, fazendo o backporting do conteúdo que acabou
de ser mesclado em main .

O uso da funcionalidade de cherry-picking abre uma solicitação de pull rapidamente,

fornecendo a rastreabilidade e a confiabilidade das políticas de branch. O cherry-picking
pode ocorrer no servidor, sem a necessidade de baixar o branch de lançamento para um
computador local. Fazer alterações, corrigir conflitos de mesclagem ou fazer pequenas
alterações devido a diferenças entre os dois branches são ações que podem ocorrer no
servidor. As equipes podem editar alterações diretamente no editor de texto baseado
no navegador ou por meio da Extensão de Conflito de Mesclagem de Solicitação de
Pull para uma experiência mais avançada.

Depois que uma solicitação de pull tem como alvo o branch de lançamento, o código
da equipe a revisa novamente, avalia as políticas de branch, testa a solicitação de pull e
a mescla. Após a mesclagem, a correção é implantada no primeiro anel de servidores
em minutos. A partir daí, a equipe implanta gradativamente a correção em mais contas
usando anéis de implantação. À medida que as alterações são implantadas para mais
usuários, a equipe monitora o sucesso e verifica se a alteração corrige o bug, sem
introduzir deficiências ou lentidão. A correção eventualmente é implantada em todos os
datacenters do Azure.

Passar para o próximo sprint

Durante as próximas três semanas, a equipe termina de adicionar recursos ao sprint 130
e se prepara para implantar essas alterações. Os membros criam o novo branch de
lançamento, releases/M130 de main , e implantam esse branch.

Nesse momento, na verdade existem dois branches em produção. Com uma

implantação baseada em anel para enviar alterações à produção com segurança, o
anel rápido recebe as alterações do sprint 130 e os servidores de anel lentos
permanecem no sprint 129 enquanto as novas alterações são validadas em produção.
Corrigir uma alteração no meio de uma implantação pode exigir o hotfix de dois
lançamentos diferentes: do sprint 129 e do sprint 130. A equipe faz a portabilidade e
implanta o hotfix em ambos os branches de lançamento. O branch 130 é implantado
novamente com o hotfix para os anéis que já foram atualizados. O branch 129 é
implantado novamente com o hotfix para os anéis externos que ainda não foram
atualizados para o lançamento do próximo sprint.

Depois que todos os anéis são implantados, o antigo branch do sprint 129 é
abandonado, porque qualquer alteração trazida para o branch do sprint 129 como um
hotfix também foi feita em main . Portanto, essas alterações também estarão no branch
releases/M130 .

Resumo
O modelo de fluxo de lançamento é fundamental na forma como a Microsoft
desenvolve com DevOps para fornecer serviços online. Esse modelo usa uma estratégia
de branch simples, baseada em tronco. Porém, em vez de manter os desenvolvedores
presos em uma fila de implantação, esperando para mesclar suas alterações, o fluxo de
lançamento da Microsoft permite que os desenvolvedores continuem trabalhando.

Esse modelo de lançamento também permite implantar novos recursos em datacenters

do Azure em uma cadência regular, apesar do tamanho das bases de código da
Microsoft e do número de desenvolvedores trabalhando nelas. O modelo também
permite enviar os hotfixes à produção com rapidez e eficiência.
Introdução ao fornecimento de serviços
de qualidade com DevOps
Artigo • 05/10/2023

Na fase de entrega do DevOps, o código se move pelo pipeline de lançamento até o

ambiente de produção. A entrega de código normalmente vem após a compilação da
integração contínua e é executada em vários ambientes de teste antes de chegar aos
usuários finais. Ao longo do caminho, sua qualidade é testada em muitas medidas
diferentes que incluem funcionalidade, escala e segurança.

Implementar a entrega contínua

Entrega contínua (CD) é o processo de compilar, testar, configurar e implantar
automaticamente de um ambiente de build para um ambiente de produção. A CD
fornece a base para entrega no DevOps no qual os testes são executados, os portões
são verificados e os bits são implantados. Há diversas plataformas de DevOps diferentes
que oferecem automação de entrega, incluindo o GitHub Actions e o Azure
Pipelines .

Design para implantação ideal

À medida que os projetos de software crescem, eles podem se tornar difíceis de
gerenciar entre equipes, versões e ambientes. Felizmente, vários paradigmas estão
disponíveis para ajudar a enfrentar esses desafios. Um paradigma é o advento da
arquitetura de microsserviços, que facilita a criação e a implantação de serviços
independentes que podem ser compostos por aplicativos maiores e mais sustentáveis.
Outra prática para auxiliar na implantação de serviços é gerenciar seus ambientes de
aplicativos como Infraestrutura como Código.

Deslocar para a direita para testar na produção

A fase Desenvolver mostrou como a qualidade e a velocidade do projeto podem ser
melhoradas ao deslocar para a esquerda para que alguns aspectos do teste sejam
realizados mais cedo no processo. Da mesma forma, a qualidade do produto pode ser
melhorada com um foco sustentado na no deslocamento para a direita do teste na
produção. Os testes em produção oferecem garantia de qualidade que simplesmente
não pode ser replicada em nenhum outro lugar do pipeline.

Próximas etapas
A Microsoft é uma das maiores empresas de desenvolvimento de software do mundo
há décadas. Saiba mais sobre como a Microsoft presta serviços em DevOps.

Procurando uma experiência prática de DevOps com entrega contínua? Aprenda a

configurar pipelines de lançamento usando o GitHub Actions ou o Azure Pipelines.
O que é a entrega contínua?
Artigo • 05/10/2023

Continuamente, a entrega de valor tornou-se um requisito obrigatório para as

organizações. Para entregar valor aos usuários finais, você deve liberar continuamente e
sem erros.

Entrega contínua (CD) é o processo de compilar, testar, configurar e implantar

automaticamente de um ambiente de build para um ambiente de produção. Um
pipeline de lançamento pode criar vários ambientes de teste ou preparo para
automatizar a criação da infraestrutura e a implantação de novas compilações.
Ambientes sucessivos suportam atividades progressivamente mais longas de integração,
carga e testes de aceitação do usuário.

Antes da CD, os ciclos de lançamento de software eram um gargalo para as equipes de

aplicativos e operações. Essas equipes geralmente dependiam de transferências
manuais que resultavam em problemas durante os ciclos de lançamento. Processos
manuais levaram a lançamentos não confiáveis que produziram atrasos e erros.

A CD é uma prática enxuta, com o objetivo de manter a produção atualizada com o

caminho mais rápido desde a disponibilidade de novos códigos ou componentes até a
implantação. A automação minimiza o tempo de implantação e o tempo de mitigação
(TTM) ou o tempo de correção (TTR) de incidentes de produção. Em termos enxutos, a
CD otimiza o tempo do processo e elimina o tempo ocioso.

A integração contínua (CI) inicia o processo de CD. O pipeline de lançamento prepara

cada ambiente sucessivo para o próximo ambiente após a conclusão bem-sucedida dos
testes. O pipeline de lançamento da CD automatizada permite uma abordagem fail-fast
à validação, em que os testes com maior probabilidade de falhar são executados
rapidamente primeiro, e os testes de execução mais longa acontecem somente depois
que os mais rápidos são concluídos com êxito.

As práticas complementares de infraestrutura como código (IaC) e monitoramento

facilitam a CD.

Técnicas de exposição progressiva

A CD suporta vários padrões de exposição progressiva, também chamados de "controle
do raio de explosão". Essas práticas limitam a exposição a implantações para evitar o
risco de problemas com a base geral de usuários.

A CD pode sequenciar vários anéis de implantação para exposição progressiva. Um

anel tenta uma implantação em um grupo de usuários e monitora sua
experiência. O primeiro anel de implantação pode ser um canário para testar novas
versões em produção antes de uma distribuição mais ampla. A CD automatiza a
implantação de um anel para o outro.

A implantação no próximo anel pode depender opcionalmente de uma etapa de

aprovação manual, em que um tomador de decisão aprova as alterações
eletronicamente. A CD pode criar um registro auditável da aprovação para
satisfazer procedimentos regulatórios ou outros objetivos de controle.

A implantação azul/verde depende de manter uma versão azul atual ativa

enquanto uma nova versão verde é implantada. Essa prática normalmente usa o
balanceamento de carga para direcionar o crescente aumento de tráfego à
implantação verde. Se o monitoramento descobrir um incidente, o tráfego pode
ser redirecionado para a implantação azul ainda em execução.

Os sinalizadores de recursos ou alternâncias de recursos são outra técnica para

experimentação e inicializações escuras. Os sinalizadores de recursos ativam ou
desativam recursos para grupos de usuários diferentes de acordo com a
identidade e associação ao grupo.

Os pipelines de versão modernos permitem que as equipes de desenvolvimento

implantem novos recursos de forma rápida e segura. A CD pode corrigir rapidamente os
problemas encontrados na produção avançando com uma nova implantação. Dessa
forma, a CD cria um fluxo contínuo de valor para o cliente.

Próximas etapas
GitHub Actions
Azure Pipelines
Documentação do Azure Pipelines
O que é a IaC (infraestrutura como
código)?.
Artigo • 05/10/2023

A infraestrutura como código (IaC) usa a metodologia de DevOps e o controle de versão

com um modelo descritivo para definir e implantar a infraestrutura, como redes,
máquinas virtuais, balanceadores de carga e topologias de conexão. Assim como o
mesmo código-fonte sempre gera o mesmo binário, um modelo IaC gera o mesmo
ambiente sempre que ele é implantado.

A IaC é uma prática-chave de DevOps e um componente de entrega contínua. Com a

IaC, as equipes de DevOps podem trabalhar com um conjunto unificado de práticas e
ferramentas para fornecer aplicativos e sua infraestrutura de suporte de forma rápida e
confiável em escala.

Evitar configuração manual para impor

consistência
A IaC evoluiu para resolver o problema de descompasso de ambiente nos pipelines de
lançamento. Sem a IaC, as equipes precisam manter as configurações dos ambientes de
implantação de forma individual. Ao longo do tempo, cada ambiente torna-se um "floco
de neve", ou seja, uma configuração exclusiva que não pode ser reproduzida
automaticamente. A inconsistência entre ambientes pode causar problemas de
implantação. A administração e a manutenção da infraestrutura envolvem processos
manuais propensos a erros e difíceis de rastrear.
A IaC evita configuração manual e impõe consistência representando os estados de
ambiente desejados por meio de código bem documentado em formatos como JSON.
As implantações de infraestrutura com IaC são repetíveis e evitam problemas de tempo
de execução causados por descompasso de configuração ou dependências ausentes. Os
pipelines de lançamento executam as descrições do ambiente e os modelos de
configuração de versão para configurar os ambientes de destino. Para fazer alterações, a
equipe edita a origem, não o destino.

A idempotência, a capacidade de uma determinada operação produzir sempre o mesmo

resultado, é um importante princípio da IaC. Um comando de implantação sempre
define o ambiente de destino na mesma configuração, independentemente do estado
inicial do ambiente. A idempotência é alcançada configurando automaticamente o
destino existente ou descartando o destino existente e recriando um novo ambiente.

Ferramentas úteis
Descobrir configurações incorretas na IaC com o Microsoft Defender para Nuvem

Fornecer ambientes de teste estáveis

rapidamente em escala
A IaC ajuda as equipes de DevOps a testar aplicativos em ambientes semelhantes aos de
produção no início do ciclo de desenvolvimento. As equipes podem provisionar vários
ambientes de teste de forma confiável sob demanda. A nuvem provisiona e destrói
dinamicamente ambientes com base em definições da IaC. O próprio código de
infraestrutura pode ser validado e testado para evitar problemas comuns de
implantação.

Usar arquivos de definição declarativa

A IaC deve usar arquivos de definição declarativa, se possível. Um arquivo de definição
descreve os componentes e a configuração que um ambiente requer, mas não
necessariamente como obter essa configuração. Por exemplo, o arquivo pode definir
uma versão e configuração de servidor necessárias, mas não especificar o processo de
instalação e configuração do servidor. Essa abstração permite maior flexibilidade para
usar técnicas otimizadas fornecidas pelo provedor de infraestrutura. As definições
declarativas também ajudam a reduzir a dívida técnica de manter o código imperativo,
como scripts de implantação, que pode se acumular ao longo do tempo.
Não há uma sintaxe padrão para a IaC declarativa. A sintaxe para descrever a IaC
geralmente depende dos requisitos da plataforma de destino. Diferentes plataformas
suportam formatos de arquivo como YAML, JSON e XML.

Implantar a IaC no Azure

O Azure fornece suporte nativo para a IaC por meio do modelo do Gerenciador de
Recursos do Azure. As equipes podem definir modelos de ARM declarativos que
especificam a infraestrutura necessária para implantar soluções.

Plataformas de terceiros como Terraform, Ansible, Chef e Pulumi também oferecem

suporte à IaC para gerenciar a infraestrutura automatizada.
Implantar na infraestrutura do Azure
com o GitHub Actions
Artigo • 05/10/2023

Neste guia, abordaremos como utilizar CI/CD e Infraestrutura como Código (IaC) para
implantar no Azure com o GitHub Actions de forma automatizada e repetível.

Este artigo é uma visão geral da arquitetura e apresenta uma solução estruturada para
projetar um aplicativo no Azure que seja escalonável, seguro, resiliente e altamente
disponível. Para ver mais exemplos reais de arquiteturas de nuvem e ideias de soluções,
navegue pelas arquiteturas do Azure.

Benefícios do uso de IaC e automação para

implantações
Há muitas maneiras de implantar no Azure, incluindo o portal do Azure, CLI, API e muito
mais. Para este guia, usaremos a automação de IaC e CI/CD. Entre os benefícios dessa
abordagem estão:

Declarativo: quando você define sua infraestrutura e processo de implantação no

código, ele pode ser versionado e revisado usando o ciclo de vida de
desenvolvimento de software padrão. A IaC também ajuda a evitar qualquer
descompasso na sua configuração.

Consistência: seguir um processo de IaC garante que toda a organização siga um

método padrão e bem estabelecido para implantar uma infraestrutura que
incorpore as práticas recomendadas e seja reforçada para atender às suas
necessidades de segurança. Quaisquer melhorias feitas nos modelos centrais
podem ser facilmente aplicadas em toda a organização.

Segurança: os modelos gerenciados centralmente podem ser reforçados e

aprovados por uma equipe de operações ou segurança na nuvem para atender
aos padrões internos.

Autoatendimento: as equipes podem ser capacitadas para implantar sua própria

infraestrutura utilizando modelos gerenciados centralmente.

Produtividade aprimorada: ao utilizar modelos padrão, as equipes podem

provisionar rapidamente novos ambientes sem precisar se preocupar com todos
os detalhes da implementação.
Mais informações podem ser encontradas em infraestrutura repetível no Centro de
Arquitetura do Azure ou em o que é infraestrutura como código na Central de Recursos
de DevOps.

Arquitetura

Fluxo de dados
1. Crie uma nova filial e verifique as modificações de código da IaC necessárias.
2. Crie uma solicitação de transferência (PR) no GitHub quando estiver tudo pronto
para mesclar suas alterações em seu ambiente.
3. Um fluxo de trabalho do GitHub Actions será acionado para garantir que seu
código esteja bem formatado, internamente consistente e produza uma
infraestrutura segura. Além disso, uma análise hipotética do Plano do Terraform ou
do Bicep será executada para gerar uma visualização das alterações que
acontecerão em seu ambiente do Azure.
4. Uma vez devidamente revisada, a PR pode ser mesclada em sua filial principal.
5. Outro fluxo de trabalho do GitHub Actions será acionado a partir da filial principal
e executará as alterações usando seu provedor de IaC.
6. (exclusivo para Terraform) Um fluxo de trabalho do GitHub Actions agendado
regularmente também deve ser executado para procurar qualquer descompasso
na configuração em seu ambiente e criar um novo problema se forem detectadas
alterações.

Pré-requisitos

Usar o Bicep
1. Criar ambientes no GitHub

Os fluxos de trabalho utilizam ambientes e segredos do GitHub para armazenar as

informações de identidade do Azure e configurar um processo de aprovação para
implantações. Crie um ambiente denominado production seguindo estas
instruções . No production ambiente, configure uma regra de proteção e
adicione os aprovadores necessários desejados que precisam aprovar
implantações de produção. Você também pode limitar o ambiente à sua filial
principal. As instruções detalhadas são encontradas aqui .

2. Configurar a Identidade do Azure:

É necessário um aplicativo do Active Directory do Azure que tenha permissões

para implantar em sua assinatura do Azure. Crie um único aplicativo e conceda a
ele as permissões de leitura/gravação apropriadas em sua assinatura do Azure. Em
seguida, configure as credenciais federadas para permitir que o GitHub utilize a
identidade usando o OpenID Connect (OIDC). Consulte a documentação do Azure
para obter instruções detalhadas. Três credenciais federadas precisarão ser
adicionadas:

Defina Tipo de Entidade como Environment e use o production nome do

ambiente.
Defina Tipo de Entidade como Pull Request .
Defina Tipo de Entidade como Branch e use o main nome da filial.

3. Adicionar segredos do GitHub

７ Observação

Embora nenhum dos dados sobre as identidades do Azure contenha segredos

ou credenciais, ainda utilizamos segredos do GitHub como um meio
conveniente de parametrizar as informações de identidade por ambiente.

Crie os seguintes segredos no repositório usando a identidade do Azure:

AZURE_CLIENT_ID : ID do aplicativo (cliente) do registro de aplicativo no Azure

AZURE_TENANT_ID : ID do locatário do Active Directory do Azure onde o

registro do aplicativo é definido.

AZURE_SUBSCRIPTION_ID : ID da assinatura onde o registro do aplicativo é

definido.
 As instruções para adicionar os segredos ao repositório podem ser encontradas
aqui .

Usar o Terraform
1. Configurar o Local do Estado do Terraform

O Terraform utiliza um arquivo de estado para armazenar informações sobre o

estado atual da infraestrutura gerenciada e a configuração associada. Esse arquivo
precisará de persistência entre diferentes execuções do fluxo de trabalho. A
abordagem recomendada é armazenar esse arquivo em uma Conta de
Armazenamento do Azure ou em outro back-end remoto semelhante.
Normalmente, esse armazenamento seria provisionado manualmente ou por meio
de um fluxo de trabalho separado. O bloco de back-end do Terraform precisará
ser atualizado com o local de armazenamento selecionado (consulte aqui a
documentação).

2. Criar um ambiente no GitHub

Os fluxos de trabalho utilizam ambientes e segredos do GitHub para armazenar as

informações de identidade do Azure e configurar um processo de aprovação para
implantações. Crie um ambiente denominado production seguindo estas
instruções . No production ambiente, configure uma regra de proteção e
adicione os aprovadores necessários desejados que precisam aprovar
implantações de produção. Você também pode limitar o ambiente à sua filial
principal. As instruções detalhadas são encontradas aqui .

3. Configurar a Identidade do Azure:

É necessário um aplicativo do Active Directory do Azure que tenha permissões

para implantar em sua assinatura do Azure. Crie um aplicativo separado para as
contas read-only e read/write e dê a elas as permissões apropriadas em sua
assinatura do Azure. Além disso, ambas as funções também precisarão de pelo
menos Reader and Data Access permissões para a conta de armazenamento onde
reside o estado do Terraform da etapa 1. Em seguida, configure as credenciais
federadas para permitir que o GitHub utilize a identidade usando o OpenID
Connect (OIDC). Consulte a documentação do Azure para obter instruções
detalhadas.

Para a identidade read/write , crie uma credencial federada da seguinte maneira:

Defina Entity Type e Environment e use o production nome do ambiente.

 Para a identidade read-only , crie duas credenciais federadas da seguinte maneira:

Defina Entity Type como Pull Request .

Defina Entity Type e Branch e use o main nome da filial.

4. Adicionar segredos do GitHub

７ Observação

Embora nenhum dos dados sobre as identidades do Azure contenha segredos

ou credenciais, ainda utilizamos segredos do GitHub como um meio
conveniente de parametrizar as informações de identidade por ambiente.

Crie os seguintes segredos no repositório usando a identidade read-only :

AZURE_CLIENT_ID : ID do aplicativo (cliente) do registro de aplicativo no Azure

AZURE_TENANT_ID : ID do locatário do Active Directory do Azure onde o

registro do aplicativo é definido.

AZURE_SUBSCRIPTION_ID : ID da assinatura onde o registro do aplicativo é

definido.

As instruções para adicionar os segredos ao repositório podem ser encontradas

aqui .

Crie outro segredo no ambiente production usando a identidade read-write :

AZURE_CLIENT_ID : ID do aplicativo (cliente) do registro de aplicativo no Azure

As instruções para adicionar os segredos ao ambiente podem ser encontradas

aqui . O segredo do ambiente substituirá o segredo do repositório ao executar a
etapa de implantação no ambiente production quando permissões elevadas de
leitura/gravação forem necessárias.

Implantar com ações do GitHub

Usar o Bicep
Há dois fluxos de trabalho principais incluídos na arquitetura de referência :

1. Testes de Unidades do Bicep

 Esse fluxo de trabalho é executado em cada confirmação e é composto por um
conjunto de testes de unidade no código de infraestrutura. Ele executa a
compilação do bicep para compilar o bicep em um modelo de ARM. Isso garante
que não haja erros de formatação. Em seguida, ele executa uma validação para
garantir que o modelo seja implantável. Por fim, o checkov , uma ferramenta de
análise de código estático de código aberto para IaC, será executado para detectar
problemas de segurança e conformidade. Se o repositório estiver utilizando o
GitHub Advanced Security (GHAS), os resultados serão carregados no GitHub.

2. Implantação / Hipóteses do Bicep

Esse fluxo de trabalho é executado em cada solicitação de pull e em cada

confirmação na filial principal. O estágio hipotético do fluxo de trabalho é usado
para entender o impacto das alterações da IaC no ambiente do Azure executando
hipóteses. Este relatório é então anexado à PR para facilitar a revisão. O estágio de
implantação é executado após a análise hipotética quando o fluxo de trabalho é
acionado por um push para a filial principal. Este estágio implantará o modelo no
Azure depois que uma revisão manual for aprovada.

Usar o Terraform
Há três fluxos de trabalho principais incluídos na arquitetura de referência :

1. Testes de Unidades do Terraform

Esse fluxo de trabalho é executado em cada confirmação e é composto por um

conjunto de testes de unidade no código de infraestrutura. Ele executa o fmt do
terraform para garantir que o código seja devidamente revisado e siga as
melhores práticas do terraform. Em seguida, ele executa a validação do
terraform para verificar se o código é sintaticamente correto e internamente
consistente. Por fim, o checkov , uma ferramenta de análise de código estático de
código aberto para IaC, será executado para detectar problemas de segurança e
conformidade. Se o repositório estiver utilizando o GitHub Advanced Security
(GHAS), os resultados serão carregados no GitHub.

2. Plano do Terraform / Aplicar

Esse fluxo de trabalho é executado em cada solicitação de pull e em cada

confirmação na filial principal. O estágio do plano do fluxo de trabalho é usado
para entender o impacto das alterações da IaC no ambiente do Azure executando
o plano do terraform . Este relatório é então anexado à PR para facilitar a revisão.
O estágio de aplicação é executado após o plano quando o fluxo de trabalho é
acionado por um push para a filial principal. Este estágio usará o documento do
 plano e aplicará as alterações após a aprovação de uma revisão manual se
houver alterações pendentes no ambiente.

3. Detecção de Descompasso do Terraform

Esse fluxo de trabalho é executado periodicamente para verificar seu ambiente em

busca de qualquer descompasso na configuração ou alterações feitas fora do
Terraform. Se algum descompasso for detectado, um problema do GitHub será
gerado para alertar os mantenedores do projeto.

Recursos relacionados
O que é a infraestrutura como código
Infraestrutura repetível
Comparar o Terraform e o Bicep
Checkov e código-fonte
Segurança Avançada do GitHub
O que são microsserviços?
Artigo • 05/10/2023

Os microsserviços descrevem o processo arquitetônico de criação de um aplicativo

distribuído a partir de serviços implantáveis separadamente que executam funções de
negócios específicas e se comunicam por interfaces da Web. As equipes de DevOps
incluem partes individuais de funcionalidade em microsserviços e criam sistemas
maiores combinando os microsserviços como blocos de construção.

Os microsserviços aplicam um exemplo do princípio aberto/fechado:

Eles estão abertos para extensão (usando as interfaces que eles expõem)
Eles são fechados para modificação (cada um é implementado e versionado
independentemente)

Os microsserviços oferecem muitos benefícios em relação às arquiteturas monolíticas:

Eles podem remover pontos únicos de falha (SPOFs) garantindo que os problemas
em um serviço não travem nem afetem outras partes de um aplicativo.
Os microsserviços individuais podem ser expandidos de forma independente para
fornecer disponibilidade e capacidade extras.
As equipes de DevOps podem estender a funcionalidade adicionando novos
microsserviços sem afetar desnecessariamente outras partes do aplicativo.

O uso de microsserviços pode aumentar a velocidade da equipe. As práticas de DevOps,

como Integração Contínua e Entrega Contínua, são usadas para conduzir implantações
de microsserviços. Os microsserviços complementam bem as arquiteturas de aplicativos
baseadas em nuvem, permitindo que as equipes de desenvolvimento de software
aproveitem cenários como programação orientada por eventos e dimensionamento
automático. Os componentes dos microsserviços expõem APIs (interfaces de
programação de aplicativos), geralmente sobre protocolos REST, para comunicação com
outros serviços.

Uma prática cada vez mais comum é usar clusters de contêiner para implementar
microsserviços. Os contêineres permitem o isolamento, o empacotamento e a
implantação de microsserviços, enquanto a orquestração expande um grupo de
contêineres em um aplicativo.

Próximas etapas
Saiba mais sobre microsserviços no Azure .
Deslocar para a direita para testar na
produção
Artigo • 05/10/2023

Deslocar para a direita é a prática de mover alguns testes para mais tarde no processo
de DevOps para testar em produção. O teste em produção usa implantações reais para
validar e medir o comportamento e o desempenho de um aplicativo no ambiente de
produção.

Uma maneira de as equipes de DevOps melhorarem a velocidade é com uma estratégia

de teste de deslocamento para a esquerda. O deslocamento para a esquerda empurra a
maioria dos testes para mais cedo no pipeline de DevOps, para reduzir o tempo até que
o novo código chegue à produção e opere de forma confiável.

Mas, enquanto muitos tipos de testes, como os testes de unidade, podem facilmente ser
deslocados para a esquerda, algumas classes de testes não podem ser executadas sem
implantar parte ou toda uma solução. A implantação em um serviço de controle de
qualidade ou de preparo pode simular um ambiente comparável, mas não há substituto
completo para o ambiente de produção. As equipes descobrem que certos tipos de
testes precisam acontecer na produção.

Os testes em produção proporcionam:

Toda a amplitude e diversidade do ambiente de produção.

A carga de trabalho real do tráfego de clientes.
Perfis e comportamentos à medida que a demanda de produção evolui ao longo
do tempo.

O ambiente de produção continua mudando. Mesmo que um aplicativo não mude, a

infraestrutura da qual ele depende muda constantemente. Os testes em produção
validam a integridade e a qualidade de uma determinada implantação de produção e
do ambiente de produção em constante mudança.

Deslocar a direita para testar em produção é especialmente importante nos seguintes

cenários:

Implantações de microsserviços
As soluções baseadas em microsserviços podem ter um grande número de
microsserviços desenvolvidos, implantados e gerenciados de forma independente.
Deslocar os testes para a direito é especialmente importante para esses projetos,
porque diferentes versões e configurações podem chegar à produção de várias
maneiras. Independentemente da cobertura de teste de pré-produção, é necessário
testar a compatibilidade na produção.

Garantir a qualidade pós-implantação

Liberar para a produção é apenas metade da entrega de software. A outra metade é
garantir qualidade em escala com uma carga de trabalho real na produção. Como o
ambiente continua mudando, uma equipe nunca termina de testar em produção.

Os dados de teste da produção são literalmente os resultados do teste da carga de

trabalho real do cliente. Os testes em produção incluem monitoramento, teste de
failover e injeção de falhas. Esse teste rastreia falhas, exceções, métricas de desempenho
e eventos de segurança. A telemetria de teste também ajuda a detectar anomalias.

Anéis de implantação
Para proteger o ambiente de produção, as equipes podem implementar alterações de
forma progressiva e controlada usando implantações baseadas em anel e sinalizadores
de recursos. Por exemplo, é melhor detectar um bug que impeça um comprador de
concluir sua compra quando menos de 1% dos clientes estão nesse anel de implantação
do que depois de trocar todos os clientes de uma só vez. O valor do recurso com falhas
detectadas deve exceder as perdas líquidas dessas falhas, medidas de forma significativa
para o negócio em questão.

O primeiro anel deve ser o menor tamanho necessário para executar o conjunto de
integração padrão. Os testes podem ser semelhantes aos já executados anteriormente
no pipeline em relação a outros ambientes, mas o teste valida que o comportamento é
o mesmo no ambiente de produção. Esse anel identifica erros óbvios, como
configurações incorretas, antes que eles afetem qualquer cliente.

Depois que o anel inicial é validado, o próximo anel pode ser ampliado para incluir um
subconjunto de usuários reais para a execução do teste. Se tudo parecer bom, a
implantação pode progredir através de mais anéis e testes até que todos estejam
usando. A implantação completa não significa que o teste acabou. A telemetria de
rastreamento é extremamente importante para testes em produção.

Injeção de falha
As equipes geralmente empregam injeção de falhas e engenharia de caos para ver como
um sistema se comporta sob condições de falha. Essas práticas ajudam a:
 Validar se os mecanismos de resiliência implementados realmente funcionam.
Validar se uma falha em um subsistema está contida nesse subsistema e não
ocorre em cascata para produzir uma interrupção importante.
Provar que o trabalho de reparo de um incidente anterior tem o efeito desejado,
sem ter que esperar que outro incidente ocorra.
Criar análises de treinamento mais realistas para engenheiros de locais ativos para
que eles possam se preparar melhor para lidar com incidentes.

É uma boa prática automatizar experimentos de injeção de falhas, porque são testes
caros que devem ser executados em sistemas em constante mudança.

A engenharia do caos pode ser uma ferramenta eficaz, mas deve ser limitada a
ambientes canários que têm pouco ou nenhum impacto no cliente.

Testar um failover
Uma forma de injeção de falhas é o teste de failover para oferecer suporte à
continuidade dos negócios e à recuperação de desastres (BCDR). As equipes devem ter
planos de failover para todos os serviços e subsistemas. Os planos devem incluir:

Uma explicação clara do impacto comercial da queda do serviço.

Um mapa de todas as dependências em termos de plataforma, tecnologia e
pessoas que elaboram os planos de BCDR.
Documentação formal dos procedimentos de recuperação de desastres.
Uma cadência para executar regularmente análises de recuperação de desastres.

Teste de falha de disjuntor

Um mecanismo de disjuntor corta um determinado componente de um sistema maior,
geralmente para evitar que falhas nesse componente se espalhem para fora de seus
limites. Você pode acionar disjuntores intencionalmente para testar os seguintes
cenários:

Se um fallback funciona quando o disjuntor é aberto. O fallback pode funcionar

com testes de unidade, mas a única maneira de saber se ele se comportará como
esperado na produção é injetar uma falha para acioná-lo.

Se o disjuntor tem o limite de sensibilidade certo para abrir quando for necessário.
A injeção de falhas pode forçar a latência ou desconectar dependências para
observar a capacidade de resposta do disjuntor. É importante verificar não apenas
se o comportamento correto ocorre, mas se ele acontece com rapidez suficiente.
Exemplo: testar um disjuntor de Cache Redis
O Cache Redis melhora o desempenho do produto, acelerando o acesso aos dados
mais usados. Considere um cenário que tenha uma dependência não crítica do Redis. Se
o Redis ficar inativo, o sistema deve continuar a funcionar, pois ele pode voltar a usar a
fonte de dados original para solicitações. Para confirmar que uma falha do Redis aciona
um disjuntor e que o fallback funciona em produção, execute periodicamente testes
relacionados a esses comportamentos.

O diagrama a seguir mostra testes para o comportamento de fallback do disjuntor do

Redis. O objetivo é garantir que, quando o disjuntor abrir, as chamadas finalmente vão
para SQL.

O diagrama anterior mostra três ATs, com os disjuntores na frente das chamadas para
Redis. Um teste força o disjuntor a abrir por meio de uma alteração de configuração e,
em seguida, observa se as chamadas vão para SQL. Outro teste então verifica a
alteração de configuração oposta, fechando o disjuntor para confirmar se as chamadas
retornam ao Redis.

Esse teste valida que o comportamento de fallback funciona quando o disjuntor é

aberto, mas não valida se a configuração do disjuntor abre o disjuntor quando deveria.
Testar esse comportamento requer simular falhas reais.

Um agente de falha pode introduzir falhas em chamadas que vão para o Redis. O
diagrama a seguir mostra o teste com injeção de falha.
 1. O injetor de falha bloqueia solicitações do Redis.
2. O disjuntor é aberto, e o teste pode observar se o fallback funciona.
3. A falha é removida, e o disjuntor envia uma solicitação de teste para o Redis.
4. Se a solicitação for bem-sucedida, as chamadas serão revertidas para o Redis.

Etapas adicionais podem testar a sensibilidade do disjuntor, se o limite é muito alto ou

muito baixo e se outros tempos limite do sistema interferem no comportamento do
disjuntor.

Neste exemplo, se o disjuntor não abrir ou fechar conforme o esperado, ele poderá
causar um incidente de local ativo (LSI). Sem o teste de injeção de falha, o problema
pode passar despercebido, pois é difícil fazer esse tipo de teste em um ambiente de
laboratório.

Próximas etapas
[Deslocar teste para a esquerda com testes de unidade]deslocamento para a
esquerda
O que são microsserviços?
Executar um failover de teste (simulação da recuperação de desastre) no Azure
Práticas de implantação segura
O que é o monitoramento?
Como a Microsoft fornece software com
o DevOps
Artigo • 05/10/2023

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.
Introdução à operação de sistemas
confiáveis com o DevOps
Artigo • 05/10/2023

A fase de operações do DevOps vem após uma entrega bem-sucedida e engloba tudo o
que as equipes devem considerar para manter, monitorar e solucionar problemas do
aplicativo. A criação fica exposta a clientes reais no ambiente de produção, em que a
confiabilidade se torna um fator essencial.

Gerenciar a exposição da versão

Colocar o produto no ambiente de produção pode parecer a etapa final, mas é apenas o
começo de um mundo totalmente novo. Muita coisa pode dar errado, por isso é
importante que as equipes adotem práticas de implantação seguras que forneçam o
equilíbrio certo entre exposição e risco do cliente. As equipes também podem testar
alterações usando sinalizadores de recursos para explorar como novas atualizações e
recursos afetam um público-alvo em potencial.

Opere com todo o seu potencial

As equipes precisam garantir que os sistemas que operam estejam sempre disponíveis,
independentemente de atualizações, alterações ou problemas subjacentes. Acompanhar
os acontecimentos exige uma compreensão profunda de todas as ferramentas e
recursos disponíveis para monitorar sistemas de produção. A abordagem correta pode
garantir que os sistemas recebam atualizações e continuem a operar sem tempo de
inatividade.

Proteger implantações de produção

A segurança passou a ser a principal preocupação dos aplicativos. O DevSecOps
descreve o conjunto de práticas que uma equipe segue para criar e manter sistemas
seguros ao máximo. Essas práticas vão além do código e da infraestrutura para também
incluir políticas a serem seguidas por seres humanos, bem como orientações para lidar e
se recuperar de possíveis violações.

Próximas etapas
Saiba como o monitoramento eficaz ajuda a garantir a alta disponibilidade do sistema e
permite que equipes do DevOps apresentem resultados rapidamente.
O que é o monitoramento?
Artigo • 05/10/2023

Depois que uma aplicação é implantada na produção, o monitoramento fornece

informações sobre os padrões de desempenho e uso da aplicação para que você possa
identificar, mitigar ou resolver problemas.

Objetivos do monitoramento
Um objetivo do monitoramento é alcançar alta disponibilidade, minimizando as
principais métricas que são medidas em termos de tempo:

Tempo de detecção (TTD): quando surgem problemas de desempenho ou de outra

natureza, dados de diagnóstico avançados sobre os problemas são fornecidos para
as equipes de desenvolvimento por meio de monitoramento automatizado.
Tempo de mitigação (TTM): as equipes do DevOps atuam nas informações para
mitigar problemas o mais rápido possível para que os usuários não sejam mais
afetados.
Tempo de correção (TTR): os tempos de resolução são medidos e as equipes
trabalham para melhorar com o tempo. Após a mitigação, as equipes trabalham
para encontrar formas de corrigir problemas na causa raiz para que eles não se
repitam.

Um segundo objetivo do monitoramento é permitir a aprendizagem validada ao rastrear

o uso. O conceito principal da aprendizagem validada é que cada implantação é uma
oportunidade de acompanhar resultados experimentais que fortalecem ou enfraquecem
as hipóteses que levaram à implantação. O rastreamento do uso e de diferenças entre
as versões permite que as equipes avaliem o impacto das mudanças e orientem as
decisões de negócios. Se uma hipótese for enfraquecida, a equipe poderá falhar
rapidamente ou adaptar-se. Se a hipótese for apoiada, a equipe poderá insistir ou
perseverar. Essas decisões baseadas em dados levam a novas hipóteses e priorização do
backlog.

Conceitos principais
Telemetria é o mecanismo de coleta de dados a partir do monitoramento. A telemetria
pode usar agentes instalados em ambientes de implantação, um SDK que depende de
marcadores inseridos no código-fonte, log do servidor ou uma combinação destes. Em
geral, a telemetria distingue entre o pipeline de dados otimizado para alertas e painéis
em tempo real e os dados de maior volume necessários para solução de problemas ou
análise de uso.

O monitoramento sintético usa um conjunto consistente de transações para avaliar o

desempenho e a disponibilidade. As transações sintéticas são testes previsíveis com a
vantagem de permitir a comparação entre lançamentos de forma altamente previsível.
O monitoramento do usuário real (RUM), por outro lado, mede a experiência do
navegador, dispositivo móvel ou desktop do usuário. Ele responde por condições de
última milha, como redes celulares, roteamento de internet e armazenamento em cache.
Diferente do Synthetics, o RUM normalmente não fornece medição repetível com o
tempo.

O monitoramento costuma ser usado para testar na produção. Uma implantação bem
monitorada transmite dados sobre a integridade e o desempenho para que você possa
detectar incidentes de produção imediatamente. Combinado com um pipeline de
lançamento de implantação contínua, o monitoramento detectará novas anomalias e
permitirá a mitigação imediata. Isso permite a descoberta de incógnitas desconhecidas
no comportamento da aplicação que não podem ser previstas em ambientes de pré-
produção.

O monitoramento eficaz é essencial para permitir que equipes do DevOps agilizem

entregas, obtenham comentários da produção, e aumentem a satisfação, a aquisição e a
retenção de clientes.

Próximas etapas
Leia mais sobre os recursos de monitoramento do Azure Monitor .

Saiba como configurar e usar o Application Insights para monitoramento .

Práticas de implantação segura
Artigo • 05/10/2023

Às vezes, um lançamento não corresponde às expectativas. Apesar de usar as práticas

recomendadas e passar por todos os controles de qualidade, ocasionalmente há
questões que resultam em uma implantação de produção que causa problemas
imprevistos para os usuários. Para minimizar e mitigar o impacto desses problemas, as
equipes do DevOps são incentivadas a adotar uma estratégia de exposição progressiva
que equilibre a exposição de certa versão com desempenho comprovado. Quando uma
versão entra em produção, ela fica disponível para níveis de públicos-alvos mais amplos
até que todos a utilizem. As equipes podem usar práticas de implantação seguras para
maximizar a qualidade e a velocidade dos lançamentos em produção.

Controle a exposição a clientes

As equipes do DevOps podem empregar várias práticas para controlar a exposição de
atualizações a clientes. Historicamente, o teste A/B tem sido uma escolha popular para
equipes que desejam saber como versões distintas de um serviço ou interface do
usuário se comportam em relação às metas de destino. O teste A/B também é
relativamente fácil de usar porque as alterações costumam ser menores e
frequentemente só comparam versões distintas na borda voltada ao cliente de um
serviço.

Implantação segura por anéis

À medida que as plataformas crescem, a escala da infraestrutura e as necessidades do
público-alvo tendem a crescer. Isso gera uma demanda por um modelo de implantação
que equilibre os riscos associados a uma nova implantação com os benefícios das
atualizações prometidas. A ideia geral é primeiro expor uma versão específica apenas a
um grupo reduzido de usuários com a maior tolerância ao risco. Se a versão funcionar
conforme o esperado, ela poderá ser exposta a um grupo mais amplo de usuários. Se
não houver problemas, o processo poderá continuar por meio de grupos mais amplos
de usuários, ou anéis, até que todos usem a nova versão. Com plataformas modernas de
entrega contínua como o GitHub Actions e o Azure Pipelines , a criação de um
processo de implantação com anéis é acessível a equipes do DevOps de qualquer
tamanho.

Sinalizadores de recurso
Às vezes, é necessário implantar determinadas funcionalidades como parte de uma
versão, mas não expô-las inicialmente aos usuários. Nesses casos, os sinalizadores de
recursos fornecem uma solução em que é possível ativar a funcionalidade via alterações
de configuração com base no ambiente, no anel ou em qualquer outra implantação
específica.

Aceitação do usuário
Semelhante a sinalizadores de recursos, a aceitação do usuário possibilita limitar a
exposição. Nesse modelo, um recurso em especial é habilitado na versão, mas não é
ativado para um usuário, a menos que ele o deseje especificamente. A decisão de
tolerância ao risco é transferida para os usuários para que possam decidir o quão rápido
desejam adotar certas atualizações.

Múltiplas práticas costumam ser empregadas ao mesmo tempo. Por exemplo, uma
equipe pode ter um recurso experimental destinado a um caso de uso bem específico.
Como é arriscado, eles o implantarão no primeiro anel para os usuários internos
testarem. Contudo, mesmo que os recursos estejam no código, alguém precisará definir
o sinalizador de recurso para uma implantação específica no anel para a exposição do
recurso via interface do usuário. Mesmo assim, o sinalizador de recurso pode expor
somente a opção de um usuário para optar por usar o novo recurso. Qualquer pessoa
que não esteja no anel, nessa implantação, ou não tenha optado por participar, não será
exposta ao recurso. Apesar de fictício, este exemplo serve para ilustrar a flexibilidade e a
praticidade da exposição progressiva.

Problemas comuns enfrentados por equipes

logo no início
À medida que as equipes decidem adotar uma prática do Agile DevOps, elas podem se
deparar com problemas parecidos com outras que migraram de entregas monolíticas
tradicionais. As equipes acostumadas a fazer uma implantação com intervalo de alguns
meses têm uma mentalidade voltada para a estabilização. Elas esperam que cada
implantação traga uma mudança significativa no serviço e que haja problemas
imprevistos.

Os conteúdos são grandes demais

Os serviços implantados com intervalo de alguns meses costumam ser preenchidos com
muitas alterações. Isso aumenta a probabilidade de problemas imediatos e também
torna difícil solucionar esses problemas pois existem muitas novidades. Ao migrar para
entregas mais frequentes, diminuem as diferenças no que é implantado, permitindo
testes mais focados e depuração mais fácil.

Nenhum isolamento de serviço

Os sistemas monolíticos costumam ser escalados nivelando o hardware em que são
implantados. Mas, quando algo dá errado na instância, isso causa problemas para todos.
Uma solução simples é adicionar várias instâncias para permitir balancear a carga de
usuários. No entanto, isso pode exigir considerações arquitetônicas significativas, pois
muitos sistemas herdados não são criados visando várias instâncias. Somado a isso,
talvez seja necessário alocar recursos duplicados significativos para funcionalidades que
possam ser melhor consolidadas em outros locais.

Com a adição de novos recursos, explore se uma arquitetura de microsserviços pode

ajudá-lo a operar e escalar com um isolamento de serviço aprimorado.

Etapas manuais conduzem a erros

Quando uma equipe só implantar poucas vezes ao ano, talvez não valha a pena
automatizar as entregas. Como resultado, muitos processos de implantação são
gerenciados de forma manual. Isso exige muito tempo e esforço, e está sujeito a erros
humanos. Basta automatizar as tarefas de compilação e implantação mais comuns para
ajudar a reduzir muito o tempo perdido e erros não forçados.

As equipes também podem usar a infraestrutura como código para controlar melhor os
ambientes de implantação. Isso elimina a necessidade de solicitações à equipe de
operações para fazer alterações manuais à medida que novos recursos ou dependências
são apresentados em vários ambientes de implantação.

Somente operações podem fazer implantações

Algumas organizações têm políticas que exigem que todas as implantações sejam
iniciadas e gerenciadas pela equipe de operações. Embora possam ter existido bons
motivos para isso no passado, um processo do Agile DevOps se beneficia muito quando
a equipe de desenvolvimento pode iniciar e controlar implantações. As plataformas
modernas de entrega contínua oferecem controle granular de quem pode iniciar quais
implantações e de quem pode acessar logs de status e outras informações de
diagnóstico, garantindo que as pessoas certas tenham as informações certas o quanto
antes.
Implantações incorretas prosseguem e não podem ser
revertidas
Às vezes, uma implantação dá errado e as equipes precisam resolvê-la. No entanto,
quando os processos são manuais e o acesso às informações é lento e limitado, pode
ser difícil reverter para uma implantação de trabalho anterior. Felizmente, existem várias
ferramentas e práticas para mitigar o risco de implantações com falha.

Princípios básicos
As equipes que desejam adotar práticas de implantação segura devem definir alguns
princípios básicos para sustentar o esforço.

Seja consistente
Use as mesmas ferramentas que utilizou para implantar na produção em ambientes de
desenvolvimento e teste. Em caso de problemas, como os que costumam surgir de
novas versões de dependências ou ferramentas, procure detectá-los bem antes da
liberação do código para produção.

Fique atento aos sinais de qualidade

Um número excessivo de equipes caem na armadilha comum de não ficarem atentas a
sinais de qualidade. Com o tempo, elas podem descobrir que escrevem testes ou
assumem tarefas de qualidade simplesmente para mudar uma advertência amarela para
uma aprovação verde. Os sinais de qualidade são de fato importantes, pois representam
a pulsação de um projeto. Os sinais de qualidade usados para aprovar implantações
devem ser rastreados constantemente todos os dias.

As implantações devem exigir zero tempo de inatividade

Embora não seja essencial que todos os serviços sempre estejam disponíveis, as equipes
devem abordar os estágios de entrega e operação do DevOps com a mentalidade de
que podem e devem implantar novas versões sem precisar abordá-las. A infraestrutura
moderna e as ferramentas de pipeline estão bem avançadas, sendo viável para
praticamente qualquer equipe atingir 100% de tempo de atividade.

As implantações devem ocorrer no horário de trabalho

Se uma equipe trabalha com a mentalidade de que as implantações exigem tempo de
inatividade zero, não importa quando uma implantação é enviada. Além disso, torna-se
vantajoso efetuar implantações no horário de trabalho, especialmente no início do dia e
no início da semana. Se algo der errado, isso deverá ser logo rastreado para controlar o
raio de alcance. Além disso, todos já estarão trabalhando e focados em corrigir
problemas.

Implantação baseada em anéis

As equipes com práticas avançadas de lançamento do DevOps estão prontas para
assumir a implantação baseada em anel. Nesse modelo, novos recursos são lançados
primeiro para clientes dispostos a aceitar o risco maior. Conforme a implantação é
comprovada, o público passa a incluir mais usuários até que todos a utilizem.

Um exemplo de modelo de anel

Um modelo típico de implantação em anel é criado para encontrar problemas o quanto
antes por meio da segmentação cuidadosa de usuários e infraestrutura. O exemplo a
seguir mostra como os anéis são usados por uma equipe importante da Microsoft.

Anel Finalidade Usuários Data Center

0 Localiza a maioria dos bugs Apenas interno, alta tolerância a Centro-Oeste dos
que afetam o usuário riscos e bugs EUA
apresentados pela
implantação

1 Áreas que a equipe não testa Clientes que utilizam uma Um pequeno data
tanto variedade do produto center

2 Questões relativas à escala Contas públicas, preferencialmente Um data center de

gratuitas usando um conjunto médio ou grande
diversificado de recursos porte

3 Problemas de escala em Grandes contas internas e clientes Data center interno

contas internas e problemas europeus e um data center
internacionais europeu

4 Unidades de escala restantes Todos os outros Todos os destinos

de implantação

Permitir tempo de preparação

O termo tempo de preparação refere-se à quantidade de tempo permitido para a
execução de uma implantação antes de expandir para o próximo anel. Alguns
problemas começam a apresentar sintomas após algumas horas ou mais tempo;
portanto, a versão deve estar em uso por um período apropriado antes de ser
considerada pronta.

Em geral, um dia com 24 horas deve ser suficiente para a maioria dos cenários
apresentarem bugs latentes. No entanto, esse período deve incluir um pico de uso,
exigindo um dia útil inteiro, para serviços que atingem o pico no horário comercial.

Agilizar hotfixes
Um incidente de site ativo (LSI) ocorre quando um bug tem um impacto sério na
produção. Os LSIs exigem a criação de um hotfix, que é uma atualização fora de banda
que visa resolver um problema de alta prioridade.

Se um bug for Sev 0, o tipo mais grave de bug, será possível implantar o hotfix direto na
unidade de escala afetada o quanto antes, com responsabilidade. Embora seja essencial
que a correção não piore as coisas, bugs dessa gravidade causam tanto transtorno que
devem ser resolvidos logo.

Os bugs classificados como Sev 1 devem ser implantados através do anel 0, mas é
possível implantá-los nas unidades de escala afetadas quando aprovados.

Os hotfixes para bugs com menor gravidade devem ser implantados em todos os anéis,
conforme planejado.

Principais aspectos a serem lembrados

Toda equipe deseja oferecer rapidamente atualizações e com o nível de qualidade mais
alto possível. Com as práticas certas, a entrega pode ser uma parte produtiva e simples
do ciclo do DevOps.

Procure implantar com frequência.

Permaneça verde no sprint inteiro.
Use ferramentas de implantação consistentes no desenvolvimento, no teste e na
produção.
Use uma plataforma de entrega contínua que permita automação e autorização.
Adote práticas de implantação seguras.

Próximas etapas
Saiba como sinalizadores de recursos ajudam a controlar a exposição de novos recursos
aos usuários.
Experimentação progressiva com
sinalizadores de recursos
Artigo • 05/10/2023

À medida que as equipes do DevOps alternam para uma metodologia do Agile que foca
a entrega contínua de recursos, é cada vez maior a necessidade de controlar como eles
são disponibilizados para os usuários. Os sinalizadores de recursos são uma ótima
solução para limitar o acesso do usuário a novos recursos, para fins de marketing ou
para testes em produção.

Desacoplamento, implantação e exposição

Com sinalizadores de recursos, uma equipe pode decidir se um conjunto de recursos
específico é visível na experiência do usuário e/ou invocado na funcionalidade. Pode-se
criar e implantar novos recursos como parte do processo de desenvolvimento comum
sem dispor desses recursos para amplo acesso. A implantação de recursos é separada
da exposição de maneira conveniente.

Os sinalizadores fornecem controle de runtime até

usuários individuais
Os sinalizadores também fornecem controle granular até o usuário individual. Quando é
chegado o momento de habilitar um recurso, seja para um usuário, um pequeno grupo
ou todos, a equipe pode simplesmente alterar o sinalizador de recurso para aprimorá-lo
sem precisar reimplantá-lo.

O escopo de um sinalizador de recurso variará com base na natureza do recurso e do

público-alvo. Em alguns casos, um sinalizador de recurso habilitará automaticamente a
funcionalidade para todos. Em outros casos, um recurso será habilitado para cada
usuário. Se desejarem, as equipes também poderão usar sinalizadores de recursos para
permitir que os usuários optem por habilitar um recurso. Não há de fato limite para a
forma como os sinalizadores de recursos são implementados.

Apoie comentários antecipados e experimentação

Os sinalizadores de recursos são uma ótima maneira de dar suporte à experimentação
inicial. Alguns recursos podem ter pontos em aberto desde o início, algo que pode
interessar somente os adeptos no estágio inicial. A tentativa de difundir esses recursos
não totalmente prontos junto a um público-alvo mais amplo pode gerar insatisfação.
Mas é inestimável o benefício de coletar comentários de usuários dispostos a lidar com
um recurso em andamento.

Comece logo a alternar

Às vezes, é útil ser capaz de desativar algo. Por exemplo, digamos que um novo recurso
não esteja funcionando da forma esperada e haja efeitos colaterais que causam
problemas em outros locais. Você pode usar sinalizadores de recurso para desativar
rapidamente a nova funcionalidade para reverter para o comportamento confiável sem
precisar reimplantar. Embora os sinalizadores de recursos sejam em geral considerados
em termos de recursos de interface do usuário, eles também podem ser facilmente
usados para alterações na arquitetura ou infraestrutura.

Estágios padrão
A Microsoft usa um processo de distribuição padrão para ativar sinalizadores de
recursos. Há dois conceitos independentes: anéis para implantações e estágios para
sinalizadores de recursos. Saiba mais sobre anéis e estágios .

Os estágios tratam de divulgação ou exposição. Por exemplo, o primeiro estágio pode

ser para a conta de uma equipe e as contas pessoais dos membros. A maioria dos
usuários não veriam algo novo porque os sinalizadores só estão ativados para este
primeiro estágio. Isso permite que uma equipe use-o e teste-o totalmente. Após a
aprovação da equipe, os clientes selecionados poderão aceitá-lo por meio do segundo
estágio de sinalizadores de recursos.

Aceitar
É uma boa prática permitir que os usuários optem por sinalizadores de recursos quando
viável. Por exemplo, a equipe pode expor um painel de visualização associado às
preferências ou configurações do usuário.
Usar sinalizadores com telemetria
Os sinalizadores de recursos fornecem uma forma de expor atualizações de maneira
incremental. Mas, as equipes devem monitorar continuamente as métricas certas para
avaliar a prontidão para uma exposição mais ampla. Essas métricas devem incluir o
comportamento de uso e o impacto das atualizações na integridade do sistema. É
importante evitar a armadilha de supor que está tudo bem somente porque parece não
haver nada de errado.

Um exemplo de sinalizador de recurso

Considere o exemplo a seguir. A equipe adicionou alguns botões aqui para Cherry-pick
e Reverter na interface do usuário de solicitação de pull. Isso foi implantado por meio
de sinalizadores de recursos.
Definir sinalizadores de recurso
O primeiro recurso exposto foi o botão Reverter. A solução usa um arquivo XML para
definir todos os sinalizadores de recurso. Há um arquivo por serviço nesse caso, o que
gera um incentivo para remover sinalizadores anteriores para evitar que a seção fique
longa demais. A equipe excluirá sinalizadores antigos porque existe uma motivação
natural para controlar o tamanho desse arquivo.

XML

<?xml version="1.0" encoding="utf-8"?>

<!--
In this group we should register Azure DevOps specific features and sets
their states.
-->
<ServicingStepGroup name="AzureDevOpsFeatureAvailability" … >
<Steps>
<!-- Feature Availability -->
<ServicingStep name="Register features"
stepPerformer="FeatureAvailability" … >
<StepData>
<!--specifying owner to allow implicit removal of features -->
<Features owner="AzureDevOps">
<!-- Begin TFVC/Git -->
<Feature name="[Link]" description="Source control
revert features" />

Uma estrutura de servidor comum incentiva a reutilização e economias de escala em

toda a equipe. O ideal é que o projeto tenha infraestrutura para que um desenvolvedor
possa simplesmente definir um sinalizador em um repositório central e ter o restante da
infraestrutura tratada para eles.

Verificar sinalizadores de recursos em runtime

O sinalizador de recursos usado aqui é denominado [Link]. Aqui está o
TypeScript real dessa página que ilustra a chamada para uma verificação de
disponibilidade de recursos.

TypeScript

private addRevertButton(): void {

if ([Link]([Link])) {
this._calloutButtons.unshift(
<button onClick={ () => [Link](
[Link],
[Link](),
 [Link]().sourceBranchStatus,

[Link]().targetBranchStatus)
}
>
{VCResources.PullRequest_Revert_Button}
</button>
);
}
}

O exemplo acima ilustra o uso no TypeScript, mas ele pode ser facilmente acessado com
o C#. O código verifica se o recurso está habilitado e, em caso positivo, renderiza um
botão para fornecer a funcionalidade. Se o sinalizador não estiver habilitado, o botão
será ignorado.

Controlar um sinalizador de recursos

Uma boa plataforma do sinalizador de recursos fornecerá várias formas de gerenciar se
certo sinalizador for definido. Em geral, há cenários de uso para o sinalizador a ser
controlado via PowerShell e interface da Web. Para o PowerShell, só precisam ser
expostas as maneiras de obter e definir o status de um sinalizador de recursos, junto
com parâmetros opcionais para itens como identificadores de conta de usuário
específicos, se aplicável.

Controlar sinalizadores de recursos por meio da interface

do usuário da Web
O exemplo a seguir usa a interface do usuário da Web exposta para este produto pela
equipe. Observe o sinalizador de recursos para [Link]. Há duas contas
pessoais listadas aqui: hallux e buckh-westeur. O estado está definido para hallux, que
fica no Centro-Norte, e é liberado para outra conta na Europa Ocidental.
A natureza do sinalizador de recursos delimitará a forma como os recursos são
expostos. Em alguns casos, a exposição seguirá um modelo de anel e estágio. Em
outros, os usuários podem aderir à interface do usuário de configuração ou até mesmo
enviar um email à equipe para acesso.

Considerações sobre sinalizadores de recursos

É possível desativar a maioria dos sinalizadores de recursos após o lançamento de um
recurso para todos. Nesse ponto, a equipe pode excluir todas as referências ao
sinalizador no código e na configuração. É uma boa prática incluir uma revisão de
sinalizador de recursos, como no início de cada sprint.

Também pode existir um conjunto de sinalizadores de recursos que persistem por vários
motivos. Por exemplo, talvez a equipe deseje manter um sinalizador de recursos que
ramifica algo de infraestrutura por um período após a total alternância do serviço de
produção. No entanto, lembre-se de que esse possível caminho de código pode ser
reativado no futuro durante uma limpeza explícita do sinalizador de recursos; assim, ele
precisa ser testado e mantido até que a opção seja removida.

Sinalizadores de recursos e estratégia de ramificação

Os sinalizadores de recursos permitem às equipes de desenvolvimento incluir recursos
incompletos no main sem afetar ninguém. Contanto que o caminho de código esteja
isolado por trás de um sinalizador de recursos, costuma ser seguro criar e publicar esse
código sem que os efeitos colaterais afetem o uso normal. Caso um recurso exija
dependências, como ao expor um ponto de extremidade REST, as equipes deverão
considerar como essas dependências podem gerar segurança ou trabalho de
manutenção mesmo sem a exposição do recurso.

Sinalizadores de recursos para mitigar riscos

Às vezes, novos recursos têm o potencial de apresentar mudanças destrutivas ou
prejudiciais. Por exemplo, o produto pode estar passando por uma transformação de
um esquema de banco de dados amplo para um longo. Nesse cenário, o desenvolvedor
deve criar uma ramificação de recurso por um período curto. Eles fazem as mudanças
desestabilizadoras na ramificação e mantêm o recurso atrás de um sinalizador. Uma
prática comum das equipes é mesclar as mudanças até main desde que não causem
danos. Isso não seria viável sem a capacidade de manter o recurso inacabado oculto
atrás de um sinalizador de recursos.

Os sinalizadores de recursos ajudam a trabalhar no

principal
Se você seguir as práticas com bom senso discutidas na fase de Desenvolvimento,
trabalhar em main será uma boa forma de restringir um ciclo do DevOps. Quando
associado a sinalizadores de recursos, os desenvolvedores podem mesclar rapidamente
recursos no upstream e enviá-los por meio de test gauntlet. O código de qualidade
pode ser publicado rapidamente para testes em produção. Após alguns sprints, os
desenvolvedores reconhecerão os benefícios dos sinalizadores de recursos e os usarão
proativamente.

Como decidir se deseja usar um sinalizador de recursos

As equipes de recursos detêm a decisão sobre se precisam ou não de um sinalizador de
recursos para certa alteração. Nem toda alteração exige um; então, cabe a um
desenvolvedor decidir quando fazer uma alteração. No caso do recurso Reverter
abordado antes, era importante usar um sinalizador de recursos para controlar a
exposição. Permitir que as equipes tomem decisões importantes sobre a área de
recursos faz parte de permitir a autonomia em uma organização do DevOps eficaz.
Criar x comprar
Embora seja possível criar sua própria infraestrutura do sinalizador de recursos, em
geral, recomenda-se a adoção de uma plataforma como LaunchDarkly . É preferível
investir na criação de recursos e não recriar a funcionalidade do sinalizador de recursos.

Próximas etapas
Saiba mais sobre como usar sinalizadores de recursos em um aplicativo [Link] Core.
Elimine o tempo de inatividade por
meio de atualizações de serviço com
controle de versão
Artigo • 05/10/2023

Historicamente, os administradores precisavam colocar um servidor offline para

atualizar o software local. No entanto, o tempo de inatividade não é a solução em
serviços globais 24 horas por dia×, 7 dias por semana. Usuários têm forte dependência
de muitos serviços de nuvem modernos para administrar os negócios. Não existe um
momento ideal para desativar um sistema, então como uma equipe pode fornecer
serviço contínuo e instalar atualizações importantes de segurança e recursos?

Além de usar atualizações com controle de versão, esses serviços essenciais podem ser
transferidos perfeitamente de uma versão para outra enquanto os clientes os usam
ativamente. Nem todas as atualizações são difíceis. É fácil atualizar layouts ou estilos de
front-end. Pode ser complexo fazer alterações em recursos, mas há práticas bem
conhecidas para reduzir os riscos de migração. No entanto, as alterações que emanam
da camada de dados apresentam uma nova classe de desafios que exigem consideração
especial.

Atualizar camadas separadamente

Com um serviço online distribuído em vários datacenters e armazenamento de dados
separado, nem tudo pode ser alterado simultaneamente. Se o serviço típico for dividido
em código de aplicativo e bancos de dados, que supostamente têm controle de versão
de forma independente entre si, um desses lados precisará absorver a complexidade de
lidar com o controle de versão.

Muitas vezes, o controle de versão é mais fácil de manipular no código do aplicativo.

Sistemas maiores em geral têm um pouco de código herdado, como o SQL que vive
dentro dos bancos de dados. Em vez de complicar ainda mais esse SQL, o código do
aplicativo deve lidar com a complexidade. Especificamente, você pode criar um conjunto
de classes de fábrica que entendem o controle de versão SQL.

Durante cada sprint, crie uma nova interface com essa versão para que sempre exista
código que corresponda a cada versão do banco de dados. Você pode facilmente
reverter binários durante a implantação. Se algo der errado após a implantação dos
novos binários, reverta para o código anterior. Se a implantação binária for bem-
sucedida, inicie a manutenção do banco de dados.
Então, como isso realmente funciona? Por exemplo, suponha que sua equipe esteja
implantando a Sprint 123 no momento. Os binários entendem o esquema do banco de
dados da Sprint 123 e entendem o esquema da Sprint 122. O padrão geral é trabalhar
com ambas as versões/sprints N e N-1 do esquema SQL. Os binários consultam o banco
de dados, determinam com qual versão do esquema estão falando e carregam a
associação apropriada. O código do aplicativo trata o caso quando o novo esquema de
dados ainda não está disponível. Depois que a nova versão estiver disponível, o código
do aplicativo poderá começar a usar a nova funcionalidade habilitada pela versão mais
recente do banco de dados.

Avançar apenas com a camada de dados

Após a atualização dos bancos de dados, o serviço estará em uma situação de roll-
forward se ocorrer um problema. As migrações de banco de dados on-line são
complexas e, muitas vezes, de várias etapas. Portanto, o roll-forward costuma ser a
melhor maneira de resolver um problema. Em outras palavras, se a atualização falhar, a
reversão provavelmente também falhará. Há pouco valor em investir no esforço para
criar e testar código de reversão que sua equipe nunca espera usar.

Sequência de implantação
Considere um cenário em que você precisa adicionar um conjunto de colunas a um
banco de dados e transformar alguns dados. Essa transição precisa ser invisível para os
usuários, o que significa evitar ao máximo os bloqueios de mesa e, depois, manter os
bloqueios pelo menor tempo possível para que eles não sejam perceptíveis.

A primeira coisa que fazemos é manipular os dados, possivelmente em tabelas paralelas

usando um gatilho SQL para manter os dados sincronizados. Grandes migrações e
transformações de dados às vezes precisam ser de várias etapas em várias implantações
em vários sprints.

Depois que os dados extras ou o novo esquema tiver sido criado em paralelo, a equipe
entrará no modo de implantação para o código do aplicativo. No modo de implantação,
quando o código faz uma chamada para o banco de dados, ele primeiro obtém um
bloqueio no esquema e, depois, o libera após executar o procedimento armazenado. O
banco de dados não pode ser alterado entre o momento em que a chamada para o
banco de dados é emitida e quando o procedimento armazenado é executado.

O código de atualização atua como um gravador de esquema e solicita um bloqueio de

gravador no esquema. O código do aplicativo tem prioridade na obtenção de um
bloqueio de leitor, e o código de atualização fica em segundo plano tentando adquirir o
bloqueio de gravador. Sob o bloqueio do gravador, apenas um pequeno número de
operações muito rápidas são permitidas nas tabelas. O bloqueio é liberado e o
aplicativo registra que a nova versão do banco de dados está em uso e utiliza a interface
que corresponde à nova versão do banco de dados.

As atualizações do banco de dados são todas executadas por meio de um padrão de

migração. Um conjunto de códigos e scripts examina a versão do banco de dados e,
depois, faz alterações incrementais para migrar o esquema da versão antiga para a
nova. Todas as migrações são automatizadas e implementadas por meio do serviço de
gerenciamento de versões.

A interface do usuário da Web também deve ser atualizada sem interromper os

usuários. Ao atualizar arquivos JavaScript, folhas de estilo ou imagens, evite misturar
versões antigas e novas carregadas pelo cliente. Isso pode levar a erros que podem
perder o trabalho em andamento, como um campo editado por um usuário. Portanto,
você deve criar a versão de todos os arquivos JavaScript, CSS e de imagem colocando
todos os arquivos associados a uma implantação em uma pasta separada com controle
de versão. Quando a interface do usuário da Web faz chamadas para a camada de
aplicativo, os ativos com uma versão especificada são carregados. Somente quando
uma ação do usuário resulta em uma atualização de página inteira é que a nova
interface do usuário da Web é carregada no navegador. A experiência do usuário não é
interrompida pela atualização.

Próximas etapas
A Microsoft é uma das maiores empresas de desenvolvimento de software do mundo
há décadas. Saiba como a Microsoft opera sistemas confiáveis com o DevOps.
Como a Microsoft opera sistemas
confiáveis com o DevOps
Artigo • 05/10/2023

A Microsoft tem operado plataformas online complexas desde os primórdios da internet

comercial. Ao longo do caminho, evoluímos um conjunto substancial de práticas para
manter os sistemas disponíveis, íntegros e seguros. Essas práticas fazem parte de uma
iniciativa maior para manter e melhorar uma cultura de site ativo.

Cultura de site ativo

A cultura de site ativo é o foco de uma organização para priorizar a experiência e a
confiabilidade do site ativo sobre os demais aspectos. Afinal, os clientes podem se
mover entre provedores de serviços com facilidade hoje com os serviços baseados em
nuvem e na internet, ampliando a importância da confiança do cliente. O site ativo deve
estar sempre disponível e funcionar conforme prometido aos clientes.

Existem vários fatores que contribuem para uma cultura de site ativo bem-sucedida.

Site ativo em primeiro lugar

Priorizar a experiência do site ativo é essencial para o sucesso de uma plataforma. As
equipes não podem concentrar o foco em recursos novos e atraentes e desconsiderar o
caminho em que esses recursos são apresentados aos usuários. Contamos com práticas
de implantação seguras que ajudam a garantir que nossos clientes tenham acesso
ininterrupto à plataforma. Isso pode ser complicado quando é preciso liberar
atualizações de serviço com controle de versão sem tempo de inatividade.

Controle da exposição por meio de sinalizadores de

recursos
À medida que passamos da fase embrionária da implantação, controlando a exposição
com sinalizadores de recursos, ocasionalmente descobrimos um problema na produção.
Apesar de toda a nossa automação e revisões, às vezes ainda temos problemas. Como
dizem, não existe lugar melhor do que a produção!

Em geral, o monitoramento de integridade e a telemetria nos alertam quando algo não

está certo. Um desenvolvedor pode criar uma ramificação main , fazer uma correção e
fazer uma solicitação de pull main . Manter o mesmo fluxo de trabalho geral significa
que os desenvolvedores não precisam alternar o contexto ou aprender um processo
distinto para uma alteração de código distinta.

Para resolver uma implantação de hotfix, é necessária mais uma etapa: escolher a
alteração na ramificação de versão. Executamos uma implantação de hotfix fora da
ramificação da versão atual todos os dias úteis pela manhã, mas também podemos fazer
isso sob demanda para correções urgentes. A correção, na verdade, atinge primeiro a
produção fora da ramificação de lançamento. Mas como desenvolvemos primeiro main ,
sabemos que ele não regredirá no próximo sprint quando uma nova ramificação de
lançamento for criada a partir de main .

Os lançamentos de produtos locais são basicamente os mesmos, embora sem a fase

embrionária de implantação. Além disso, como fazemos mais testes manuais em
configurações e formas de dados variadas, há um intervalo maior entre a ramificação de
lançamento e o momento em que o produto chega às mãos dos clientes.

Deve-se cuidar pessoalmente da segurança

O foco é tornar as vulnerabilidades reais e pessoais. Essa é uma garantia de que as
pessoas realmente se importem. Também fazemos amplo uso de jogos de guerra para
encontrar e abordar riscos de segurança em todo o sistema, em código ou não. Quando
a equipe de socorro pode mostrar que obteve o código ao revirar uma caixa de diálogo,
isso realmente motiva o proprietário do código a resolver o problema e garantir que ele
não ocorra novamente em nenhum outro lugar. Esse tipo de competição é muito mais
real e pessoal do que uma análise estática, alertando sobre um risco potencial de XSS.
Criamos esse tipo de cultura e dinâmica por meio de jogos de guerra e outros exercícios
de segurança. As pessoas se orgulham de invadir o código umas das outras ou de
conseguir bloquear as tentativas. Isso inspira uma cultura de código seguro.

Não podemos prever todos os vetores de ataque, mas podemos supor que haverá uma
violação e planejar uma reação rápida a essa violação. Grande parte do trabalho de
segurança gira em torno disso para nossas equipes.

Finalmente, os seres humanos cometem erros. Às vezes, por preguiça, fazem coisas
como armazenar senhas em compartilhamentos de arquivos. Podemos aconselhar que
não façam isso, enviá-los para treinamentos em segurança e adotar medidas. A maioria
das pessoas aprende, mas basta a ação de uma pessoa para desestabilizar o sistema.
Você pode ter diferentes tipos de listas de melhores práticas, mas a menos que esteja
tornando isso real, precisa supor que as pessoas cometerão erros. Isso requer um certo
nível de supervisão para garantir que processos críticos sejam seguidos.

A engenharia é mais do que um parceiro de operações

Aprendemos desde cedo a tornar o local ativo uma parte importante das
responsabilidades da equipe de engenharia. Essa foi uma noção importante para nós
porque, antes, uma pessoa podia implantar algo, folgar no fim de semana e, ao voltar
na segunda-feira, deparar-se com 900 problemas de clientes que foram tratados
durante o fim de semana inteiro pelo atendimento ao cliente e por equipes de
operações. É importante que a engenharia pague o preço por problemas no local ativo.
Caso contrário, não há incentivo para criar sistemas que evitem esses problemas.
Quando for chamado às 2h da manhã para consertar algo que quebrou, você se
lembrará disso.

À medida que desenvolvemos essa responsabilidade, o site ativo é nosso item mais
importante e se torna o mantra da equipe inteira. Trata-se da experiência do cliente que
eles têm agora e não um mero imposto. Na verdade, as pessoas contam conosco para
oferecê-lo e nos orgulhamos disso. Esse precisa ser um diferencial do nosso produto.

A telemetria de produção é a pulsação do seu serviço

Para sobreviver no mundo acelerado, onde praticamente tudo pode dar errado,
precisamos de ótimos sistemas de alerta. Alertas não acionáveis, alertas redundantes ou
volumes de alertas excessivos levam você a ignorar todos os alertas. É fácil criar muitos
alertas; então, o processo realmente se resume a uma pergunta simples: esse alerta é
acionável? Isso garante que estamos nos envolvendo com os problemas dos clientes
certos e tratando-os o mais rápido possível.
À medida que a equipe de engenharia se concentrava em alertas acionáveis, eles
notaram que muitos problemas que surgem, especialmente no meio da noite, tendem a
ter correções semelhantes, pelo menos temporariamente. Isso resultou no foco em
sistemas que se destacavam em failover e autorrecuperação. Agora os problemas
surgem, geram alertas e se corrigem o suficiente para que a equipe de engenharia
aguarde até de manhã para correção. Isso não teria acontecido se a equipe de
engenharia apenas adiasse partes que mantinham outras pessoas acordadas à noite.
Agora, eles trabalham para equilibrar essas melhorias como parte não apenas do ritmo
acelerado do recurso, mas também da velocidade de melhoria da engenharia.

Resumo
A adoção de uma cultura de site ativo afetou a maneira como a Microsoft cria e fornece
software. Ao tornar as equipes de engenharia uma parte fundamental da segurança e
das operações, a qualidade do nosso código e a experiência do usuário final
melhoraram significativamente. Ser um participante pleno nas operações tornou a
engenharia um stakeholder fundamental, resultando em sistemas que são projetados
para operações melhores.
Segurança no DevOps (DevSecOps)
Artigo • 05/10/2023

A segurança é parte essencial do DevOps. Mas como uma equipe sabe se um sistema é
seguro? É realmente possível entregar um serviço totalmente seguro?

Infelizmente, a resposta é não. O DevSecOps é um esforço contínuo que exige a atenção

de todos em operações de desenvolvimento e TI. Embora o trabalho nunca seja
realmente feito, as práticas empregadas pelas equipes para evitar e lidar com violações
podem ajudar a gerar sistemas com a máxima segurança e resiliência.

"Essencialmente, se alguém desejar entrar, conseguirá... isso é um fato. Dizemos aos

clientes: número um, você está na disputa, mesmo que não soubesse disso. Número
dois, é quase certo que você seja infiltrado." -- Michael Hayden, ex-diretor da NSA e
da CIA

A conversa sobre segurança

As equipes sem uma estratégia formal do DevSecOps são incentivadas a começar o
planejamento o quanto antes. No início, pode haver resistência dos membros da equipe
sem total consciência das ameaças que existem. Outros podem não sentir que a equipe
está equipada para enfrentar o problema e que qualquer investimento especial seria
uma distração desperdiçada dos recursos de entrega. No entanto, é necessário iniciar a
conversa para criar um consenso quanto à natureza dos riscos, como a equipe pode
atenuá-los e se a equipe precisa de recursos ausentes no momento.

Espere que os céticos levantem alguns argumentos comuns, como:

O quanto a ameaça é real? Muitas vezes, as equipes não estimam o valor

potencial dos serviços e dos dados que estão encarregadas de proteger.
Nossa equipe é boa, certo? Uma discussão sobre segurança pode ser encarada
como uma dúvida sobre a capacidade da equipe de criar um sistema seguro.
Não acho que isso seja possível. Esse é um argumento comum entre engenheiros
juniores. Aqueles com experiência geralmente sabem melhor das coisas.
Nunca sofremos uma violação. Mas como você sabe disso? Como você saberia?
Debates intermináveis sobre valor. O DevSecOps é um compromisso sério que
pode ser percebido como uma distração do trabalho principal do recurso. Embora
o investimento em segurança precise ser equilibrado com outras necessidades, ele
não pode ser ignorado.
A mudança de mentalidade
A cultura do DevSecOps exige uma mudança importante de mentalidade. Você precisa
evitar violações, mas também supor que existem.

Componentes de estratégia de segurança

Existem muitas técnicas a serem aplicadas em busca de sistemas mais seguros.

Prevenção de violações Presumir violações

Modelos de ameaça Exercícios de jogo de guerra

Revisões de código Monitores de segurança central

Testes de segurança Testes de penetração de site dinâmico

SDL (Security Development Lifecycle)

Todas as equipes já devem ter pelo menos algumas práticas em vigor para evitar
violações. Escrever código seguro tornou-se mais padrão e há muitas ferramentas
gratuitas e comerciais para ajudar na análise estática e em outros recursos de teste de
segurança.

Mas, muitas equipes carecem de uma estratégia que pressuponha que as violações do
sistema são inevitáveis. Talvez seja difícil admitir que você foi violado, especialmente em
meio a conversas difíceis com a gerência, mas essa suposição pode ajudá-lo a tirar
dúvidas sobre segurança em seu próprio ritmo. Você não deseja descobrir tudo isso
durante uma emergência de segurança real.

Perguntas comuns para reflexão incluem:

Como detectar um ataque?

Como você responderá se houver um ataque ou penetração?
Como se recuperar de um ataque, por exemplo, quando os dados são vazados ou
adulterados?

Principais práticas do DevSecOps

Há várias práticas comuns do DevSecOps que se aplicam a praticamente todas as
equipes.

Primeiro, procure melhorar o tempo médio de detecção e o tempo médio de recuperação.

Essas métricas indicam quanto tempo leva para detectar uma violação e quanto tempo
leva para recuperar, respectivamente. É possível acompanhá-las com testes contínuos
no local ativo dos planos de resposta de segurança. Ao avaliar políticas em potencial, é
importante considerar como aprimorar essas métricas.

Pratique a defesa em profundidade. Quando ocorre uma violação, os invasores podem

obter acesso a redes internas e o que está contido nelas. Embora o ideal seja deter os
invasores antes de chegarem a esse ponto, uma política que supõe violações leva as
equipes a minimizar a exposição de um invasor que já conseguiu entrar.

Por fim, faça avaliações periódicas pós-violação de práticas e ambientes. Após

solucionar uma violação, sua equipe deve avaliar o desempenho das políticas e sua
própria adesão a elas. As políticas são mais eficazes quando as equipes de fato as
cumprem. Toda violação, real ou praticada, deve ser vista como uma oportunidade de
melhoria.

Estratégias para mitigar ameaças

Há um excesso de ameaças para enumerar todas elas. Algumas falhas de segurança
ocorrem devido a problemas em dependências como sistemas operacionais e
bibliotecas, portanto, mantê-los atualizados é fundamental. Outras ocorrem devido a
bugs no código do sistema que exigem uma análise cuidadosa para localizar e
consertar. A má gestão de segredos é a causa de muitas violações, bem como a
engenharia social. É uma ótima prática pensar sobre os tipos distintos de falhas de
segurança e o seu significado para o sistema.

Vetores de ataque
Considere um cenário em que um invasor obteve acesso às credenciais de um
desenvolvedor. O que é possível fazer?

Privilégio Tráfego

Eles podem enviar emails? Colegas de Phish

Eles podem acessar outros Fazer logon, mimikatz, repetir

computadores?

Eles podem modificar a fonte Injetar código

Eles podem modificar o processo de Injetar código, executar scripts

compilação/liberação?

Eles podem acessar um ambiente de Se um ambiente de produção assumir uma

teste? dependência do ambiente de teste, explore-o
 Privilégio Tráfego

Eles podem acessar o ambiente de Há tantas opções...

produção?

Como sua equipe pode se defender contra esses vetores?

Armazene segredos em cofres protegidos

Remover contas do administrador local
Restringir SAMR
Credential Guard
Remover servidores com hospedagem dupla
Assinaturas separadas
Autenticação multifator
Estações de trabalho com acesso privilegiado
Detectar com o ATP & Microsoft Defender para Nuvem

Gerenciamento de segredos
Todos os segredos devem ser armazenados em um cofre protegido. Os segredos
incluem:

Senhas, chaves e tokens

Chaves de conta de armazenamento
Certificados
Credenciais usadas em ambientes compartilhados que também não são de
produção

Você deve usar uma hierarquia de cofres para eliminar a duplicação de segredos.
Considere também como e quando os segredos são acessados. Alguns são usados em
tempo de implantação ao criar configurações de ambiente e outros são acessados em
runtime. Os segredos de tempo de implantação costumam exigir uma nova implantação
para obter novas configurações, enquanto os segredos de runtime são acessados
quando necessário e podem ser atualizados a qualquer momento.

As plataformas têm recursos de armazenamento seguro para gerenciar segredos em

pipelines de CI/CD e ambientes de nuvem, como Azure Key Vault e Ações do
GitHub .

Ferramentas úteis
 O Microsoft Defender para Nuvem é ideal para alertas genéricos de infraestrutura,
como malware, processos suspeitos etc.
Ferramentas de análise de código-fonte para testes estáticos de segurança de
aplicativos (SAST).
Segurança avançada do GitHub para análise e monitoramento de repositórios.
O mimikatz extrai senhas, chaves, códigos PIN, tíquetes e muito mais da
memória do [Link] , o Serviço do Subsistema de Autoridade de Segurança
Local no Windows. Ele só exige acesso administrativo ao computador ou uma
conta com o privilégio de depuração habilitado.
O BloodHound cria um gráfico dos relacionamentos em um ambiente do Active
Directory. A equipe vermelha pode utilizá-lo para identificar facilmente vetores de
ataque de difícil identificação rápida.

Exercícios de jogo de guerra

Uma prática comum da Microsoft é participar de exercícios de jogos de guerra. Estes são
eventos de teste de segurança em que duas equipes têm a tarefa de testar a segurança
e as políticas de um sistema.

A equipe vermelha assume o papel de invasor. Eles tentam usar como modelo os
ataques reais para encontrar lacunas na segurança. Eles podem explorar e também
demonstrar o impacto em potencial de suas violações.

A equipe azul assume a função da equipe do DevOps. Eles testam a capacidade de

detectar e responder aos ataques da equipe vermelha. Isso ajuda a melhorar a
consciência situacional e a avaliar a preparação e a eficácia da estratégia do DevSecOps.

Desenvolva uma estratégia de jogos de guerra

Os jogos de guerra são eficazes para reforçar a segurança porque motivam a equipe
vermelha a localizar e explorar problemas. Provavelmente será muito mais fácil do que o
esperado no início. As equipes que não tentam ativamente atacar seus próprios
sistemas em geral não sabem o tamanho e a quantidade de lacunas de segurança
disponíveis para os invasores. A equipe azul pode ficar desmoralizada no início porque
será derrotada repetidas vezes. Felizmente, o sistema e as práticas devem evoluir com o
tempo para que a equipe azul vença de modo consistente.

Prepare-se para jogos de guerra

Antes de iniciar os jogos de guerra, a equipe deve tratar problemas eventuais por meio
de um passe de segurança. Este é um ótimo exercício a ser executado antes de tentar
um ataque porque fornecerá uma experiência de linha de base para todos para
comparação após encontrar a primeira exploração mais adiante. Comece identificando
vulnerabilidades por meio de uma revisão manual de código e ferramentas de análise
estática.

Organizar as equipes

Organize as equipes vermelha e azul por especialidade. A meta é criar as equipes mais
capazes de cada lado para permitir a execução mais eficaz possível.

A equipe vermelha deve incluir alguns engenheiros e desenvolvedores preocupados

com a segurança bem familiarizados com o código. Também é útil aumentar a equipe
com um especialista em testes de penetração, se possível. Em caso de ausência de
especialistas internos, muitas empresas oferecem esse serviço junto com a mentoria.

A equipe azul deve ser composta por engenheiros com mentalidade operacional com
profundo conhecimento dos sistemas e registros disponíveis. Eles têm a melhor
oportunidade de detectar e abordar comportamentos suspeitos.

Executar os primeiros jogos de guerra

Aguarde até que a equipe vermelha seja efetivada nos primeiros jogos. Eles devem ser
capazes de ter êxito em meio a ataques simples, como encontrar segredos com baixa
proteção, injeção de SQL e campanhas de phishing bem-sucedidas. Reserve um bom
tempo entre as rodadas para aplicar correções e comentários sobre políticas. Isso varia
de acordo com a organização, mas você só deseja começar a próxima rodada quando
todos estiverem confiantes de que a rodada anterior foi minerada pelo seu valor.

Jogos de guerra em andamento

Após algumas rodadas, a equipe vermelha precisará contar com técnicas mais
sofisticadas, como cross-site scripting (XSS), explorações de desserialização e
vulnerabilidades do sistema de engenharia. Talvez seja útil trazer especialistas de
segurança externos para áreas como o Active Directory para atacar explorações mais
obscuras. A essa altura, a equipe azul não só deve ter uma plataforma reforçada para
defender, mas também fará uso de registro abrangente e centralizado para perícia pós-
violação.

"Os zagueiros pensam em listas. Os atacantes pensam em gráficos. Mesmo que isso
seja verdade, os atacantes vencem." -- John Lambert (MSTIC)
Com o tempo, a equipe vermelha levará muito mais tempo para atingir os objetivos. Se
isso ocorrer, será necessário um impacto limitado da descoberta e do encadeamento de
várias vulnerabilidades. Com o uso de ferramentas de monitoramento em tempo real, a
equipe azul deve começar a detectar tentativas em tempo real.

Diretrizes
Jogos de guerra não devem ser gratuitos para todos. É importante reconhecer que o
objetivo é gerar um sistema mais eficaz executado por uma equipe mais eficaz.

Código de conduta

Aqui está um exemplo de código de conduta usado pela Microsoft:

1. As equipes vermelha e azul não causarão problemas. Se o potencial de causar

danos for significativo, ele deverá ser documentado e abordado.
2. A equipe vermelha não deve comprometer mais do que o necessário para detectar
os ativos de destino.
3. As regras de bom senso se aplicam aos ataques físicos. Embora a equipe vermelha
seja incentivada a ser criativa com ataques não técnicos, como a engenharia social,
elas não devem imprimir crachás falsos, assediar pessoas etc.
4. Se um ataque de engenharia social for bem-sucedido, não divulgue o nome da
pessoa que foi comprometida. É possível compartilhar a lição sem alienar ou
constranger um membro da equipe com quem todos precisam continuar a
trabalhar.

Regras de envolvimento

Aqui estão exemplos de regras de contrato usadas pela Microsoft:

1. Não afeta a disponibilidade do sistema.

2. Não acesse dados de clientes externos.
3. Não enfraqueça demais as proteções de segurança em vigor em qualquer serviço.
4. Não execute de maneira intencional ações destrutivas em relação a recursos.
5. Proteja credenciais, vulnerabilidades e outras informações essenciais obtidas.

Resultados finais

Documente riscos de segurança ou lições aprendidas em uma lista de pendências de

itens de reparo. As equipes devem definir um contrato de nível de serviço (SLA) para
definir a rapidez com que os riscos de segurança serão tratados. Os riscos graves têm
prioridade, enquanto os problemas secundários podem ter um prazo de dois sprints.

Apresente um relatório à organização inteira com lições aprendidas e vulnerabilidades

encontradas. Esta é uma oportunidade de aprendizado para todos; portanto, aproveite-
a ao máximo.

Lições aprendidas na Microsoft

A Microsoft pratica regularmente jogos de guerra e aprendeu muitas lições ao longo do
percurso.

Os jogos de guerra se mostram eficazes para mudar a cultura do DevSecOps e

priorizar a segurança.
Não subestime os ataques de phishing pois eles são muito eficazes para os
invasores. Para conter o impacto, pode-se limitar o acesso à produção e exigir
autenticação de dois fatores.
O controle do sistema de engenharia leva ao controle de tudo. Controle
estritamente o acesso ao agente de build/lançamento, fila, pool e definição.
Pratique a defesa em detalhes para dificultar a vida dos invasores. Cada limite a ser
violado torna-os mais lentos e oferece outra oportunidade de capturá-los.
Nunca ultrapasse realms de confiança. Em testes, a produção não deve confiar em
nada.

Próximas etapas
Saiba mais sobre o ciclo de vida de desenvolvimento de segurança e o DevSecOps no
Azure .
Habilite o DevSecOps com o Azure e o
GitHub
Artigo • 05/10/2023

O DevSecOps, às vezes chamado de Secure DevOps, baseia-se nos princípios de

DevOps , mas coloca a segurança no centro de todo o ciclo de vida do aplicativo. Esse
conceito é chamado de "segurança shift-left": ele move a segurança upstream de uma
preocupação somente com a produção para abranger os estágios iniciais de
planejamento e desenvolvimento. Cada equipe e pessoa que trabalha em um aplicativo
precisa considerar a segurança.

A Microsoft e o GitHub oferecem soluções para criar confiança no código que você
executa em produção. Essas soluções inspecionam o código e permitem sua
rastreabilidade até itens de trabalho e insights sobre os componentes de terceiros que
estão em uso.

Proteger o código com o GitHub

Os desenvolvedores podem usar ferramentas de verificação de código que analisam
rápida e automaticamente o código em um repositório do GitHub para encontrar
vulnerabilidades de segurança e erros de codificação.

Você pode verificar o código para encontrar, fazer a triagem e priorizar correções para
problemas existentes. A varredura de código também impede que os desenvolvedores
introduzam novos problemas. É possível programar verificações para dias e horários
específicos ou acionar varreduras quando ocorre um evento específico no repositório,
como, por exemplo, um push. Você também pode acompanhar as dependências de seu
repositório e receber alertas de segurança quando o GitHub detectar dependências
vulneráveis.

Examine seu código com CodeQL e verificação de token

Gerencie avisos de segurança para seus projetos
Proteja dependências do seu código com o Dependabot

Controle seu trabalho com o Azure Boards

As equipes podem usar o serviço Web do Azure Boards para gerenciar projetos de
software. O Azure Boards fornece um conjunto avançado de recursos, incluindo suporte
nativo para Scrum e Kanban, painéis personalizáveis e relatórios integrados.
 Planeje e acompanhe o trabalho com o Azure Boards
Conectar o Azure Boards com o GitHub

Criar e implantar contêineres com o Azure

Pipelines
Integre clusters do Azure Pipelines e do Kubernetes com facilidade. Você pode usar os
mesmos documentos YAML para criar pipelines de vários estágios como código para
integração contínua e entrega contínua.

O Azure Pipelines integra o rastreamento de metadados em suas imagens de contêiner,

incluindo hashes de confirmação e números de problemas do Azure Boards, para que
você possa inspecionar aplicativos com confiança.

A capacidade de criar pipelines de implantação com arquivos YAML e armazená-los no

controle do código-fonte ajuda a gerar um loop de comentários mais curto entre
equipes de desenvolvimento e operação que dependem de documentos claros e
legíveis.

Armazene imagens do Docker no Registro de Contêiner do Azure

Crie uma imagem do Docker com o Azure Pipelines
Implante no Kubernetes com rastreabilidade total
Proteja seu Azure Pipelines

Executar e depurar contêineres com o Bridge to

Kubernetes
Desenvolver um Aplicativo Kubernetes pode ser desafiador. Você precisa do
Armazenamento de Arquivos do Kubernetes e do Docker. Você precisa imaginar como
testar seu aplicativo localmente e interagir com outros serviços dependentes. Talvez seja
necessário desenvolver e testar múltiplos serviços de uma só vez e com uma equipe de
desenvolvedores.

O Bridge to Kubernetes permite que você execute e depure o código em seu

computador de desenvolvimento, enquanto ainda está conectado ao cluster do
Kubernetes com o restante do aplicativo ou dos serviços. Você pode testar seu código
de ponta a ponta, acessar pontos de interrupção no código em execução no cluster e
compartilhar um cluster de desenvolvimento entre os membros da equipe sem
interferência.

Saiba mais sobre o Bridge to Kubernetes.

Impor a segurança do contêiner com o
Microsoft Defender para contêineres e o Azure
Policy
O Microsoft Defender para contêineres é a solução nativa de nuvem para proteger
contêineres.

Visão geral do Microsoft Defender para Contêineres

Noções básicas sobre clusters do Azure Policy para Kubernetes
AKS (Serviço de Kubernetes do Azure)

Gerenciar identidades e acesso com a

plataforma de identidade da Microsoft
A plataforma de identidade da Microsoft é uma evolução da plataforma de
desenvolvedor do Azure AD (Azure Active Directory). Ela permite que os
desenvolvedores criem aplicativos que conectem todas as identidades da Microsoft e
obtenham tokens para chamar APIs da Microsoft, como o Microsoft Graph ou APIs que
os desenvolvedores criaram.

Documentação da plataforma de identidade da Microsoft

O Azure AD B2C fornece a identidade de empresa para cliente como um serviço. Seus
clientes usam suas identidades de conta social, empresarial ou local preferenciais para
obter acesso de logon único a seus aplicativos e APIs.

Documentação do Azure AD B2C

O gerenciamento de acesso para recursos de nuvem é uma função crítica para

organizações que usam a nuvem. O RBAC do Azure (controle de acesso baseado em
funções do Azure) ajuda a gerenciar quem tem acesso aos recursos do Azure, o que
pode fazer com esses recursos e a quais áreas pode acessar.

Saiba mais sobre o gerenciamento de acesso com o RBAC do Azure

Você pode usar a plataforma de identidade da Microsoft para autenticar o restante das
ferramentas de DevOps, incluindo suporte nativo no Azure DevOps e integrações com o
GitHub Enterprise.

Autentique no GitHub Enterprise

No momento, um cluster do AKS (Serviço de Kubernetes do Azure) (especificamente, o
provedor de nuvem do Kubernetes) requer uma identidade para criar recursos
adicionais, como balanceadores de carga e discos gerenciados no Azure. Essa
identidade pode ser uma identidade gerenciada ou uma entidade de serviço. Se você
usar uma entidade de serviço, deverá fornecer uma ou o AKS criará uma em seu nome.
Se você usar a identidade gerenciada, uma será criada pelo AKS automaticamente. Para
clusters que usam entidades de serviço, a entidade de serviço precisará ser renovada
eventualmente para manter o cluster em funcionamento. O gerenciamento de entidades
de serviço adiciona complexidade, motivo pelo qual é mais fácil usar identidades
gerenciadas. Os mesmos requisitos de permissão se aplicam a entidades de serviço e
identidades gerenciadas.

Identidades gerenciadas são basicamente um wrapper ao redor das entidades de

serviço e simplificam o gerenciamento.

Use identidades gerenciadas no AKS

Gerenciar chaves e segredos com o Azure Key

Vault
O Azure Key Vault pode ser usado para armazenar com segurança e controlar o acesso a
tokens, senhas, certificados, chaves de API e outros segredos. Centralizar o
armazenamento de segredos de aplicativo no Key Vault permite que você controle a
distribuição. O Key Vault reduz consideravelmente a probabilidade de os segredos
serem vazados acidentalmente. Quando você usa o Key Vault, os desenvolvedores de
aplicativos não precisam mais armazenar informações de segurança no aplicativo, o que
elimina a necessidade de tornar essas informações parte do código. Por exemplo, um
aplicativo pode precisar se conectar a um banco de dados. Em vez de armazenar a
cadeia de conexão no código do aplicativo, armazene-o com segurança no Key Vault.

Armazene certificados, chaves e segredos com o Azure Key Vault

Monitorar seus aplicativos

Com o Azure Monitor, você pode monitorar seu aplicativo e a infraestrutura em tempo
real, identificando problemas com seu código e possíveis atividades suspeitas e
anomalias. O Azure Monitor se integra a pipelines de lançamento no Azure Pipelines
para habilitar a aprovação automática de portões de qualidade ou reversão de versão
com base nos dados de monitoramento.
Saiba como monitorar aplicativos e infraestrutura com o Azure Application Insights e o
Azure Monitor.

Gerenciamento de desempenho de aplicativo com o Application Insights

Monitore aplicativos conteinerizados com o Azure Monitor

Crie a arquitetura certa

A segurança é um dos aspectos mais importantes de qualquer arquitetura. A segurança
fornece garantias de confidencialidade, integridade e disponibilidade contra ataques
deliberados e abuso de dados e sistemas valiosos. Se essas garantias forem perdidas,
isso poderá afetar negativamente suas operações e receitas de negócios, bem como a
reputação de sua organização no mercado.

Arquitetura de aplicativos e serviços

Arquitetura do DevSecOps
Eventos e palestras do DevOps
Artigo • 11/09/2023

Destaques
Introdução à Azure DevOps Agile na Microsoft

Serviços do Azure DevOps Services

Vídeos e apresentações para serviços do Azure DevOps.

TÍTULO DESCRIPTION VÍDEO DOWNLOAD

Visão geral do Planeje de forma mais inteligente, colabore Video PPT

Azure DevOps melhor e entregue mais rapidamente com um
conjunto de serviços modernos de
desenvolvedor.

Planeje seu Qualquer pessoa que trabalhe em projetos de Video PPT

trabalho com o software sabe que há problemas para rastrear,
Azure Boards gerenciar e priorizar. O Azure Boards tem todos
os recursos de que sua equipe precisa para
gerenciar seu trabalho com êxito. Visualize
projetos com quadros Kanban, execute em
sprints, gerencie sua lista de pendências e use as
consultas para encontrar trabalho e visualizar
resultados. Introdução ao Azure Boards.

Gerencie e Se você escreve código, é necessário um lugar Video

armazene seu para armazenar e gerenciar esse código com um
código no Azure sistema de controle de versão confiável como o
Repos Git. O Azure Repos fornece a melhor solução Git
da categoria. Você recebe repositórios privados e
públicos, revisões de código social e muito mais
gratuitamente. Saiba como começar a usar o Git
 TÍTULO DESCRIPTION VÍDEO DOWNLOAD

no Azure Repos e como sua equipe pode usar

solicitações de pull para trabalhar em conjunto
no código.

Use o Azure Saiba como obter um repositório do GitHub e Video

Pipelines para adicionar builds contínuos usando o Azure
adicionar builds Pipelines. Você verá cada etapa ao fazer um
contínuos aos projeto [Link] GitHub e adicionar build
projetos do contínuos para validar a qualidade do código de
GitHub. cada solicitação de pull. O Azure Pipelines é
gratuito para projetos de código aberto.

Criar e implantar Com o Azure Pipelines, você pode criar e Video

seu código com o implantar código escrito em qualquer linguagem,
Azure Pipelines usando qualquer plataforma. Neste vídeo, você
aprenderá por que o Azure Pipelines é a melhor
ferramenta do planeta para integração e
implantação contínua (CI/CD) do seu código.

Introdução ao O Azure Artifacts ajuda você a gerenciar Video PPT

Azure Artifacts componentes de software fornecendo uma
interface do usuário intuitiva, bem como
ferramentas úteis para garantir imutabilidade e
desempenho para os componentes que você
criar ou consumir. Saiba como começar criando
um feed para um pacote npm a ser usado no
Azure Pipeline.

Teste manual e O Azure DevOps Test Plan fornece todas as Video

automatizado com ferramentas de que você precisa para testar com
o Azure Test Plans êxito seus aplicativos. Crie e execute planos de
teste manuais, gere testes automatizados e
colete os comentários dos usuários. Neste vídeo,
você verá os aspectos básicos sobre como
começar a usar o Azure Test Plan, para que possa
começar a testar seu aplicativo hoje mesmo.

Azure DevOps Server

Apresentação do Azure DevOps Server.

TÍTULO DESCRIPTION DOWNLOAD

Azure Compartilhe códigos, rastreie trabalhos e envie softwares usando PPT

DevOps as ferramentas para desenvolvedores integradas e hospedadas
Server localmente.
Lições aprendidas e histórias de jornada do
Azure DevOps
Vídeos e apresentações para lições aprendidas e histórias de jornada do Azure DevOps.

TÍTULO DESCRIPTION VÍDEO DOWNLOAD

60.000 testes em seis Uma boa cobertura de testes é essencial para Video PPT
minutos: crie um detectar problemas antes que uma solicitação
pipeline de teste de pull tenha sido mesclada, mas é necessário
confiável & implante que seja o tipo certo de teste, além de
com segurança com confiável. Sam Guckenheimer investiga a
o Azure Pipelines transformação de testes pela qual a equipe
dele na Microsoft passou ao iniciar sua jornada
de DevOps. Ele orienta você sobre as
mudanças pelas quais eles passaram e por quê,
e explica os dados que eles encontraram para
provar o caso de mudança e o que eles fizeram
para se mudar. Sam também dá detalhes sobre
o que é melhor coberto pelos testes de
unidade, que você deve deixar para revisão
manual de código na solicitação de pull e o
que é adequado para testes em produção.

Implantação Este relatório de experiência trata da mudança Video PPT

progressiva, de arquitetura de um monolito para práticas
experimentação, nativas da nuvem. Ele abrange a mudança
multilocação, sem gradual de locatário único para multilocatário,
tempo de escalabilidade vertical para escalabilidade
inatividade, horizontal, recursos fixos para custos variáveis
segurança na nuvem otimizados, atualizações periódicas para
atualizações de tempo de inatividade zero, lista
de pendências única para experimentação
contínua, implantação linear para progressiva
com um raio de impacto controlado, longos
ciclos de lançamento para testes contínuos,
opacidade para observabilidade e relatórios de
segurança de pré-lançamento para práticas de
segurança contínuas.

DevOps para IA Como o campo de IA é novo em comparação Video PPT

com o desenvolvimento de software
tradicional, as melhores práticas e soluções em
torno do gerenciamento de ciclo de vida
desses sistemas de IA ainda precisam se
solidificar. Esta palestra discutirá o que a
Microsoft fez em diferentes departamentos,
incluindo o Bing.
TÍTULO DESCRIPTION VÍDEO DOWNLOAD

Evoluindo o Uma visão geral da jornada Windows para Video PPT

Windows: esta transformar seu processos, ferramentas e
jornada para o cultura em um modelo de DevOps.
DevOps

Encontrar mais vídeos

Azure DevOps no YouTube
Vídeos de DevOps no Microsoft Shows