Obter através da App Store Leia esta publicação em nosso aplicativo!
Abordagens de controle de versão em Scrum [fechado]
Recentemente, com meus colegas de trabalho, discutimos como organizar o controle de versão em um projeto Scrum. Mais especificamente, os critérios para a criação de filiais (por desenvolvedor, por tarefa, por história, por Sprint?) E os métodos de integração.
Minha opinião era que uma maneira útil de organizá-lo é criar um ramo para cada História do Usuário, para que você possa integrar cada História no tronco removível assim que for concluída e também permite que você sempre tenha uma "versão entregue" do aplicativo a qualquer momento.
Então, se uma história não puder ser concluída, pode ser deixada de fora e não compromete a versão do sprint. (Que considerando uma ferramenta centralizada, pode ser se usando uma distribuída, as considerações seriam diferentes)
Gostaria de conhecer suas próprias abordagens, qual o tipo de ferramentas que você prefere e os prós e contras que você viu com a experiência e as lições aprendidas.
fechado como primeiramente baseado em opinião, por Robin Green, Paul Roub, Skatox, Qiu, Cory Charlton 18 de agosto de 15 às 19:06.
Muitas boas perguntas geram algum grau de opinião com base na experiência de especialistas, mas as respostas a esta pergunta tendem a ser quase inteiramente baseadas em opiniões, ao invés de fatos, referências ou conhecimentos específicos. Se esta questão pode ser reformulada para ajustar as regras no centro de ajuda, edite a questão.
Mantenha o protocolo de ramificação leve. No Scrum, se alguém quiser ramificar o código para trabalhar em um recurso específico, deixe-os. Ninguém deve ter medo de se ramificar. Este é um dos benefícios do DVCS - ramo de pessoas quando eles querem e não são tendenciosos pelas regras ou padrões da equipe.
Para o meu dinheiro, é caso a caso, e se você começar a ver padrões em seus processos de desenvolvimento, formalize-os para que todos estejam na mesma página.
Apenas certifique-se de que cada desenvolvedor entende que é sua responsabilidade integrar e mesclar suas mudanças. Isso deve definir a barra em torno do lugar certo para garantir que as pessoas façam a chamada certa quanto ao momento de se ramificar o código.
Um ramo por história de usuário soa bastante excessivo para mim. Nós mantemos uma única base de código (tronco) e trabalhamos com isso. A única vez que normalmente nos ramificamos é consertar um problema de produção atual que não poderia esperar até uma versão regular.
Esse é um tópico muito interessante.
Nós sempre reforçamos a ramificação por criação de tarefas, de fato, cada tarefa (não história, mas tarefas reais como decompostas após a reunião de planejamento de Scrum) terá pelo menos uma ramificação associada.
Você pode ver como parece no seguinte diagrama:
Isso faz com que as coisas gostem de encorajar opiniões de pares muito fáceis, já que a equipe pode verificar o que foi modificado em uma tarefa (ramo), mesmo quando os desenvolvedores decidiram fazer muitos compromissos intermediários (o que é uma prática muito boa!)
Há uma série de links abaixo que podem ser úteis:
Sempre que temos uma história ou um conjunto de histórias que ameaçam deixar o ramo mestre em desordem durante vários dias ou envolver "muitos" desenvolvedores, criamos um ramo para isso (não é muito comum, tentamos fazer tarefas para evitar isso, mas isso acontece) como uma espécie de coisa de mitigação de risco. Queremos ter certeza de que o ramo principal está sempre pronto para a liberação no final de cada sprint, mesmo que isso signifique potencialmente que não possamos aumentar o valor do ramo principal depois do sprint.
O ramo da história / função / tarefa é sincronizado contra o ramo principal com muita frequência, e o objetivo é sempre ter o ramo fundido novamente bem antes do final do sprint.
Claro, todos usamos 'git', então, de fato, sempre temos uma filial local em que trabalhamos, e nos tornamos muito bons em sincronizar com o mestre com freqüência suficiente para evitar integrações big-bang e raramente o suficiente para não deixar inútil / código não utilizado no ramo mestre.
Além disso, fazemos "ramificação por propósito" (PDF). Eu também escrevi um pouco mais sobre como fazemos aqui.
Gostaria de usar um ramo por versão e usar a Integração Contínua para evitar que uma história de usuário prejudique os outros.
A única alteração que você deve fazer no seu sistema de controle de origem é integrá-lo ao sistema de integração contínua (como o TeamCity ou o CruiseControl).
Sim, eu sei que não estou realmente respondendo sua pergunta, mas eu realmente quero dizer isso. No projeto de software ágil, você deseja liberar o produto aos clientes (ou ser capaz de) o mais rápido possível. É por isso que você precisa saber que o que está em seu sistema fonte está funcionando ou se não está funcionando por que não está funcionando.
Não vejo como um ramo por recurso pode torná-lo mais ágil ou magra. O custo do gerenciamento de filiais é muito alto. Eu argumentaria que, se você sentir que precisa de um ramo por recurso, suas histórias são muito grandes. Uma história deve ser completada pelo próximo scrum e, se não, certamente pelo próximo. Então, se uma filial existe apenas por 1-2 dias, não vejo como isso pode ser útil ou seu custo reembolsado. É rotina para muitas pessoas trabalharem em uma história, então eu às vezes uso um ramo de desenvolvedores para que os desenvolvedores trabalhem para que possam mesclar o código Muitas vezes ao dia enquanto trabalham na mesma história sem que o código seja implantado para testar (ramo principal) . Idealmente, você teria poucas histórias em andamento e as completaria tão rápido que você só precisaria do ramo principal e nenhum outro.
Estratégia de versão ágil
Obter através da App Store Leia esta publicação em nosso aplicativo!
Controlando números de versão em sprints [fechado]
Tradicionalmente, os números de compilação de software se encaixam no formato.
Onde uma versão principal é implementada sempre que há mudanças de quebra, Menor quando novos recursos mini são adicionados, Libere quando algo for publicado e seja construído sempre que for construído.
Eu acho que os dois últimos dígitos funcionam muito bem em um ambiente de CI, cada construção de CI aumenta o número de compilação e cada versão para o Live incrementa o número de lançamento.
No entanto, o grande trabalho de cachoeira e os desenvolvimentos de mudança de ruptura são desencorajados em metodologias mais modernas. Nós preferimos liberar pouco e muitas vezes e, portanto, não tendem a fazer grandes mudanças de ruptura. Dado isto, é muito difícil determinar quando criar uma nova versão principal.
Nós tentamos evitar fazer grandes mudanças de ruptura e, assim, estamos conseguindo números muito baixos e menores, mas não tivemos a desculpa para avançar ainda uma versão importante. Que critérios devem ser usados para determinar quando as construções maiores e menores devem ser feitas (particularmente aplicativos baseados na web)?
Estou ciente de que há versões de estilo de data, mas estou interessado em Major. Minor. Build. Release apenas.
fechado como baseado principalmente em opinião de Michael Kohne, Dan Pichelman, MichaelT, mattnz, Dynamic Jul 2 '14 às 15:03.
Muitas boas perguntas geram algum grau de opinião com base na experiência de especialistas, mas as respostas a esta pergunta tendem a ser quase inteiramente baseadas em opiniões, ao invés de fatos, referências ou conhecimentos específicos. Se esta questão pode ser reformulada para ajustar as regras no centro de ajuda, edite a questão.
Eu acho que algum dos desafios começa com sua afirmação de:
Onde uma versão principal é implementada sempre que houver mudanças de quebra.
E tenho certeza de que você quer dizer "quebrar mudanças" no sentido de mudanças significativas na API; Mudanças na comunicação cliente / servidor; protocolo de trabalho, etc. "Big Stuff" (TM) em outras palavras.
Mas o problema é que não é apenas quebrar as mudanças que contam, mas qualquer mudança significativa que conta. "Significativo" varia de aplicativo para aplicativo, e é por isso que é difícil ser específico sobre o que se qualifica como significativo. Alterar o número principal deve ser um anúncio informal para os usuários finais que:
Algo grande é diferente. Eles devem preparar ou estar cientes de que isso provavelmente não será uma atualização trivial.
Então, aqui estão algumas das razões comuns que eu vi atualizar o número principal:
Marketing (ou desenvolvimento) sentiu como ele. Wicked legal, novo, grande recurso introduzido. Ou todo um monte disso. O esquema de banco de dados sofreu mudanças significativas. Muitas vezes isso irá forçar uma atualização para os usuários finais. Protocolo muda. Isso pode incluir mudanças significativas entre o navegador e o servidor da Web, ou pode estar entre o cliente e o servidor. A estabilidade da aplicação melhorou significativamente (ou piorou) e você deseja alterar a versão principal para informar ou alertar os usuários sobre a mudança. Alguma quantidade específica de tempo já passou - isso pode ser X meses, anos, seja o que for. O produto agora é compatível com algum padrão externo ou processo de auditoria. A aplicação foi bifurcada. Mudanças significativas foram feitas no suporte de bibliotecas, ou quais bibliotecas poderiam ser usadas.
De um modo geral, você quer dizer por que você aumentou o valor principal. É aqui que construir um "passo de elevador" para justificar o incremento pode ser útil. E, assim como um passo de elevador que você usa para se vender, esta é uma declaração rápida que resume o que era grande o suficiente para merecer a mudança.
Alguns pensamentos adicionais sobre o controle de versão.
Primeiro, você não precisa atualizar o valor principal de forma regular. Pode não fazer sentido se tudo o que está sendo fornecido é um monte de pequenos itens.
Se você sentir que está "ficando sem espaço" com os valores dos outros números, considere:
Use valores hexadecimais (base 16) ou outra base em vez de apenas valores decimais (base 10). Use dois ou mais dígitos dentro de cada valor. Então, você teria M. mm. rr. bbb, por exemplo.
Se o usuário do seu software não puder atualizar para a nova versão e usá-lo sem outras etapas de migração manual (dados, configuração, interfaces e similares), esse é um indicador forte para aumentar a versão principal.
Seja o que for que você esteja usando internamente, externamente você ainda terá uma cachoeira como o ciclo de liberação.
Quer se chame agora de "lançamento de recursos", "lançamento para produção", "versão de entrega do cliente", ou seja, será o produto combinado de uma série de sprints e ciclos internos mais curtos.
Estratégia de versão ágil
Obter através da App Store Leia esta publicação em nosso aplicativo!
Versionamento semântico em Agile.
Digamos que eu tenho 14 dias de iteração de sprint, onde eu tenho várias histórias para novos recursos, poucas melhorias e alguns erros para consertar. Eu também implanto essas mudanças quando estão prontas, eu não estou aguardando o fim do sprint.
Meu problema é - como controlar o controle de versão semântico de produtos desenvolvidos e mantidos assim? Se houver lançamento a cada 14 dias, será fácil, aumentarei o número da versão e anotarei todas as alterações no changelog. Mas e se as mudanças forem implantadas de forma contínua? Deveria haver uma versão aumentada sempre que algo for implantado? Ou devo esperar até que Sprint termine e depois disso, faça algum "currículo" e aumente o número da versão apenas uma vez por iteração de forma independente na implantação real? Quais são as melhores práticas para o controle de versão semântico no Agile?
EDITAR: Para melhor explicar minhas necessidades, eu quero uma mudança para as partes interessadas em primeiro lugar. Eu não acho que eles estarão interessados em novo registro em changelog após cada mudança implantada.
Para o gerenciamento de lançamento típico, você quer que um número de compilação seja gerado pelo seu sistema de compilação para que as DLLs sejam versionadas sempre que forem implantadas. Isso garantirá que você poderá verificar a versão que é implantada em um determinado servidor.
Sua versão de "marketing", que geralmente é colocada em notas de versão ou publicada em seu site, não deve ser atualizada em cada versão. Essas notas de lançamento devem ser acumuladas e agrupadas, provavelmente programadas com o final do seu sprint.
Se o clássico esquema de versão semântica "MAJOR. MINOR. PATCH" faz sentido, depende de quem você implantar e, especialmente, quando e com que frequência você se implanta para o usuário final. O esquema é mais útil se você trabalhar com versão estável "4.5", onde você começa com 4.5.0. As versões 4.5.1, 4.5.2, e assim por diante, contêm apenas correções de bugs, enquanto você internamente já trabalha na versão 4.6.
Por exemplo, se você fornecer um "ramo estável" ao seu usuário final, dê uma versão 4.5.0 para a implantação inicial e 4.5.1, 4.5.2 sempre que você liberar um patch. No seu desenvolvimento interno "ágil" e na implementação do meio do sprint, você já pode ter uma versão 4.6, basta chamá-la de "versão beta". Sempre que você o implanta no meio do sprint, adicione o número de compilação gerado automaticamente como "4.6.beta build 123". Quando o seu sprint termina, atribua-o "4.6.0" e mude o número da versão para o próximo sprint internamente para "4.7". Começar com ".0" é apenas uma convenção, você também pode usar o ".0" para etiquetar versões beta e começar com ".1" para seus usuários finais. IMHO a palavra "beta" é muito mais expressiva, dizendo a todos que o sprint "ainda não está completo".
Se você liberar um registro completo de alterações do usuário final com cada versão beta depende de você, mas pelo menos no final do sprint, o log de alterações deve ser concluído e sempre que você fornecer um bugfix ao usuário final, você também deve atualizar os documentos de histórico.
Você encontrará a estratégia de liberar dois ramos separados, um ramo "estável" com números de versão semântica e um "ramo de desenvolvimento" marcado com números de compilação ou algo similar, em muitos produtos de código aberto como o Inkscape, o Firefox ou o 7-zip.
Se, no entanto, você não trabalha com estações estáveis e de desenvolvimento separadas, e divulgue diariamente uma nova versão ao usuário final, você também deve incrementar um número de versão diariamente. Para tal caso, os números de versão "4.5.1", "4.5.2",. provavelmente refletirá suas implantações individuais e não indicará a diferença entre correções de erros e outras alterações. Isso pode estar certo, não é mais o "controle de versão semântico" clássico. Nesse cenário, você também pode implantar versões 4.5, 4.6, 4.7, 4.8, que não dá nenhuma diferença real.
No que diz respeito à sua pergunta sobre as entradas no seu changelog: IMHO quando algo é visível para o usuário final, vale a pena uma entrada no changelog, assim que você implantar a alteração. Por exemplo, se você usar alternar recursos e fazer alterações em algum recurso meio cozido que ainda não esteja ativado para o usuário, isso não pertence a um changelog. Se você fizer apenas refatoração, sem alteração visível para o usuário, isso não pertence a um changelog. Se você corrigir um bug que poderia ter afetado alguns usuários, isso pertence definitivamente ao changelog - e deve ser mencionado lá ao mesmo tempo em que você implanta o bugfix. E não importa se você liberar diariamente, mensalmente ou anualmente.
Eu usaria números de compilação. Normalmente, um número de compilação corresponderia à versão mais alta do sistema de controle de versão. Se o número de compilação das segundas-feiras era 1745 e verificou-se 5 mudanças durante a terça-feira, o número de construção das noites de terça-feira seria 1750.
Em seguida, faça um breve resumo do que mudou entre 1745 e 1750.
Então, toda vez que você atualiza o número da versão do seu sistema, você pode adicionar todos os resumos curtos das compilações para obter as alterações do último número da versão para o novo.
O método preferido que usei há pelo menos alguns anos agora é superar o número após a conclusão de cada história. Isto significa que as versões lançadas no final do sprint não serão contínuas, p. Depois de 1.2.3 você pode encontrar 1.5.2 em vez de 1.4.0.
No changelog você pode listar as versões intermediárias com suas descrições correspondentes ou apenas agrupar todas as mudanças na versão "lançada" e ignorar as versões no meio.
Inicialmente, eu estava com medo de que os usuários achassem os "buracos" entre os números de versão problemáticos, mas uma vez que eles sabem sobre isso, não é um problema na prática. A grande vantagem é que aumentar o número após cada história torna o processo menos propenso a erros - você não precisa verificar todo o trabalho a partir de 2 semanas para decidir qual será o próximo número de versão - ao olhar para uma única história, é óbvio . Além disso, os "saltos" em números de versão entre cada versão dão uma estimativa aproximada de quantas mudanças entraram no lançamento. No geral, eu achei que este sistema funcionou bem (isto foi com clientes internos da empresa, mas se você já trabalha em um ciclo de liberação ágil, ele também deveria funcionar para clientes externos).
O recurso abre caminho para a grandeza.
Ou tarefa que se ramifica para lá. Ou liberar ramificações. Você escolhe.
O Agile Coach.
Quase todos os sistemas de controle de versão hoje oferecem suporte a linhas de trabalho independentes que derivam de uma base de código central. Dependendo do seu sistema de controle de versão, o ramo principal pode ser chamado de mestre, mainline, padrão ou tronco. Os desenvolvedores podem criar seus próprios ramos da linha principal do código e trabalhar de forma independente ao lado dele.
Por que se preocupar com a ramificação?
O Branching permite que equipes de desenvolvedores colaborem facilmente dentro de uma base de código central. Quando um desenvolvedor cria um ramo, o sistema de controle de versão cria uma cópia da base de código naquele momento. Mudanças no ramo não afetam outros desenvolvedores no time. Isso é uma coisa boa, obviamente, porque os recursos em desenvolvimento podem criar instabilidade, o que seria altamente perturbador se todo o trabalho estava acontecendo na linha principal do código. Mas os ramos não precisam viver em confinamento solitário. Os desenvolvedores podem facilmente reduzir as mudanças de outros desenvolvedores para colaborar em recursos e garantir que seu ramo privado não diverge muito do mestre.
ProTip: Os ramos não são apenas bons para o trabalho de recursos. Os ramos podem isolar o time de mudanças arquitetônicas importantes, como atualizações, bibliotecas comuns, etc.
Três estratégias de ramificação para equipes ágeis.
Os modelos de ramificação geralmente diferem entre equipes e são objeto de muito debate na comunidade de software. Um grande tema é a quantidade de trabalho que deve permanecer em um ramo antes de ser incorporado de novo ao mestre.
Liberação de ramificação.
A ramificação de lançamento refere-se à idéia de que uma versão está inteiramente contida em um ramo. Isso significa que, no final do ciclo de desenvolvimento, o gerente de lançamento criará um ramo do mestre (por exemplo, "ramo de desenvolvimento 1.1"). Todas as alterações para a versão 1.1 devem ser aplicadas duas vezes: uma vez para o ramo 1.1 e, em seguida, para a linha do código mestre. Trabalhar com dois ramos é trabalho extra para a equipe e é fácil esquecer de fundir ambos os ramos. Os ramos de liberação podem ser difíceis de manejar e difíceis de gerenciar, pois muitas pessoas estão trabalhando no mesmo ramo. Todos sentimos a dor de ter que combinar muitas mudanças diferentes em um único ramo. Se você deve fazer um ramo de lançamento, crie o ramo o mais próximo possível da versão real.
Aviso: liberar ramificação é uma parte importante do suporte de software versionado no mercado. Um único produto pode ter vários ramos de libertação (por exemplo, 1.1, 1.2, 2.0) para suportar o desenvolvimento de sustentação. Tenha em mente que as mudanças em versões anteriores (ou seja, 1.1) podem precisar ser mescladas para ramos de liberação posteriores (ou seja, 1.2, 2.0). Confira nosso webinar abaixo para saber mais sobre como gerenciar os ramos de lançamento com o Git.
Característica ramificação.
Muitas equipes ágeis que procuram um modelo de ramificação mais flexível passaram de ramificação de lançamento para ramificação de recursos. Um modelo de ramal de características mantém todas as mudanças para um recurso particular dentro de um ramo. Quando o recurso é totalmente testado e validado por testes automatizados, o ramo é então mesclado em mestre.
Os ramos de recursos geralmente são acoplados com bandeiras de recursos - & quot; toggles & quot; que permitem ou desativam um recurso dentro do produto. Isso facilita a implantação do código em mestre e controle quando o recurso é ativado, facilitando a implantação do código antes do recurso ser exposto aos usuários finais.
ProTip: Outro benefício das bandeiras de recursos é que o código pode permanecer dentro da compilação, mas inativo enquanto está em desenvolvimento. Se algo estiver errado quando o recurso estiver ativado, um administrador do sistema pode reverter o sinalizador de recurso e voltar para um bom estado conhecido em vez de ter que implantar uma nova compilação.
Ramificação de tarefas.
Na Atlassian, nos concentramos em um fluxo de trabalho de ramificação por tarefa. Toda organização tem uma maneira natural de quebrar o trabalho em tarefas individuais dentro de um rastreador de problemas, como o JIRA Software. As questões se tornam o ponto central de contato da equipe para esse trabalho. A ramificação de tarefas, também conhecida como ramificação de problemas, conecta diretamente esses problemas com o código-fonte. Cada questão é implementada em seu próprio ramo com a chave de problema incluída no nome da filial. É fácil ver qual código implementa esse problema: basta procurar a chave de problema no nome da filial. Com esse nível de transparência, é mais fácil aplicar mudanças específicas ao mestre ou qualquer ramo de lançamento legado em execução.
Desde centros ágiles em torno de histórias de usuários, os ramos de tarefas parecem bem com o desenvolvimento ágil. Cada história de usuário (ou correção de bugs) vive dentro de seu próprio ramo, facilitando a visão de quais problemas estão em andamento e estão prontos para serem lançados. Para um mergulho profundo na ramificação de tarefas (às vezes chamado de ramificação de questões ou ramificação por questão), pegue algumas pipocas e confira a gravação do webinar abaixo, uma das nossas mais populares de todos os tempos.
Agora conheça o gêmeo malvado da ramificação: a fusão.
Todos nós sofremos a dor de tentar integrar vários ramos em uma solução sensata. Tradicionalmente, sistemas de controle de versão centralizados como o Subversion fizeram uma operação muito dolorosa. Mas os sistemas de controle de versões mais recentes, como o Git e o Mercurial, tomam uma abordagem diferente para rastrear versões de arquivos que vivem em diferentes ramos.
Com o Git, a fusão é trivial, liberando-nos para explorar todo o poder dos fluxos de trabalho de ramificação.
Os ramos tendem a ser de curta duração, tornando-os mais fáceis de fundir e mais flexíveis em toda a base do código. Entre a capacidade de mesclar freqüentemente e automaticamente os ramos como parte da integração contínua (CI), e o fato de que os ramos de curta duração simplesmente contêm menos mudanças, "fundir o inferno" torna-se uma coisa do passado para equipes usando Git e Mercurial.
Isso é o que torna a ramificação de tarefas tão incrível!
Validar, validar, validar.
Um sistema de controle de versão só pode ir tão longe em afetar o resultado de uma fusão. Testes automatizados e integração contínua também são críticos. A maioria dos servidores CI pode automaticamente colocar novos ramos em teste, reduzindo drasticamente o número de "surpresas" na junção final a montante e ajudando a manter a linha principal do código estável.
Produtos discutidos.
Inscreva-se para mais artigos.
Leituras recomendadas.
Coloque-o em prática.
Faça sério sobre ramificação.
Gerencie os repositórios do Git, configure as permissões e colabore no código. Seguro, rápido e de nível empresarial. Explore Bitbucket.
A seguir.
Por que as críticas de código são importantes.
A revisão de código ajuda os desenvolvedores a aprender a base de código, novas tecnologias e novas técnicas. Mas o kicker é que eles realmente lhe pouparam tempo.
Podemos também recomendar.
Problemas impressionantes para fluxos de trabalho de ramificação Git.
Conheça as três equipes de erros de novato que compram ao adotar um fluxo de trabalho de ramificação de recursos e como corrigi-los usando problemas para rastrear o trabalho no software JIRA. Continue lendo.
Sobre o autor.
Dan Radigan.
Evangelista Agile Sênior, Atlassian.
A Agile teve um enorme impacto sobre mim tanto profissional como pessoalmente, como eu aprendi, as melhores experiências são ágeis, tanto no código como na vida. Muitas vezes, você me encontrará na interseção de tecnologia, fotografia e motociclismo. Encontre-me no Twitter! danradigan.
Obter através da App Store Leia esta publicação em nosso aplicativo!
Versionamento semântico em Agile.
Digamos que eu tenho 14 dias de iteração de sprint, onde eu tenho várias histórias para novos recursos, poucas melhorias e alguns erros para consertar. Eu também implanto essas mudanças quando estão prontas, eu não estou aguardando o fim do sprint.
Meu problema é - como controlar o controle de versão semântico de produtos desenvolvidos e mantidos assim? Se houver lançamento a cada 14 dias, será fácil, aumentarei o número da versão e anotarei todas as alterações no changelog. Mas e se as mudanças forem implantadas de forma contínua? Deveria haver uma versão aumentada sempre que algo for implantado? Ou devo esperar até que Sprint termine e depois disso, faça algum "currículo" e aumente o número da versão apenas uma vez por iteração de forma independente na implantação real? Quais são as melhores práticas para o controle de versão semântico no Agile?
EDITAR: Para melhor explicar minhas necessidades, eu quero uma mudança para as partes interessadas em primeiro lugar. Eu não acho que eles estarão interessados em novo registro em changelog após cada mudança implantada.
Para o gerenciamento de lançamento típico, você quer que um número de compilação seja gerado pelo seu sistema de compilação para que as DLLs sejam versionadas sempre que forem implantadas. Isso garantirá que você poderá verificar a versão que é implantada em um determinado servidor.
Sua versão de "marketing", que geralmente é colocada em notas de versão ou publicada em seu site, não deve ser atualizada em cada versão. Essas notas de lançamento devem ser acumuladas e agrupadas, provavelmente programadas com o final do seu sprint.
Se o clássico esquema de versão semântica "MAJOR. MINOR. PATCH" faz sentido, depende de quem você implantar e, especialmente, quando e com que frequência você se implanta para o usuário final. O esquema é mais útil se você trabalhar com versão estável "4.5", onde você começa com 4.5.0. As versões 4.5.1, 4.5.2, e assim por diante, contêm apenas correções de bugs, enquanto você internamente já trabalha na versão 4.6.
Por exemplo, se você fornecer um "ramo estável" ao seu usuário final, dê uma versão 4.5.0 para a implantação inicial e 4.5.1, 4.5.2 sempre que você liberar um patch. No seu desenvolvimento interno "ágil" e na implementação do meio do sprint, você já pode ter uma versão 4.6, basta chamá-la de "versão beta". Sempre que você o implanta no meio do sprint, adicione o número de compilação gerado automaticamente como "4.6.beta build 123". Quando o seu sprint termina, atribua-o "4.6.0" e mude o número da versão para o próximo sprint internamente para "4.7". Começar com ".0" é apenas uma convenção, você também pode usar o ".0" para etiquetar versões beta e começar com ".1" para seus usuários finais. IMHO a palavra "beta" é muito mais expressiva, dizendo a todos que o sprint "ainda não está completo".
Se você liberar um registro completo de alterações do usuário final com cada versão beta depende de você, mas pelo menos no final do sprint, o log de alterações deve ser concluído e sempre que você fornecer um bugfix ao usuário final, você também deve atualizar os documentos de histórico.
Você encontrará a estratégia de liberar dois ramos separados, um ramo "estável" com números de versão semântica e um "ramo de desenvolvimento" marcado com números de compilação ou algo similar, em muitos produtos de código aberto como o Inkscape, o Firefox ou o 7-zip.
Se, no entanto, você não trabalha com estações estáveis e de desenvolvimento separadas, e divulgue diariamente uma nova versão ao usuário final, você também deve incrementar um número de versão diariamente. Para tal caso, os números de versão "4.5.1", "4.5.2",. provavelmente refletirá suas implantações individuais e não indicará a diferença entre correções de erros e outras alterações. Isso pode estar certo, não é mais o "controle de versão semântico" clássico. Nesse cenário, você também pode implantar versões 4.5, 4.6, 4.7, 4.8, que não dá nenhuma diferença real.
No que diz respeito à sua pergunta sobre as entradas no seu changelog: IMHO quando algo é visível para o usuário final, vale a pena uma entrada no changelog, assim que você implantar a alteração. Por exemplo, se você usar alternar recursos e fazer alterações em algum recurso meio cozido que ainda não esteja ativado para o usuário, isso não pertence a um changelog. Se você fizer apenas refatoração, sem alteração visível para o usuário, isso não pertence a um changelog. Se você corrigir um bug que poderia ter afetado alguns usuários, isso pertence definitivamente ao changelog - e deve ser mencionado lá ao mesmo tempo em que você implanta o bugfix. E não importa se você liberar diariamente, mensalmente ou anualmente.
Eu usaria números de compilação. Normalmente, um número de compilação corresponderia à versão mais alta do sistema de controle de versão. Se o número de compilação das segundas-feiras era 1745 e verificou-se 5 mudanças durante a terça-feira, o número de construção das noites de terça-feira seria 1750.
Em seguida, faça um breve resumo do que mudou entre 1745 e 1750.
Então, toda vez que você atualiza o número da versão do seu sistema, você pode adicionar todos os resumos curtos das compilações para obter as alterações do último número da versão para o novo.
O método preferido que usei há pelo menos alguns anos agora é superar o número após a conclusão de cada história. Isto significa que as versões lançadas no final do sprint não serão contínuas, p. Depois de 1.2.3 você pode encontrar 1.5.2 em vez de 1.4.0.
No changelog você pode listar as versões intermediárias com suas descrições correspondentes ou apenas agrupar todas as mudanças na versão "lançada" e ignorar as versões no meio.
Inicialmente, eu estava com medo de que os usuários achassem os "buracos" entre os números de versão problemáticos, mas uma vez que eles sabem sobre isso, não é um problema na prática. A grande vantagem é que aumentar o número após cada história torna o processo menos propenso a erros - você não precisa verificar todo o trabalho a partir de 2 semanas para decidir qual será o próximo número de versão - ao olhar para uma única história, é óbvio . Além disso, os "saltos" em números de versão entre cada versão dão uma estimativa aproximada de quantas mudanças entraram no lançamento. No geral, eu achei que este sistema funcionou bem (isto foi com clientes internos da empresa, mas se você já trabalha em um ciclo de liberação ágil, ele também deveria funcionar para clientes externos).
O recurso abre caminho para a grandeza.
Ou tarefa que se ramifica para lá. Ou liberar ramificações. Você escolhe.
O Agile Coach.
Quase todos os sistemas de controle de versão hoje oferecem suporte a linhas de trabalho independentes que derivam de uma base de código central. Dependendo do seu sistema de controle de versão, o ramo principal pode ser chamado de mestre, mainline, padrão ou tronco. Os desenvolvedores podem criar seus próprios ramos da linha principal do código e trabalhar de forma independente ao lado dele.
Por que se preocupar com a ramificação?
O Branching permite que equipes de desenvolvedores colaborem facilmente dentro de uma base de código central. Quando um desenvolvedor cria um ramo, o sistema de controle de versão cria uma cópia da base de código naquele momento. Mudanças no ramo não afetam outros desenvolvedores no time. Isso é uma coisa boa, obviamente, porque os recursos em desenvolvimento podem criar instabilidade, o que seria altamente perturbador se todo o trabalho estava acontecendo na linha principal do código. Mas os ramos não precisam viver em confinamento solitário. Os desenvolvedores podem facilmente reduzir as mudanças de outros desenvolvedores para colaborar em recursos e garantir que seu ramo privado não diverge muito do mestre.
ProTip: Os ramos não são apenas bons para o trabalho de recursos. Os ramos podem isolar o time de mudanças arquitetônicas importantes, como atualizações, bibliotecas comuns, etc.
Três estratégias de ramificação para equipes ágeis.
Os modelos de ramificação geralmente diferem entre equipes e são objeto de muito debate na comunidade de software. Um grande tema é a quantidade de trabalho que deve permanecer em um ramo antes de ser incorporado de novo ao mestre.
Liberação de ramificação.
A ramificação de lançamento refere-se à idéia de que uma versão está inteiramente contida em um ramo. Isso significa que, no final do ciclo de desenvolvimento, o gerente de lançamento criará um ramo do mestre (por exemplo, "ramo de desenvolvimento 1.1"). Todas as alterações para a versão 1.1 devem ser aplicadas duas vezes: uma vez para o ramo 1.1 e, em seguida, para a linha do código mestre. Trabalhar com dois ramos é trabalho extra para a equipe e é fácil esquecer de fundir ambos os ramos. Os ramos de liberação podem ser difíceis de manejar e difíceis de gerenciar, pois muitas pessoas estão trabalhando no mesmo ramo. Todos sentimos a dor de ter que combinar muitas mudanças diferentes em um único ramo. Se você deve fazer um ramo de lançamento, crie o ramo o mais próximo possível da versão real.
Aviso: liberar ramificação é uma parte importante do suporte de software versionado no mercado. Um único produto pode ter vários ramos de libertação (por exemplo, 1.1, 1.2, 2.0) para suportar o desenvolvimento de sustentação. Tenha em mente que as mudanças em versões anteriores (ou seja, 1.1) podem precisar ser mescladas para ramos de liberação posteriores (ou seja, 1.2, 2.0). Confira nosso webinar abaixo para saber mais sobre como gerenciar os ramos de lançamento com o Git.
Característica ramificação.
Muitas equipes ágeis que procuram um modelo de ramificação mais flexível passaram de ramificação de lançamento para ramificação de recursos. Um modelo de ramal de características mantém todas as mudanças para um recurso particular dentro de um ramo. Quando o recurso é totalmente testado e validado por testes automatizados, o ramo é então mesclado em mestre.
Os ramos de recursos geralmente são acoplados com bandeiras de recursos - & quot; toggles & quot; que permitem ou desativam um recurso dentro do produto. Isso facilita a implantação do código em mestre e controle quando o recurso é ativado, facilitando a implantação do código antes do recurso ser exposto aos usuários finais.
ProTip: Outro benefício das bandeiras de recursos é que o código pode permanecer dentro da compilação, mas inativo enquanto está em desenvolvimento. Se algo estiver errado quando o recurso estiver ativado, um administrador do sistema pode reverter o sinalizador de recurso e voltar para um bom estado conhecido em vez de ter que implantar uma nova compilação.
Ramificação de tarefas.
Na Atlassian, nos concentramos em um fluxo de trabalho de ramificação por tarefa. Toda organização tem uma maneira natural de quebrar o trabalho em tarefas individuais dentro de um rastreador de problemas, como o JIRA Software. As questões se tornam o ponto central de contato da equipe para esse trabalho. A ramificação de tarefas, também conhecida como ramificação de problemas, conecta diretamente esses problemas com o código-fonte. Cada questão é implementada em seu próprio ramo com a chave de problema incluída no nome da filial. É fácil ver qual código implementa esse problema: basta procurar a chave de problema no nome da filial. Com esse nível de transparência, é mais fácil aplicar mudanças específicas ao mestre ou qualquer ramo de lançamento legado em execução.
Desde centros ágiles em torno de histórias de usuários, os ramos de tarefas parecem bem com o desenvolvimento ágil. Cada história de usuário (ou correção de bugs) vive dentro de seu próprio ramo, facilitando a visão de quais problemas estão em andamento e estão prontos para serem lançados. Para um mergulho profundo na ramificação de tarefas (às vezes chamado de ramificação de questões ou ramificação por questão), pegue algumas pipocas e confira a gravação do webinar abaixo, uma das nossas mais populares de todos os tempos.
Agora conheça o gêmeo malvado da ramificação: a fusão.
Todos nós sofremos a dor de tentar integrar vários ramos em uma solução sensata. Tradicionalmente, sistemas de controle de versão centralizados como o Subversion fizeram uma operação muito dolorosa. Mas os sistemas de controle de versões mais recentes, como o Git e o Mercurial, tomam uma abordagem diferente para rastrear versões de arquivos que vivem em diferentes ramos.
Com o Git, a fusão é trivial, liberando-nos para explorar todo o poder dos fluxos de trabalho de ramificação.
Os ramos tendem a ser de curta duração, tornando-os mais fáceis de fundir e mais flexíveis em toda a base do código. Entre a capacidade de mesclar freqüentemente e automaticamente os ramos como parte da integração contínua (CI), e o fato de que os ramos de curta duração simplesmente contêm menos mudanças, "fundir o inferno" torna-se uma coisa do passado para equipes usando Git e Mercurial.
Isso é o que torna a ramificação de tarefas tão incrível!
Validar, validar, validar.
Um sistema de controle de versão só pode ir tão longe em afetar o resultado de uma fusão. Testes automatizados e integração contínua também são críticos. A maioria dos servidores CI pode automaticamente colocar novos ramos em teste, reduzindo drasticamente o número de "surpresas" na junção final a montante e ajudando a manter a linha principal do código estável.
Produtos discutidos.
Inscreva-se para mais artigos.
Leituras recomendadas.
Coloque-o em prática.
Faça sério sobre ramificação.
Gerencie os repositórios do Git, configure as permissões e colabore no código. Seguro, rápido e de nível empresarial. Explore Bitbucket.
A seguir.
Por que as críticas de código são importantes.
A revisão de código ajuda os desenvolvedores a aprender a base de código, novas tecnologias e novas técnicas. Mas o kicker é que eles realmente lhe pouparam tempo.
Podemos também recomendar.
Problemas impressionantes para fluxos de trabalho de ramificação Git.
Conheça as três equipes de erros de novato que compram ao adotar um fluxo de trabalho de ramificação de recursos e como corrigi-los usando problemas para rastrear o trabalho no software JIRA. Continue lendo.
Sobre o autor.
Dan Radigan.
Evangelista Agile Sênior, Atlassian.
A Agile teve um enorme impacto sobre mim tanto profissional como pessoalmente, como eu aprendi, as melhores experiências são ágeis, tanto no código como na vida. Muitas vezes, você me encontrará na interseção de tecnologia, fotografia e motociclismo. Encontre-me no Twitter! danradigan.
Comments
Post a Comment