Contenu connexe Similaire à Control de versiones y despliegue en la nube Similaire à Control de versiones y despliegue en la nube (20) 1. 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!
2. • ©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!
4. 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!
6. 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!
7. 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!
8. 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
9. 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
10. 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!
11. 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!
12. 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!
14. 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!
15. 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!
16. 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!
17. 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!
18. 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!
19. 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!
21. 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
22. 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!
23. 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
24. Referencias!
• Pro Git: libro sobre git!
– http://git-scm.com/book!
• Docs en heroku.com!
• Docs en github.com!
24!©GSyC!
