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
Git y Jenkins. El futuro en la gestión del ciclo de vida de aplicaciones
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
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
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
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