Descreva seu stream de trabalho usando o version control (VCS ou DVCS)

Eu gostaria de aprender o stream de trabalho de outras pessoas ao usar vcs ou dvcs.

Por favor, descreva sua estratégia para lidar com as seguintes tarefas:

  • Implemente um recurso
  • Corrigindo bugs (durante o desenvolvimento e o aplicativo implantado)
  • Revisão de código
  • Código de refatoração (post code-review)
  • Incorporar patches
  • Ao liberar a versão mais recente do seu aplicativo (desktop, web, celular, você os trataria de maneira diferente?)

Sinta-se livre para organizar sua resposta não agrupada pelas tarefas, mas agrupada por qualquer coisa que você achar relevante, mas por favor organize-a por VCS / DVCS (por favor, não as misture).

Obrigado.

A principal característica que todos os VCs usam para as várias tarefas que você está mencionando é a ramificação : a capacidade de isolar um esforço de desenvolvimento de maneira colaborativa. Como é um VCS Central, vários desenvolvedores podem colaborar em um mesmo ramo, com bloqueios pessimistas ou otimistas em arquivos, a fim de desenvolver um histórico paralelo.

Mas ser um VCS tem dois grandes impactos na ramificação:

  1. Ele tende a desencorajar commits, porque uma vez que um arquivo é confirmado, ele imediatamente influenciará o espaço de trabalho de outras views com a mesma configuração (isto é, “trabalhando na mesma ramificação”).
    ~ O processo de “publicação” é ativo, com consequências imediatas,
    ~ enquanto a parte “consumidora” (atualizando seu espaço de trabalho) é passiva (você é forçado a lidar com as mudanças publicadas por outros imediatamente após a atualização do seu espaço de trabalho)
  2. Ele funciona bem para o stream de trabalho de mesclagem linear (ou seja, “mesclar apenas da ramificação A para a ramificação B, sem mesclar as mesclagens nas duas direções” – A para B para A para B …). As fusões são triviais, todas as modificações de A são simplesmente transferidas para B

Agora:

Implementando um recurso

Qualquer VCS fará isso criando uma ramificação, mas o que me surpreendeu muito é que uma ramificação de “recurso” não é fácil:
* o recurso pode ficar muito complicado
* pode estar pronto a tempo para o próximo lançamento
* apenas parte dela pode precisar ser mesclada no ramo principal de desenvolvimento
* pode depender de outros resources que ainda não foram totalmente concluídos

Portanto, você precisa ter cuidado na forma como gerencia seu ramo de resources, e seus commits: se eles estão intimamente relacionados ao mesmo recurso, ele irá bem (você mescla tudo de volta ao seu ramo de desenvolvimento principal quando você precisa dele) . Caso contrário, as mesclagens parciais não serão fáceis com essas ferramentas.

Corrigindo bugs

A diferença entre correção de bug durante o desenvolvimento e após o lançamento é que, no primeiro caso, você pode fazer isso linearmente no mesmo branch, como no último caso você terá que estabelecer um branch de correção de bug, e decidir quais bugs você irá precisa voltar a porta para o seu ramo de desenvolvimento atual.

Revisão de código

É melhor usado com ferramentas externas ( como o Crucible, por exemplo), e usa funções VCS como culpabilidade ou annotations extensivamente, a fim de melhor atribuir correções de código após uma revisão.

Código de refatoração (post code-review)

Se a refatoração for menor, ela poderá continuar no mesmo ramo. Mas se for grande, uma ramificação especial precisa ser configurada, com testes de unidade feitos antes de começar a refatoração.

Incorporar patches

O mesmo comentário do último ponto. Se o patch for grande, uma ramificação precisa ser criada.

Liberando a versão mais recente do seu aplicativo

Um VCS só vai levar você até o momento quando se trata de liberar seu aplicativo, porque não é uma ferramenta de gerenciamento de versões.
Você precisará identificar anteriormente uma versão a ser lançada (label), mas depois disso vem o processo de implantação que envolve:

  • parando o que está atualmente em execução
  • copiando os novos arquivos
  • implantando-os (atualizando database sql, webapp, …)
  • instanciando todos os arquivos de configuração (com os valores corretos, endereços, número da porta, caminhos, …)
  • reiniciando (e se o seu sistema é composto de vários componentes, reiniciando-os na ordem correta!)

As principais coisas com o VCS e o gerenciamento de versões são:

  • eles não são muito bem adaptados para armazenar binários para serem liberados, o que significa que você precisa deles para construir seu aplicativo, não para armazenar o executável resultante
  • eles nem sempre são bem-vindos no ambiente de produção (onde as restrições de segurança limitam o access de gravação, bem como o número de ferramentas em execução nessas plataformas, essencialmente ferramentas de monitoramento e relatório)

