$30 off During Our Annual Pro Sale. View Details »

Git y Jenkins. El futuro en la gestión del ciclo de vida de aplicaciones

Paradigma
May 17, 2012
3k

Git y Jenkins. El futuro en la gestión del ciclo de vida de aplicaciones

Git es un sistema de control de versiones distribuido. Jenkins es un sistema de integración contínua.

Esta presentación es el material de un seminario de impartido por Juan José Fidalgo de @paradigmate el 17 de mayo del 2012 en Escuela Politécnica Superior de la Universidad CEU San Pablo en Madrid.

La aplicación práctica de la presentación se sigue mejor con un cliente por línea de comandos, por ejemplo con el plugin eGit en el entorno de desarrollo Eclipse.

Más información en http://www.paradigmatecnologico.com/git-y-jenkins-el-futuro-en-la-gestion-del-ciclo-de-vida-de-aplicaciones/ y http://www.javahispano.org/portada/2012/4/25/seminario-gratuito-sobre-git-y-jenkins.html

Paradigma

May 17, 2012
Tweet

Transcript

  1. Spring Roo & Spring Insight @federicojcdm 14 de Octubre de

    2010
  2. 2  Fue diseñado por Linus Torvalds  Git es

    un sistema de control de versiones distribuido. En oposición a un sistema de control de versiones centralizado, Git, da a cada programador una copia local del historial del desarrollo entero, y los cambios se propagan entre los repositorios locales.  Git da un fuerte soporte al desarrollo no lineal, y, proporciona mecanismos simples y eficaces para la gestión y mezclado de ramas.  Git permite trabajar con una menor dependencia del repositorio central, en comparación con sistemas de control de versiones como CVS o SVN. ¿Qué es Git?
  3. 3  En un sistema de control de versiones centralizado,

    como pueden ser CVS o SVN, el historial de versiones está alojado en el repositorio central. A partir de una copia local del repositorio no es posible reconstruir el repositorio de nuevo.  En uno distribuido, como Git, cada copia local del repositorio, contiene el historial completo de versiones. Es posible montar un nuevo repositorio, sin pérdida alguna de información, a partir de cualquiera de las copias locales.  En un sistema de control de versiones centralizado, la mayoría de las operaciones, incluida la gestión de versiones, requieren de conexión al repositorio central.  En uno distribuido, un gran número de operaciones, incluido el control de versiones de los elementos, se puede realizar sin conexión con el repositorio central. Distribuido vs Centralizado I
  4. 4  En un sistema de control de versiones centralizado,

    se facilitan las tareas administrativas a cambio de reducir flexibilidad, pues todas las decisiones fuertes (como crear una nueva rama) necesitan la aprobación del responsable.  En uno distribuido no es necesario tomar decisiones centralizadamente.  En sistemas de control de versiones centralizados como CVS o SVN, la creación, mergeado o gestión de ramas es algo muy dependiente del repositorio central, y, que es tratado como algo no habitual.  En Git, la creación, mergeado o gestión de ramas, es algo que puede hacerse en caso de ser necesario sin ningún tipo de dependencia del repositorio central, y, es tratado como algo natural y habitual. Distribuido vs Centralizado II
  5. 5  Existen versiones del cliente Git para Windows, Mac

    OSX, y Linux  El cliente puede ser descargado desde desde http://git-scm.com/  Desde http://git-scm.com/ puede descargarse un .exe para Windows  Desde http://git-scm.com/ puede descargarse un .dmg para Mac OSX  Desde http://git-scm.com/ pueden descargarse los fuentes para Linux  En las distintas distribuciones de Linux, suele existir un paquete precompilado del cliente de Git, así, por ejemplo, para instalar la versión precompilada del cliente Git en algunas distribuciones Linux, – En Ubuntu En Ubuntu: apt-get install git-core – En Fedora En Fedora: yum install git-core Instalación de un cliente de Git
  6. 6  Creando un nuevo repositorio local de Git 

    Añadiendo elemento al índice de Git Manejo Básico Cliente Git I
  7. 7  Comando status  Realizando commit Manejo Básico Cliente

    Git II
  8. 8  Consultando el historial de commit  Consultando cambios

    realizados Manejo Básico Cliente Git III
  9. 9  Volviendo a una versión anterior temporalmente Manejo Básico

    Cliente Git IV
  10. 10  Regresando de una versión anterior Manejo Básico Cliente

    Git V
  11. 11  Volviendo a una versión anterior definitivamente Manejo Básico

    Cliente Git VI
  12. 12  Gitosis es una herramienta que nos ofrece la

    posibilidad de controlar el acceso a los repositorios Git.  Gitosis gestiona múltiples repositorios con una sola cuenta de usuario en el servidor, utilizando claves SSH para identificar a los usuarios.  Con Gitosis, para los usuarios de los repositorios Git, no será necesario que tengan una cuenta de usuario en el servidor, sino que se gestionará el control de acceso de forma completamente transparente a ellos.  Es de fácil instalación y configuración.  Puede verse un ejemplo de instalación y configuración de Gitosis en la siguiente url, http://ymbra.com/es/blog/ramon/gestion-de-repositorios-git-con- gitosis Git en el servidor: Gitosis
  13. 13  GitHub (https://github.com/) es una alternativa de un tercero

    que permite gestionar proyectos Git.  GitHub es gratuito para proyectos open source, y en esta modalidad, únicamente permite operar con repositorios públicos.  GitHub permite operar con repositorios privados, pero, a través de cuentas de pago.  GitHub es una alternativa interesante para aquellas empresas que quieran utilizar repositorios Git, sin tener que preocuparse de habilitar un servidor Git, administrarlo, gestionar backups, seguridad, …... Git en el servidor: GitHub
  14. 14  Ir a https://github.com/  Ir a la opción

    “Signup and Pricing”  Ir a la opción “Create a free account”  Rellenar datos  Acceder Git en el servidor: Configuración GitHub
  15. 15  Para la creación de un par de claves(clave

    pública/clave privada) SSH se seguirá el siguiente procedimiento, Git en el servidor: Generación SSH keys
  16. 16  Localizar en el sistema local la clave pública

    generada (id_rsa.pub)  Acceder a la cuenta de GitHub  Ir a opción “Account Settings”  Seleccionar opción “SSH Keys”  Añadir la clave pública (id_rsa.pub) mediante la opción “Add SSH Key” Git en el servidor: Acceso SSH GitHub
  17. 17  Acceder a la cuenta de GitHub  Seleccionar

    opción “New Repository”  Completar datos del nuevo repositorio, y crear repositorio Git en el servidor: Creación de Repositorios
  18. 18  Copiar ruta del repositorio remoto que se obtuvo

    al crear el repositorio en GitHub.  En el sistema local, sobre el repositorio Git, añadir la ruta del repositorio remoto de GitHub  Subir cambios locales a repositorio remoto (push) Git en el servidor: Subir Repositorio a GitHub
  19. 19  Para realizar una actualización del repositorio local contra

    el repositorio remoto, no debe de haber cambios por commitear. Puede comprobarse si existen cambios por commitear, mediante la ejecución de “git status”.  En caso de existir cambios por commitear, antes de realizar la actualización contra el repositorio remoto pueden tomarse dos acciones posibles – Commitear los cambios pendientes – Realizar “git stash”, que guardará los cambios desde el último commit en una pila para tal efecto, y, situará el estado del repositorio local en el del último commit que fue realizado. Con posterioridad a realizar la actualización desde el repositorio remoto, podrá ejecutarse “git pop”, para realizar un merge entre lo que fue almacenado en la pila, y, lo que ha sido actualizado desde el repositorio remoto.  Para realizar la actualización desde el repositorio remoto, que realizará un merge entre la versión del repositorio local, y, la versión del repositorio remoto. En caso de existir conflictos en el merge, Git tratará de resolverlos automáticamente, si no puede resolverlos automáticamente informará de ello, para que sean resueltos manualmente. Git en el servidor: Actualizar desde Repositorio
  20. 20  Acceder a la cuenta de GitHub  Obtener

    la url SSH del repositorio remoto a clonar  Realizar clonado del repositorio remoto en sistema local Git en el servidor: Clonado de Repositorios
  21. 21  Accediendo al repositorio GitHub por https Git en

    el servidor: Otros protocolos en GitHub I
  22. 22  Accediendo al repositorio GitHub read-only Git en el

    servidor: Otros protocolos en GitHub II
  23. 23  Un proyecto puede ser branched o bifurcado en

    un instante de tiempo de forma que, desde ese momento en adelante, dos copias de los ficheros de ese proyecto puedan ser desarrolladas a diferentes velocidades o de diferentes formas, de modo independiente. El proyecto tiene entonces 2 (o más) "ramas".  La ventaja es que se puede hacer un "merge" de las modificaciones de ambas ramas, posibilitando la creación de "ramas de prueba" que contengan código para evaluación, si se decide que las modificaciones realizadas en la "rama de prueba" sean preservadas, se hace un "merge" con la rama principal, o entre dos ramas cualquiera.  Cualquier repositorio de Git, al ser inicializado, crea automáticamente una rama por defecto, que recibe el nombre de rama master, y que suele ser usada como rama principal. Gestión de Branch con Git I
  24. 24  Listando los branches existentes,  Creando un nuevo

    branch en el repositorio local,  Cambiando al nuevo branch en el repositorio local, Gestión de Branch con Git II
  25. 25  Creando un nuevo branch en repositorio local, y,

    quedar situado en el nuevo branch Gestión de Branch con Git III
  26. 26  Realizando merge entre dos branch, Gestión de Branch

    con Git IV
  27. 27  Subiendo branch del repositorio local al servidor, Gestión

    de Branch con Git V
  28. 28  Borrando branches locales, Gestión de Branch con Git

    VI
  29. 29  Trayendo branches desde el servidor al repositorio local,

    Gestión de Branch con Git VII
  30. 30  Borrando branches en el servidor, Gestión de Branch

    con Git VIII
  31. 31 egit: Creando un Repositorio Local I

  32. 32 egit: Creando un Repositorio Local II

  33. 33 egit: Creando un Repositorio Local III

  34. 34 egit: Añadiendo Elementos al Índice de Git I

  35. 35 egit: Añadiendo Elementos al Índice de Git II

  36. 36 egit: Añadiendo Elementos al Índice de Git III

  37. 37 egit: Añadiendo Elementos al Índice de Git IV

  38. 38 egit: Haciendo commit I

  39. 39 egit: Haciendo commit II

  40. 40 egit: Mostrando Historia de un elemento I

  41. 41 egit: Mostrando Historia de un elemento II

  42. 42 egit: Ir a una versión anterior temporalmente

  43. 43 egit: Regresando de una versión anterior

  44. 44 egit: Ir a una versión anterior definitivamente

  45. 45 egit: Configurando repositorio remoto I

  46. 46 egit: Configurando repositorio remoto II

  47. 47 egit: Configurando repositorio remoto III

  48. 48 egit: Configurando repositorio remoto IV

  49. 49 egit: Configurando repositorio remoto V

  50. 50 egit: Configurando repositorio remoto VI

  51. 51 egit: Subir cambios locales a repositorio remoto

  52. 52 egit: Actualizando desde repositorio remoto

  53. 53 egit: Clonado de repositorios I

  54. 54 egit: Clonado de repositorios II

  55. 55 egit: Clonado de repositorios III

  56. 56 egit: Clonado de repositorios IV

  57. 57 egit: Clonado de repositorios V

  58. 58 egit: Clonado de repositorios VI

  59. 59 egit: Creando nuevo Branch I

  60. 60 egit: Creando nuevo Branch II

  61. 61 egit: Creando nuevo Branch III

  62. 62 egit: Realizando merge entre dos ramas I

  63. 63 egit: Realizando merge entre dos ramas II

  64. 64 egit: Realizando merge entre dos ramas III

  65. 65 egit: Realizando merge entre dos ramas IV

  66. 66 egit: Subiendo branch local al servidor I

  67. 67 egit: Subiendo branch local al servidor II

  68. 68 egit: Borrando branch local

  69. 69 egit: Trayendo branch del servidor a local I

  70. 70 egit: Trayendo branch del servidor a local II

  71. 71 egit: Trayendo branch del servidor a local III

  72. 72 egit: Trayendo branch del servidor a local IV

  73. 73 egit: Trayendo branch del servidor a local V

  74. 74 egit: Borrando brach en el servidor I

  75. 75  Metodología informática propuesta inicialmente por Martin Fowler. 

    Consiste en hacer integraciones automáticas de un proyecto lo más a menudo posible para así poder detectar fallos cuanto antes.  Se entiende por integración la compilación y ejecución de tests de todo un proyecto. Sistemas de Integración continua
  76. 76  Jenkins es un software de Integración continua open

    source escrito en Java.  Es un fork del proyecto Hudson.  Jenkins corre en un servidor de aplicaciones.  Soporta herramientas de control de versiones como CVS, Subversion, Git, Mercurial, Perforce y Clearcase.  Puede ejecutar proyectos basados en Apache Ant y Apache Maven, así como scripts de shell y programas batch de Windows.  Liberado bajo licencia MIT. Presentación Jenkins
  77. 77  Jenkins puede descargarse desde http://jenkins-ci.org/  Instalar la

    aplicación jenkins.war en un servidor.  Acceder consola de Jenkins Instalación de Jenkins
  78. 78  Acceder opción administrar Jenkins/Configuración del sistema Configuración básica

    de Jenkins I
  79. 79  Configurar seguridad Configuración básica de Jenkins II

  80. 80  Configurar JDK Configuración básica de Jenkins III

  81. 81  Configurar Maven Configuración básica de Jenkins IV

  82. 82  Configurar Mail Configuración básica de Jenkins V

  83. 83  Instalar plugin de Git Integración Jenkins – Git

    I
  84. 84  Configuración plugin de Git Integración Jenkins – Git

    II
  85. 85  Crear nueva tarea Configuración tarea Jenkins I

  86. 86 Configuración tarea Jenkins II

  87. 87 Configuración tarea Jenkins III

  88. 88  Sin testing en nuestro proyecto, un sistema de

    integración continua únicamente probará que nuestro proyecto compila.  A medida que añadimos pruebas unitarias/integración a nuestro proyecto, en cada compilación desde el sistema de integración continua se ejecutan la pruebas.  Cuanto más pruebas unitarias/integración existan en nuestro proyecto, más eficaz es un sistema de integración continua, ya que será más sencillo que se detecten errores que se ha subido al repositorio. Importancia del Testing en Integración continua
  89. 89  Emma permite medir el grado de coverage que

    las pruebas unitarias/integración hacen a nuestro código.  Emma nos muestra que partes del código y cuales no están cubiertas por nuestras pruebas unitarias/integración.  Emma nos da una idea de la calidad del testing que estamos realizando.  Existe un plugin de Emma que integra con Jenkins.  Existe un plugin de Emma que integra con Eclipse: EclEmma. Emma
  90. Madrid Avda. de Europa, 26 - Ática 5, 3ª Planta

    28224 Pozuelo de Alarcón E-mail: info@paradigmatecnologico.com Teléfono: +34 91 352 59 42 Fax: +34 91 715 89 66