Guia: Gerenciamento de versão de software para equipes pequenas

Formalização do processo de gerenciamento de liberação (se houver)

Em algumas configurações de equipe, principalmente aquelas encontradas em startups, não há DevOps, nem engenheiros de infraestrutura, para dar suporte ao lançar uma nova versão do produto.

Além disso, ao contrário de grandes empresas burocráticas com processos formais definidos, o CTO ou o chefe da equipe de desenvolvimento de software em uma startup muitas vezes não está ciente das complexidades do processo de gerenciamento de lançamento de software; alguns desenvolvedores na empresa podem estar cientes dos detalhes complexos do processo, mas nem todos. Se esse conhecimento não for documentado minuciosamente , acredito que pode resultar em confusão.

Neste artigo, tentarei dar algumas dicas sobre como formalizar o processo de lançamento, principalmente do ponto de vista do desenvolvedor.

Digite a lista de verificação da versão do software

Você pode estar familiarizado com a ideia de uma lista de verificação para algumas operações, conforme o Checklist Manifesto , um livro de Atul Gawande. Acredito que um processo de liberação formal (como muitas outras tarefas no mundo do desenvolvimento de software) oferece aos desenvolvedores a oportunidade de implementar esse protocolo. Uma lista de verificação do processo de liberação deve ser mantida em um documento compartilhado, preferencialmente na forma de um wiki colaborativo ou uma planilha no Google Drive.

Ao compartilhar esse documento vital com a equipe e conceder permissões de edição, todos os membros têm acesso ao processo de liberação formalmente definido. Isso permite que eles entendam como o processo funciona. Além disso, após discussões com outros membros da equipe, isso permite que a equipe melhore de vez em quando. Isso deve trazer transparência e permitir que toda a equipe tenha acesso em tempo real ao que está acontecendo durante o lançamento, quais etapas foram concluídas e por quem.

Ao olhar para esta planilha, as partes interessadas podem decidir entre 'GO' versus 'NO GO', com base no resultado das etapas. Por exemplo, se um teste de estresse der errado em um ambiente de teste, com base no evento, o gerente de projeto pode decidir cancelar a liberação de produção.

Etapas sugeridas para usar como base

Nesta seção, vou propor algumas etapas que você pode usar para criar sua própria lista de verificação para seu processo de lançamento. Algumas dessas etapas não são obrigatórias . Cada aplicativo é diferente e cada organização funciona de maneira diferente, portanto, sinta-se à vontade para se adaptar e fazer alterações que se ajustem melhor ao seu fluxo de trabalho.

1. Criar uma ramificação de lançamento

É provável que você esteja familiarizado com o conceito de Git Workflow ou com a ideia de ramificações de lançamento, um tópico que foi explicado em uma postagem anterior do blog.

Idealmente, você deve ter pelo menos três ramificações:

• master : deve refletir o estado atual do que está no ambiente de produção. Cada novo commit no master deve incluir apenas uma nova versão.
• desenvolver : esta ramificação deve conter os próximos recursos concluídos (e testados). É comum criar uma ramificação separada para cada recurso e depois mesclá-lo para desenvolver quando o recurso estiver pronto.
• release : ramificações de lançamento são uma coleção de commits que estão prontos para serem enviados para produção, além de algumas pequenas correções de bugs adicionais relacionadas ao lançamento.

Observe que as ramificações de lançamento devem ser removidas assim que o lançamento for concluído, portanto, essas ramificações são criadas e destruídas o tempo todo, diferentemente de master ou develop , que são sempre as mesmas.

Para criar uma nova ramificação de lançamento , na ramificação de desenvolvimento em seu terminal git, digite:

$ git checkout -b release/xyz

É conveniente usar uma convenção de nomenclatura, como a definida acima, substituindo xyz pelo número da versão major.minor.patch de acordo com suas necessidades (é uma política que você deve definir dentro de sua equipe e cumpri-la).

É importante dizer, também, que se você codificar algumas correções de bugs na ramificação de lançamento, você não deve esquecer de mesclá-las de volta para desenvolver . O principal objetivo da ramificação de lançamento é ter um instantâneo de visualização de como o aplicativo deve se comportar depois de entrar em produção.

2. Versão Bump

O próximo passo seria aumentar (modificar ou aumentar) o número da versão na ramificação de lançamento .

Você deve abrir o AndroidManifest.xml / package.json / pom.xml / ou onde quer que a versão do aplicativo esteja armazenada em seu projeto (YMMV), atualizar o número da versão e, em seguida, confirmar as alterações no branch de lançamento atual.

