O desenvolvimento de software em 2020 é um ambiente em rápida mudança. Está ficando mais claro a cada dia que se nossas organizações querem sobreviver a este período de incerteza política e econômica, elas devem ser capazes de se mover com rapidez e adaptabilidade. Mas como se controla a segurança à velocidade? Se o seu objetivo é passar de um ciclo de entrega de software que foi construído com muitos guardrails e implementações infrequentes, para uma metodologia mais moderna que suporta a capacidade de resposta através de lançamentos frequentes para fluir valor para seus clientes o mais rápido e seguro possível, então quem você coloca a cargo das decisões de gerenciamento de mudanças importa, muito.

Tradicionalmente em muitas organizações, essas decisões são tomadas centralmente por um gerente de mudanças que conduz reuniões periódicas do conselho consultivo de mudanças (CAB). O CAB em si é uma coleção de representantes de várias funções dentro e fora da TI corporativa, encarregados de rever as mudanças propostas e auxiliar o gerente de mudanças na avaliação, priorização e agendamento de mudanças. Por projeto, este é um grupo que não está diretamente envolvido no projeto ou implementação da mudança proposta, razão pela qual o processo que eles conduzem é conhecido como uma revisão “externa”.

Mas, quem deve ser o responsável? A fim de melhor suportar tanto a velocidade como a segurança COMO BEM-ESTAR, você quer que suas equipes de desenvolvimento e seus clientes conduzam sua tomada de decisão. Do ponto de vista técnico, seus desenvolvedores têm uma melhor idéia do que está em um lançamento, se existem interdependências e se ele foi testado, do que qualquer conselho consultivo de mudanças. De uma perspectiva empresarial, é hora de percebermos que o cliente é o árbitro final do que vai e não vai funcionar, não algum gerente sênior, e certamente não o seu conselho consultivo de mudanças.

Um conselho consultivo de mudanças pode ser mais lento, mas no mínimo é mais seguro, certo?

O conselho consultivo de mudanças (e muito do que você encontrará no ITIL), pode parecer formas razoáveis de reduzir o risco e adicionar rigor, especialmente em ambientes lentos e complexos. Se você tiver apenas uma chance a cada 30 ou 90 dias para mudar a produção, manter as coisas fora de lançamentos com portões de qualidade e aprovações de gerenciamento parece ser uma boa maneira de gerenciar riscos. Ninguém iria debater que é um processo mais lento (que pode adicionar semanas ou meses ao tempo entre um desenvolvedor escrevendo código e sua entrada em operação), mas é mais seguro, certo?

Atualmente, não. Não é.

Um estudo de vários anos em uma grande variedade de indústrias e ambientes descobriu que ter uma CAB ou um processo de “aprovação externa” similar teve um desempenho pior do que não ter nenhum processo de aprovação. Aqui está o que a autora principal, Dra. Nicole Fosgren, teve a dizer sobre os resultados:

Nós descobrimos que as aprovações externas estavam negativamente correlacionadas com o tempo de execução, frequência de implantação e tempo de restauração, e não tinham nenhuma correlação com a taxa de falhas de mudança. Em suma, a aprovação por um organismo externo (como um gerente ou um CAB) simplesmente não funciona para aumentar a estabilidade dos sistemas de produção, medida pelo tempo para restaurar o serviço e a taxa de falhas de mudança. No entanto, certamente retarda as coisas. Na verdade, é pior do que não ter nenhum processo de aprovação de mudanças.

O que é melhor do que não ter nenhum processo de aprovação de mudanças em tudo?

Dr. Fosgren e sua equipe não estão realmente sugerindo que você não tem nenhum processo de aprovação, mas dado o mau desempenho dos CABs no mundo real, devemos repensar que tipo de processo irá realmente mantê-lo seguro.

Aqui está outra citação do estudo Accelerate:

Nossa recomendação baseada nesses resultados é usar um processo leve de aprovação de mudanças baseado em revisão por pares, como programação de pares ou revisão de código intrateam, combinado com um pipeline de implantação para detectar e rejeitar mudanças ruins. Este processo pode ser usado para todos os tipos de mudanças, incluindo código, infra-estrutura e alterações de banco de dados.

Peer Code Reviews Combined with What Now?

