Descargado 18 veces
Más contenido relacionado
Similar a 05 intro-git-github-heroku-v4
05 intro-git-github-heroku-v4
- 1. Introducción al Controlde 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 DepartamentoGSyC, URJC! – Algunos derechos reservados. Este trabajo se distribuye bajo la licencia Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License! 2!©GSyC!
- 3. Contenidos! • Introducción: controlde versiones! • Control de versiones con Git! • Repositorios distribuidos: Github! • Despliegue de aplicaciones RoR en Heroku! 3!©GSyC!
- 4. Introducción: control deversiones! • 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!
- 5. Control de versionescon Git!
- 6. git! • Git esun 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 repositorioo 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! • Enel 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 deficheros! • 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 trabajocon 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!
- 13.
- 14. Github: Introducción! • Permitealmacenar 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 usargithub! 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 ‘[email protected]’ 3. Crea pareja de claves para ssh que te identificarán ante el servicio github:! 1. cd ~/.ssh 2. ssh-keygen –t rsa –C [email protected] 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 trabajocon git+github 1/4!• Creamos cuenta, y un repo <nombre-repo-remoto> en github – (ver transparencia anterior)! • git remote add origin [email protected]: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 trabajocon 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 trabajocon 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 trabajocon 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!
- 20. Despliegue de aplicaciones RoRen Heroku
- 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!