É importante atualizar o número da versão por dois motivos.

Primeiro, você pode rastrear e mapear os recursos que foram introduzidos em cada versão e, segundo, você estará ciente da versão que eles estão usando caso precisem fazer alguma solução de problemas ou entrar em contato com você para obter suporte. Se você estiver criando um aplicativo móvel, o número da versão que você está atualizando nesta etapa geralmente é exibido para o usuário final, na seção Sobre ou no Google Play ou Apple App Store . Esta etapa também é uma boa oportunidade para atualizar dependentes do ambiente -configuration (embora eu sugira mantê-los em um repositório separado), como fazer a ramificação apontar para o banco de dados de produção ou quaisquer outros ajustes necessários no processo de compilação.

Por fim, é recomendável que você envie o branch de lançamento para a origem, para que fique disponível para seus outros desenvolvedores:

$ git push -u origin release/xyz

3a. Mesclar o branch de lançamento para master e marcá-lo

Apenas a ramificação master deve ser implantada para produção, portanto, nesta etapa, precisamos mesclar a ramificação de lançamento em master .

 $ git checkout master $ git merge --no-ff release/xyz $ git push

O sinalizador --no-ff é opcional, no entanto, seu uso é recomendado para forçar a criação de um novo objeto commit, mesmo que a mesclagem possa ser concluída usando a técnica de avanço rápido.

Em seguida, é hora de marcar o lançamento no branch master :

$ git tag -a xyz -m 'description of new version, features or fixes included'

As tags são úteis porque você está persistindo nesse ponto específico no histórico no repositório git e pode voltar mais tarde para recriar uma ramificação separada de uma tag específica.

3b. Use uma solicitação pull para mesclar a ramificação de lançamento

Outra alternativa usada com frequência é usar uma solicitação pull para mesclar a ramificação de lançamento em master .

Existem inúmeras vantagens nessa abordagem. Um novo espaço é criado para colaboração, que a equipe pode usar para discutir vários problemas relacionados ao lançamento. Este ponto é um bom momento para adicionar um portão extra para incorporar um processo de revisão de código, tendo mais olhos para monitorar o código que será introduzido e discutir possíveis modificações.

Algumas ferramentas que permitem implementar solicitações de pull em seus fluxos de trabalho são GitHub, Bitbucket e GitLab (solicitação de mesclagem como eles chamam no último). Com essas ferramentas, você não digita os comandos do git manualmente, em vez disso, você usa uma interface da Web para definir o branch de origem ( release ) e o branch de destino ( master ), e então você adiciona um ou mais revisores, todos os quais irão ser capaz de escrever comentários embutidos sobre essas novas mudanças, sugerir melhorias e assim por diante.

Depois que todos os revisores aprovarem a solicitação pull, você poderá mesclar automaticamente as alterações no mestre pressionando um botão na interface do usuário.

4. Implante o mestre no ambiente de produção

É uma boa prática, neste estágio, ter um testador em sua equipe para fazer um teste de fumaça (isso pode ser definido em uma lista de verificação separada) antes de implantar o aplicativo. Uma boa sugestão é implantar o branch master em um ambiente de teste separado. O testador pode executar algumas ações básicas para garantir que nada deu errado após a mesclagem na versão mais recente. Como realizar um teste de fumaça está além do escopo deste artigo, mas você pode encontrar muito material na web sobre isso. O resultado do teste de fumaça pode ser integrado à lista de verificação/planilha de liberação, documentando tudo o que deu errado.

Neste ponto, você está pronto para implantar as alterações e torná-las ativas. Vá em frente e implante o branch master . Esta etapa dependerá da pilha de infraestrutura que você está usando. Pode envolver conectar-se à sua instância do Amazon EC2 para fazer upload do seu aplicativo ou enviar por push para um controle remoto do Heroku ou conectar-se via ssh ao seu VPS para copiar a nova versão ou qualquer outro processo.

Depois que o aplicativo for carregado, verifique se ele foi implantado com êxito e se funciona conforme o esperado.

5. Mesclar de volta para desenvolver e excluir a ramificação de lançamento

Agora que o lançamento está quase concluído, você desejará mesclar o branch de lançamento em develop , atualizar o número da versão no último e transferir todas as correções de bugs feitas para o branch de desenvolvimento principal:

 $ git checkout develop $ git merge release/xyz

Agora é hora de remover o branch de lançamento :

$ git branch -d release/xyz

6. Geração de registro de alterações

