Introducción al Control de versiones (git, github) y despliegue en la nube

(heroku)!Ingeniería de Sistemas de Información!Grado en Ingeniería en Tecnologías de

Telecomunicación!

GSyC!

• ©2012 Departamento GSyC, URJC!– Algunos derechos reservados. Este trabajo se

distribuye bajo la licencia Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License!

2!©GSyC!

Contenidos!•  Introducción: control de versiones!•  Control de versiones con Git!•  Repositorios distribuidos: Github!•  Despliegue de aplicaciones RoR en Heroku!

3!©GSyC!

Introducción: control de versiones!•  Control de versiones o gestión de la configuración!

–  Version control system (VCS), Source code control (SCC), software configuration management (SCM)!

•  Sistemas para registrar la historia de los cambios que van sufriendo un conjunto de ficheros!

•  Sirve para: !–  Poder saber cuándo se modificó y quién lo hizo, cada fichero de un

proyecto!–  Poder reconstruir el estado de los ficheros al estado que tenían en algún

momento del pasado, por ejemplo para deshacer cambios que han conducido a un error!

–  Poder coordinar los cambios que realiza un conjunto de desarrolladores sobre los ficheros de un proyecto!

•  Sistema de control de versiones (Version Control System-VCS)!–  Herramienta SW que ayuda a gestionar el el control de versiones!–  Ej: SCCS, RCS, CVS, SVN, Git!

4!©GSyC!

Control de versiones con Git!

git!•  Git es un sistema de control de versiones distribuido!•  Repositorio o repo!

–  Guarda la historia completa de un subconjunto de ficheros del proyecto!

•  GitHub y ProjectLocker ofrecen hospedaje para git en la red!–  Útiles para colaborar entre varios miembros de un equipo de

desarrollo!–  Útil para desarrolladores individuales para hacer backups del

repositorio!–  Útil como imagen!

•  GitHub y ProjectLocker ofrecen hospedaje para git en la red!–  Útiles para colaborar entre varios miembros de un equipo de desarrollo!–  Útiles también para desarrolladores individuales: para hacer backups de

los ficheros de sus proyectos!–  Útil como portfolio que vende tu imagen, para encontrar trabajo!

6!©GSyC!

git: el repositorio o repo!•  El repo es donde git guarda la historia

completa de algún subconjunto de ficheros del proyecto!– No todos los ficheros del proyecto tienen que estar en el

repositorio!

•  Para inicializar el repo de un proyecto!1. cd <directorio-raiz-del-proyecto> 2. git init •  El repositorio queda inicializado, pero vacío,

en ! <directorio-raiz-de- proyecto>/.git/

7!©GSyC!

git: tracked files!•  Es el subconjunto de ficheros del proyecto que forman

parte del repositorio !•  Sus versiones se van guardando sus versiones cada vez

que se compromete su estado (se hace commit)!•  git add ‘*txt’ añade recursivamente los ficheros

acabados en txt al conjunto de tracked files!•  No todos los ficheros del proyecto tienen por qué formar

parte de los tracked files: ej. ficheros intermedios como los de log, no!

•  En .gitignore se especifican los ficheros que no deben añadirse. Ej:!

8!©GSyC!

# a comment – línea de comentario *.a # ignorar los ficheros que acaben en .a !lib.a # pero sí lib.a, aunque hemos ignorado los acabados en .a /TODO # ignorar sólo el fichero /TODO, no los ficheros TOD en subirs build/ # ignorar todos los ficheros del subdir build/ doc/*.txt # ignorar doc/notes.txt, pero nodoc/server/arch.txt

Fichero .gitignore!•  En el raíz del proyecto el fichero .gitignore especifica los

ficheros que no deben añadirse al repo. Ej:!

•  Ejemplo de .gitignore para RoR:!

9!©GSyC!

# a comment – línea de comentario *.a # ignorar los ficheros que acaben en .a !lib.a # pero sí lib.a, aunque hemos ignorado los acabados en .a /TODO # ignorar sólo el fichero /TODO, no los ficheros TOD en subirs build/ # ignorar todos los ficheros del subdir build/ doc/*.txt # ignorar doc/notes.txt, pero nodoc/server/arch.txt

