Os 10 mandamentos da implantação contínua

Este artigo apareceu pela primeira vez na revista IEEE Software, que oferece informações sólidas e revisadas por pares sobre questões de tecnologia estratégica. Para lidar com os desafios de gerenciar empresas confiáveis e flexíveis, os gerentes de TI e líderes técnicos contam com o IT Pro para soluções de ponta..

Conteúdo relacionado de patrocinadores

Com base em discussões que ocorreram no Continuous Deployment Summit, evento ocorrido no campus do Facebook, os pesquisadores destacaram 10 mandamentos sobre as práticas de implantação contínua. Esses mandamentos representam um conjunto de abordagens e crenças que orientam a prática atual e estabelecem um alvo tangível para a validação empírica.

O Facebook viu seu número de desenvolvedores crescer a um fator de 20, em um período de seis anos, enquanto o tamanho da base do código aumentou a um fator de 50. No entanto, em vez de desacelerar, a produtividade dos desenvolvedores permaneceu constante, conforme medido em linhas (de código) por desenvolvedor. O Facebook atribui grande parte desse sucesso às suas práticas de implantação contínua.

A implantação contínua, do inglês continuous deployment, envolve o teste automático de alterações incrementais do software, e normalmente a implantação destas em ambientes de produção. Com isso, as atualizações podem chegar aos clientes em dias ou até horas. Essas mudanças super-rápidas mudaram fundamentalmente a forma de pensar da área de engenharia de software, com grande impacto na cultura, habilidades e práticas das empresas.

Para estudar esta mudança fundamental, os pesquisadores organizaram uma conferência sobre implantação contínua, o Continuous Deployment Summit, de um dia no campus do Facebook em julho de 2015. O objetivo do encontro era compartilhar as melhores práticas e desafios na transição para a implantação contínua. Estiveram presentes um representante de cada uma dessas empresas: Cisco, Facebook, Google, IBM, LexisNexis, Microsoft, Mozilla, Netflix, Red Hat e SAS. Essas 10 empresas representam um espectro de pioneiros da implantação contínua com implementações maduras para empresas com bagagem arquitetônica que exigem uma transição de vários anos para implantação contínua.

As implantações de seus produtos variam de 1.000 vezes ao dia, a uma ou duas vezes por ano. No entanto, todas elas se esforçam para aproveitar a implantação mais rápida para entregar produtos de maior qualidade a seus clientes, cada vez mais rápido. Para conseguir isso, eles usam análises avançadas para traduzir uma enorme quantidade de dados de telemetria em produtos aprimorados.

Aqui, discutiremos a conferência com foco nos dez principais mandamentos que surgiram deste encontro. Esses mandamentos representam um conjunto funcional de abordagens e crenças que orientam a prática atual e estabelecem um alvo tangível para a validação empírica pela comunidade de pesquisa.

Práticas usadas nas empresas

Antes do encontro, 17 equipes de nove das 10 empresas completaram uma pesquisa sobre práticas de implantação contínua. Os entrevistados indicaram com que frequência sua empresa usou cada uma das 11 práticas comuns. (A Tabela 1 define algumas dessas práticas e outros termos de implantação contínua.) Embora os entrevistados pudessem indicar o uso parcial de uma prática, nenhum deles o fez. Ou eles usaram uma prática o tempo todo, ou não usaram, ou não souberam responder.

(Click na imagem para ampliar)

A Figura 1 resume as práticas das empresas. As práticas mais comuns foram o teste unitário automático, uso de servidor de teste, e o desenvolvimento em branches no controle de versão (branching). As empresas também usaram frequentemente a revisão de código como um sinal manual em um processo de implantação altamente automatizado. Observamos um ressurgimento da revisão do código, agora geralmente executado por ferramentas distribuídas simples, porque os engenheiros estão mais motivados a deixar que outros vejam seu código antes que ele seja rapidamente implantado e os defeitos se tornem públicos. Além disso, as empresas usaram a mudança de propriedade, onde os engenheiros ficam de plantão para lidar com as implicações de seus próprios defeitos, em vez de a empresa manter um grupo de suporte de campo separado para lidar com todos os defeitos. Assim, os engenheiros estão mais motivados para implantar software de alta qualidade.

(Click na imagem para ampliar)

FIGURA 1. O uso de 11 práticas de implantação contínua pelos respondentes da pesquisa (17 equipes de nove empresas responderam). Para mais informações sobre algumas dessas práticas, veja a Tabela 1.