Deve haver um arquivo na raiz do seu projeto chamado CHANGELOG.md (ou equivalente) onde você deve adicionar uma nova entrada sempre que houver um novo lançamento para documentar tudo o que está incluído nele, como correções de bugs, novos recursos, problemas conhecidos e qualquer outra informação relevante na forma de notas de lançamento. Isso é muito útil para usuários e contribuidores verem quais mudanças foram feitas entre cada release (ou versão) do projeto.

A entrada do changelog inclui a data, o número da versão e algumas notas sobre o lançamento. As entradas devem ser mantidas em ordem cronológica inversa. Aqui está um modelo simples que estou usando e que você pode adaptar ao seu projeto:

 <app's name or component released> <version xyz> | <date> <developer's name in charge of release> | <developer's email> Features: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Bugs fixed: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Enhancements: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Optional: known issues plus other release notes.

Além disso, essa etapa pode ser completamente automatizada codificando um script básico que percorre o git log e gera automaticamente a entrada do changelog ou usando uma ferramenta que faz o mesmo, como:

• Github Changelog Generator, por skywinder,
• ReadmeGen por fojuth
• github-changes, por lalitkapoor

Tenha em mente, porém, que o grau de automação que você obtém é diretamente proporcional ao rigor do formato da sua mensagem de confirmação. Acredito que é sempre uma boa prática concordar com um formato específico para mensagens de commit com a equipe. Seguindo as diretrizes sobre o estilo das mensagens de commit, elas serão mais fáceis de analisar e, portanto, mais provável que você possa automatizar a geração do changelog.

7. Comunique-se com as Partes Interessadas

Este é o lugar onde você normalmente faria o seguinte:

