Quebra de build devido ao mau uso do Subversion
“Saber pilotar o Subversion além do commit e update é importante, mas só isso não basta. A falta de um processo adequado pode levar a resultados indesejáveis devido ao uso inadequado da ferramenta. Um exemplo disto é o mau uso do repositório como backup, que pode levar à situação conhecida como “quebrar a build”.”
Enviado por André Felipe Dias (andref·diasΘpronus·eng·br) – referência (pronus.eng.br).
• Publicado por Augusto Campos em
2008-06-17
@brlinuxblog
Feed RSS
Falou besteira das grandes. Ficar fazendo branch não é a solução para desenvolvedor tosco que comita código quebrado. Unit test neles …
Qualquer ferramenta se mal usada vai criar problemas.
“Imagine uma equipe com 10 desenvolvedores que usam a política de sempre fazer o commit das alterações feitas durante o dia antes de ir embora da empresa.”
Quam criou essa política tem que apanhar com um gato morto até ele miar. Só se dá commit quando vc tem algo completo e compilável, de preferência junto com a documentação correspondente sob o mesmo tag para eventuais consultas.
@el_foo
O que ele quis dizer é que pdoe comitar o código quebrado em um branch privado, mas que na hora do merge, o último commit tem que estar funcionando direito. Funciona, mas não acho uma boa idéia, pois estimula uma má pratica (commit de código quebrado) e dá trabalho extra, merges de projetos grandes são penosos
Para solução disto é feito um build local quando é concluído o a iteração do sistema, nós mesmos nem fazemos builds e mandamos por controle de versões, para o controle de versões só mandamos os documentos de desenvolvimento, o código fonte do sistema, as ferramentas utilizadas ou feitas por nós e imagens, mas o compilado sempre é local, só deixamos explicito a pasta Build pois quando for rodado o make ele irá procurar por esta pasta para colocar o programa compilado.
E atribuimos em nossa polita que haverá um lock de dados quando alguém for fazer alguma iteração de dados.
Falou tudo! Pensei isso antes mesmo de acabar de ler o texto.
Aqui no trabalho usamos branhces para implementar novas funcionalidades. Antes comitavamos sempre no trunk mas isso trazia uma perda de velocidade, pois se alguem tivesse terminado uma funcionalidade “nao poderia” colocar em produção pois as outras funcionalidade inacabadas tambem faziam parte desse codigo e estavam comitadas no trunk. É claro que antes de colocar em producao poderiamos “limpar” o codigo e retirar qualquer vinculo com as funcionalidades inacabadas, mas nao faziamos isso. ;-)
O que fazemos para minimizar os conflitos na hora do merge é o segunte: Cada desenvolvedor faz diariamente a “absorção” do codigo que está no trunk. Assim a “distância” entre o trunk e a branch nao tende a ficar grande e quando for a hora de fazer o contrario (jogar no trunk as modificacoes da branch) a tendência é que nao existam conflitos, pois como a branch é a implementacao de uma coisa nova, essa “coisa” é novidade no trunk. Mesmo que a branch altere um codigo existente no trunk, as absorções diárias evitam conflitos nesses códigos.
Estamos trabalhando assim há alguns meses e tem funcionado muito bem. A velocidade que gahamos é que sempre que uma funcionalidade acaba de ser implementada é feito o merge dessa branch com o trunk e o “novo” sistema já pode ir pra produção.