Os entrevistados também relataram os benefícios que eles perceberam a partir das práticas de implantação contínua. Os benefícios mais comuns foram a melhoria da velocidade de entrega de funcionalidades, qualidade e satisfação do cliente. Além disso, os funcionários ficaram mais satisfeitos devido ao feedback mais rápido dos clientes e a diminuição do estresse. Embora tornar os defeitos públicos com uma implantação rápida pode aumentar o estresse, a compensação é que o estresse de perder um prazo de liberação diminui quando o próximo trem de lançamento logo sai da estação. Em contraste, manter limites de implantação rigorosos e infrequentes podem prejudicar a qualidade (3). Com a implantação contínua, os gerentes perceberam que as decisões foram mais orientadas por dados com feedback rápido. As equipes também acreditaram que alcançaram maior produtividade e melhor colaboração em geral.

Além disso, os entrevistados responderam sobre os desafios da implantação contínua. A arquitetura, segurança e consistência podem ser comprometidas quando o desenvolvimento enfatiza a velocidade de entrega (4). Com implantações mais frequentes, a capacidade de testar várias configurações de software é muitas vezes limitada, fazendo com que alguns recursos comuns, como a acessibilidade, não sejam testados (5). As equipes podem resistir às mudanças em seu processo de desenvolvimento, especialmente quando os papéis tradicionais devem ser combinados em uma única equipe. Os produtos com arquiteturas monolíticas, dívida técnica e poucos testes automatizados podem ter um aumento mais lento na frequência de implantação, levando potencialmente anos para chegar a implantação contínua. Finalmente, os produtos que exigem altos níveis de segurança e regulação podem não ser capazes de adotar completamente a implantação contínua.

Os mandamentos

Embora nenhum dos seguintes mandamentos tenha sido aplicado por todas as 10 empresas, todos os participantes concordaram com esses conceitos.

1. Cada funcionalidade é um experimento

Jez Humble argumenta que a chave para a execução de uma empresa enxuta é "adotar uma abordagem experimental para o desenvolvimento de produtos" (6). Nesta visão, nenhuma funcionalidade provavelmente irá persistir por muito tempo sem dados que justifiquem sua existência.

Anteriormente, as funcionalidades eram cuidadosamente consideradas e negociadas. Elas eram projetadas, desenvolvidas e depois entregues. A evidência raramente apoiava as decisões.

Com a implantação contínua, os desenvolvedores tratam cada funcionalidade planejada como um experimento, permitindo que algumas funcionalidades implantadas sejam descontinuadas. Por exemplo, na Netflix, se não houver pessoas suficientes passando o cursor sobre um novo elemento, um novo experimento pode mover o elemento para um novo local na tela. Se todos os experimentos mostrarem falta de interesse, a nova funcionalidade será excluída.

Os participantes do encontro relataram o uso de várias práticas de apoio. Geralmente, as empresas coletam estatísticas em todos os aspectos do software. Eles registram métricas de desempenho e estabilidade, como horários de renderização de página, acessos à colunas do banco de dados, exceções e códigos de erro, tempos de resposta, e taxas de chamada a métodos de APIs. Para que as empresas coletem essas informações, a arquitetura do software deve ser projetada com uma mentalidade de telemetria. Em vez de manter cópias de registros de desempenho e erros em um único servidor, as empresas transmitem as métricas para um armazenamento de dados centralizado na memória.

Finalmente, para apoiar a análise de dados, várias empresas empregam uma grande equipe de cientistas de dados que chegam a ser até um terço da equipe de engenharia. Essas empresas criam e usam um rico conjunto de ferramentas de exploração de dados, incluindo linguagens de consulta de dados personalizadas.

No entanto, existem vários desafios. Por exemplo, algumas empresas aumentaram rapidamente a infraestrutura para armazenar dados relacionados a métricas. A Netflix coletou inicialmente 1,2 milhão de métricas relacionadas aos seus serviços de transmissão, mas isso logo aumentou para 1 bilhão de métricas. Isso não só superou o limite de armazenamento de dados na memória, mas a empresa também precisou considerar mais cuidadosamente quais dados eram essenciais para a experimentação.

Além disso, as consultas de engenharia para extrair informações relevantes de uma funcionalidade são complexas. Um participante comentou: "Você precisa de um doutorado para escrever uma consulta de análise de dados". É necessário um investimento significativo em telemetria e análise. Investir nesses esforços separadamente pode ser dispendioso. Os participantes discutiram situações em que haviam coletado enormes quantidades de dados, mas tiveram que refazer o experimento porque faltava um dado essencial.

No entanto, nem todas as funcionalidades garantem uma experimentação completa, especialmente as que não são voltadas diretamente ao usuário, como as de armazenamento. Além disso, os desenvolvedores devem considerar cuidadosamente as implicações de privacidade da coleta de dados.