Quando li essa recomendação em março de 2018, não tive nenhum problema em visualizar a primeira metade: revisões de código por pares e demonstrações semanais da equipe já eram as normas no BlazeMeter. A segunda metade? Nem por isso! Éramos um aplicativo SaaS “moderno”, mas nunca tinha ouvido falar de “um pipeline de implantação detectar e rejeitar mudanças ruins”.

Para gerir o risco durante os lançamentos naquela altura, usávamos uma combinação de implementações azul/verde e lançamentos canários. A plataforma fazia o “empurrar” mas não o “detectar” ou o “rejeitar” – isso dependia dos nossos melhores e mais brilhantes SRE’s, que verificavam o estado de dezenas de coisas manualmente antes de aumentarmos para 100% dos utilizadores. A leitura de “detectar e rejeitar mudanças ruins” apenas trouxe uma imagem de uma caixa preta em um quadro branco rotulado, “a mágica acontece aqui”. Flashbacks para estudos de cinema na faculdade, onde aprendi o que “deus ex machina” significava.

Detectar e Rejeitar: Exemplos estão lá fora se você olhar

Um lote pode mudar em dois anos. Desde que me juntei ao Split como um CD Evangelista, tenho visto Lukas Vermeer descrever como o pipeline de implantação do Booking.com pode detectar e reverter uma má mudança dentro de um único segundo. Eu ouvi o Sonali Sheel do Walmart Labs explicar como eles usam sua plataforma Expo para parar uma implementação a meio caminho antes que ela cause danos às suas principais métricas, algo que eles chamam de Test to Launch.

A plataforma de entrega de recursos Split foi criada por pessoas com visões similares de gerenciamento de mudanças modernas baseadas em experiências vividas no LinkedIn, Salesforce.com e Yahoo. Os fundadores receberam conselhos de pessoas que tinham abordado a complexidade, velocidade e escala de sistemas similares na Amazon e na Microsoft.

Quando ouvi falar da Split e descobri os exemplos que eles estavam comercializando, pulei para a chance de me juntar a eles. Construir tal plataforma internamente era algo que apenas alguns gigantes tinham tempo e recursos para enfrentar. Se o mesmo tipo de exposição de granulação fina e detecção automática de impacto estivesse disponível como SaaS, então a entrega de software com impacto poderia ser desbloqueada para cada equipe, não apenas para as startups de unicórnio.

Isso é incrível, mas não vai funcionar aqui

Uma coisa engraçada aconteceu repetidamente enquanto eu viajava para conferências de tecnologia, dando palestras sobre os primeiros pioneiros que tinham construído essas plataformas em casa. O público respondia primeiro com espanto e depois com resignação. “Isso é muito legal, mas nós não somos o Booking.com, LinkedIn ,ou Facebook. Não podemos fazer isso no nosso ambiente.”

Nos meus esforços para ser “vendor-neutral” evitando as especificidades da implementação do Split, eu tinha praticamente redesenhado aquela imagem difusa de uma caixa negra marcada “a magia acontece aqui”.

E se não fosse tão difícil?

Se nunca viu uma plataforma que forneça um controlo de exposição de grão fino e um mecanismo automatizado rigoroso para detectar e rejeitar mudanças más no seu ambiente, não pode ser culpado por pensar que é ficção científica.

Acontece que existem apenas quatro problemas principais a resolver aqui:

1. Desacoplar o deploy do release, para que o código possa ser empurrado até a produção mas impedido de ser executado até estar pronto. Isto facilita a verdadeira integração contínua, pequenos lotes, desenvolvimento de recursos incrementais e ramificação por abstração, que são todos críticos para a entrega contínua onde o fluxo é a norma.
2. Expor seletivamente o novo código, começando com pequenos públicos internos e trabalhando para fora. Isso facilita os testes na produção, a codificação de cachorros, programas de acesso antecipado, e o lote de alterações para clientes com mudança-adverso.
3. Dados de comportamento do sistema e do usuário e alinhá-los com os dados de exposição indicando quem está dentro e fora de cada coorte de usuários. O objetivo é tornar o processo de atribuição (alinhando “Quem recebeu o quê?”, com “Então isso aconteceu”) automático e contínuo.
4. Comparar os padrões de métricas entre os incluídos e excluídos de cada coorte para identificar (e opcionalmente alertar sobre) diferenças significativas. Você pode já ter visto este padrão antes no contexto de “testes A/B” que tipicamente rastreia o impacto das mudanças em uma métrica de conversão, mas aqui estamos falando de rastrear amplamente o impacto de todo o trabalho de engenharia e ter um relógio sempre vigilante para impactos em todas as métricas valorizadas organizacionalmente, se o impacto sobre essas métricas é esperado ou não.

