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

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

2. ¿Qué es Git?
 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.
2

3. Distribuido vs Centralizado I
 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.
3

4. Distribuido vs Centralizado II
 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.
4

5. Instalación de un cliente de Git
 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: apt-get install git-core
Ubuntu
– En Fedora: yum install git-core
Fedora
5

6. Manejo Básico Cliente Git I
 Creando un nuevo repositorio local de Git
 Añadiendo elemento al índice de Git
6

7. Manejo Básico Cliente Git II
 Comando status
 Realizando commit
7

8. Manejo Básico Cliente Git III
 Consultando el historial de commit
 Consultando cambios realizados
8

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

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

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

12. Git en el servidor: Gitosis
 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
12

13. Git en el servidor: GitHub
 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, …...
13

14. Git en el servidor: Configuración GitHub
 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
14

15. Git en el servidor: Generación SSH keys
 Para la creación de un par de claves(clave pública/clave privada)
SSH se seguirá el siguiente procedimiento,
15

16. Git en el servidor: Acceso SSH GitHub
 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”
16

17. Git en el servidor: Creación de Repositorios
 Acceder a la cuenta de GitHub
 Seleccionar opción “New Repository”
 Completar datos del nuevo repositorio, y crear repositorio
17

18. Git en el servidor: Subir Repositorio a GitHub
 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)
18

19. Git en el servidor: Actualizar desde Repositorio
 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.
19

20. Git en el servidor: Clonado de Repositorios
 Acceder a la cuenta de GitHub
 Obtener la url SSH del repositorio remoto a clonar
 Realizar clonado del repositorio remoto en sistema local
20

21. Git en el servidor: Otros protocolos en GitHub I
 Accediendo al repositorio GitHub por https
21

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

23. Gestión de Branch con Git I
 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.
23

24. Gestión de Branch con Git II
 Listando los branches existentes,
 Creando un nuevo branch en el repositorio local,
 Cambiando al nuevo branch en el repositorio local,
24

25. Gestión de Branch con Git III
 Creando un nuevo branch en repositorio local, y, quedar situado en
el nuevo branch
25

26. Gestión de Branch con Git IV
 Realizando merge entre dos branch,
26

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

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

29. Gestión de Branch con Git VII
 Trayendo branches desde el servidor al repositorio local,
29

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

31. egit: Creando un Repositorio Local I
31

32. egit: Creando un Repositorio Local II
32

33. egit: Creando un Repositorio Local III
33

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

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

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

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

38. egit: Haciendo commit I
38

39. egit: Haciendo commit II
39

40. egit: Mostrando Historia de un elemento I
40

41. egit: Mostrando Historia de un elemento II
41

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

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

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

45. egit: Configurando repositorio remoto I
45

46. egit: Configurando repositorio remoto II
46

47. egit: Configurando repositorio remoto III
47

48. egit: Configurando repositorio remoto IV
48

49. egit: Configurando repositorio remoto V
49

50. egit: Configurando repositorio remoto VI
50

51. egit: Subir cambios locales a repositorio remoto
51

52. egit: Actualizando desde repositorio remoto
52

53. egit: Clonado de repositorios I
53

54. egit: Clonado de repositorios II
54

55. egit: Clonado de repositorios III
55

56. egit: Clonado de repositorios IV
56

57. egit: Clonado de repositorios V
57

58. egit: Clonado de repositorios VI
58

59. egit: Creando nuevo Branch I
59

60. egit: Creando nuevo Branch II
60

61. egit: Creando nuevo Branch III
61

62. egit: Realizando merge entre dos ramas I
62

63. egit: Realizando merge entre dos ramas II
63

64. egit: Realizando merge entre dos ramas III
64

65. egit: Realizando merge entre dos ramas IV
65

66. egit: Subiendo branch local al servidor I
66

67. egit: Subiendo branch local al servidor II
67

68. egit: Borrando branch local
68

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

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

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

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

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

74. egit: Borrando brach en el servidor I
74

75. Sistemas de Integración continua
 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.
75

76. Presentación Jenkins
 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.
76

77. Instalación de Jenkins
 Jenkins puede descargarse desde http://jenkins-ci.org/
 Instalar la aplicación jenkins.war en un servidor.
 Acceder consola de Jenkins
77

78. Configuración básica de Jenkins I
 Acceder opción administrar Jenkins/Configuración del sistema
78

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

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

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

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

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

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

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

86. Configuración tarea Jenkins II
86

87. Configuración tarea Jenkins III
87

88. Importancia del Testing en Integración continua
 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.
88

89. Emma
 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.
89

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