À medida que as empresas avançam, enfrentarão o desafio de como estabelecer uma cultura de experimentação das funcionalidades. Como permitir que as equipes coletem consistentemente informações específicas ao longo do ciclo de vida de uma funcionalidade sem apresentar demasiada sobrecarga ou processo?

2. O custo da mudança morreu

O custo para mudar o código durante a sua produção pode ser surpreendentemente barato. Isso contrasta diretamente com as previsões de que correções no software implantado se tornaria exponencialmente mais caro. Em 1981, Barry Boehm mostrou que o custo da mudança aumenta dez vezes em cada fase do desenvolvimento (7). Por exemplo, se a correção de uma alteração durante a fase de codificação custa US $ 100, corrigi-lo durante o teste custará US $ 1.000, e durante a produção custará US $ 10.000.

Com a implantação contínua, o tempo entre desenvolvimento e descoberta de defeito em produção é geralmente curto, na ordem de horas ou dias. Por exemplo, um desenvolvedor libera uma nova funcionalidade para a produção após dois dias de trabalho. No dia seguinte, um usuário relata um defeito. A correção deve ser eficiente porque o desenvolvedor acabou de trabalhar naquilo, então é mais fácil lembrar do que acabou de fazer. Com a implantação contínua, todas as fases de desenvolvimento acontecem o "mesmo dia" pela mesma pessoa, ou pessoas, e o aumento exponencial de custos não acontece. Assim, a curva de custo de mudança se aplana: uma mudança que custa US $ 100 para ser consertada durante o desenvolvimento também custará US $ 100 durante a produção.

O Google descobriu que a extensão das mudanças a serem revisadas durante a solução de problemas é pequena, o que torna a identificação do responsável mais fácil e rápida. Além disso, quando as atualizações são implantadas em produção, a equipe de desenvolvimento toma conhecimento dos desafios do processo de lançamento mais rapidamente através do feedback. No Facebook, os desenvolvedores devem confirmar através do sistema de bate-papo interno que eles estão no modo de espera ou que suas alterações não serão liberadas durante um dos dois lançamentos de produção diários. Assim, todos os desenvolvedores com alterações implantadas podem reagir a qualquer erro encontrado minutos depois de entrar em operação.

Praticamente nenhum dos participantes do encontro discutiu o custo das mudanças, indicando que os efeitos são mínimos em comparação com outras preocupações com os custos.

Em modelos mais tradicionais de implantação e lançamento, o código passa por rodadas de garantia de qualidade para eliminar defeitos. Se o ciclo de lançamento for de três a seis meses, os defeitos recentemente encontrados podem não ser apontados pelos usuários por mais três a seis meses. Mesmo ciclos de manutenção mais curtos ainda são ordens de magnitude mais longas que as implementações diárias. A implantação contínua permite aos desenvolvedores implantar rapidamente novas funcionalidades e corrigir defeitos.

A implantação contínua não garante que um defeito seja encontrado imediatamente. Se for encontrado mais tarde, o custo da mudança é o mesmo que antes. No entanto, se um defeito não for encontrado depois de muito tempo, é provável que a funcionalidade seja de baixa utilização.

3. Seja rápido para implantar, mas lento (ou mais lento ainda) para liberar

A implantação do código em produção não significa necessariamente que as funcionalidades voltadas ao usuário estejam disponíveis para clientes imediatamente. Às vezes, uma nova funcionalidade pode ser implantada e avaliada durante a produção por vários meses antes de ser divulgada publicamente.

Por exemplo, no Instagram (uma empresa do Facebook), um engenheiro pode querer criar um novo recurso para encadear mensagens em comentários de fotos. Ao implantar o código em produção, o engenheiro pode avaliar e testar o recurso em um ambiente ao vivo, executando o código, mas mantendo os resultados invisíveis aos usuários ao não ativar o novo recurso na interface do usuário. Este lançamento secreto (dark launche) permite que o engenheiro implante e estabilize lentamente pequenos pedaços diretamente durante a produção sem afetar a experiência do usuário. Após a estabilização, o engenheiro pode ativar o recurso e liberá-lo.

Os participantes do encontro descreveram várias técnicas e razões para retardar os lançamentos. O Instagram geralmente usa dark launches para implantar e estabilizar recursos por até seis meses antes de lançá-los oficialmente. A Microsoft geralmente implementa grandes mudanças arquitetônicas, usando uma combinação de dark launches e funcionalidades marcadas (feature flags). Feature flag significa que uma funcionalidade é implantada, mas desativada até que esteja pronta para ser lançada; O desenvolvedor desativará e desligará a funcionalidade através de um servidor de configuração. Esta prática permite que a Microsoft evite lidar com problemas de integração ou a manutenção de branches de funcionalidades de longa duração. A implantação de mudanças precoce e frequentemente, e normalmente em produção, reduz o fricção geral da implantação.

