Slide 1
Slide 1 text
Spring Roo
&
Spring Insight
@federicojcdm
14 de Octubre de 2010
Slide 2
Slide 2 text
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?
Slide 3
Slide 3 text
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
Slide 4
Slide 4 text
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
Slide 5
Slide 5 text
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
Slide 6
Slide 6 text
6
Creando un nuevo repositorio local de Git
Añadiendo elemento al índice de Git
Manejo Básico Cliente Git I
Slide 7
Slide 7 text
7
Comando status
Realizando commit
Manejo Básico Cliente Git II
Slide 8
Slide 8 text
8
Consultando el historial de commit
Consultando cambios realizados
Manejo Básico Cliente Git III
Slide 9
Slide 9 text
9
Volviendo a una versión anterior temporalmente
Manejo Básico Cliente Git IV
Slide 10
Slide 10 text
10
Regresando de una versión anterior
Manejo Básico Cliente Git V
Slide 11
Slide 11 text
11
Volviendo a una versión anterior definitivamente
Manejo Básico Cliente Git VI
Slide 12
Slide 12 text
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
Slide 13
Slide 13 text
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
Slide 14
Slide 14 text
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
Slide 15
Slide 15 text
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
Slide 16
Slide 16 text
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
Slide 17
Slide 17 text
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
Slide 18
Slide 18 text
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
Slide 19
Slide 19 text
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
Slide 20
Slide 20 text
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
Slide 21
Slide 21 text
21
Accediendo al repositorio GitHub por https
Git en el servidor: Otros protocolos en GitHub I
Slide 22
Slide 22 text
22
Accediendo al repositorio GitHub read-only
Git en el servidor: Otros protocolos en GitHub II
Slide 23
Slide 23 text
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
Slide 24
Slide 24 text
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
Slide 25
Slide 25 text
25
Creando un nuevo branch en repositorio local, y, quedar situado en
el nuevo branch
Gestión de Branch con Git III
Slide 26
Slide 26 text
26
Realizando merge entre dos branch,
Gestión de Branch con Git IV
Slide 27
Slide 27 text
27
Subiendo branch del repositorio local al servidor,
Gestión de Branch con Git V
Slide 28
Slide 28 text
28
Borrando branches locales,
Gestión de Branch con Git VI
Slide 29
Slide 29 text
29
Trayendo branches desde el servidor al repositorio local,
Gestión de Branch con Git VII
Slide 30
Slide 30 text
30
Borrando branches en el servidor,
Gestión de Branch con Git VIII
Slide 31
Slide 31 text
31
egit: Creando un Repositorio Local I
Slide 32
Slide 32 text
32
egit: Creando un Repositorio Local II
Slide 33
Slide 33 text
33
egit: Creando un Repositorio Local III
Slide 34
Slide 34 text
34
egit: Añadiendo Elementos al Índice de Git I
Slide 35
Slide 35 text
35
egit: Añadiendo Elementos al Índice de Git II
Slide 36
Slide 36 text
36
egit: Añadiendo Elementos al Índice de Git III
Slide 37
Slide 37 text
37
egit: Añadiendo Elementos al Índice de Git IV
Slide 38
Slide 38 text
38
egit: Haciendo commit I
Slide 39
Slide 39 text
39
egit: Haciendo commit II
Slide 40
Slide 40 text
40
egit: Mostrando Historia de un elemento I
Slide 41
Slide 41 text
41
egit: Mostrando Historia de un elemento II
Slide 42
Slide 42 text
42
egit: Ir a una versión anterior temporalmente
Slide 43
Slide 43 text
43
egit: Regresando de una versión anterior
Slide 44
Slide 44 text
44
egit: Ir a una versión anterior definitivamente
Slide 45
Slide 45 text
45
egit: Configurando repositorio remoto I
Slide 46
Slide 46 text
46
egit: Configurando repositorio remoto II
Slide 47
Slide 47 text
47
egit: Configurando repositorio remoto III
Slide 48
Slide 48 text
48
egit: Configurando repositorio remoto IV
Slide 49
Slide 49 text
49
egit: Configurando repositorio remoto V
Slide 50
Slide 50 text
50
egit: Configurando repositorio remoto VI
Slide 51
Slide 51 text
51
egit: Subir cambios locales a repositorio remoto
Slide 52
Slide 52 text
52
egit: Actualizando desde repositorio remoto
Slide 53
Slide 53 text
53
egit: Clonado de repositorios I
Slide 54
Slide 54 text
54
egit: Clonado de repositorios II
Slide 55
Slide 55 text
55
egit: Clonado de repositorios III
Slide 56
Slide 56 text
56
egit: Clonado de repositorios IV
Slide 57
Slide 57 text
57
egit: Clonado de repositorios V
Slide 58
Slide 58 text
58
egit: Clonado de repositorios VI
Slide 59
Slide 59 text
59
egit: Creando nuevo Branch I
Slide 60
Slide 60 text
60
egit: Creando nuevo Branch II
Slide 61
Slide 61 text
61
egit: Creando nuevo Branch III
Slide 62
Slide 62 text
62
egit: Realizando merge entre dos ramas I
Slide 63
Slide 63 text
63
egit: Realizando merge entre dos ramas II
Slide 64
Slide 64 text
64
egit: Realizando merge entre dos ramas III
Slide 65
Slide 65 text
65
egit: Realizando merge entre dos ramas IV
Slide 66
Slide 66 text
66
egit: Subiendo branch local al servidor I
Slide 67
Slide 67 text
67
egit: Subiendo branch local al servidor II
Slide 68
Slide 68 text
68
egit: Borrando branch local
Slide 69
Slide 69 text
69
egit: Trayendo branch del servidor a local I
Slide 70
Slide 70 text
70
egit: Trayendo branch del servidor a local II
Slide 71
Slide 71 text
71
egit: Trayendo branch del servidor a local III
Slide 72
Slide 72 text
72
egit: Trayendo branch del servidor a local IV
Slide 73
Slide 73 text
73
egit: Trayendo branch del servidor a local V
Slide 74
Slide 74 text
74
egit: Borrando brach en el servidor I
Slide 75
Slide 75 text
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
Slide 76
Slide 76 text
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
Slide 77
Slide 77 text
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
Slide 78
Slide 78 text
78
Acceder opción administrar Jenkins/Configuración del sistema
Configuración básica de Jenkins I
Slide 79
Slide 79 text
79
Configurar seguridad
Configuración básica de Jenkins II
Slide 80
Slide 80 text
80
Configurar JDK
Configuración básica de Jenkins III
Slide 81
Slide 81 text
81
Configurar Maven
Configuración básica de Jenkins IV
Slide 82
Slide 82 text
82
Configurar Mail
Configuración básica de Jenkins V
Slide 83
Slide 83 text
83
Instalar plugin de Git
Integración Jenkins – Git I
Slide 84
Slide 84 text
84
Configuración plugin de Git
Integración Jenkins – Git II
Slide 85
Slide 85 text
85
Crear nueva tarea
Configuración tarea Jenkins I
Slide 86
Slide 86 text
86
Configuración tarea Jenkins II
Slide 87
Slide 87 text
87
Configuración tarea Jenkins III
Slide 88
Slide 88 text
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
Slide 89
Slide 89 text
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
Slide 90
Slide 90 text
Madrid
Avda. de Europa, 26 - Ática 5, 3ª Planta
28224 Pozuelo de Alarcón
E-mail: [email protected]
Teléfono: +34 91 352 59 42
Fax: +34 91 715 89 66