Fornecimento progressivo: Uma Fundação Facilmente Estabelecida

Desacoplamento do lançamento e exposição seletiva de novo código estão se tornando conhecidos como entrega progressiva, um termo cunhado pelo analista da RedMonk James Governor. Várias bandeiras de recursos comerciais fornecem esses recursos fora da caixa e está surgindo um consenso de que as bandeiras de recursos se juntaram à lista de ferramentas para desenvolvedores que fazem mais sentido comprar do que construir e manter internamente.

As bandeiras de recursos são uma base essencial para alcançar fluxo, mas por si só elas não aceleram a detecção de impacto. A maioria das implementações de bandeiras de características facilitam o fluxo, mas não fazem nada para indicar se tudo está bem ou se você está alcançando resultados significativos.

Head’s Up: Data Scientists Don’t Scale

Ingesting system and user behavior and automatically aligning it with the exposed cohorts is rare among all but the most sophisticated in-house systems. A maioria das equipes que tentam esta prática estão fazendo muito trabalho manual e ad-hoc de ciência de dados. Uma vez que estão limitadas pelos recursos humanos e não pela capacidade computacional, são forçadas a escolher quando e onde prestar atenção.

Carga cognitiva não é seu amigo quando se trata de fluxo, portanto o design do Split nem sequer requer que as equipes escolham os eventos a serem associados a cada rolagem da bandeira de recursos; todos os eventos ingeridos, uma vez vinculados à métrica organizacional, são continuamente atribuídos aos coortes on e off de cada rolagem, sem qualquer intervenção. A divisão também facilita o trabalho de identificação e ingestão de dados de eventos através de integrações com Segment, Sentry, mParticle e Google Analytics.

Semper Fi para Dutos de Entrega Contínua

Comparar padrões de métricas entre os incluídos e não incluídos em cada coorte de forma rigorosa para determinar automaticamente diferenças significativas é ainda mais raro na natureza do que a atribuição. Este é exactamente o problema que os módulos de Monitorização e Experimentação do Split resolvem. O Monitor foca na identificação e alerta sobre os impactos das métricas à medida que uma implantação está em andamento (também conhecida como “limitação do raio de explosão de incidentes”), enquanto a Experimentação, como os testes A/B, procura fornecer uma fonte contínua de dados imparciais, não condicionados pela disponibilidade de um analista, para indicar se cada característica atingiu um impacto desejado ou não.

Better Together: Revisão por pares, entrega progressiva e criação automática de sentido

Por que nos esforçamos por fluxo? Não se trata de saída. Trata-se de resultados. Nós nos esforçamos por fluxo para que possamos iterar o ciclo de feedback da idéia -> implementação -> observação com menos atrito em menos tempo. Quer se chame “desenvolvimento orientado para o impacto” ou “desenvolvimento orientado para o cliente”, esta abordagem de avançar mais rapidamente com uma maior (e mais rápida) consciência dos resultados vai muito além do “pipeline de implementação para detectar e rejeitar mudanças ruins” que a equipe da DORA recomendou que combinássemos com as práticas de revisão pelos pares. Sim, podemos detectar e rejeitar automaticamente mudanças ruins, mas mais importante ainda, podemos construir um processo que pode ser repetido para triangular em direção a resultados significativos do negócio.

Aprenda mais sobre como alcançar o gerenciamento e o fluxo de mudanças, juntos, em Entrega Contínua

• Veja um vídeo de quatro minutos sobre a definição de Entrega Contínua para ver por que o tamanho de pequenos lotes é crítico para alcançar um fluxo consistente.
• Pega dicas de várias equipes que enviam para a produção diariamente no e-book da O’Reilly, Entrega Contínua na Natureza
• Veja um vídeo detalhado com Craig Sebenik (LinkedIn, Crunchbase, Matterport) sobre os benefícios da mudança para o desenvolvimento baseado em troncos.

Veja um conteúdo mais significativo sobre como alcançar resultados significativos com a entrega de recursos em escala? Marque o blog Split, visite-nos no YouTube, ou siga-nos no Twitter @splitsoftware.