No entanto, esta abordagem apresenta muitos desafios. A configuração dinâmica permite aos desenvolvedores reagir rapidamente a problemas ao desativarem as funcionalidades, mas os desenvolvedores podem facilmente causar interrupções ao ativarem inadvertidamente estados de configuração inválidos. Muitos participantes do encontro relataram que embora as mudanças de código passassem por testes e análises rigorosos, não havia necessariamente ferramentas suficientes disponíveis para testar e avaliar mudanças de configuração com o mesmo rigor.

Limpar e remover feature flags desnecessárias é uma prática altamente variável que muitas vezes contribuiu para a dívida técnica. Para algumas empresas presentes no encontro, criar um ambiente de produção duplicado, ou sombra da infra-estrutura, é muito caro ou complicado. Eles são forçados a fazer testes durante a produção, mesmo que isso não seja estritamente desejado.

Muitas técnicas podem controlar a velocidade com que os clientes vêem novas mudanças. Uma empresa pode liberar software lentamente, todos os dias, enquanto ainda está implantando. As empresas devem investir em esforços extras de engenharia para garantir que as estratégias de lançamento atrasado e os testes durante a produção não afetem negativamente a experiência do usuário.

4. Investir para sobreviver

A sobrevivência no mercado de hoje significa investir em ferramentas e automação. As práticas já vistas como práticas recomendadas ou medidas de maturidade são agora a espinha dorsal de um processo que depende da implantação rápida. O teste automatizado do sistema costumava ser uma maneira de executar grandes conjuntos de testes para verificar se as aplicações empresariais não tinham regredido entre os lançamentos. Agora, esses testes são necessários para que os desenvolvedores possam obter feedback rápido e para que os lançamentos possam ser automatizados para aceitar ou recusar um patch. Esta automação permite que equipes pequenas gerenciem grandes infraestruturas.

As empresas no topo do espectro de implantação contínua, como Instagram e Netflix, dizem que a automação paga dividendos maciços. O Facebook descobriu que uma pequena equipe focada em ferramentas e automação de lançamento pode capacitar uma equipe muito maior de desenvolvedores focados em funcionalidades. O Instagram usa a automação para impor o processo. O investimento em ferramentas permite capturar fluxos de trabalho e tarefas comuns em operações repetitivas e executáveis que desenvolvedores ou sistemas automáticos podem executar. O processo de captura por ferramentas permite que os processos sejam testados, versionados e vetados como código de produção.

O Instagram enfrentou desafios com automação parcial de um processo, que tem o risco de os desenvolvedores ignorarem as etapas implícitas necessárias durante a implantação. Por exemplo, um desenvolvedor pode esquecer de obter manualmente um bloqueio de operação em um serviço (através de outra ferramenta) antes de executar um comando de implantação.

Os praticantes estão concluindo que para que eles permaneçam competitivos e sobrevivam, as melhores práticas, como testes unitários automatizados, são indispensáveis. Fornecer um produto superior agora está acoplado à velocidade com a qual as melhorias são implantadas. Essa mudança exige que as empresas invistam estrategicamente na automação, pois o escopo e a escala mudam ao longo do tempo.

5. Você é a pessoa do suporte

Os desenvolvedores têm o poder e a liberdade de implantar mudanças por sua própria iniciativa. Com grandes poderes vem grandes responsabilidades. Se o código quebra durante a produção, de quem é a responsabilidade - a equipe de desenvolvimento ou de operações?

Os métodos tradicionais de software encorajam os silos de responsabilidade. Os desenvolvedores "jogam código para a frente" para equipes de garantia de qualidade (QA), que, em seguida, jogam para a frente, para as equipes de operações. Vários participantes do encontro discutiram sobre desenvolvedores que codificam, mas não param para entender requisitos, user stories ou ambientes de produção. Quando se é dono do recurso ou da mudança no código, isso muda da água para o vinho (desde o início até a implantação), a carga fica com o desenvolvedor. Este fardo significa que, quando as coisas quebram, o desenvolvedor é aquele que recebe a chamada de suporte e deve resolver o problema, independentemente da hora do dia.

