como permanecer eficiente quando uma construção quase sempre é interrompida

Eu trabalho em uma equipe de tamanho médio que compartilha o mesmo código-fonte e, embora tenha uma integração contínua, mas como todos nós temos que trabalhar no mesmo ramo, a construção quase sempre é interrompida.

Como também temos uma regra, que foi introduzida recentemente para aliviar as construções quebradas, que afirma que ninguém tem permissão para fazer check-in enquanto a construção é vermelha.

Dito isto, durante um dia todos têm algumas janelas de 10 a 15 minutos onde permitimos o check-in.

E à medida que a equipe cresce, as janelas das oportunidades de check-in diminuem ainda mais. Isso força os desenvolvedores a acumular suas alterações localmente, o que resulta em conjuntos de alterações maiores, ainda mais difíceis de garantir que as alterações não quebrem nada. Você pode ver o ciclo vicioso.

O que você pode recomendar para me manter eficaz trabalhando em um ambiente como este. Além disso, lembre-se de que sou desenvolvedor, não gerente, e não posso alterar muito o processo ou o comportamento de outras pessoas.

Para começar, este comentário:

... ter um ramo implica uma complexidade extra e, portanto, trabalho extra ...

é totalmente falso. Costumo ouvi-lo de pessoas que não estão acostumadas a ramificar, mas ainda está errado.

Se você tiver muitos desenvolvedores acumulando alterações localmente, suas alterações locais constituirão uma ramificação de fato do repositório principal.

Quando eles finalmente pressionam, essa é uma fusão de fato .

O fato de suas ramificações e mesclagens estarem implícitas não remove a complexidade extra com a qual você está preocupado, apenas a oculta. A verdade é que tornar esse processo explícito pode ajudá-lo (plural = toda a equipe) a aprender a administrá-lo.

Agora você diz

ninguém pode fazer check-in enquanto a construção é vermelha

mas, nesse caso, a compilação nunca pode ser corrigida, portanto, não pode ser bastante precisa.

Em geral, se for razoável construir localmente (ou seja, a construção não for muito grande ou lenta), os desenvolvedores devem fazer isso antes de pressionar de qualquer maneira.

Suponho que esse não seja o caso, porque, em primeiro lugar, eles não promoveriam construções quebradas, mas seria ótimo se você pudesse esclarecer esse ponto.

Em geral, a resposta para

como permanecer eficiente quando uma construção quase sempre é interrompida

é: pare de quebrar a compilação .

desenvolvedores ... acumulam suas alterações localmente ... Você pode ver o ciclo vicioso.

É realmente cruel. Acumular mudanças localmente é uma grande bandeira vermelha, indicando que algo está muito podre no processo de desenvolvimento. Isso meio que destrói todo o propósito de ter um sistema de controle de versão .

Contanto que você queira evitar mudar o processo ou o comportamento de outras pessoas, a solução mais natural seria configurar seu próprio ramo e usá-lo para "acumular" suas alterações (para integrar-se ainda mais ao ramo da equipe quando você receber uma chance).

Na verdade, se houver mais pessoas como você, você pode até colaborar e estabelecer um ramo de desenvolvimento compartilhado para trocar livremente suas atualizações sem interferir nas idéias de gerenciamento incompetentes. A ramificação permite muitas maneiras diferentes de simplificar o trabalho em equipe.

• ^{Nota lateral, toda vez que o gerente faz ou diz algo que o força a evitar comprometimentos, a manter o código localmente, traduza suas palavras em negrito e claro "Eu sou incompetente" .}

lembre-se de que sou desenvolvedor, não gerente, e não posso alterar muito o processo ou o comportamento de outras pessoas ...

Por uma questão de precisão, você realmente pode , são questões de influência e habilidades de comunicação e não é necessário estar em posição de poder para mudar as coisas ao seu gosto (pesquise na Web algo como "gerenciar" se você está interessado em mais detalhes).

