1. 1. Adoção do DevOps
1.1. Conceitos básicos
1.1.1. DevOps
1.1.1.1. O DevOps é uma filosofia sob a qual as equipes de negócios, de desenvolvimento e de operações colaboram continuamente para garantir que as soluções de TI estejam disponíveis aos negócios no prazo e que sejam executadas sem interrupções.
1.1.1.2. Aborda
1.1.1.2.1. Pessoas
1.1.1.2.2. Processos
1.1.1.2.3. Ferramentas
1.1.1.3. O que não é DevOps?
1.1.1.3.1. Não existe um cargo DevOps!
1.1.1.3.2. Não existe um time DevOps!
1.1.1.4. O que é DevOps
1.1.1.4.1. DevOps é Cultura
1.1.1.4.2. DevOps é integração entre áreas
1.1.1.4.3. DevOps é visão sistêmica do fluxo de valor
1.1.2. Entrega contínua
1.1.2.1. Disciplina de desenvolvimento de software na qual você cria software de maneira que ele possa ser liberado para produção a qualquer momento.
1.1.2.2. Infraestrutura como código é portanto um pré-requisito
1.1.2.3. Garante que tanto o código como a infraestrutura (“as code”) estejam em um estado implantável
1.1.2.4. Principais benefícios
1.1.2.4.1. Menor risco de implantação
1.1.2.4.2. Progresso confiável
1.1.2.4.3. Feedback do usuário
1.1.3. Integração contínua
1.1.3.1. Refere-se à integração, construção e teste de código dentro do ambiente de desenvolvimento, permitindo então a realização de testes sistêmicos.
1.1.4. Implantação contínua
1.1.4.1. Alterações são automaticamente colocadas em produção, resultando em muitas implantações de produção todos os dias
1.1.5. Infraestrutura ágil
1.1.5.1. É aplicar princípios ágeis à infraestrutura.
1.1.5.2. é tratar sua infraestrutura com código (infrastrucure as code).
1.1.5.2.1. permite que ambientes sejam criados a partir de um repositório de código-fonte, um backup de dados e um servidor físico disponível (“bare metal”).
1.1.6. Kata
1.1.6.1. Criação de estrutura para a prática diária e habitual de trabalho de melhoria
1.1.7. WIP
1.1.7.1. Trabalho que entrou no sistema produtivo (fluxo de valor), mas ainda não está concluído e disponível para um cliente ou usuário.
1.1.8. Débito técnico
1.1.8.1. Tudo aquilo que reduz a velocidade do time e que aumenta o TCO
1.1.8.2. Causado por:
1.1.8.2.1. Definição inicial insuficiente
1.1.8.2.2. Pressões do negócio
1.1.8.2.3. Ausência de processo ou compreensão
1.1.8.2.4. Componentes fortemente acoplados
1.1.8.2.5. Ausência de testes
1.1.8.2.6. Ausência de documentação
1.1.8.2.7. Ausência de colaboração
1.1.8.2.8. Desenvolvimento paralelo
1.1.8.2.9. Ausência de refatoração sistemática
1.1.9. Lean IT
1.1.9.1. 5 princípios
1.1.9.1.1. 1. Valor (Customer value)
1.1.9.1.2. 2. Fluxo de valor (Value Stream)
1.1.9.1.3. 3. Fluxo (flow)
1.1.9.1.4. 4. Sistema de produção puxado (pull)
1.1.9.1.5. 5. Perfeição (perfection)
1.1.10. Fluxo de valor
1.1.10.1. É o processo necessário para converter uma hipótese de negócios em um produto ou serviço que entregue valor ao cliente
1.1.10.2. deve ser desenhado de ponta a ponta – do pedido do cliente à entrega
1.1.10.3. Lead time
1.1.10.3.1. Tempo entre o momento em que um cliente pediu algo e o momento em que isso é entregue.
1.1.10.4. Tempo de processo (process time)
1.1.10.4.1. é efetivamente o esforço gasto em uma atividade (tempo que alguém realmente trabalhou em gasto, empregou tempo).
1.1.10.5. Percentual de conclusão e precisão (%C/P)
1.1.10.5.1. reflete a qualidade da saída de cada etapa em nosso fluxo de valor
1.1.11. Movimento Agile
1.1.11.1. Indivíduos e interação entre eles mais que processos e ferramentas
1.1.11.2. Software em funcionamento mais que documentação abrangente
1.1.11.3. Colaboração com o cliente mais que negociação de contratos
1.1.11.4. Responder a mudanças mais que seguir um plano
1.2. Princípios das três maneiras
1.2.1. Fluxo
1.2.1.1. Permite o fluxo rápido da esquerda para a direita do trabalho de Desenvolvimento para Operações e para o cliente
1.2.1.2. Práticas utilizadas
1.2.1.2.1. Tornar o trabalho visível
1.2.1.2.2. Gerenciar o trabalho em progresso (WIP)
1.2.1.2.3. Reduzir o tamanho dos lotes e intervalos de trabalho
1.2.1.2.4. Reduzir o número de transferências de trabalho
1.2.1.2.5. Aplicar a teoria das restrições
1.2.1.2.6. Remover desperdícios
1.2.2. Feedback
1.2.2.1. Permite o fluxo rápido e constante de feedback da direita para a esquerda em todos os estágios do fluxo de valor
1.2.2.2. Práticas utilizadas
1.2.2.2.1. Builds automatizados (integração contínua)
1.2.2.2.2. Testes integrados (serviços) automatizados
1.2.2.2.3. Entrega contínua
1.2.2.2.4. Testes unitários automatizados
1.2.2.2.5. Implantação contínua
1.2.2.2.6. Telemetria
1.2.2.2.7. Problemas são analisados e resolvidos coletivamente (swarming)
1.2.2.2.8. Otimizar o trabalho pensando na próxima etapa do fluxo
1.2.3. Aprendizado contínuo e experimentação
1.2.3.1. Possibilita a criação de uma cultura generativa e de alta confiança
1.2.3.2. Experimentação contínua, assumindo riscos e aprendendo com o sucesso e com o fracasso
1.2.3.3. Compreender que a repetição e a prática são o pré-requisito para o domínio.
1.2.3.4. É necessário criar um ambiente seguro para experimentação e aprendizagem organizacional.
1.2.3.4.1. Não procure culpados. Procure a causa-raiz do problema.
1.2.3.4.2. Procure descobrir como redesenhar o sistema para que o erro não volte a ocorrer.
1.2.3.4.3. Aprenda com os erros.
1.2.3.5. Práticas utilizadas
1.2.3.5.1. Alocar tempo para melhorar o trabalho diário
1.2.3.5.2. Transformar descobertas locais em melhorias globais
1.2.3.5.3. Introduzir falhas no sistema para aumentar a resiliência
1.2.3.5.4. Líderes devem reforçar uma cultura de aprendizado
1.3. Transformação DevOps
1.3.1. Categoria de serviços ou produtos
1.3.1.1. Greenfield
1.3.1.1.1. Novo projeto ou iniciativa de software
1.3.1.2. Brownfield
1.3.1.2.1. Produtos ou serviços existentes
1.3.1.2.2. Tem quantidades significativas de débito técnico
1.3.2. TI Bimodal
1.3.2.1. System of Records (SoR)
1.3.2.1.1. Tem um ritmo de mudança mais lento
1.3.2.1.2. ERP, Sistemas bancários
1.3.2.1.3. “Fazer certo“.
1.3.2.2. System of Engagement (SoE)
1.3.2.2.1. Tem um ritmo de mudança muito maior
1.3.2.2.2. Plataformas de mídias sociais, sites, e-commerce
1.3.2.2.3. “Fazer rápido“.
1.3.2.3. Pode ser conveniente dividir os sistemas nessas categorias; no entanto, é sabido que o conflito crônico central entre "fazer certo" e "fazer rápido" pode ser quebrado com o DevOps.
1.3.3. Passos para a transformação DevOps
1.3.3.1. Escolher um fluxo de valor a ser transformado.
1.3.3.2. Identificar os papéis (e times) necessários para criar valor para o cliente.
1.3.3.3. Criar um mapa de fluxo de valor para tornar visível todo o trabalho necessário.
1.3.3.4. Usar o mapa de valor para guiar as equipes sobre como criar mais valor mais rapidamente.
1.3.4. Papéis necessários para criar valor para o cliente
1.3.4.1. Dono de Produto
1.3.4.2. Desenvolvimento
1.3.4.3. QA
1.3.4.3.1. Assegura que existam ciclos de feedback para garantir que o serviço funcione conforme desejado
1.3.4.4. Operações
1.3.4.5. InfoSec
1.3.4.6. Gerentes de Liberação (Release managers)
1.3.4.7. Executivo de tecnologia ou gerente de fluxo de valor
1.3.5. Realizando a transformação
1.3.5.1. Defina uma meta clara, mensurável, realista e desafiadora.
1.3.5.2. Monte um time dedicado para realizar as mudanças no fluxo de valor.
1.3.5.2.1. Estratégia melhor que reservar 20% do tempo de algumas pessoas para a mudanças.
1.3.5.3. Crie um espaço físico separado para a equipe dedicada.
1.3.5.4. Reserve 20% do tempo para trabalhar em requisitos não funcionais e débitos técnicos.
1.3.6. Ferramentas compartilhadas
1.3.6.1. Backlog comum de trabalho
1.3.6.1.1. Trabalho possa ser priorizado globalmente
1.3.6.2. Fila de trabalho priorizada
1.3.7. Organização dos Times
1.3.7.1. Lei de Conway
1.3.7.1.1. como organizamos nossas equipes tem um efeito poderoso no software que produzimos, bem como nos resultados de arquitetura e produção resultantes
1.3.7.2. Estrutura organizacional
1.3.7.2.1. Funcional (orientada por processos)
1.3.7.2.2. Matricial
1.3.7.2.3. Mercado (orientada ao mercado)
1.3.7.3. Generalistas x especialistas
1.3.7.3.1. “I-SHAPE” (especialista)
1.3.7.3.2. “T-SHAPE” (generalista especialista)
1.3.7.3.3. “E-SHAPE”
1.3.7.4. Times pequenos (two pizza teams – 2PT)
1.3.8. Integrar Operações e Desenvolvimento
1.3.8.1. Criar recursos de autoatendimento (Ops as Service)
1.3.8.2. Incorporar engenheiros de Operações nos times de serviço
1.3.8.3. Estabelecer uma ligação entre Operações (Ops liaisons) e times de serviço
1.3.8.4. Integração por meio de rituais
1.3.8.4.1. Participar das Reuniões diárias
1.3.8.4.2. Participar das Retrospectivas
1.3.8.4.3. Integrar os trabalhos com quadro Kanban
2. 2. A primeira maneira: fluxo
2.1. Pipeline de implantação
2.1.1. Conceito
2.1.1.1. É uma manifestação automatizada de seu processo para levar o software do controle de versão para as mãos de seus usuários
2.1.2. Tipicamente ele incluirá os estágios de:
2.1.2.1. Automação de build e integração contínua
2.1.2.2. Automação de testes
2.1.2.3. Automação da implantação
2.1.3. Necessidade básica para um pipeline:
2.1.3.1. Fluxo de valor mapeado.
2.1.3.2. Orquestração de release e pipeline (continuous integration).
2.1.3.3. Infraestrutura como código (automatizada e self-service).
2.1.3.4. Testes automatizados (unidade, integração, funcionais).
2.1.4. Infraestrutura como código
2.1.4.1. Garantir o uso de ambientes semelhantes ao de produção (production-like) em todos os estágios do fluxo de valor (para todos os ambientes).
2.1.4.2. Ambientes
2.1.4.2.1. Devem ser criados sob demanda
2.1.4.2.2. Criados de maneira automatizada
2.1.4.2.3. Scripts e informações de configuração armazenadas no controle de versão
2.1.4.2.4. Também para o ambiente de produção
2.1.5. Contêineres
2.2. Repositório único de gerenciamento de versão
2.2.1. Restaurar o serviço de produção
2.2.2. Permite ver rapidamente todas as mudanças que podem ter contribuído para um problema
2.2.3. Fornece meios para reverter para um estado de execução anterior conhecido (rollback)
2.3. Adaptação da definição de pronto (DoD)
2.3.1. Objetivo é garantir que Desenvolvimento e QA estejam rotineiramente integrando o código com ambientes semelhantes ao de produção em intervalos cada vez mais frequentes
2.3.2. Isso é feito expandindo a definição de “pronto” para além da entrega de código correto.
2.4. Soluções para otimizar fluxo de valor
2.4.1. Utilize contêiners.
2.4.2. Utilize máquinas virtuais.
2.4.3. Use repositórios compartilhados (controle de versões).
2.4.4. Adapte a definição de pronto.
2.4.5. Gerencie o %C/P (Percentual de conclusão e precisão) no fluxo de valor (%C/P = %A/C).
2.4.6. Use ferramentas para automatizar a construção de ambientes.
2.4.7. Elimine ou automatize comunicações e aprovações.
2.4.8. Paralelize o que for possível no seu pipeline de implantação.
2.5. Teste automatizado
2.5.1. Parte primordial de uma iniciativa DevOps
2.5.2. Green build
2.5.2.1. Tudo o que está no controle de versão está em um estado que pode ser “buildado” e implantado
2.5.3. Pirâmide ideal de testes
2.5.3.1. A pirâmide ideal de testes
2.5.3.1.1. Testes unitários automatizados abundantes
2.5.3.1.2. Poucos testes GUI automatizados
2.5.3.1.3. Testes Manuais complementares
2.5.4. Desenvolvimento orientado a teste (test driven development)
2.5.4.1. Escreva um teste, veja falhar.
2.5.4.2. Escreva só o código suficiente para passar no teste.
2.5.4.3. Melhore o código sem alterar seu comportamento.
2.6. Integração contínua
2.6.1. Rstratégias de ramificação (branch)
2.6.1.1. Otimizado para produtividade individual
2.6.1.1.1. Pró: Ninguém atrapalha o trabalho de outra pessoa
2.6.1.1.2. Contra: A integração se torna um pesadelo
2.6.1.2. Otimizado para produtividade do time
2.6.1.2.1. Todos trabalham na mesma área comum
2.6.1.2.2. Contra
2.6.1.2.3. Pró
2.6.1.2.4. Desenvolvimento baseado no tronco (trunk).
2.6.1.3. O esforço necessário para juntar (merge) ramificações com êxito novamente aumenta exponencialmente à medida que o número de ramificações aumenta.
2.7. Lidando com débito técnico
2.7.1. Práticas para ajudar a resolver
2.7.1.1. Integração contínua
2.7.1.2. Desenvolvimento baseado no tronco
2.7.1.3. Investimento em automação de testes
2.7.1.4. Uso da infraestrutura como código e self-service
2.7.1.5. Reprodução de erros nas estações de trabalho
2.7.1.6. “one piece flow”
2.7.1.7. Bliz de melhoria (improvement / kaizen blitz)
2.7.1.7.1. Também é chamada de: hack days, hackathons e 20% de tempo de inovação (20% innovation time).
2.7.1.7.2. O objetivo é melhorar o trabalho diário, buscando resolver problemas enfrentados no dia a dia.
2.8. Liberações de baixo risco
2.8.1. Implantação (deployment)
2.8.1.1. Instalação de uma versão especificada
2.8.1.2. A implantação não precisa expor os clientes a uma nova versão do serviço.
2.8.2. Liberação (release)
2.8.2.1. A liberação ocorre quando disponibilizamos um recurso
2.8.2.2. Padrões de liberação baseados em ambiente
2.8.2.2.1. Implantação azul-verde (blue-green deployments)
2.8.2.2.2. Liberação canária (Canary releases)
2.8.2.3. Padrões de liberação baseados em aplicativos
2.8.2.3.1. Implementar alternância de funcionalidades
2.8.2.3.2. Lançamentos escuros
2.8.3. Arquitetura de software
2.8.3.1. Arquitetura fortemente acoplada (tightly-coupled architecture)
2.8.3.1.1. Monolítico
2.8.3.2. Arquitetura fracamente acoplada (loosely-coupled architecture)
2.8.3.2.1. Microsserviço
2.8.3.2.2. Características
3. 3. A segunda maneira: feedback
3.1. Telemetria
3.1.1. Monitorar a integridade e o desempenho
3.1.1.1. da aplicação
3.1.1.2. da infraestrutura
3.1.1.3. impacto nos negócios
3.1.2. Permite visualizar e resolver problemas mais rapidamente
3.1.2.1. Torna o time mais pro-ativo e menos reativo
3.1.3. Ambientes monitorados
3.1.3.1. pré-produção
3.1.3.2. produção
3.1.3.3. pipeline de implementação
3.1.4. Arquitetura de monitoramento moderna
3.1.4.1. Coletor de dados (data collection)
3.1.4.1.1. Coletam informações nas camadas de
3.1.4.2. Roteador de eventos (event router)
3.1.5. Telemetria self-service
3.1.5.1. Qualquer pessoa pode ter acesso às informações de telemetria
3.1.5.2. Utilizar radiadores de informações
3.1.5.2.1. Não há nada o que esconder, nem de clientes
3.1.6. Usar técnicas estatísticas
3.1.6.1. Permitir uma melhor da telemetria e permitir que a organização possa se antecipar à futuros problemas
3.2. Feedback
3.2.1. Ciclos rápidos de release com forte feedback!
3.2.2. Estratégias quando erros forem identificados em produção
3.2.2.1. Fix forward (correção)
3.2.2.1.1. Fazer alterações de código para corrigir o defeito as quais são implantadas em produção através do pipeline de implantação
3.2.2.1.2. Pode ser perigoso
3.2.2.1.3. Pode ser extremamente segura quando há testes automatizados, processo de implantação rápido e telemetria suficiente
3.2.2.2. Rollback (reversão)
3.2.2.2.1. Voltar para o release anterior usando features toggles ou retirando os servidores quebrados de produção, usando os padrões de liberação azul-verde ou canário.
3.2.2.2.2. Opção mais fácil e menos arriscada
3.2.2.2.3. Há perda de valor porque o usuário não pode mais usar a funcionalidade
3.2.3. Sustentando a operação
3.2.3.1. Engenheiros de confiabilidade do site - Site Reliability Engineers - SRE
3.2.3.1.1. Time de Produto (desenvolve)
3.2.3.1.2. Time de Ops (sustenta)
3.2.3.2. Diretrizes de lançamento (launch guidance)
3.2.3.2.1. Número de defeitos e severidade
3.2.3.2.2. Tipo / frequência de alertas
3.2.3.2.3. Cobertura de monitoramento (*)
3.2.3.2.4. Arquitetura do sistema (*)
3.2.3.2.5. Processo de implantação (*)
3.2.3.2.6. Higiene da produção
3.2.3.2.7. Não se trata de um checklist tradicional (* principais diferenças).
3.2.3.3. Lançamento de um novo serviço
3.2.3.3.1. LRR - Launch Readiness Review (Revisão de preparação para lançamento)
3.2.3.3.2. HRR - Hand-Off Readiness Review (Revisão de preparação para transferência)
3.2.3.3.3. A HRR é muito mais rigorosa e tem padrões de aceitação mais altos, enquanto a LRR é autorreferida pelas equipes de produto
3.2.4. UX como mecanismo de feedback
3.2.4.1. Investigação contextual (contextual inquiry).
3.2.4.1.1. Normalmente há um grande reação da equipe de produto ao utilizar esta técnicas
3.2.4.1.2. É quando a equipe do produto observa um cliente usar o aplicativo em seu ambiente natural, geralmente trabalhando em sua mesa
3.2.4.1.3. Os desenvolvedores devem observar os engenheiros Ops para entender como eles integram com os produtos criados para colocá-los em produção
3.2.4.1.4. A observação da UX ajuda a criar requisitos não funcionais e adicioná-los ao backlog compartilhado de trabalho
3.3. Desenvolvimento orientado por hipóteses
3.3.1. Quanto mais rápido pudermos experimentar, iterar e integrar feedback, mais rápido poderemos aprender e sair à frente da concorrência
3.3.2. Realizar os experimentos mais baratos e mais rápidos possíveis para validar
3.3.3. Técnicas
3.3.3.1. Teste A/B (A/B Testing)
3.3.3.1.1. Duas opções são colocadas em produção para verificar qual retorna mais resultado
3.3.3.1.2. Pode-se usar feature toggles
3.3.3.2. Desenvolvimento orientado à hipótese (hypothesis-driven development)
3.4. Revisão e coordenação
3.4.1. Aprovações vs revisões por pares
3.4.1.1. A criação de etapas de aprovação por parte de pessoas que estão cada vez mais distantes do trabalho pode, na verdade, reduzir a probabilidade de sucesso
3.4.1.2. Criar práticas de controle efetivas que se assemelhem mais à revisão por pares, reduzindo a dependência de órgãos externos para autorizar as mudanças
3.4.2. Revisão por pares no Git Hub
3.4.2.1. Pull request
3.4.2.1.1. Um bom pull request é efetivo quando
3.4.2.1.2. Processo
3.4.3. Tipos de revisão por pares
3.4.3.1. Sobro os ombros (Over-the-shoulder)
3.4.3.2. Passagem de e-mail (Email pass-around)
3.4.3.3. Revisão de código assistida por ferramentas (Tool-assisted code review)
3.4.3.4. Programação por pares (Pair programming)
3.4.3.4.1. Navegador
3.4.3.4.2. Motorista
4. 4. A terceira maneira: aprendizado e experimentação contínua
4.1. Objetivo é criar Resiliência
4.1.1. Capacidade de se recuperar de situações de cria e aprender com elas.
4.2. Aprendizado
4.2.1. Criação de resiliência partir de falhas na produção
4.2.1.1. O exército símio (the simian army)
4.2.1.1.1. Chaos Gorilla
4.2.1.1.2. Chaos Kong
4.2.1.1.3. Latency Monkey
4.2.1.1.4. Conformity Monkey
4.2.1.1.5. Janitor Monkey
4.2.1.1.6. Doctor Monkey
4.2.1.1.7. Security Monkey
4.2.1.2. Game days
4.2.1.2.1. Criar resiliência por meio da destruição
4.2.1.2.2. Ajudar as equipes a simular falhas para que possam praticar e aprender
4.2.1.2.3. Passos
4.2.2. Reunião blameless post mortem
4.2.2.1. Passos para realizar a reunião
4.2.2.1.1. 1 - Agendar a reunião e convocar pessoas necessárias
4.2.2.1.2. 2 - Realizar reunião
4.2.2.1.3. 3 - Publicar os resultados da reunião
4.2.3. Criação de resiliência partir de falhas na produção
4.3. Descobertas
4.3.1. Objetivo: Transformar este aprendizado local em global
4.3.1.1. Práticas que a GitHub adotou
4.3.1.1.1. Automação do chat
4.3.1.2. Automatizar processos e atividades
4.3.1.3. Repositório de código fonte centralizado
4.3.1.3.1. Qualquer atualização em qualquer componente já está automaticamente disponível para todos.
4.3.1.4. Comunidades de prática
4.3.1.5. Histórias de usuário de operações
4.3.1.5.1. Quando há um trabalho de Operações que não pode ser totalmente automatizado ou feito autoatendimento, o objetivo deve ser o de torna-lo recorrente o mais repetitivo e determinístico possível
4.3.1.5.2. Representam atividades de trabalho que podem ser reutilizadas em todos os nossos projetos
5. 5. Segurança da informação e gerenciamento de mudança
5.1. Segurança da informação
5.1.1. Conformidade por demonstração (Compliance by demonstration)
5.1.1.1. Ter pessoas de InfoSec participando das reuniões de review/demonstração
5.1.1.1.1. Entender os objetivos do time no contexto dos objetivos organizacionais
5.1.1.1.2. Observar as implementações conforme elas estão sendo construídas
5.1.1.1.3. Fornecer orientação e feedback nas etapas iniciais do projeto
5.1.1.2. Permite reduzir drasticamente o uso de listas de verificação estáticas
5.1.1.3. InfoSec ganha contexto de negócio para tomar melhores decisões baseadas em riscos
5.1.2. Registro de incidentes
5.1.2.1. Utilizar mesma ferramenta de Ops e Desenvolvimento
5.1.2.2. Garante que o trabalho seja visível e possa ser priorizado em relação a todos os outros trabalhos
5.1.3. Integrar a InfoSec
5.1.3.1. Utilizar o repositório de código fonte comum
5.1.3.1.1. Incluir quaisquer mecanismos ou ferramentas que nos ajudem a garantir que nossos aplicativos e ambientes estejam seguros
5.1.3.1.2. Facilita muito o trabalho diário porque qualquer coisa que seja criada está disponível, pesquisável e reutilizável
5.1.3.1.3. Serve como um mecanismo de comunicação
5.1.4. Integrar InfoSec com pipeline de implantação
5.1.4.1. Integrar testes de segurança ao pipeline de implantação
5.1.4.1.1. Garantir a segurança do pipeline
5.1.4.1.2. Fornecer feedback rápido sobre a segurança da informação
5.1.4.2. Tipos de testes
5.1.4.2.1. Análise estática (Static analysis)
5.1.4.2.2. Análise dinâmica (Dynamic analysis)
5.1.4.2.3. Integridade do código fonte e assinatura de código (Source code integrity and code signing)
5.1.4.3. Riscos de segurança com uso de pipeline de implantação
5.1.4.3.1. Desenvolvedores introduzirem código que permite acesso não autorizado.
5.1.4.3.2. Usuários não autorizados que obtêm acesso ao nosso código ou ambiente.
5.2. Gerenciamento de mudança
5.2.1. A maioria das mudanças não precisará de aprovação manual quando há baixo
5.2.2. Tipos de mudança
5.2.2.1. Padrão
5.2.2.1.1. Baixo risco
5.2.2.1.2. É pré-aprovada
5.2.2.2. Normal
5.2.2.2.1. Existe aprovação
5.2.2.2.2. Envolve comitê
5.2.2.3. Urgente
5.2.2.3.1. Quando é necessário colocar algo em produção imediatamente
5.2.3. Pipeline de implantação aumenta a reputação de implantações
5.2.4. Práticas para ganhar confiança sobre as mudanças
5.2.4.1. Mostrar a lista de mudanças feitas por um período significativo (trimestre).
5.2.4.2. Compartilhar a lista completa dos problemas de cada mudança.
5.2.4.3. Compartilhar o indicador MTTR (tempo médio para reparo - mean time to repair).
5.2.4.4. Demonstrar que há controle sobre o ambiente.
5.2.4.5. Demonstrar que erros são detectados e corrigidos rapidamente.