Como os desenvolvedores são os donos das alterações do início ao fim, as estruturas de equipe tradicionais devem mudar. A Netflix não possui equipes de operações dedicadas. Embora ainda existam funções funcionais, como QA ou operações, elas são incorporadas em equipes de desenvolvimento, criando centenas de equipes ligeiramente acopladas, mas altamente alinhadas. Em vez de ter uma função dedicada (por exemplo, QA, operações ou desenvolvimento), as equipes possuem uma seção transversal representativa das funções necessárias. O Instagram encontrou valor em equipes com membros que se concentram em áreas, mas são, como parte da equipe, responsáveis pela vida de um recurso. Tanto o Instagram como a Red Hat empregaram rotações de suporte nas quais cada membro da equipe dedica tempo no atendimento ao cliente, o que resulta em dor compartilhada.

Dar autonomia às equipes vem com desafios - por exemplo, como as equipes autônomas se integram de forma confiável? A Netflix consegue essa integração através de uma arquitetura de microservices que requer que as equipes criem APIs que elas mantenham e assegurem que sejam estáveis de alteração para alteração. O Google impõe a comunicação do serviço da equipe através de um tipo de API comum e um tipo de dados definido que todos os serviços devem usar. Com padrões de comunicação definidos, as equipes são livres para construir o que eles precisam para realizar suas tarefas, de qualquer maneira que seja mais eficiente para elas.

Do ponto de vista organizacional, como as equipes migram para essa nova visão do mundo? A LexisNexis notou que com estruturas de organização tradicionais, diferentes equipes reportam a diferentes partes da organização com diferentes objetivos, o que torna a integração dessas equipes muito mais difícil. Além disso, outras áreas que requerem mudanças tornam difícil lidar com equipes e aspectos de propriedade (como testes manuais e restrições de recursos). O papel do desenvolvedor está se tornando menos horizontal e mais vertical, aumentando a responsabilidade, mas também capacitando os desenvolvedores a entender o impacto de suas mudanças.

6. Configuração é código

Os profissionais de implantação contínua estão descobrindo que, em escala, não tratar a configuração como código, leva a um número significativo de problemas de produção. Tradicionalmente, a configuração tem sido considerada uma questão de tempo de execução gerenciada por uma equipe de operações ou administradores de sistema.

As mudanças são feitas em servidores ao vivo, muitas vezes de uma forma única que pode desestabilizar um servidor. Por exemplo, um engenheiro está experimentando a otimização da velocidade de consulta em um banco de dados (BD), e altera a configuração em uma das caixas do BD. Essa alteração deve ser replicada em quatro servidores de BD. Quando vários servidores destinam-se a representar o mesmo aplicativo, se a configuração de ao menos um deles for modificada, isso pode levar a rupturas desconhecidas ou difíceis de depurar.

As ferramentas modernas de gerenciamento de configuração, como Ansible, Puppet, Chef e Salt, permitem que o gerenciamento de configuração seja feito por scripts e orquestrado em todos os recursos do servidor.

As organizações deveriam tratar o gerenciamento de configuração da mesma forma que o de recursos e código. Por exemplo, na Netflix, para cada commit, o processo de compilação cria um pacote Debian especificando completamente as dependências necessárias e as instalam em uma nova imagem virtual da Amazon Web Services.

Os representantes do Facebook e da Netflix que estiveram no encontro observaram que apesar das ferramentas, as alterações de configuração ainda podem causar erros difíceis de depurar. A Netflix faz 60 mil dessas mudanças diariamente e não possui sistema para rastreá-las ou revisá-las. Isso leva, como os participante da Netflix colocaram, a empresa a dar tiros no pé. As equipes da Red Hat descobriram que, assim como com bases de código grandes, grandes conjuntos de configurações podem se tornar incontroláveis.

A lição das empresas já experientes no espectro da implantação contínua é considerar o gerenciamento de configuração desde o início de um novo projeto ou na transição de projetos com bagagem arquitetônica para um modelo de implantação contínua. Em outras palavras, o gerenciamento de configuração deve ser uma competência básica tratada como código.

Tratar configuração como código implica usar todas as melhores práticas relacionadas ao acoplamento, coesão, integração contínua e escala.

7. Conforte o cliente com desconforto

À medida que as empresas se migram para a implantação contínua, elas experimentam maneiras de confortar os clientes com relação ao novo ritmo de entrega. No mundo consumidor de hoje, como produtos e dispositivos recebem um fluxo constante de atualizações, os clientes geralmente não têm escolha senão aceitá-los. Novas gerações de clientes podem, de fato, esperar por elas. Se os dispositivos móveis estão treinando todos nós para aceitar mudanças constantes, e se mesmo carros e televisões se atualizem automaticamente, por que não software de negócios? O número de clientes que desejam esperar um ano ou dois para atualizações irá diminuir rapidamente. Ainda assim, nem todos os clientes e as empresas estão prontos para essa mudança.