No entanto, isso é bastante complicado e consome muito esforço, e eu posso entender perfeitamente se alguém simplesmente prefere manter o foco na codificação, com pouco envolvimento na política - então, se você não quiser (mesmo que em teoria possa ), isso é compreensível. :)

Sou sensível à noção de que você se sente impotente para mudar o ambiente, mas acho que essa situação é um sério desafio ao seu profissionalismo como programador.

O que aconteceria se um cirurgião armazenasse bisturis sujos com os limpos? O que aconteceria se um encanador não testasse os canos que instalou? O que aconteceria se um violinista tocasse sempre fora de sintonia com a orquestra?

Por que os programadores devem ser isentos do trabalho em equipe e da cortesia comum? Como membro dessa equipe, você compartilha a responsabilidade pelo resultado. É irresponsável ignorar a equipe, pois sabota seus próprios esforços.

Estou curioso para saber de onde vem a regra de que "ninguém pode fazer check-in enquanto a construção é vermelha" vem? É uma boa regra se isso concentrar todos na correção da compilação. Eu tentaria dar o exemplo e ajudar a corrigir a compilação sempre que ela quebrar. Vamos ser sinceros, você não está fazendo nada mais. Se isso te incomoda, então eu sugiro expressar essas preocupações. A voz de alguém ativamente tentando melhorar uma situação tem mais influência do que o cara que resmunga no canto.

Eu acho que enquanto você pensa que é "apenas um desenvolvedor" e, portanto, não pode mudar as coisas que sofrerá com esse problema.

O que você precisa fazer é reverter todos os commit do repositório toda vez que alguém interromper a compilação e depois dizer a esse cara que ele acabou de interromper a compilação e que precisa parar. Você também precisa explicar essa situação ao gerente e dizer a ele que a produtividade da sua equipe está sofrendo por causa desse problema.

Você precisa fazer o possível para alterar melhor o processo e pedir desculpas mais tarde, em vez de pedir permissão.

Eu acho que você e sua equipe estão em uma situação em que o processo precisa ser alterado e você não pode trabalhar eficientemente com esse modelo quebrado. Eu também acho que é sua responsabilidade fazer algo sobre esse problema quando você o reconhecer. Se ninguém mais fará nada a respeito do problema, você é quem deve!

Eu posso me relacionar com sua situação, eu enfrentei uma situação semelhante com o meu projeto mais recente no trabalho. Acabamos implementando uma espécie de sistema de "batata quente", em que o desenvolvedor que mais recentemente quebrou a compilação teve que tomar conta da babá / babá / monitorá-la até que ela fosse corrigida E passou em todos os nossos testes de verificação.

Isso foi bem-sucedido porque os testes de compilação e verificação demoravam ~ 4 horas rotineiramente; portanto, interromper a compilação significava que você perderia meio dia fazendo um trabalho real. Escusado será dizer que isso resultou em desenvolvedores usando ramos de forma mais eficiente antes de fundi-los no tronco. Para a maioria dos desenvolvedores, a mentalidade anterior era "Vou deixar o sistema de criação de IC notificar-me se meu código estiver quebrado".

Uma simples alteração no sistema de IC faria isso: qualquer alteração que interrompa a construção é revertida automaticamente. Melhor ainda, permita que o repositório de IC se torne uma área de preparação, onde as alterações só são enviadas ao repositório autoritativo quando a construção é verde. Ferramentas como a Gerrit podem ajudar aqui.

Duas outras coisas podem ajudar aqui:

• sua equipe de fumaça pode testar um IC construído localmente? Se você verificar se não quebra a compilação - ou pelo menos não a compila de maneiras comuns sem precisar confirmar e acionar a gerência e a ira da equipe.
• existem várias maneiras de definir construções quebradas, dependendo de como você arquitetar o IC. Isso inclui a definição de falha - em desenvolvimento pesado, não consideramos falhas nos testes uma pausa, mas sim outro objetivo a ser alcançado.

Mas você realmente deve olhar para os galhos.