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: info@paradigmatecnologico.comTeléfono: +34 91 352 59 42

Fax: +34 91 715 89 66