Um exemplo proeminente desse desafio envolve a experiência da Microsoft com o Windows 10. A Microsoft passou de grandes e infrequentes atualizações de seu sistema operacional para melhorias incrementais regulares. O esforço para migrar usuários para o Windows 10 também foi particularmente mais pró-ativo, por exemplo, com a pré-transferência de arquivos de instalação levando os usuários a atualizarem (o software) frequentemente, e restringindo sua capacidade de desativar as atualizações. Essas mudanças podem atrair clientes mais inteligentes, mas prejudicam os clientes empresariais que talvez não estejam dispostos a aceitar mudanças frequentes devido aos testes internos de integração e às preocupações com regulamentações.

IBM e Mozilla incluem importantes partes interessadas em testes de unidade e integração durante o desenvolvimento. Isso reduz o risco de implementações fracassadas nas instalações das partes interessadas e ajuda-os a se sentir mais à vontade aceitando novos lançamentos.

A Cisco vem explorando o uso de implantações mais rápidas como modelo de convenção com clientes.

Muitas vezes, a maior fonte de desconforto do cliente é a produtividade interrompida quando um cliente atualiza as versões. Por exemplo, a IBM costumava levar um mês para migrar um sistema para uma nova versão no site de um cliente. O principal desafio foi coordenar alterações de código e banco de dados com instâncias locais. Por fim, a IBM reduziu o processo para uma hora. Da mesma forma, na SAS, a maior barreira para a implantação foi que cada implantação impôs longos períodos de tempo de inatividade para os clientes, e teve que dar suporte a muitas versões de conjuntos de dados e sistemas implantados.

Ao mudarem rapidamente, as empresas devem considerar se estão se indo mais rápido do que os usuários desejam. Ainda assim, o melhor conforto que uma empresa pode fornecer é a capacidade de entregar uma mudança no prazo exato, sempre que o cliente estiver pronto.

8. Olhando para trás para avançar

A implantação contínua requer reflexão contínua sobre o processo de entrega.

Quase todos os participantes do encontro tinham uma história sobre derrubar operações inteiras com erros acidentais nas mudanças de configuração. Por exemplo, uma configuração JSON (JavaScript Object Notation) mal formada uma vez derrubou o componente de descoberta inteiro da arquitetura da Netflix.

Para apoiar a reflexão sobre falhas de produção, todas as empresas empregam retrospectivas (ou postmortem). Em retrospectivas, os membros da equipe discutem as causas e consequências de uma interrupção inesperada da operação ou falha na implantação. Eles também discutem possíveis mudanças no processo.

Vários participantes descreveram suas experiências com retrospectivas. Na Netflix, os desenvolvedores relatam interrupções como tickets em um kanban board e classificam sua gravidade. Ao gerenciarem as interrupções, os desenvolvedores podem realizar uma meta-análise delas para descobrir tendências e problemas sistemáticos com os processos de implantação. As falhas mais graves são discutidas em retrospectivas semanais, que contam com a presença de múltiplos atores entre equipes.

Alguns participantes mencionaram que, apesar da utilidade das retrospectivas, elas podem ser terríveis. Os desenvolvedores não recebem bem a notícia sobre o impacto de um erro de codificação para os usuários, e têm problemas lidar com as emoções. Mencionar vitórias pode ajudar a manter a moral da equipe e aliviar as emoções inesperadas. Em determinadas circunstâncias, faz sentido deixar a parte responsável fora da sala, se possível. Ainda assim, apesar do potencial desconforto durante as retrospectivas, várias empresas observaram uma queda considerável nos erros depois que começaram a empregá-las.

Retrospectivas também podem mudar as visões culturais. No início do Facebook, a empresa educou seus desenvolvedores com uma cultura de "Mover rápido, quebrar coisas". No entanto, em certo ponto, essa mensagem foi levada longe demais, e surgiu um novo credo moderador: "Desacelere e corrija a sua m***".

Algumas das outras empresas refletiram sobre os benefícios de práticas específicas e procuraram dados que atestassem os benefícios. Por exemplo, depois de estudar extensivamente as revisões de código, a Microsoft até agora não encontrou redução significativa de defeitos. Em vez disso, os principais benefícios envolvem compartilhamento de conhecimento e aprimoramento do onboard (o processo pelo qual novos funcionários aprendem as habilidades e comportamentos necessários).

