Release processes form an important, if overlooked, part of the complete software development life cycle. Many organizations implement the roles of release engineering and release management in different ways, with a wide amount of variance within the software industry. Ill-designed processes can lead to a higher number of software faults and costly delays. Failures in release engineering can have negative implications, yet the causes of release process failures are not well understood within in the software engineering research community. This dissertation addresses the questions of what the common release process structure is, what the common failure modes are, and how organizations recover from and prevent these failures. We address these questions through a series of case studies with practicing release engineers at commercial software companies. The live interviews with these individual companies provide insight into the state of the practice in release engineering today across a broad spectrum of organization and software domains. The results of these studies indicate four areas of theory in release engineering which future researchers can probe in more depth. These areas center around process organization, social causes of release process failure, the relationship between software architecture and the release process, and how organizations attempt to improve release processes. For practicing release engineers, these results show that most organizations would benefit from three primary improvements: increased process automation, more modular software design, and improved organizational communication and support of release engineering groups. By implementing these improvements, software development companies and the release engineering processes they support will avoid the most common process failures in this critical phase of the software life cycle. / text

Submitted by Rodrigo Souza (rodrigorgs@gmail.com) on 2015-08-10T11:52:14Z No. of bitstreams: 1 rodrigo-thesis-final.pdf: 3966742 bytes, checksum: a3ca54b041cfdc2f5dad0f568b6d3a61 (MD5) / Made available in DSpace on 2015-08-10T11:52:14Z (GMT). No. of bitstreams: 1 rodrigo-thesis-final.pdf: 3966742 bytes, checksum: a3ca54b041cfdc2f5dad0f568b6d3a61 (MD5) / Introdução: A escrita de mudanças no código-fonte para corrigir defeitos ou implementar novas funcionalidades é uma tarefa importante no desenvolvimento de software, uma vez que contribui para evoluir um sistema de software. Nem todas as mudanças, no entanto, são aceitas na primeira tentativa. Mudanças inadequadas podem ser rejeitadas por causa de problemas encontrados durante a revisão de código, durante o teste automatizado, ou durante o teste manual, possivelmente resultando em retrabalho. Nosso objetivo é entender melhor a associação estatística entre diferentes tipos de rejeição --- revisões de código negativas, commits suplementares, reversão de commits e reabertura de tíquetes ---, caracterizar seus impactos em um projeto e entender como elas são afetadas por certas mudanças de processo. Para este fim, esta tese apresenta uma análise de três grandes projetos de software livre desenvolvidos pela Mozilla Foundation, os quais sofreram mudanças significativas no seu processo, como a adoção de lançamentos frequentes. Métodos: Para perseguir nosso objetivo, nos baseamos em tíquetes e commits de um período de mais de quatro anos do histórico dos projetos. Computamos métricas sobre a ocorrência de diversos tipos de rejeição de mudanças e medimos o tempo que leva tanto para submeter uma mudança quanto para rejeitar mudanças inapropriadas. Além disso, validamos nossos resultados com desenvolvedores da Mozilla. Resultados: Descobrimos que técnicas usadas em estudos anteriores para detectar mudanças inadequadas são imprecisas; por isso, propusemos uma técnica alternativa. Determinamos que mudanças inadequadas são um problema relevante e diário, que afeta cerca de 18% de todos os tíquetes em um projeto. Também descobrimos que, quando a Mozilla adotou lançamentos frequentes, embora a proporção de commits revertidos tenha aumentado, as reversões foram realizadas mais cedo no processo. / Background: Writing source code changes to fix bugs or implement new features is an important software development task, as it contributes to evolve a software system. Not all changes are accepted in the first attempt, though. Inappropriate changes can be rejected because of problems found during code review, automated testing, or manual testing, possibly resulting in rework. Our objective is to better understand the statistical association between different types of rejection---negative code reviews, supplementary commits, reverts, and issue reopening---to characterize their impacts within a project, and to understand how they are affected by certain process changes. To this end, this thesis presents an analysis of three large open source projects developed by the Mozilla Foundation, which underwent significant changes in their process, such as the adoption of rapid releases. Methods: To pursue our objective, we analyzed issues and source code commits from over four years of the projects' history. We computed metrics on the occurrence of multiple types of change rejection and measured the time it takes both to submit a change and to reject inappropriate changes. Furthermore, we validated our findings by discussing them with Mozilla developers. Results: We found that techniques used in previous studies to detect inappropriate changes are imprecise; because of that, we proposed an alternative technique. We determined that inappropriate changes are a relevant, daily problem, that affects about 18% of all issues in a project. We also discovered that, under rapid releases, although the proportion of reverted commits at Mozilla increased, the reverts were performed earlier in the process.