• Informe a equipe por meio de uma ferramenta de mensagens interna (por exemplo: Slack) que uma nova versão foi concluída. Eu recomendo criar um novo canal (por exemplo: #releases ) com o único propósito de comunicar eventos relacionados ao lançamento. É fácil adicionar ganchos em um canal do Slack para postar uma mensagem após a execução de uma ação.
• Como alternativa, envie um e-mail para as partes interessadas com um link para o log de alterações ou o arquivo de log de alterações anexado.
• Escreva uma postagem no blog (se você tiver um blog para seu aplicativo ou produto) ou um tweet.

Mais ações podem ser tomadas dependendo da natureza da sua organização. O importante é não esquecer de comunicar que uma nova versão do seu produto está disponível.

8. Preparando o rastreador de problemas

Após a execução de uma versão, você provavelmente precisará atualizar o status de alguns de seus tickets para acompanhar as correções de bugs ou recursos atualmente em produção. Geralmente, isso envolve a alteração de algumas tags (para projetos pequenos, uso uma tag de liberação pendente , que removo após a conclusão da versão).

Se você usar marcos para cada nova versão, provavelmente precisará atualizar seu status ou marcá-los como concluídos. Alguns rastreadores de problemas até permitem planejar o lançamento e alinhá-lo com sprints, rastrear se um bug está bloqueando um lançamento e outras informações úteis.

Tudo depende de como você usa a ferramenta. Quero apenas salientar que a tarefa de atualizar as informações no rastreador de problemas deve ser incluída na sua lista de verificação de lançamento.

Sobre como automatizar o processo de lançamento

O leitor deve ter notado que, além da etapa de registro de alterações descrita acima, muitas das etapas acima mencionadas também podem ser automatizadas.

A capacidade de automatizar algumas partes do processo de lançamento é uma grande vitória e economiza muito tempo. Sugiro criar scripts ou descobrir como automatizar etapas individuais e trabalhar em direção a uma meta de entrega contínua. A entrega contínua pode reduzir riscos, reduzir custos e reduzir o tempo que os desenvolvedores precisam gastar no gerenciamento da versão. Consequentemente, você poderá lançar com mais frequência e ser mais produtivo em termos de horas alocadas para desenvolvimento.

O santo graal das empresas de DevOps é poder lançar uma nova versão pressionando um botão (ou executando um comando) que acionaria o processo de lançamento automaticamente, ou melhor ainda, um sistema que lançaria uma nova versão do seu software em um tempo designado. Claro, isso é difícil de conseguir porque você também precisa automatizar muito do processo de teste, mas não é impossível.

Adotando as melhores práticas

Nesta seção, descreverei algumas práticas recomendadas que achei convenientes, seja para tornar o processo de lançamento mais suave ou para tomar medidas de segurança caso algo dê errado.

Encontre o dia mais adequado para realizar a liberação

Eu costumo lançar aplicativos em que estou trabalhando às quintas-feiras, entre o meio-dia e o fechamento do expediente.

Se você trabalha de segunda a sexta-feira, não é uma boa ideia lançar em uma sexta-feira. Se algo quebrar após o lançamento, você não terá tempo para consertá-lo até segunda-feira (a menos que queira trabalhar durante o fim de semana). É por isso que é mais conveniente fazer lançamentos na quinta-feira, porque você tem sexta-feira para monitorar a nova versão após ser implantada, corrigir qualquer problema ou fazer uma reversão.

Outra coisa importante a mencionar se você estiver gerenciando um aplicativo da web é saber o fuso horário em que a maioria dos seus usuários está localizada. Você deve cronometrar a liberação durante um período de baixo tráfego para minimizar o dano potencial se algo falhar. Às vezes, isso pode ser complicado quando sua base de usuários está espalhada por todo o mundo, mas de qualquer maneira, você deve fazer alguma pesquisa e decidir o melhor momento.

Faça backup do seu banco de dados antes de uma nova versão

Se você não tiver backups periódicos do seu banco de dados agendados, sugiro fortemente que você adicione uma etapa ao seu processo de lançamento para realizar um backup antes de iniciar o lançamento.

Lançamentos graduais

Você já se perguntou por que, quando um editor anuncia que lançou um novo recurso, leva dias ou até semanas para que esse recurso esteja disponível em seu telefone? Isso porque muitas empresas usam lançamentos em etapas.

O Facebook já faz isso há muito tempo. Ele testa um novo recurso em cinco ou 10% de seus usuários, aumentando-o gradualmente até atingir 100% da base de usuários. Durante a fase de lançamento gradual, você precisará analisar atentamente os comentários dos usuários e os relatórios de erros. Com essas informações, você pode adiar o lançamento ou corrigir erros antes que eles afetem todos os usuários.

Há uma ótima ferramenta no Developer Console do Android que implementa lançamentos em etapas para seus aplicativos Android.

Integração contínua

A Integração Contínua é uma prática que vale a pena adotar por muitas razões. Em primeiro lugar, permite detectar erros antecipadamente, aumentando a taxa de lançamentos bem-sucedidos. Em segundo lugar, é o primeiro passo lógico antes de implementar a Entrega Contínua e a automação completa, conforme descrito anteriormente.

Martin Fowler é um grande defensor da Integração Contínua. Ele descreve uma enorme quantidade de benefícios que podem ser adicionados ao seu processo de liberação ao usar essa prática. Este é um tema grande e existem muitos livros e posts sobre isso, e estou mencionando aqui porque acredito que isso lhe dará muito mais confiança em suas operações. Entre as muitas vantagens de usar CI, você encontrará: risco reduzido, maior visibilidade para saber o que está funcionando e o que não está funcionando, detecção precoce de bugs, maior frequência de implantações e muito mais.

O ponto de partida para a implementação do CI é configurar um “servidor de integração contínua”; algumas boas ferramentas para experimentar são: CruiseControl, Bamboo, Jenkins e Travis.

Exitlude: Tudo vai dar certo

Agressivamente, todos nós defendemos o papel que desempenhamos Lamentavelmente, os tempos vêm para enviar você em seu caminho Já vimos tudo, fogueiras de confiança, inundações instantâneas de dor Isso realmente não importa, não se preocupe, vai tudo funciona

Exitlude, Os Assassinos

Para encerrar, eu diria que é muito importante ter um processo de lançamento bem definido para seu aplicativo, independentemente de sua complexidade, base de usuários ou quão pequena seja sua organização.

Se não, sugiro que comece a pensar em algumas etapas básicas, usando este guia e outros semelhantes, e faça um brainstorming com sua equipe para criar um primeiro rascunho. Experimente-o em sua próxima versão e, em seguida, repita. Eventualmente, você acabará construindo seu próprio processo de lançamento.

Depois disso, comece a pensar em como automatizar partes do processo . Pense em áreas que podem ser melhoradas. Explore formas de reduzir o tempo de lançamento incorporando pequenas otimizações. A automação deve ser seu objetivo final; no entanto, não planeje isso desde o início, ou você falhará ao tentar um salto tão grande. Tal como acontece com todos os processos, é melhor melhorá-lo gradualmente.

Você tem outros truques ou diretrizes que usa para lançar novas versões do seu aplicativo? Se assim for, deixe-me saber. Eu não venho do mundo DevOps, sou apenas um desenvolvedor bastante organizado e estruturado, mas comparado a muitos veteranos, ainda sou um novato nesse aspecto, então sinta-se à vontade para comentar ou entrar em contato comigo se tiver algo a acrescentar.