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ê aprenderá:

  • Melhores práticas de codificação que vão ajudar a aprimorar sua capacidade de entregar um produto de qualidade. Saiba por que as análises de código são essenciais para a qualidade e como monitorar e corrigir builds falhos garante tempo de lançamento mais rápido.
  • Como configurar e maximizar o hub de versões do Jira Software. Aprenda a economizar horas de trabalho permitindo que o hub de versões disponibilize imagens claras do progresso e o status das versões.
  • Automação completa desde o build e o código até o lançamento. Simplifique 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 versã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 problemas. O hub de versões verifica todos os itens da versão, para que você não precise fazer a reconciliação manual de itens e código.

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

P2: Quem gerencia o lançamento de versões na Atlassian em geral?

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 lançamento 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ês associam 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 commit
3. Solicitação pull - inclua a chave do item no nome da ramificação de origem, na mensagem de commit incluída ou no título da solicitação pull
4. Build - inclua a chave do item em uma mensagem de commit incluída
5. Implementação - inclua a chave do item em uma mensagem de commit incluída

P4: Que experiência vocês têm 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 é raro ser um problema. A maioria dos itens tem pouca sobreposição de código, mas às vezes ocorrem conflitos, sim.

Geralmente acontecem dois problemas:

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

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ês recomendam para gerenciar ramificações paralelas para desenvolvimentos contínuos (recursos), hotfixes e respectiva implementação em diferentes ambientes (QA/staging/produção)?

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

Dados mais avançados podem ser encontrados em conversas anteriores, como 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 de 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 contínuo 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 às versões subsequentes depois, 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 quadro 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 no momento as versões são específicas por projeto, o hub de versões também é.

P8: É possível fazer o preenchimento automático dos avisos do hub de versões em uma sala do Hipchat?

R8: No momento 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 com 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? Um script para ser implementado ao servidor de produção como uma tarefa no Bamboo?

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

  • Ele pode definir a data de lançamento e alterar o status de uma versão para "Lançado". Se houver algum item aberto na versão, ele também vai dar a opção de mover esses itens para outra versão. Todas essas opções ficam disponíveis 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 um build novo que pode ser configurado no Bamboo para tomar as medidas 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 um estágio manual para uma compilação do Bamboo que foi executada. Assim você pode ter um build de execução automática, mas também um estágio opcional com acionamento apenas manual e que executa de fato a implementação/o lançamento. (O estágio seria equivalente a todo o build na Opção nº 2, mas pode usar os artefatos que o 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