*.rbc* .sassc .sass-cache capybara-*.html .rspec /.bundle /vendor/bundle /log/* /tmp/* /db/*.sqlite3 /public/system/* /coverage/ /spec/tmp/* **.orig rerun.txt pickle-email-*.html

git: commit de ficheros!•  Cuando estás contento con el estado del proyecto haces commit para

que se refleje en el repo el estado actual de los tracked files!•  A la “foto” que guarda commit se le asigna un commit ID, obtenido

como firma digital SHA-1 (40 dígitos hexadecimales) de todos los ficheros en su estado actual!–  Número único en el universo (todos los repos tuyos y de otros)!

•  ¿Qué permite commit?!–  Recuperar en el futuro el estado (foto) comprometido de los tracked files!–  ¡NO es una copia de backup de tus ficheros!!

•  Es muy importante añadir un texto que explique el estado que se compromete!–  Cuando se hace commit se añade el comentario !–  Configuración del editor que se arranca al hacer commit:!

•  git config –-global core.editor ‘vim’ –  Podemos añadir mensaje en la línea de comandos: ! git commit –m ‘msg’

10!©GSyC!

git: stage area!•  El stage es un área en la que se almacenan los cambios que serán

comprometidos al repositorio!–  Se pueden añadir/quitar ficheros de stage antes de comprometer!

•  git add en realidad sirve para 2 cosas:!–  Añadir un fichero a conjunto de tracked files!–  Añadir al stage el estado actual de un fichero: si después se modifica y luego se

compromete, el estado que va al repositorio es el que se puso en stage!•  Si después de modificar un fichero f queremos que los nuevos

cambios acaben comprometiéndose cuando se comprometa, hay que volver a pasarlo al stage con git add f

•  git commit compromete los ficheros del stage al repositorio!•  git commit –a hace que el estado actual de todos los tracked files,

aunque no les hayamos hecho git add, sea el que se acabe comprometiendo!

–  Es equivalente a hacer primero un git add de todos lo tracked files y luego git commit

11!©GSyC!

Sesión de trabajo con git!•  git config -–global core.editor ‘vim’

•  mkdir p1 –  Creamos nuestro proyecto en el directorio p1

•  cd p1; touch a.txt; touch b.txt

•  git init

•  git add a.txt

•  git status

•  git add b.txt

•  git status

•  git commit

•  git status

•  echo “nueva linea” > a.txt

•  git status –  Uno de los ficheros, a.txt, tiene cambios

•  git diff –  Muestra diferencias entre ficheros actuales y su versión stagged

–  Es decir, son los cambios que pasarían a stagged si hiciésemos git add

•  git commit -a –  Con –a compromete el estado actual de los tracked files ficheros, no el stagged

•  git status –  No hay cambios pendientes de comprometer

•  git log

12!©GSyC!

Repositorios distribuidos: Github

Github: Introducción!•  Permite almacenar gratuitamente todos los repos que

quieras!–  Siempre que sean públicos!–  Alternativa: projectlocker. La cuenta gratis restringe la cantidad de

datos, pero permite repos privados!•  Sólo una vez al principio:!

–  Generas pareja clave pública/privada para autenticarte en el servicio github con ssh!

–  Configuras git para que conozca la clave!–  Sólo necesitas una clave para todas tus cuentas y repos!

•  Luego: usando git, haces push de tu repo a github, creando allí una réplica!

•  Otros desarrolladores pueden hacer push de sus cambios y pull de los de otros!

14!©GSyC!

Preparación para usar github!1.  Crea una cuenta gratis en github!2.  Informamos a git del nombre de usuario y del correo-e para que cada commit quede

identificado!1.  git config –-global user.name ‘username-de-github’

2.  git config –-global user.email ‘tucorreo@electronico.com’

3.  Crea pareja de claves para ssh que te identificarán ante el servicio github:!1.  cd ~/.ssh

2.  ssh-keygen –t rsa –C tucorreo@electronico.com

3.  <Enter> para guardar en el fichero sugerido!4.  Introduce una passfrase, y acuérdate de ella (para no meterla en el futuro siempre: ssh-

agent bash; ssh-add)!5.  chmod 0600 *

4.  Añade tu clave pública a github!1.  En https://github.com/settings/ssh elige Add SSH Key!2.  Copia los contenidos de ~/.ssh/id_rsa.pub!3.  Ahora te pide tu password en github!

5.  Crea un repositorio remoto para cada nuevo proyecto, en https://github.com/new!1.  Recuerda el nombre. Ejemplo: <nombre-repo-remoto>

6.  Repite los pasos 3-4 para cada máquina distinta en la que quieres tener una copia del repo!

15!©GSyC!

Sesión de trabajo con git+github 1/4!

•  Creamos cuenta, y un repo <nombre-repo-remoto> en github –  (ver transparencia anterior)!

•   git remote add origin git@github.com:username-de-github/<nombre-repo-remoto>.git

–  Con este comando le decimos a git que nos referiremos a nuestro repositorio <nombre-repo-remoto> remoto de github .gitcomo origin !

•  git push origin master –  Mandamos a origin (github) nuestro master local!

•  Supongamos que hemos invitado a nuestro repo en github a otros usuarios (añadiendo sus claves públicas), y han modificado nuestros ficheros haciendo git push !

•  git pull origin master •  Obtenemos sus cambios!

•  git diff HEAD –  Comparamos los cambios de todo (stagged y no stagged) con lo último

comprometido (HEAD)!–  Es decir, nos dice lo que se comprometería con git commit -a

16!©GSyC!

Sesión de trabajo con git+github 2/4!

•  touch c.txt –  Añadimos fichero que no existía

•  git add c.txt –  Añadimos fichero que no existía!

•  echo ‘hola’ > c.txt •  git diff •  git diff HEAD •  git diff --staged

–  Nos da los cambios entre stagged y el último commit: aparece c.txt!•  git reset c.txt

–  Cambiamos de opinión: quitamos de stagged c.txt:!–  Sigue ahí, pero ahora ya no está stagged luego git commit no lo guardará en el repo!

•  git checkout -– f.txt –  Devolver a su último estado comprometido el fichero f.txt!–  Recuperamos así una versión anterior que nos funcionó!

17!©GSyC!

Sesión de trabajo con git+github 3/4!

•  Vamos a crear una rama aparte de la rama master a la que llamamos clean_up!

•  git branch clean_up –  Creamos branch clean_up, alternativo al main branch o master!

•  git branch –  Vemos ramas que tenemos en este proyecto: master y clean_up !

•  git checkout clean_up –  Cambiamos de master a la rama clean_up. Lo que hagamos ahora con git

sólo tiene efecto en esta rama!•  git branch

–  Vemos que efectivamente hemos cambiado!•  git rm ‘*.txt’

–  En la nueva rama borramos los ficheros y añadimos a stage su borrado!•  git status •  git commit –m “mensaje…”

–  Comprometemos cambios en la rama clean_up!18!©GSyC!

Sesión de trabajo con git+github 4/4!

•  Una vez satisfechos con la rama clean_up vamos a mezclarla con master!

•  git checkout master –  Volvemos a la rama master!

•  git merge clean_up –  Mezclamos cambios de clean_up con master!

•  git branch –d clean_up –  Eliminamos la rama clean_up!

•  git push origin master –  Acabamos haciendo push a github de la rama master!

19!©GSyC!

Despliegue de aplicaciones RoR en Heroku

Despliegue en heroku!•  Heroku proporciona servicios PaaS (Platform-as-a-Service) para RoR,

Django,…!•  Créate una cuenta gratis en heroku.com!•  En tu máquina: heroku login!

–  Subirá tu clave pública para que puedas luego autenticarte automáticamente cuando ejecutes otros comandos de heroku!

–  Si cambiases tu clave pública tienes que volver a subirla a heroku:! heroku keys:add ~/.ssh/id_rsa.pub!

•  La app rails correrá en el entorno de producción de heroku!–  Heroku instalará las gemas del grupo :production de tu Gemfile!–  Heroku utiliza PostgreSQL, así que asegúrate de que la gema de PostgreSQL (pg)

aparece listada en el grupo :production!

•  Corre bundle en tu repo local, por última vez antes de desplegar! bundle install -–path vendor/bundle --without production

21 ©GSyC

group :production do gem 'pg’ … end

Despliegue en heroku!•  El código de tu app debe estar bajo git, ¡incluyendo el Gemfile claro!!

–  Asegúrate de comprometer a tu repo todo antes de desplegar!–  Asegúrate de que todo funciona en local!

•  Será la rama master del repo de tu app RoR la que se suba a heroku y se arranque despliegue!

•  heroku create –-stack cedar –  Esto sólo lo hacemos la 1ª vez que desplegamos una nueva aplicación RoR en

heroku!–  Apunta la url que te devuelve. La puedes cambiar en heroku.com por otra cosa

más manejable!•  git push heroku master

–  Esto lo hacemos cada vez que queremos subir una nueva versión de la app de nuestro repo!

–  Manda a heroku todos los ficheros comprometidos, y arranca en heroku la aplicación!

–  Fíjate en la salida por si hay errores al desplegar!

22!©GSyC!

Despliegue en heroku!•  heroku ps

–  Comprueba cómo fue todo con !•  heroku run rake db:migrate

–  Crea las migraciones en la BD de producción!•  heroku run rake db:seed

–  Poblamos la base de datos con •  Comandos equivalentes (devel / producción con heroku):!

23!©GSyC!

Repo local (development)! Heroku (producción)!rails server git push heroku master

rails console heroku run console

rake db:migrate heroku run rake db:migrate

more log/development.log heroku logs

Referencias!

•  Pro Git: libro sobre git!– http://git-scm.com/book!

• Docs en heroku.com!• Docs en github.com!

24!©GSyC!