masterThesis
Build and test conflicts in the wild
Autor
SILVA, Léuson Mário Pedro da
Institución
Resumen
Collaborative software development allows developers to simultaneously contribute to the same project performing different activities. Although this might increase development productivity, it also brings conflicts among developers contributions. Conflicts may arise in different development phases: during merging, when different contributions are integrated (merge conflicts); after integration, when building the integration results fail (build conflicts); or when testing, unexpected software behavior happens (test conflicts). To understand how different contributions from merge scenarios influence build and test conflicts occurrence, in this thesis we investigate the frequency, causes and adopted resolution patterns for these conflicts. We perform an empirical study evaluating merge scenarios from Java projects that use Travis CI for continuous integration and Maven as build manager. To identify conflicts, we access information from git repositories of the projects and their associated build process. Filters were applied to select merge commits that present unsuccessful build processes (caused by problems during the build creation or test execution), while their parent commits have successful build process. Besides parsing build logs for identifying the causes behind the broken builds, we also parse the source code to establish interference between contributions. Different from previous studies, we also evaluate scenarios that caused merge conflicts fixed by integrators, leading us to classify our results based on contributor and integrator changes to fix the conflicts. Although the number of build conflicts caused by contributor changes is high (66,4%), we have evidence that build conflicts can also be caused by changes performed after the integration by integrators (33,6%). The most recurrent causes of build conflicts concentrate on static semantic problems (80%), especially Unavailable Symbol (52,8% of all build conflicts that represents the attempt to use a symbol no longer available in the project). Test conflicts are caused by failed test cases, that are not restricted to old tests but also new or updated during the merge scenario. Additional analysis performed after tests execution can also cause test conflicts. Related to the adopted resolution patterns, build and test conflicts were fixed without returning to an old project version. Typically, parent commits authors are also responsible for fixing build and test conflicts. Our findings bring the evidence of build and test conflicts showing they occur independent of merge conflict occurrence during integration. For build conflicts, we define a catalog of causes that can be applied to assistive tools on software development aiming to avoid or treat such problems. For test conflicts, our scripts can be used to develop an assistive tool to developers when trying to understand the test case failure since we filter the parent’s contributions informing only those parts involved in the test failure. CAPES Desenvolvimento colaborativo de software permite que desenvolvedores contribuam simultaneamente para um mesmo projeto realizando diferentes atividades. Embora esta abordagem possa aumentar a produtividade de desenvolvimento, ela também traz consigo conflitos entre contribuições de desenvolvedores. Conflitos podem surgir em diferentes momentos. Durante cenários de merge, quando contribuições diferentes são integradas (conflitos de merge), como também após a integração, durante a tentativa de realizar o processo de build, quando este processo falha devido o resultado da integração falha (conflitos de build), ou mudança no comportamento do software (conflitos de teste). Para entender como contribuições diferentes de cenários de merge influenciam em conflitos de build e teste, nesta dissertação nós investigamos a frequência, causas e padrões de resolução adotados para resolver estes conflitos. Para tanto, nós realizamos um estudo empírico avaliando cenários de merge de projetos Java usando Travis (para integração contínua) e Maven (como gerenciador de build). Para identificar conflitos, nós acessamos as informações de repositórios git como também seus processos de build associados. Sucessivos filtros foram aplicados para selecionar commits de merge que apresentavam processos de build malsucedidos (causadas por problemas durante a criação da build ou execução dos testes), enquanto seus commits pais apresentavam processos bem-sucedidos. Além de analisar os logs das builds para extrair as causas das quebras, nós também avaliamos o código-fonte para identificar as interferências entre contribuições. Diferente de estudos anteriores, nós também avaliamos a ocorrência de conflitos em cenários oriundos de conflitos de merge levando-nos a classificar nossos resultados baseados nas mudanças dos contribuidores e integradores. Embora o número de conflitos de build causados por mudanças dos contribuidores seja alto (66,4%), nós temos evidência que conflitos de build também podem ser causados por mudanças feitas após a integração por integradores (33,6%). As causas mais recorrentes de conflitos de build concentram-se em problemas estáticos semânticos, especialmente Símbolo Indisponível (52,8% de todos os conflitos de build representando a tentativa de usar um símbolo indisponível no projeto). Conflitos de teste são causados por casos de teste falhos, que não são restritos a casos de teste antigos como também novos ou atualizados durante o cenário de merge. Análises adicionais realizadas após a execução de testes também causar conflitos de teste. Em relação aos padrões de resolução de conflitos, a solução mais utilizada consiste em adaptar as causas dos conflitos ao novo estado do projeto, ao invés de retornar para um estado antigo. Tipicamente, desenvolvedores autores pelos commits pais, também são responsáveis por resolver os conflitos. Nossas descobertas trazem a evidência de conflitos de build e teste mostrando que estes ocorrem independentes de conflitos de merge durante a integração. Em relação aos conflitos de build, nós identificamos um catálogo de causas que pode ser aplicado em ferramentas de suporte ao desenvolvimento de software evitando ou tratando estes problemas. Para conflitos de teste, nossos scripts podem apoiar o trabalho de desenvolvedores durante a tentativa de entender a falha de um caso de teste, uma vez que nós filtramos as contribuições dos commits pais informando apenas aquelas envolvidas na falha do teste.