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