• Abstract and Figures
• Public Full-text

UNIVERSITÉ DE MONTRÉAL MINING SOFTWARE REPOSITORIES FOR RELEASE ENGINEERS - EMPIRICAL STUDIES ON INTEGRATION AND INFRASTRUCTURE-AS-CODE YUJUAN JIANG DÉPARTEMENT DE GÉNIE INFORMATIQUE ET GÉNIE LOGICIEL ÉCOLE POLYTECHNIQUE DE MONTRÉAL THÈSE PRÉSENTÉE EN VUE DE L’OBTENTION DU DIPLÔME DE PHILOSOPHIÆ DOCTOR (GÉNIE INFORMATIQUE) AOÛT 2016 c Yujuan Jiang, 2016. UNIVERSITÉ DE MONTRÉAL ÉCOLE POLYTECHNIQUE DE MONTRÉAL Cette thèse intitulée: MINING SOFTWARE REPOSITORIES FOR RELEASE ENGINEERS - EMPIRICAL STUDIES ON INTEGRATION AND INFRASTRUCTURE-AS-CODE présentée par: JIANG Yujuan en vue de l’obtention du diplôme de: Philosophiæ Doctor a été dûment acceptée par le jury d’examen constitué de: M. GAGNON Michel, Ph. D., président M. ADAMS Bram, Doctorat, membre et directeur de recherche M. GUÉHÉNEUC Yann-Gaël, Doctorat, membre Mme BAYSAL Olga, Ph. D., membre externe iii DEDICATION To my grandpa Who has become a star in the heaven iv ACKNOWLEDGMENTS Many people I met, many things happened, are hidden as part of this thesis. First of all, I want to thank my parents, for their endless and unconditional love. You respect my every single choice and impractical dream. You always hold the faith in me, even when I myself had lost it. Exclusive thanks are dedicated to my supervisor, Dr.Bram Adams. Humble, enthusiastic and hard-working, for work and for life, you show me what should be like as a researcher and an individual person. You lead me through all the way up here, with enormous patience and kindness. In past four years, what I gained was not only professional skills, but also the will to face new challenges, the courage of learning from failures and the belief in hard working. Thank you Bram, I am so lucky to have you as my supervisor. Thanks are also due to my all co-authors for their amazing collaborations: Prof. Daniel German and Prof. Foutse Khomh. Without you guys this thesis would not have been possible. I would like to thank Dr.Michel Gagnon, Dr.Yann-Gaël Guéhéneuc, Dr.Olga Baysal for ac- cepting my invitation to be jury members, Dr.Dominique Orban to be representative of my defense. I really appreciate your help. Also, thanks are recorded to professors that gave me insightful advice in my academic life: Dr.Giuliano Antoniol, Dr.Peter Rigby, and Dr.Micheal Godfrey. In addition, I want to thank my three best friends in Canada: Jiaqi, Qin and Xiaoxi, for your company, encouragement and watermelon in summer. Last but not least, I wish to thank all colleagues and friends in our lab: Parastou, Latifa, Venera, Laleh, Soumaya, Aminata, Ons, Mahdis, Noopur, Le, Zephyrin, Wei, Francis, Ruben, Rodrigo... for all the inspiring talks, help and happiness. I will remember the days we spent together. v RÉSUMÉ Release engineering (Releng) est le processus de la mise en production logicielle des contribu- tions des développeurs en un produit intégré livré aux utilisateurs. Ce processus consiste des phases d’intégration, de construction et des tests, de déploiement et de livraison, pour finale- ment entrer au marché. Alors que, traditionnellement, la mise en production prend plusieurs mois pour livrer un produit logiciel complet aux clients, la mise en production moderne vise à apporter de la valeur au client plus rapidement, dans l’ordre des jours ou des semaines, pour recevoir de rétroaction utile plus rapidement et pour minimiser le temps perdu sur des fonctionnalités échouées. De nos jours, une panoplie d’outils et de techniques a émergé pour soutenir la mise en production. Ils visent essentiellement à automatiser les phases dans le pipeline de la mise en production, ce qui réduit le travail manuel et rend le processus reproductible et rapide. Par exemple, Puppet est l’un des outils les plus populaires pour Infrastructure-as-Code (IaC), ce qui automatise le processus de mettre en place une nouvelle infrastructure (par exemple, une machine virtuelle ou un conteneur dans lequel une application peut être compilée, testée et déployée) selon des spécifications textuelles. IaC a évolué rapidement en raison de la croissance de l’infonuagique. Cependant, de nombreux problèmes existent encore pour la mise en production. Par exemple, alors que de nombreux outils de la mise en production gagnent en popularité, le choix de la technique la plus appropriée exige des praticiens d’évaluer empiriquement la performance des techniques dans un contexte réaliste, avec des données représentatives. Pire encore, à un niveau plus haut, les ingénieurs de la mise en production doivent analyser le progrès de l’organisation dans chaque phase de la mise en production, afin de savoir si la prochaine date de sortie peut être respectée ou si des obstacles se produisent. De nouveau, il n’y a pas de méthode cohérente et établie pour ce faire. Pour aider les praticiens à mieux analyser leur processus de la mise en production, nous ex- plorons la façon selon laquelle la fouille de référentiels logiciels (Mining Software Repositories; MSR) est capable d’analyser le progrès d’une phase de la mise en production ou d’évaluer la performance d’un outil de mise en production. MSR agit sur les données stockées dans des référentiels de logiciels tels que les systèmes de gestion de versions, les référentiels de bogues ou des environnements de révision technique. Au lieu que les développeurs, les testeurs et les examinateurs utilisent ces référentiels juste pour enregistrer des données de développe- ment (telles que les changements de code, rapports de bogues ou des révisions techniques), vi MSR rend ces données actionnables en les analysant. Par exemple, en faisant l’extraction de l’information des changements de code source et de rapports de bogues, on peut recréer l’ensemble du processus de développement d’un projet ou de la mise en production. De nos jours, de nombreux référentiels logiciels à source libre sont disponibles au public, offrant des possibilités pour l’analyse empirique de la mise en production en utilisant des technologies MSR. Dans cette thèse, on a fait des analyses MSR pour deux phases critiques de la mise en production, c.-à-d. l’intégration et le provisionnement de l’environnement d’un logiciel (avec IaC), sur plusieurs projets larges à source libre. Cette série d’études empiriques ciblait de comprendre le progrès du processus de la mise en production et d’évaluer la performance des outils de point. Nous nous sommes concentrés principalement sur ces deux phases parce qu’elles sont essentielles dans la mise en production, et un grand nombre de données est disponible pour elles. D’abord, nous avons constaté que la révision technique et l’intégration de changements de code sont impactées par de différents facteurs. Nos résultats suggèrent que les développeurs réussissent à faire passer leurs contributions à travers la révision technique plus rapidement en changeant moins de sous-systèmes à la fois et de diviser une grande contribution en plusieurs contributions plus petites. En outre, les développeurs peuvent faire accepter leurs contribu- tions plus facilement et plus rapidement en participant davantage dans la communauté de développeurs à source libre et d’acquérir plus d’expérience dans des sous-systèmes similaires. Dans cette étude sur le noyau Linux, nous avons trouvé que l’un des défis majeurs de MSR dans le contexte de la mise en production logicielle est de relier les différents référentiels nécessaires. Par exemple, le noyau Linux ou le projet Apache HTTPD utilisent tous les deux des listes de diffusion pour effectuer le processus de révision technique. Les experts examinent des contributions par courriel, et un fil de courriels est utilisé pour ramasser toutes les différentes versions d’une contribution. Cependant, souvent un nouveau fil de discussion, avec sujet différent, est utilisé pour soumettre une nouvelle révision, ce qui signifie qu’aucun lien physique étroit n’existe entre toutes les révisions d’une contribution. En plus, les versions révisées d’une contribution non plus n’ont de lien physique avec la version acceptée dans le référentiel de gestion de versions, à moins qu’un identifiant de validation soit affiché dans un courriel. Surtout quand une contribution a été révisée plusieurs fois et a beaucoup évolué en comparaison avec la version initiale, le suivi à partir de sa toute première version est difficile à faire. Nous avons proposé trois approches de différente granularité et de rigueur différente, dans le but de récupérer les liens physiques entre les révisions de contributions dans le même fil vii de courriels. Dans notre étude, nous avons constaté que la technique au niveau des lignes individuelles fonctionne le mieux pour lier des contributions entre différents fils de courriels, tandis qu’une combinaison de cette approche avec celle à base de sommes de contrôle réalise la meilleure performance pour relier les contributions dans un fil de courriels avec la version finale dans le référentiel de gestion de versions. Être capable de reconstituer l’historique complet de contributions nous a permis d’analyser le progrès de la phase de révision du noyau Linux. Nous avons constaté que 25% des contributions acceptées prennent plus de quatre semaines pour leur révision technique. Deuxièmement, pour évaluer la capacité de MSR pour analyser la performance des outils de mise en production, nous avons évalué dans un projet commercial une approche d’intégration hybride qui combine les techniques de branchement et de “feature toggles”. Des branches per- mettent aux développeurs de travailler sur différentes fonctionnalités d’un système en par- allèle, en isolation (sans impacter d’autres équipes), tandis qu’un feature toggle permet aux développeurs de travailler dans une branche sur différentes tâches en cachant des fonctionnal- ités sous développement avec des conditions “if” dans le code source. Au lieu de réviser leur processus d’intégration entièrement pour abandonner les branches et de passer aux feature toggles, l’approche hybride est un compromis qui tente de minimiser les risques des branches tout en profitant des avantages des feature toggles.

Load more

  194

Copy Link