À medida que as empresas continuam a adotar a implantação contínua, a necessidade existe não apenas para calibrar como uma prática é exercida e como uma cultura é definida, mas também para questionar constantemente os benefícios e a eficácia de ter essas práticas e culturas em primeiro lugar. Um aspecto importante das retrospectivas é manter uma "cultura sem culpa", mas isso pode ser difícil quando os desenvolvedores também devem ser totalmente responsáveis por suas mudanças implantadas do começo ao fim.

9. Convide a privacidade e a segurança para se juntarem ao desenvolvimento

A maioria dos participantes do encontro indicou que a segurança e privacidade do software eram silos - a responsabilidade de um grupo específico, e não de todos os desenvolvedores envolvidos na implementação de software implementável. A implantação contínua pode aumentar o risco porque os especialistas em segurança e privacidade não podem revisar todas as mudanças rapidamente implantadas e porque as sprints muitas vezes não planejam preocupações de segurança (8).

Como mencionamos anteriormente, no desenvolvimento waterfall e espiral, os desenvolvedores lançam o código para que testadores lidem com defeitos. Com metodologias ágeis, os testadores são "convidados à mesa" e participam como parceiros desde o início de uma iteração. Juntos, então, os desenvolvedores e testadores lançam seus produtos testados na parede para a equipe de operações implantar o produto.

Com a implantação contínua, a equipe de operações também é convidada à mesa, participando durante uma iteração e lidando com as implicações das operações do desenvolvimento das funcionalidades. No entanto, as pessoas nos silos de segurança e privacidade normalmente não são convidadas à mesa. Desde 2012, os pesquisadores estão discutindo como estabelecer a colaboração entre equipes de segurança e equipes de desenvolvimento e TI (9). Esta colaboração geralmente é chamada de DevSecOps. Nós propomos ir mais longe e convidar explicitamente pessoas de privacidade e segurança (PrivSec) a participar em todo o desenvolvimento (DevPrivSecOps). O objetivo é aumentar o conhecimento de desenvolvedores, testadores, e da equipe de operações em segurança, e aumentar a parceria de especialistas em segurança e privacidade.

As empresas podem ter um processo ou supervisão separada para mudanças que tenham maior risco de segurança ou implicações de privacidade.

No Facebook, uma mudança de código considerada como tendo implicações de privacidade pode passar por um processo de envio que é mais longo do que um dia (10). Além disso, uma pequena equipe cria uma camada de acesso para todos os dados e controles que forçam a adesão à privacidade e preocupações regulatórias. O Google instituiu controles para implantação segura, como a autorização de usuários que fazem check in de código para implantação, controle de acesso rígido, e teste com amostra de dados (checksumming) binários. O Google também tem uma divisão rigorosa entre sua rede de produção e a rede da empresa. A rede de produção consiste apenas em servidores; não ter estações de trabalho reduz a possibilidade de adulteração com código implantado.

10. Esteja você preparado ou não, a implantação contínua vem aí

Seu concorrente adiciona continuamente valor aos seus produtos. Você também? Todos os participantes do encontro indicaram a urgência de entregar rapidamente novas funcionalidades para se manterem competitivos.

Uma pesquisa global de 2015 da CA Technologies indicou que, de 1.425 executivos de TI, 88% adotaram o DevOps ou planejavam adotá-lo nos próximos cinco anos (11). O DevOps e a implantação contínua têm práticas semelhantes; algumas pessoas equiparam informalmente as duas abordagens. De acordo com uma pesquisa de 2015 da Puppet Labs envolvendo 4.976 entrevistados, as empresas de TI que adotaram DevOps experimentaram 60 vezes menos falhas e implantaram 30 vezes mais frequentemente do que as organizações que não o adotaram (12). Os entrevistados indicaram a adoção generalizada de DevOps em todo o mundo e em organizações de todos os tamanhos. Os cinco principais domínios que utilizam DevOps foram tecnologia, software para web, bancos e finanças, educação e telecomunicações. A prevalência e o crescimento do DevOps só são possíveis se os indicadores de desempenho suportarem benefícios empresariais como mais clientes, colaboração entre departamentos, melhor qualidade e desempenho de software, e manutenção mais rápida (11) (12).

Os educadores de engenharia de software também devem ter conhecimento. Nas palavras de Brian Stevens, ex-vice-presidente executivo e diretor de tecnologia da Red Hat, "o modelo legado de engenharia de software simplesmente não vai sobreviver a esta transição" (13). A educação de engenharia de software muitas vezes fica para trás da nova realidade de implantação contínua e se concentra no modelo legado. Os cursos principais de engenharia de software de graduação também devem ensinar habilidades fundamentais, como:

• integração e construção contínuas,
• integração automatizada e testes de sistema, e
• a necessidade de seguir boas práticas de validação e verificação se os desenvolvedores não quiserem ser acordados no meio da noite para consertar o código que eles implantaram durante o dia.