O mecanismo de liberação também tem uma influência nas dependencies binárias:

  • para dependencies binárias externas, você provavelmente usará mecanismos como maven para obter revisões fixas de bibliotecas externas
  • mas para dependencies internas, quando você não está desenvolvendo apenas um aplicativo, mas vários que dependem um do outro, você precisa saber como fazer referência aos binários produzidos pelos outros aplicativos (dependencies binárias internas), e eles geralmente não serão armazenados no seu VCS (especialmente na fase de desenvolvimento, onde você pode produzir muitos lançamentos diferentes para seus outros aplicativos poderem usar)

Você também pode optar por estar nas dependencies de origem (e obter todas as fonts dos outros projetos internos necessários para o seu próprio), e um VCS é bem adaptado para isso, mas nem sempre é possível / prático recompilar tudo.

A principal diferença com um DVCS (Controle de Versão Distribuída) de um VCS é que ele é feito (pela própria natureza de seu trabalho distribuído) para fazer uma coisa e uma coisa bem:

mesclar .

Então, as tarefas que você mencionou podem ser vistas desse ângulo.
As ramificações ainda serão feitas, mas nem todas serão visíveis por outros desenvolvedores. Muitos deles não deixam o seu repository local .

Ser um DVCS tem dois impactos principais na fusão:

  1. você se compromete quantas vezes quiser. Esses commits não são imediatamente visíveis para os outros (ou seja, “eles não terão que mesclá-los imediatamente após a próxima atualização de seu espaço de trabalho”)
    O processo de publicação é passivo: seus pushs podem ser ignorados por outros repositorys.
    A parte “consumidora” é ativa: você pode examinar o que foi enviado a você antes de mesclá-lo ao seu ramo e decidir o que deseja mesclar e de quem (e não apenas porque todos estão trabalhando em um mesmo ramo”).
  2. funciona bem para qualquer stream de trabalho de mesclagem (parcial, entrecruzada, recursiva, …) O DAG (Directed Acyclic Graph) frequentemente usado para gravar o histórico por esses DVCS (pelo menos Git e Mercurial) torna fácil encontrar o que tem já foi mesclado e encontrar o ancestral comum. Essa é uma diferença importante entre o SVN e seus colegas do DVCS , mas há outros também .

Agora:

Implemente um recurso

Conforme detalho na minha resposta CVCS (Central VCS) , a dificuldade por trás de uma ramificação “feature” é que muitos sub-resources acabarão interligados.
É aí que o DVCS irá brilhar, pois permitirá que você reorganize seu histórico local (como em “não for pressionado ainda”) (changesets para o Mercurial, SHA1 commits ofr Git), para facilitar as mesclagens parciais ou as criações de ramificações sub-características.

Corrigindo bugs

Você pode quase criar uma ramificação por correção de bugs se quiser. A idéia é garantir que uma correção de bug seja identificada por um simples conjunto linear de compromissos mesclados no ramo de desenvolvimento (ou no ramo de manutenção, caso isso seja liberado).
Eu prefiro certificar-me de primeiro rebase a ramificação bug-fix no topo da ramificação de desenvolvimento (para ter certeza de que minhas correções ainda estão em conformidade com qualquer trabalho que possa ter sido feito em paralelo no ramo principal) antes de mesclar essa ramificação com o bug-fix one (mesclagem fast-forward: a ramificação principal agora faz referência a todas as correções)

Revisão de código

O recurso de culpa ou anotação ainda está lá para ajudar a atribuir as tarefas durante uma revisão de código, mas desta vez, todos os desenvolvedores não estão necessariamente em um site (pois é um * Distributed * VCS) e não com o mesmo esquema de identificação ( não usando o mesmo LDAP por exemplo).

Uma maneira DVCS para organizar a revisão de código é empurrar novas alterações para um repo especial de revisão de código, que irá:

  • rejeitar os commits se eles não responderem aos critérios de qualidade exigidos
  • aceite-os (combine-os com o repository de revisão de código) e envie-os para um novo repository (usado para vários testes, por exemplo)

Código de refatoração (post code-review)

Eles são feitos no repository local do desenvolvedor, em uma ramificação (já que é tão fácil mesclá-lo de volta)

Incorporar patches

O mesmo processo que a última seção.

Ao liberar a versão mais recente do seu aplicativo (desktop, web, celular, você os trataria de maneira diferente?)

O processo de lançamento real é simplesmente iniciado por uma versão especial identificada (tag) do seu software. (o resto do “processo de gerenciamento de release”, que é a parte de implantação e configuração, é detalhado na resposta do CVCS )
A questão é, com um DVCS:
“de qual repository será essa versão oficial do seu software?”

Você precisa estabelecer um repository “central” ou “oficial” que desempenhará o papel de:

  • repo para versões a serem lançadas
  • repo para novos repositorys queria contribuir

Por isso, pode servir tanto para fins de lançamento, como também para novos propósitos de desenvolvimento.