Neste artigo, quero compartilhar minha experiência de como resolvemos o problema de congelar tarefas em nossa empresa.
Eu trabalho em uma startup, que, como todas as startups, está passando por uma fase de crescimento de 10 pessoas há um ano para 35 pessoas hoje, e o número de programadores nesse período aumentou de 5 para 25 pessoas, e a maioria delas veio nos últimos seis meses.
A estrutura da empresa, apesar da juventude, eu chamaria de antiquada, já que ninguém nunca esteve envolvido nos processos de construção. Com o crescimento, nos dividimos em uma equipe de desenvolvimento, uma equipe de teste e uma equipe de devops, e tudo funcionou mais ou menos.
O processo de desenvolvimento, se pode ser chamado de "processo", era assim:
O trabalho do desenvolvedor terminou assim que o código passou na revisão do código e ele o colocou no desenvolvimento.
O trabalho do testador terminou quando ele testou e smerzhil no ramo mestre.
Os desenvolvedores às vezes clicavam no botão "Implantar no Prod", depois que o gerente do projeto diário disse: "Eles não são implantados há muito tempo, talvez seremos cancelados hoje?"
Que bom:
- Muita automação, por exemplo, os status no Jira são sincronizados com os rótulos das ramificações no GitLab, uma tarefa no Jira é fechada após uma implantação no prod, o código é automaticamente implementado para testar e preparar ambientes com uma mesclagem no desenvolvimento e no mestre, respectivamente.
- Tudo é coberto e testado.
- Os programadores escrevem os próprios planos de teste e testam a funcionalidade principal.
Os problemas:
- Os testadores não podem fazer nada por uma semana, porque as tarefas são interrompidas no status code_review. No final da semana, os programadores ainda fazem essa revisão e, na segunda-feira, os testadores têm muito trabalho.
- Como após a revisão do código, tudo é corrigido no desenvolvimento e, se algo contém um erro, não podemos implantar nada. Enquanto um desenvolvedor corrige esse bug, outro pode causar mau cheiro a outro recurso que também contém um bug. Por causa disso, costumávamos esperar uma semana ou duas até que esse brunch se estabilizasse e o testador tivesse tempo de controlá-lo no master antes de um dos desenvolvedores comprometer outra coisa a desenvolver.
- Implante recursos em pacotes grandes, o que adiciona riscos ao teste ou captura inadequados durante a implantação.
Descreverei dois casos que deixaram claro para nós que é impossível trabalhar mais.
Por exemplo, em uma das sextas-feiras, tivemos 15 brunches no status code_review, e na segunda-feira todos eles mudaram o status para ready_for_test. Os testadores disseram ao Daily o quanto eles nos amam. Por três meses, não conseguimos vender, por vários motivos, alguns recursos bastante grandes.
Primeiro, descobrimos muitas code_review. Descobriu-se que esse problema pode ser resolvido de maneira simples, graças às seguintes regras:
- Somente três tarefas podem estar no status code_review. Essa é a regra mais importante que não pode ser violada.
- Se o programador terminou o desenvolvimento e deseja converter a tarefa em code_review, ele procura ver se pode fazê-lo (consulte a regra 1).
- Se já houver três tarefas no status code_review, primeiro ele ajudará o colega a fazer uma revisão do código. E se, no processo de revisão, ele tiver comentários ou sugestões de mudança, ele fará uma programação emparelhada com um colega cuja tarefa ele está revisando.
A idéia principal é não deixar o código congelar quando já está escrito e fornecer aos testadores um fluxo de trabalho uniforme por uma semana.
Implementamos isso em uma hora: nos reunimos, discutimos e fomos fazer uma revisão e emparelhar a programação.
Se acontecer que alguém esquece (e às vezes alguém esquece) a primeira regra, a frase "Temos mais de 3 relações públicas em code_review" voa imediatamente para a sala de bate-papo. Vamos revisar !!! ". Ao mesmo tempo, não há uma pessoa especial que garanta que não haja mais de três solicitações pull, isso é feito pelos próprios desenvolvedores.
Apesar de essas alterações impedirem o congelamento de tarefas, ainda tínhamos problemas com implantações e vazamentos de bugs no desenvolvimento. Desde que após a revisão do código, sempre mesclamos no ramo de desenvolvimento e ele foi implementado automaticamente no ambiente de teste para teste.
Essa solução era um tipo de hotfix e, em seguida, era necessário fazer alterações básicas nos processos.
A principal coisa que decidimos fazer é mudar as áreas de responsabilidade. Agora a empresa não possui uma equipe de desenvolvimento, equipe de teste ou equipe de devops separada que transferem tarefas uma para a outra e são responsáveis apenas por sua parte.
Organizamos os desenvolvedores em várias equipes: uma para cada cliente, já que possuímos um produto principal, mas ele é personalizado para cada cliente por um longo tempo (somos um híbrido de uma empresa de produtos e serviços). Agora, os recursos de envio para o prod são de responsabilidade da equipe. Não há equipes de teste e devops familiares, mas há controle de qualidade como serviço e DevOps como serviço.
O controle de qualidade como serviço é uma equipe que não testa, mas garante a qualidade dos produtos. Os engenheiros de controle de qualidade ajudam os desenvolvedores a elaborar planos de teste e a participar de sessões de teste. Portanto, nós os libertamos dos testes manuais e eles tiveram tempo para escrever testes de ponta a ponta e desenvolver ferramentas para ajudar nos testes. Também implementamos um sistema de monitoramento.
O DevOps como serviço é uma equipe que desenvolve scripts de implantação, suporta o trabalho de ambientes de teste e automatiza várias tarefas.
O novo processo de desenvolvimento é este:
- Existe uma tarefa, do cliente, gerente de produto ou um dos principais.
- No estágio de planejamento do sprint, levamos isso ao desenvolvimento.
- O desenvolvedor grava o código em uma ramificação separada para a tarefa e, quando termina, converte-o no status code_review.
- Um dos colegas faz uma revisão.
- Quando a tarefa passa na revisão, o desenvolvedor mescla à ramificação com a tarefa tudo o que está comprometido em desenvolver e implementa essa ramificação no ambiente de teste.
- Em seguida, ele planeja um comício que chamamos de Sessão de Teste e convida um engenheiro de controle de qualidade e colegas, se necessário.
- O engenheiro de controle de qualidade verifica e refina o plano de teste antes da Sessão de Teste.
- Na sessão de teste, o desenvolvedor percorre todo o plano de teste como uma demonstração. Às vezes, um plano de teste é dividido em partes e depois testamos em paralelo. O principal é que isso seja feito juntos em uma sala separada para reuniões.
- Se depois de testar os bugs não foram encontrados, o desenvolvedor mescla seu código no ramo de desenvolvimento e imediatamente no ramo principal (isso é algo que ainda não mudamos, pois ainda precisamos atualizar os scripts de implantação). No futuro, planejamos deixar apenas o ramo principal.
- Depois disso, o desenvolvedor inicia a implantação no preparo, apenas para verificar se a implantação ainda é executada em um ambiente idêntico ao produto.
- Se tudo estiver ok, implante imediatamente no produto. A decisão de implantar ou não é tomada pela equipe de desenvolvimento, mas o controle de qualidade tem o direito de interromper as implantações se considerar necessário um teste adicional ou se é necessário aguardar se for necessário corrigir algum bug crítico no produto.
Curiosamente, essa transformação lançou algumas mudanças adicionais, não no processo de desenvolvimento, mas no planejamento e na alteração dos tópicos sobre os quais estamos falando no Diário.
Agora porque o desenvolvedor é responsável por entregar a história do usuário ao produto. No planejamento, começamos a escrever a história do usuário de forma que cada um seja independente dos outros e também possa ser implantado de forma independente, como uma unidade implantável. A história do usuário ficou maior, mas eles ficaram menores.
Também no planejamento, não avaliamos o tempo de desenvolvimento, mas falamos sobre quando planejamos implantar um recurso.
No Daily, não dizemos que "eu terminei o desenvolvimento", mas dizemos "hoje vou implantar o recurso X" ou "hoje estou retirando o ambiente de teste, quem tem tempo para me ajudar com a sessão de teste?"
Como resultado, desenvolvemos equipes de desenvolvimento independentes que possuem seus próprios ambientes de teste e planejam o que e quando implantar.