Além disso, os educadores devem conscientizar os estudantes sobre as realidades de implantação em um ambiente ao vivo e em grande escala, e as preocupações relacionadas, como migração de dados, estratégias de implantação, pipelines de implantação, e padrões de codificação de telemetria.

Pronto ou não, aqui vem a implantação contínua. Você vai estar pronto para entregar?

Referências

1. T. Savor et al., "Continuous Deployment at Facebook and OANDA", Proc. 38th Int'l Conf. Software Eng. Companion, 2016, pp. 21-30.

2. M. Marschall, "Transforming a Six Month Release Cycle to Continuous Flow", Proc. 2007 Agile Conf. (Agile 07), 2007, pp. 395-400.

3. R. Torkar, P. Minoves, and J. Garrigós, "Adopting Free/Libre/Open Source Software Practices, Techniques and Methods for Industrial Use", J. Assoc. for Information Systems, vol. 12, no. 1, 2011, article 1.

4. Z. Codabux and B. Williams, "Managing Technical Debt: An Industrial Case Study", Proc. 4th Int'l Workshop Managing Technical Debt, 2013, pp. 8-15.

5. M. Mäntylä et al., "On Rapid Releases and Software Testing: A Case Study and a Semi-systematic Literature Review", Empirical Software Eng., vol. 20, no. 5, 2014, pp. 1384-1425.

6. J. Humble, Lean Enterprise: How High Performance Organizations Innovate at Scale, O'Reilly Media, 2015.

7. B.W. Boehm, Software Engineering Economics, Prentice-Hall, 1981.

8. Z. Azham, I. Ghani, and N. Ithnin, "Security Backlog in Scrum Security Practices", Proc. 5th Malaysian Conf. Software Eng. (MySEC 11), 2011, pp. 414-417.

9. J. Turnbull, "DevOps / Security", presentation at DevOpsDays Austin 2012, 2012;

10. D.G. Feitelson, E. Frachtenberg, and K.L. Beck, "Development and Deployment at Facebook", IEEE Internet Computing, vol. 17, no. 4, 2013, pp. 8-17.

11. DevOps: The Worst-Kept Secret to Winning in the Application Economy, CA Technologies, Oct. 2014;

12. 2015 State of DevOps Report, white paper, Puppet Labs, 2015;

13. B. Stevens, "2014 Red Hat Summit: Brian Stevens, Red Hat Keynote", 2014.

Sobre os autores

Chris Parnin é professor assistente no Departamento de Ciência da Computação da Universidade Estadual da Carolina do Norte. Entre em contato com ele aqui.

Eric Helmsé um desenvolvedor da Red Hat Software e estudante de doutorado no Departamento de Ciência da Computação da Universidade Estadual da Carolina do Norte. Entre em contato com ele aqui.

Chris Atleeé gerente sênior de engenharia de lançamento do Mozilla. Entre em contato com ele aqui.

Harley Boughtoné estudante PhD em ciência da computação na Universidade de York. Anteriormente, ele era desenvolvedor de software e o gerente de programa para DB2 e dashDB na IBM. Entre em contato com ele aqui.

Mark Ghattas é arquiteto de soluções sênior da Cisco Systems. Entre em contato com ele aqui.

Andy Glover é gerente de engenharia de entrega na Netflix. Entre em contato com ele aqui.

James Holman é diretor sênior da SAS e chefe da divisão para implantação do software SAS. Entre em contato com ele aqui.

John Micco eacute; gerente de engenharia de produtividade no Google. Entre em contato com ele aqui.

Brendan Murphy é o diretor de pesquisas da Microsoft. Entre em contato com ele aqui..

Tony Savor é diretor de engenharia do Facebook e professor adjunto nos Departamento de Ciência da Computação e Engenharia elétrica e informática da Universidade de Toronto. Entre em contato com ele aqui.

Michael Stumm é professor do Departamento de Engenharia Elétrica e Informática da Universidade de Toronto. Entre em contato com ele aqui.

Shari Whitaker é gerente de operações de desenvolvimento da LexisNexis. Entre em contato com ela aqui.

Laurie Williams é professora e chefe associada do departamento de Ciência da Computação da Universidade Estadual da Carolina do Norte. Entre em contato com ela aqui.

Este artigo apareceu pela primeira vez na revista IEEE Software, que oferece informações sólidas e revisadas por pares sobre questões de tecnologia estratégica. Para lidar com os desafios de gerenciar empresas confiáveis e flexíveis, os gerentes de TI e líderes técnicos contam com o IT Pro para soluções de ponta..