Jornada a uma versão sem problemas

Este vídeo garante reduzir os níveis de estresse antes da próxima versão blockbuster

Laura Daly Laura Daly
Buscar tópicos

A melhor medida de sucesso de uma equipe ágil é quando o software em funcionamento é lançado para os clientes. Porém, mesmo as equipes de software experientes se complicam na hora de validar os itens concluídos em relação a ruídos; as revisões de código foram ignoradas, o código não foi mesclado, as construções para o código mesclado falharam… parece familiar?

Nesta apresentação, você vai aprender:

  • Codificar as práticas recomendadas que vão melhorar a capacidade de entregar um produto de qualidade. Como revisões de código são essenciais para oferecer qualidade, e como monitorar e corrigir builds com falhas vai garantir um tempo mais rápido para a liberação.
  • Como instalar e maximizar o hub de versões do Jira Software. Como economizar horas de trabalho permitindo que o hub de versões forneça um cenário claro do progresso e status de uma versão.
  • Concluir a automação desde o build e código, até o liberação. Simplificar o fluxo de trabalho lançando a versão direto do hub de versões.

Assista e aprenda

P & R

Os anfitriões Jason Wong e Megan Cook escolheram as perguntas e respostas favoritas desta apresentação. Leia para saber mais sobre como ter uma versão sem problemas e bem-sucedida.

P1: Quais são os três principais fatores não técnicos que tornam o hub de versões bem-sucedido?

R1: (1) Lançar com confiança: as partes interessadas dentro e fora da equipe vão ser capazes de saber exatamente o que está pronto para ser lançado a qualquer momento ao longo do ciclo de liberação.

(2) Economizar tempo, tomar decisões mais rápido: receba a informação automática e instantânea de quais recursos estão concluídos e prontos para serem lançados e quais têm itens. O hub de versões verifica todos os itens da versão, para que você não precise reconciliar itens e código manualmente.

(3) Registro de versões: saiba o que saiu (quando e qual versão) observando as versões lançadas e o que é planejado no momento para cada versão futura observando as versões não lançadas.

P2: Quem geralmente gerencia o liberação de versões na Atlassian?

R2: cada equipe da Atlassian tem uma abordagem específica, mas, no geral, a gente tenta automatizar o máximo possível do processo, para que as atualizações de segurança de produção ou o liberação de uma nova versão de atualização de segurança de um produto possam ser feitos por qualquer desenvolvedor, com sobrecarga mínima.

Geralmente as equipes têm uma lista das coisas que precisam ser feitas, mas a gente tenta minimizar isso o máximo possível. Ferramentas como o hub de versões ajudam nesse processo para garantir que o que planejamos lançar seja da mais alta qualidade e que não haja incoerências entre os estados dos itens do Jira Software e o desenvolvimento real.

Algumas das maiores equipes (por exemplo, Jira Software e Confluence) vão ter uma rotação dedicada para um especialista em bugs/gerente de versões que gerencie todas as versões.

Para versões Major e Minor maiores, geralmente há uma pessoa responsável por cuidar do liberação, garantindo que o escopo esteja sendo gerenciado e todo o trabalho necessário para o liberação seja administrado com relação a riscos e ao tempo. isso pode ser supervisionado por um líder de equipe ou gerente de desenvolvimento, mas a gente tenta garantir que haja rotação entre os membros da equipe, para que todos conheçam o processo e entendam os requisitos de liberação de um software de qualidade.

Quanto ao planejamento do cronograma, os líderes de equipe vão coordenar com os gerentes de produto e profissionais de marketing a definição de expectativas sobre quando uma versão vai estar pronta e se o escopo ou o tempo precisam ser gerenciados. São essas pessoas que decidem quais recursos vão ser lançados em quais versões.

P3: Como você associa uma ramificação/commit/solicitação pull/build/implementação a um item?

R3:

1. Ramificação - inclua a chave do item no nome da ramificação
2. Commit - inclua a chave do item na mensagem de confirmação
3. Solicitação pull - inclua a chave do item no nome da ramificação de origem, na mensagem de confirmação incluída ou no título da solicitação pull
4. Build - inclua a chave do item em uma mensagem de confirmação incluída
5. Implementação - inclua a chave do item em uma mensagem de confirmação incluída

P4: Que experiência você tem em lidar com os conflitos que surgem ao trabalhar no mesmo código em ramificações de itens isoladas?

R4: A experiência que a gente tem é de que isso raramente é um problema. A maioria dos itens têm pouca sobreposição de código, mas ocasionalmente conflitos ocorrem, sim.

Geralmente acontecem dois problemas:

  • Ramificações de recursos de longa execução isoladas de outros desenvolvimentos em andamento
  • Tarefas de refatoramento enormes que precisam ser separadas até que sejam concluídas, testadas e prontas para liberação

Para o primeiro, uma opção séria é fazer o desenvolvimento e integrar com frequência, mas manter os recursos por trás dos sinalizadores de recursos, para que apenas o próprio uso interno ou alguns poucos clientes vejam as mudanças em andamento. Isso garante que o código conflitante seja integrado com frequência contínua e minimiza as chances de conflito, além de minimizar o risco e o impacto quando um grande recurso é adicionado à ramificação de desenvolvimento principal.

