Implantación De Un Sistema De Integración Continua

Total Page:16

File Type:pdf, Size:1020Kb

Implantación De Un Sistema De Integración Continua Projecte fi de carrera – Integració Continua Implantació d’un Sistema de Integració Continua Memòria Daniel García Magané Enginyeria en Informàtica Miquel Colobran Huguet Curs 2017-18 (1er semestre) 1 Projecte fi de carrera – Integració Continua DEDICATORIA I AGRAÏMENTS En primer lloc, agrair a la meva dona Jenny per ser el suport que necessitava, animant- me cada dia, per a dur a terme aquest PFC. Li dono les gràcies per la seva paciència en tots aquests anys i caps de setmana de PACs tancats a casa sense poder sortir. Gràcies per intentar fer de mi una millor persona cada dia. Gràcies de tot cor. En segon lloc, a les meves dues filles bessones Abril i Sira, us demano perdó per haver estat desaparegut aquestes últims mesos, ho sento. Us dono les gràcies per fer-me sentir millor en els pitjors moments amb el vostre somriure i alegria infinits. Als meus pares per donar-me l’oportunitat d’estudiar i recolzar-me sempre que els he necessitat. Gràcies. I finalment al meu professor de PFC, en Miquel Colobran, per la seva gran ajuda sense la qual no hauria sigut possible realitzar aquest treball. Ha sigut un plaer treballar amb tu. Moltes gràcies. 2 Projecte fi de carrera – Integració Continua Descripció del Treball Avui en dia en les empreses dedicades al desenvolupament de software, un gran avantatge competitiu és la capacitat de lliurar els seus productes i serveis de forma ràpida, segura, lliure d’errors i respectant els ajustats temps de mercat (time to market). El desenvolupament de software amb metodologies Àgils es caracteritza pel lliurament constant de productes MVP (Minimum Value Product). La capacitat de poder oferir ràpidament als clients les noves funcionalitats desitjades i detectar l’abans possible qualsevol error és l’objectiu de qualsevol organització. Disposar d’eines per a gestionar les diferents versions del producte així com administrar els entorns de desenvolupament i producció de la forma més automatitzada possible, donarà sense dubte un gran avantatge i noves oportunitats de negoci a les empreses. En aquest PFC es vol presentar una proposta de treball completa per descriure el procés de transformació d’una empresa tipus. Es partirà des d’un entorn sense un correcte control de la gestió del desenvolupament de projectes informàtics cap a un entorn totalment automatitzat en termes de Integració Continua. Es tractaran aspectes relacionats amb la forma de treballar i de gestionar els projectes informàtics. S’analitzaran entre d’altres, temes importants com l’organització dels repositoris de codi font, les eines disponibles per a validar, compilar i publicar les aplicacions, les metodologies i els procediments de treball. També es consideraran els recursos de xarxa, de software i de maquinari necessaris per a integrar-se dins de l’organització. S’analitzaran les diferents estratègies i productes del sector i es descriurà una possible implementació. 3 Projecte fi de carrera – Integració Continua Índex Índex de figures ............................................................................................................................6 1 Introducció ...........................................................................................................................8 1.1 Justificació i Context del projecte .................................................................................8 1.2 Objectius del projecte ..................................................................................................8 1.3 Organització i Planificació del treball ............................................................................9 1.4 Enfoc i metodologia seguida.......................................................................................15 1.5 Requisits del projecte. ................................................................................................15 1.6 Productes obtinguts ...................................................................................................16 1.7 Breu descripció dels capítols de la memòria ..............................................................16 2 Introducció a la Integració Continua ..................................................................................17 2.1 Què és la Integració Continua ? ..................................................................................17 2.2 Breu antecedents històrics de la IC ............................................................................17 2.3 Principals components d’un sistema de IC .................................................................18 2.4 Principals fluxos i interaccions en un sistema d’IC ......................................................20 2.5 Característiques i pràctiques d’un sistema d’IC ..........................................................21 2.6 Altres pràctiques relacionades amb la IC ....................................................................27 3 Anàlisis de productes IC en el mercat .................................................................................30 3.1 Jenkins ........................................................................................................................30 3.2 Bamboo ......................................................................................................................35 3.3 Team City ....................................................................................................................42 3.4 CircleCI .......................................................................................................................47 3.5 GoCD ..........................................................................................................................52 3.6 Resum i comparativa de les eines...............................................................................56 3.7 Justificació del producte triat .....................................................................................58 4 Implementació d’un Sistema d’Integració Continua ..........................................................61 4.1 Descripció i anàlisis de l’entorn inicial ........................................................................61 4.2 Anàlisis d’entorns .......................................................................................................62 4.3 Anàlisis de l’estructura del codi font ..........................................................................65 4.4 Anàlisis de recursos necessaris ...................................................................................73 4.5 Instal·lació d’un repositori de Codi Font .....................................................................73 4.6 Instal·lació de l’eina d’Integració Continua.................................................................76 4.7 Metodologia desenvolupament .................................................................................85 4.8 Formació d’equips ......................................................................................................89 4.9 Monitoratge ...............................................................................................................90 4 Projecte fi de carrera – Integració Continua 5 Conclusions ........................................................................................................................92 6 Bibliografía .........................................................................................................................93 5 Projecte fi de carrera – Integració Continua Índex de figures Figura 1: Diagrama de Gantt resumit .....................................................................................10 Figura 2: Diagrama de Gantt complet ....................................................................................11 Figura 3: Components i interaccions bàsiques a un sistema de IC (font) .........................21 Figura 4: Relacions i dependències dins el flux de IC (font) ...............................................25 Figura 5: Exemple de flux de treball i notificacions ...............................................................26 Figura 6: Altres pràctiques relacionades (font) ......................................................................27 Figura 7: Integracio Continua Vs Lliurament Continu ...........................................................28 Figura 8: Continuos Delivery Vs Continuous Deployment ...................................................28 Figura 9: Exemple de configuració de tasques en Pipelines ...............................................31 Figura 10: Jenkins - Edició i visualització de pipelines ...........................................................32 Figura 11: Jenkins - Visualització d’una execució fallida de les pipelines ...........................32 Figura 12: Jenkins - Visualització de l’activitat històrica d’una pipeline ...............................32 Figura 13: Jenkins - Visualització del estat de les branques .................................................33 Figura 14: Exemple escenari plataforma Jenkins .................................................................34 Figura 15: Ecosistema de Jenkins i connexió a altres plataformes (font) ..........................35 Figura 16: Model arquitectura bàsica Bamboo ......................................................................36 Figura 17: Exemple de configuració de jobs en Bamboo (font) ..........................................37 Figura 18: Relació entre stage, task i job a Bamboo ............................................................38 Figura 19: Panell
Recommended publications
  • APPLICATION of the DELTA DEBUGGING ALGORITHM to FINE-GRAINED AUTOMATED LOCALIZATION of REGRESSION FAULTS in JAVA PROGRAMS Master’S Thesis
    TALLINN UNIVERSITY OF TECHNOLOGY Faculty of Information Technology Marina Nekrassova 153070IAPM APPLICATION OF THE DELTA DEBUGGING ALGORITHM TO FINE-GRAINED AUTOMATED LOCALIZATION OF REGRESSION FAULTS IN JAVA PROGRAMS Master’s thesis Supervisor: Juhan Ernits PhD Tallinn 2018 TALLINNA TEHNIKAÜLIKOOL Infotehnoloogia teaduskond Marina Nekrassova 153070IAPM AUTOMATISEETITUD SILUMISE RAKENDAMINE VIGADE LOKALISEERIMISEKS JAVA RAKENDUSTES Magistritöö Juhendaja: Juhan Ernits PhD Tallinn 2018 Author’s declaration of originality I hereby certify that I am the sole author of this thesis. All the used materials, references to the literature and the work of others have been referred to. This thesis has not been presented for examination anywhere else. Author: Marina Nekrassova 08.01.2018 3 Abstract In software development, occasionally, in the course of software evolution, the functionality that previously worked as expected stops working. Such situation is typically denoted by the term regression. To detect regression faults as promptly as possible, many agile development teams rely nowadays on automated test suites and the practice of continuous integration (CI). Shortly after the faulty change is committed to the shared mainline, the CI build fails indicating the fact of code degradation. Once the regression fault is discovered, it needs to be localized and fixed in a timely manner. Fault localization remains mostly a manual process, but there have been attempts to automate it. One well-known technique for this purpose is delta debugging algorithm. It accepts as input a set of all changes between two program versions and a regression test that captures the fault, and outputs a minimized set containing only those changes that directly contribute to the fault (in other words, are failure-inducing).
    [Show full text]
  • Embedded Software Knowledge Management System (ESWKMS) Release 0.0
    Embedded Software Knowledge Management System (ESWKMS) Release 0.0 ESWKMS community September 24, 2015 Contents 1 Human Relation Patterns 3 1.1 Categorization of human relation patterns................................3 2 Build Patterns 5 2.1 Categorization of build patterns.....................................5 2.2 All build patterns in alphabetic order..................................6 3 Release Antipatterns 9 4 Requirement Patterns 11 4.1 Standardized Textual Specification Pattern............................... 11 4.2 Perform Manual Review Pattern..................................... 11 5 Design Patterns 13 5.1 Categorization of “design” patterns................................... 13 5.2 Pattern Selection Procedure....................................... 19 5.3 Legend to the design pattern sections.................................. 19 5.4 All design patterns in alphabetic order.................................. 19 6 Idioms in C 27 6.1 Classification of idioms......................................... 27 6.2 Add the name space........................................... 27 6.3 Constants to the left........................................... 27 6.4 Magic numbers as variables....................................... 28 6.5 Namend parameters........................................... 28 6.6 Sizeof to variables............................................ 28 7 Bibliography 29 8 “It is all about structure and vision.” 31 9 Indices and tables 33 i ii Embedded Software Knowledge Management System (ESWKMS), Release 0.0 Contents: Contents 1 Embedded
    [Show full text]
  • Software Configuration Management
    Front cover Software Configuration Management A Clear Case for IBM Rational ClearCase and ClearQuest UCM Implementing ClearCase Implementing ClearQuest for UCM ClearCase and ClearQuest MultiSite Ueli Wahli Jennie Brown Matti Teinonen Leif Trulsson ibm.com/redbooks International Technical Support Organization Software Configuration Management A Clear Case for IBM Rational ClearCase and ClearQuest UCM December 2004 SG24-6399-00 Note: Before using this information and the product it supports, read the information in “Notices” on page xvii. First Edition (December 2004) This edition applies to IBM Rational ClearCase and MultiSite Version 2003.06.00 and IBM Rational ClearQuest and MultiSite Version 2003.06.00. Some information about Version 06.13 is included. © Copyright International Business Machines Corporation 2004. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Notices . xvii Trademarks . xviii Preface . xix The team that wrote this redbook. xxi Become a published author . xxiii Comments welcome. xxiii Part 1. Introduction to SCM . 1 Chapter 1. The quest for software lifecycle management . 3 Stories from the wild. 4 Software asset management . 5 Better software configuration management means better business . 6 Seven keys to improving business value . 7 Safety . 7 Stability . 8 Control. 8 Auditability. 9 Reproducibility. 10 Traceability . 11 Scalability . 12 Good SCM is good business . 13 Chapter 2. Choosing the right SCM strategy . 15 The questions. 16 A version control strategy. 17 Delta versioning . 17 A configuration control strategy . 19 A process management strategy . 21 A problem tracking strategy . 23 Chapter 3. Why ClearCase and ClearQuest .
    [Show full text]
  • Soc Concurrent Development Page 1 of 7
    SoC drawer: SoC concurrent development Page 1 of 7 SoC drawer: SoC concurrent development Establish a disciplined process for hardware and software co -design, integration, and test Sam Siewert ( [email protected] ), Adjunct Professor, University of Colorado Summary: A system-on-a-chip (SoC) can be more complex in terms of hardware-software interfacing than many earlier embedded systems because an SoC often includes multiple processor cores and numerous I/ O interfaces. The process of integrating and testing the firmware-hardware interface can begin early, but without good management and testing, the mutability of firmware and early stages of hardware design simulation can lead to disastrous setbacks for a project. This article teaches system designers about tools and methods to minimize project churn. View more content in this series Date: 20 Dec 2005 Level: Intermediate Activity: 687 views Comments: 0 ( Add comments ) Average rating (based on 17 votes) This article is the third in the SoC drawer series . The series aims to provide the system architect with a starting point and some tips to make system-on-a-chip (SoC) design easier. SoCs are either configurable or reconfigurable. Configurable SoCs are constructed from core logic that can be reused and modified for an application-specific integrated circuit (ASIC) implementation; reconfigurable SoCs use soft cores and field-programmable gate array (FPGA) fabrics that can be reprogrammed by simply downloading new in-circuit FPGA programming. The mutability of SoCs in terms of firmware and FPGA fabric is attractive because it allows for modification and addition of features. Likewise, for configurable SoCs, the mutability during early co-design and co-simulation allows for quick design changes in both hardware and firmware, making for a very agile project.
    [Show full text]
  • An Application of Configuration Management on Graphical Models
    MBVC – Model Based Version Control: An Application of Configuration Management on Graphical Models MEHIAR MOUKBEL Master of Science Thesis Stockholm, Sweden 2007 i MBVC – Model Based Version Control: An Application of Configuration Management on Graphical Models By: Mehiar Moukbel A A B Merge Engine B Master of Science Thesis MMK 2007:38 MDA261 KTH Machine Design SE-10044STOCKHOLM ii Master of Science Thesis MMK 2007:38 MDA261 MBVC – Model Based Version Control: An Application of Configuration Management on Graphical Models Mehiar Moukbel Approved Examiner Supervisor 2007-03-20 Martin Törngren Jianlin Shi Jad El-Khoury Commissioner Contact person KTH, Machine Design Abstract File-based version control consists of tools in the software engineering industry, with many available commercial products that allow multiple developers to work simultaneously on a single project. However these tools are most commonly used on plain textual documents such as source code. There exist few tools today for versioning fine-grained data such as graphical Simulink models. Since Simulink is widely used as a modeling tool in numerous engineering fields, nonetheless in the mechatronics field, it will be interesting to study the possibility of developing a tool for version control of graphical models. Two textual software configuration management (SCM) products, CVS and Rational Clear Case, were studied and their functionalities were analyzed, along with a different number of research topics on document versioning. The existing algorithms of ‘diff’ and ‘merge’ functions were also studied to give an understanding of how these functions work for text based documents. The knowledge gained from the tools, existing algorithms and literature on the subject were used to write MATLAB programs that perform diff and merge on Simulink models.
    [Show full text]
  • Abschlussarbeit
    Abschlussarbeit André Behrens Testen von Legacy Code in Open Source Projekten Fakultät Technik und Informatik Faculty of Engineering and Computer Science Department Informatik Department of Computer Science André Behrens Testen von Legacy Code in Open Source Projekten Bachelorarbeit eingereicht im Rahmen der Bachelorprüfung im Studiengang Angewandte Informatik am Department Informatik der Fakultät Technik und Informatik der Hochschule für Angewandte Wissenschaften Hamburg Betreuende Prüferin: Frau Prof. Dr. Bettina Buth Zweitgutachterin: Frau Prof. Dr. Ulrike Steffens Abgegeben am 19.02.2016 André Behrens Thema der Arbeit Testen von Legacy Code in Open Source Projekten Stichworte Softwaretest, Legacy Code, Open Source Projekte, ews-java-api, Microsoft Exchange Server, Java Kurzzusammenfassung Thema dieser Arbeit ist es Teststrategien im Zusammenhang von Open Source Projekten und Legacy Code aufzuzeigen. Hier werden zunächst Grundlagen des Softwaretests mit Teststrategien in großen Unternehmen verglichen und deren Anwendbarkeit anhand von Analysen und Beispielen auf ein Projekt angewandt, welches große Bestandteile von Legacy Code aufweist. André Behrens Title of the paper Testing Legacy Code in Open Source Projects Keywords Softwaretest, Legacy Code, Open Source Projects, ews-java-api, Microsoft Exchange Server, Java Abstract This thesis is about test strategies in big firms as well as them to be used in open source projects and will give some introduction on software testing basics in comparison with their applicability with strategies
    [Show full text]
  • ESWP3 - Embedded Software Principles, Procedures and Patterns Release 1.0
    ESWP3 - Embedded Software Principles, Procedures and Patterns Release 1.0 ESWP3 contributors October 04, 2015 Contents 1 Principles 3 1.1 Categorization of principles.......................................3 1.2 All principles in alphabetic order....................................3 2 Procedures 5 2.1 Categorization of procedures.......................................5 2.2 All procedures in alphabetic order....................................5 3 Patterns 7 3.1 Human Relation Patterns.........................................7 3.2 Build Patterns.............................................. 10 3.3 Requirement Patterns........................................... 13 3.4 Design Patterns.............................................. 16 3.5 Unit Test Patterns............................................. 32 3.6 Tool evaluation patterns......................................... 39 3.7 About the meta-data........................................... 41 4 Bibliography 43 5 “It is all about structure and vision.” 45 6 Indices and tables 47 i ii ESWP3 - Embedded Software Principles, Procedures and Patterns, Release 1.0 This project is about summarizing, referencing, structuring and relating principles, procedures (as sequences of pat- terns in a pattern language) and patterns in the context of embedded software engineering. As “(P)atterns are only meaningful as part of a Pattern Language(.)” (Bergin 2013, pos. 74) this project tries also to “make” relations between different pattern languages and the higher-level principles “visible”. Contents: Contents
    [Show full text]
  • Altova Umodel 2019 User & Reference Manual
    User and Reference Manual Altova UModel 2019 User & Reference Manual All rights reserved. No parts of this work may be reproduced in any form or by any means - graphic, electronic, or mechanical, including photocopying, recording, taping, or information storage and retrieval systems - without the written permission of the publisher. Products that are referred to in this document may be either trademarks and/or registered trademarks of the respective owners. The publisher and the author make no claim to these trademarks. While every precaution has been taken in the preparation of this document, the publisher and the author assume no responsibility for errors or omissions, or for damages resulting from the use of information contained in this document or from the use of programs and source code that may accompany it. In no event shall the publisher and the author be liable for any loss of profit or any other commercial damage caused or alleged to have been caused directly or indirectly by this document. Published: 2019 © 2019 Altova GmbH Table of Contents 1 UModel 3 2 Introducing UModel 6 2.1 Support Notes................................................................................................................. 7 3 UModel Tutorial 10 3.1 Getting Started................................................................................................................. 11 3.2 Use Cases................................................................................................................. 14 3.3 Class Diagrams................................................................................................................
    [Show full text]
  • Altova Umodel 2021 Basic Edition
    Altova UModel 2021 Basic Edition User & Reference Manual Altova UModel 2021 Basic Edition User & Reference Manual All rights reserved. No parts of this work may be reproduced in any form or by any means - graphic, electronic, or mechanical, including photocopying, recording, taping, or information storage and retrieval systems - without the written permission of the publisher. Products that are referred to in this document may be either trademarks and/or registered trademarks of the respective owners. The publisher and the author make no claim to these trademarks. While every precaution has been taken in the preparation of this document, the publisher and the author assume no responsibility for errors or omissions, or for damages resulting from the use of information contained in this document or from the use of programs and source code that may accompany it. In no event shall the publisher and the author be liable for any loss of profit or any other commercial damage caused or alleged to have been caused directly or indirectly by this document. Published: 2021 © 2015-2021 Altova GmbH Table of Contents 1 Introduction 10 1.1 Support.......................................................................................................................................................... Notes 11 2 UModel Tutorial 14 2.1 Getting.......................................................................................................................................................... Started 15 2.2 Use Cases.........................................................................................................................................................
    [Show full text]
  • Rational Business Driven Development for Compliance
    Front cover Rational Business Driven Development for Compliance Say what you do, do what you say, and be able to prove it Manage compliance using Rational tools and processes Leverage compliance for business advantage Ueli Wahli Majid Irani Matthew Magee Ana Negrello Celio Palma Jason Smith ibm.com/redbooks International Technical Support Organization Rational Business Driven Development for Compliance November 2006 SG24-7244-00 Note: Before using this information and the product it supports, read the information in “Notices” on page ix. First Edition (November 2006) This edition applies to IBM Rational software tools, such as RequisitePro, ClearCase, ClearQuest, ClearQuest Test Manager, Portfolio Manager, BuildForge, Functional Tester, Manual Tester, Performance Tester, Method Composer, Unified Process, ProjectConsole, and SoDA. © Copyright International Business Machines Corporation 2006. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Notices . ix Trademarks . x Preface . xi The team that wrote this IBM Redbook . xii Thanks . xiii Become a published author . xiv Comments welcome. xiv Chapter 1. A discussion about compliance . 1 Overview of today’s regulated environment . 2 What it means to be compliant . 3 Policy creation and management . 4 Regulations . 5 Sarbanes-Oxley . 6 USA Patriot Act . 7 Basel II . 7 Title 21 CFR 11 . 8 HIPAA . 8 Gramm-Leach-Bliley . 9 Sustainable compliance management . 9 How auditors inspect . 10 Compliance: an opportunity to improve the business. 13 Regulations versus standards . 14 Software development oriented standards. 16 COSO . 16 COBIT . 16 ITIL . 17 SPICE . 17 ISO 900x . 18 Six Sigma .
    [Show full text]
  • A Survey of Version Control Systems
    A Survey of Version Control Systems Ali Koc, M.A. Abdullah Uz Tansel, PhD Graduate Center – City University of New York Baruch College – City University of New York New York, USA New York, USA Abstract —Version control has been an essential aspect of any see who works how much, give credit or blame mistakes − software development project since early 1980s. In the recent blame is actually a command in some version control years, however, we see version control as a common feature systems (2). embedded in many collaborative based software packages; such as word processors, spreadsheets and wikis. In this paper, we This paper is organized such that in section 2 we explain the common structure of version control systems, explain the structure of version control systems and provide historical information on their development, and provide an abstract depiction of their basic functionalities. identify future improvements. Section 3 traces the history of version control systems and briefly describes commonly used software systems. We Keywords- version control; revision control; collaboration. discuss possible functions that can be added to version control systems in Section 4, and Section 5 concludes the I. INTRODUCTION paper. Change is a vital aspect of data. Most data encounters multiple modifications over the course of its life. For II. STRUCTURE OF VERSION CONTROL SYSTEMS certain forms of complex data, version control (aka The data, its versions, and all the information revision control) systems are commonly used to track associated with each version are stored in a location called changes; such as software source code, documents, repository . There are four repository models commonly graphics, media, VLSI layouts, and others.
    [Show full text]
  • Git Commit -M "Commit Message„ – Új Commit • Git Push – Commitok Feltöltése Remote-Ra LEGFONTOSABB GIT PARANCSOK
    VÁLLALATI INFORMÁCIÓS RENDSZEREK előadás „A tananyag az EFOP-3.5.1-16-2017-00004 pályázat támogatásával készült.” © 2018-2019, Dr. Hegedűs Péter VERZIÓKÖVETÉS FOGALMA ÉS ESZKÖZEI Vállalati Információs Rendszerek © 2018-2019, Dr. Hegedűs Péter VERZIÓKÖVETÉS CÉLJA • Forráskód és egyéb szöveges (vagy bináris) állományok (asset) változásainak nyomon követése – Minden változtatás egyedi azonosítóval ellátott (revision) – Változás meta-információi • Ki, mikor, mit módosított – Megváltozott sorok (diff) • A változások visszakereshetők, visszaállíthatók • Különböző változások összefésülhetők (merge) • Csapatok által fejlesztett közös kódbázis esetén elengedhetetlen VERZIÓKÖVETÉS MEGVALÓSÍTÁSA • Speciális szoftverek (VCS – Version Control System) – Számos különböző koncepció a fenti célok megvalósítására • Változások tárolása – Fájlok/adatok kezdeti változatának tárolása, módosítások nyomon követése • Intuitív, de átnevezés, törlés, összefésülés problémás – Minden változás az egész adathalmaz egy újabb állapota • Apró/egyszerű módosítások esetén kevésbé intuitív • Nagy/komplex változtatások esetén viszont egyszerűsít VÁLTOZÁSOK SZERKEZETE • Az egyes verziók (revision) irányított gráfként reprezentálhatók – Directed Acyclic Graph (DAG) • Gráf pontjai az egyes revíziók • Élek a rákövetkező revízió kapcsolat – Több párhuzamos fejlesztési ág • Tipikusan van egy fő ág – Az összefűzés (merge) műveletek miatt nem fa – A változások szekvenciálisan követik egymást időben • Sorba rendezhető revizió szám vagy időbélyegző alapján – HEAD jelöli a legutolsó
    [Show full text]