Se isso não for viável, e no caso de grandes refatoramentos, garantimos que a ramificação de desenvolvimento seja integrada à ramificação de recursos o mais rápido possível (mesclando as alterações na base/ramificação desenvolvimento para a ramificação de recursos). Isso garante que todo o desenvolvimento em andamento seja concluído e testado em relação à ramificação de recursos de longa execução o mais rápido possível. Se houver algum conflito de mesclagem, é muito mais fácil convencer as pessoas que fizeram as alterações a resolver ou, pelo menos, manter o escopo mínimo para facilitar a resolução.

A melhor solução é dividir qualquer trabalho em partes que possam ser mescladas na ramificação estável ou de desenvolvimento com a maior frequência possível. Isso minimiza a chance de alterações nos mesmos arquivos serem feitas nas ramificações de recursos ao mesmo tempo.

P5: Qual estratégia você recomenda para gerenciar ramificações paralelas para desenvolvimentos em andamento (recursos), hotfixes e respectiva implementação em diferentes ambientes (garantia de qualidade/staging/produção)?

R5: A gente tem várias estratégias de ramificação documentadas no site do Git. Especificamente, consulte a seção de comparação de fluxos de trabalho.

Dados mais avançados podem ser encontrados em conversas anteriores, Use bem o Git e fluxos de trabalho de implementação contínua são abordados com mais profundidade em Fluxos de trabalho do Git para equipes SaaS.

Resumindo, há dois fluxos de trabalho predominantes: um fluxo de trabalho de versão do produto para produtos para download e um fluxo de trabalho do SAAS para serviços on-line (fluxos de trabalho do Git para equipes SaaS).

Para produtos para download, a maioria das equipes usa uma variante do Gitflow Workflow, em que o mestre é usado para desenvolvimento em andamento e cada versão menor anterior tem a própria ramificação, a partir da qual ramificações de atualização de segurança são feitas e mescladas de volta e, quando necessário, uma versão de atualização de segurança é compilada. Cada ramificação de versão anterior tem todas as alterações mescladas posteriormente às versões subsequentes, e o mestre garante que todas as atualizações de segurança sejam incluídas em todas as versões subsequentes.

P6: O hub de versões funciona bem com o Kanban e versões frequentes?

R6: Sim, ele funciona bem. O botão Lançar no painel Kanban pode ser usado para criar uma nova versão contendo todos os itens dessa versão. Após a versão ser criada, o hub de versões pode ser usado para verificar quaisquer avisos ou para obter uma visão geral da versão.

Mesmo sem o painel Kanban, você pode criar uma versão a qualquer momento e adicionar itens mesmo se eles já tiverem sido concluídos. O hub de versões pode então ser usado para verificar quaisquer avisos para garantir que a versão esteja pronta.

P7: O hub de versões pode mostrar informações sobre os itens de vários projetos do Jira Software ou é específico por versão de projeto e correção?

R7: O hub de versões é uma visão aprofundada de uma versão. Como atualmente as versões são específicas por projeto, o hub de versões também é.

P8: É possível que os avisos do hub de versões sejam preenchidos automaticamente em uma sala do Hipchat?

R8: Atualmente não há integrações entre os avisos do hub de versões e o Hipchat, e não há planos de criar essas integrações. A gente tem pensado sobre as diferentes maneiras em que o hub de versões pode melhorar a colaboração da equipe com o Hipchat e quer ouvir mais dos clientes sobre como eles podem usar essa integração ou quaisquer outras integrações com os outros produtos que a gente oferece.

P9: Ao que o botão Lançar é associado? A um script para ser implementado ao servidor de produção como um Job no Bamboo?

R9: O botão Lançar tem algumas funções:

  • Ele pode definir a data de liberação e alterar o status de uma versão para "Lançada". Se houver algum item em aberto na versão, ele também vai dar a opção de mover o item para outra versão. Tudo isso está disponível com ou sem a integração do Bamboo.
  • Quando o Bamboo é integrado ao Jira Software, o botão Lançar pode ser usado para iniciar uma nova build que pode ser configurada no Bamboo para executar as etapas necessárias para lançar a versão (por exemplo, um script para implementar na produção ou produzir um novo artefato).
  • O botão Lançar também pode ser usado para iniciar uma preparação manual para uma build do Bamboo que tenha sido executada. Isso permite que você tenha uma build executada automaticamente, mas tenha uma preparação opcional que seja ativada apenas manualmente e que execute a implementação/liberação. (A preparação seria equivalente a toda a build na Opção nº 2, mas podendo usar os artefatos que a build produz na execução.)

P10: Há algum plano para integrar o hub de versões ao Github/GitHub Enterprise?

R10: O hub de versões já funciona com o GitHub e o GitHub Enterprise. Tudo o que você precisa fazer é conectar a instância do Jira Software à conta do GitHub usando as Contas DVCS encontradas no menu do administrador de complementos no Jira Software. Em seguida, você pode começar a acompanhar o progresso de qualquer uma das versões com qualquer informação de desenvolvimento relacionada incluída no hub de versões.

a seguir
Qa at speed