• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Control de Versiones - Guión
 

Control de Versiones - Guión

on

  • 590 views

 

Statistics

Views

Total Views
590
Views on SlideShare
589
Embed Views
1

Actions

Likes
0
Downloads
1
Comments
0

1 Embed 1

http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Control de Versiones - Guión Control de Versiones - Guión Document Transcript

    • Guión charla control de versionesQue controla un VCSUn VCS controla las diferencias (deltas) entre versiones de un mismo fichero. Una versiónes una foto del contenido de un fichero. Ejemplo de cálculo de diferencias en una imagen: Revisión 1 Revisión 2 delta GIF: 62046 bytes GIF: 62591 bytes GIF: 8280 bytes(también nos sirve para ganar muy rápido al “busca las 10 diferencias”)A esta técnica se le llama delta-compression.La idea de fondo es que si somos capaces de aplicar delta a la primera revisión,obtendremos la segunda revisión.Esto con ficheros de texto es trivial y en entornos Unix lo llevamos haciendo desde los 70con los comandos diff y patch. Del concepto de patch (parche) se evolucionó hacia elconcepto de Control de Revisión y de aquellas barros, estos lodos.Anécdota: hasta hace bien poco, la horda de “contributors” del kernel de linux mandabaparches al mismísimo Linus Trovalds, quien los iba aplicando a mano en su copia local.Estuvieron así durante años hasta que les dio por dominar el mundo con Git.
    • ¿VCS = backup?¡NO!Bueno, vale, es algo que se parece mucho a un backup, pero va mucho más allá. Eincluso, usarlo como backup es motivo suficiente para usar un VCS en cualquier proyecto. El control de versiones, en definitiva, va de poder responder a estas preguntas: 1. ¿Qué constituye una versión concreta de mi trabajo? ¿Cómo puedo reproducir un determinado estado de cualquiera de las versiones que he entregado? 2. ¿Quién ha hecho qué, cuándo y por qué? No solo es útil para saber cuándo han ido mal las cosas, sino también para contar la historia de tu producto. (Traducido de Continuous Delivery, de Jef Humble y David Farley)Además, resulta que tiene unos mecanismos excepcionales para permitir la colaboraciónentre distintos “actores” en el marco de un proyecto.Podemos editar el mismo fichero a la vez y nuestro VCS favorito se desvivirá por intentarmezclar todos los cambios sin romper nada. Muchas veces lo consigue y otras, nos tocaarreglar “los líos de otros” (nunca los nuestros, eh?, que siempre hacemos los commitsbien).Branching y merging: el comienzo del finNormalmente trabajaremos en la rama troncal o maestra de nuestro repositorio de CVS.Cuando queremos desviar la evolución de nuestro desarrollo por un camino distinto,hacemos un branch, o rama en inglés. A partir de ese momento, los deltas que el CVSalmacene para los ficheros de la rama irán por separado de los deltas de la ramaprincipal.Cuando queremos que los deltas acumulados aisladamente dentro de una rama seimporten a la rama principal, hacemos un mergeA priori son funcionalidades que tienen muy buena pinta. Aislar una determinada vía dedesarrollo para una sola nueva funcionalidad y no ensuciar la rama principal... ¿Ensuciar?Si para desarrollar algo nuevo vamos a ensuciar la rama principal, seguramente queestamos haciendo algo mal.
    • En última instancia, según los autores de Continuous Delivery (que de esto saben unhuevo), todo commit al CVS debe constituir una pieza de producto entregable. Muchos delos branchs que creamos para no mancillar la castidad de la rama principal, suelenterminar conteniendo mucho código duplicado y cuanto más largo es su recorrido, másdifícil suele resultar la reincorporación del branch a la rama principal.Por otro lado, si el branch no va a ser reincorporado al branch principal y no va a estaractivo indefinidamente, puede tener sentido prepararlo.En cualquier caso, esta es solo mi opinión y os recomiendo experimentar y sacar vuestraspropias conclusiones.Marcha atrás: la esquiva quimeraEn el caso de que una entrega no llegue a buen puerto, el control de versiones nos puedeayudar a recuperar un estado previo de nuestro proyecto. Sin embargo, en un proyecto de cierta envergadura, resulta complicado llevar una gestión tan exigente sobre el control de versiones como para permitir el rollback a la versión anterior. Aunque es posible hacerlo, muchas veces tendremos que valorar su coste frente a otras alternativas menos elegantes como el nunca suficientemente valorado backup previo o mediante el despliegue de una nueva versión del proyecto quecorrija cualquier defecto detectado en la entrega. A veces la huida hacia delante es lamejor opción.Subversion para geeksMergeo parcial entre dos branches:1) Nos movemos al punto en el que queremos mergear y obtenemos la ruta actual sobre la que queremos mergear:cerebro:/src/bar/chuchu/blabla cocotero$ svn infoRuta: .URL: http://foo.com/bar/trunk/chuchu/blablaRaíz del repositorio: http://foo.comUUID del repositorio: 4fda1d5b-c8f9-44cf-8ad8-48e2fb4af63b...(tomamos nota de la URL)2) Ejecutamos un merge contra la misma ruta del branch rc4:cerebro:/src/bar/chuchu/blabla cocotero$ svn merge http://foo.com/bar/trunk/chuchu/blabla http://foo.com/bar/branches/rc4/chuchu/blabla .
    • 3) Revisamos los cambios y hacemos commit de lo que haga falta.Añadir y eliminar externalscerebro:/src/bar/blabla cocotero$ svn propset svn:externals“chuchu http://foo.com/bar/trunk/chuchu” vendor/.Crea un external en vendor/chuchu que apunta al repo que indicamoscerebro:/src/bar/blabla cocotero$ svn propdel svn:externalsvendor/.Elimina cualquier external que pueda haber en vendor. Si necesitas borrar un external enconcreto, puedes usar el comando svn propedit svn:externalsIgnorar ficheros o directorioscerebro:/src/bar/blabla cocotero$ echo “*” > .svnignorecerebro:/src/bar/blabla cocotero$ svn add .svnignorecerebro:/src/bar/blabla cocotero$ svn propset svn:ignore -F .svnignore .Ignoramos cualquier cosa dentro de blabla que no esté ya en nuestro repocerebro:/src/bar/blabla cocotero$ echo “cache” > .svnignorecerebro:/src/bar/blabla cocotero$ svn add .svnignorecerebro:/src/bar/blabla cocotero$ svn propset svn:ignore -F .svnignore .Ignoramos el fichero o directorio cache dentro de blablaGit para humanosAntes de empezar, diré que la clave es usar GitHub. Si usas GitHub unas semanas lecoges el tranquillo a Git sin problemas.Rompiendo el modo centralizado1) Crea un repo que sera el “maestro”2) Te haces un fork del maestro para ticerebro:/src/ cocotero$ git clone git@github.com:ggalmazor/BusinessLayer.git3) Te añades al resto de contributors como origencerebro:/src/ cocotero$ git remote add rubengit@github.com:regiluze/BusinessLayer.gitcerebro:/src/ cocotero$ git remote add mikelgit@github.com:mintxaus/BusinessLayer.git
    • 4) Te traes sus repos:cerebro:/src/ cocotero$ git fetch rubencerebro:/src/ cocotero$ git fetch mikel5) Premio:cerebro:/src/ cocotero$ git branch -a* master remotes/mikel/master remotes/origin/HEAD -> origin/master remotes/origin/master remotes/ruben/masterTienes todos sus branches en local :) Ahora puedes mergearte con ellos sin pasar por elrepo “maestro”.Además de esto, podrás organizar mejor las aportaciones del equipo mediante pull-requests.Supervivencia 101: manual de etiquetaHaz commits a menudo El diámetro de la potencial cagada es proporcional al tamaño del commit. Tus compañeros te lo agradecerán. Trata de que 1 commit = 1 funcionalidad/historia de usuario/bug/ticketAñade mensajes descriptivos¡Hazlo siempre! No hay excusa. Que la primera línea contenga un resumen del commit. Que el resto de líneas sean el detalle. Si usas Subversion y Trac añade un link al ticket que resuelves y para que en el Trac salga un enlace al commit.Si usas GitHub aprovecha para meter MarkDown y enlaza al issue relacionado con elcommit.Si usas historias de usuario mete una referencia al código de la historia que resuelves.Piensa en otras maneras de mejorar los mensajes de commit y ponlas en práctica.Ten en cuenta que, con toda probabilidad, tus compañeros son unos psicópatas y quesaben dónde vives o, peor aún, los bares que frecuentas.
    • Rescepto a los commits ajenos No pises los commits de los demás. Evita hacer commits de ficheros que solo consistan en cambios de indentación o líneas vacías. A no ser que pongan las llaves en la línea siguiente. Si es así, tenéis mi permiso para arrasar. Evita cambios en ficheros debidos a distintos encodings.VCS != basurero Usa la definición de ficheros y directorios ignorados de tu VCS. No hagas commit de las carpetas que genera tu IDE para el proyecto. No hagas commit de las carpetas de la papelera de reciclaje o los _DS_STORE Convén con tus compañeros la estructura de directorios del proyecto y respétalaBlame before you claim Ante cualquier posible afrenta, usa el comando blame (o similar) de tu VCS para ver quién ha sido el malhechor y cuales eran sus verdaderas intenciones. En el mejor de los casos, estaban corrigiendo una cagada tuya. En el peor, tendrás pruebas irrefutables.Resolución de conflictos Si las opciones de tu VCS no son suficientes o no se te da bien el comando de línea, usa alguna herramienta gráfica como Meld para aplicar los cambios a mano. Eclipse incluye un editor de conflictos bastante majo y SmartSVN también. ¿Git tiene alguna?Por último: usa el comando de línea Adquirir expertise con la shell es algo que revierte en muchas ventajas, no solo para manejar un VCS. Los clientes gráficos suelen ser pesados y solo pueden aportar alguna ventaja en operaciones complejas de verdad. El comando de línea, al contrario, es todo lo rápido que puede llegar a ser y los interfaces de usuario suelen estar muy bien pensadas para sortear el handicap del “modo texto”. Además, podrás fardar ante propios y ajenos con tu shell kungfu.
    • Centralizado y distribuidoDistribuido es cuando los participantes hacen checkin y checkout entre ellos. ¿El ejemplomás conocido? GitCentralizado es cuando los participantes hacen checkin y checkout de un repositoriocentral. ¿El ejemplo más conocido? Git¿Cuál es la diferencia? Los del centralizado no tienen más remedio.Muchos estaréis usando Git como si de un VCS centralizado se tratara. ¿Usáis remotesdistintos que origin?En el fondo, no importa demasiado si es centralizado o remoto. Mi percepción después de6 años gestionando servidores Subversion y 1 con Git es que montar un Subversion estáchupado y que montar un Git no compensa existiendo servicios como GitHub.Si alguien necesita instrucciones o ayuda para montar cualquiera de estos dos VCS lepuedo echar una mano o, al menos, ponerle en el buen camino.
    • Caso de uso: desarrollamos un Wordpress para unclienteSituaciónTenemos un que desarrollar y mantener un site con Wordpress. Además, tenemos queañadir una serie de plugins y un tema que hemos desarrollado nosotros mismos.PlanteamientoCreamos un repo para cada plugin de nuestra cosecha y para el tema que vamos aimplantar.Creamos un repo para el Wordpress que vamos a entregarRepo: PluginContiene un único directorio tal y como se llamará cuando lo pongamos en la carpeta /wp-content/plugins del Wordpress. Por ejemplo “cocotero_delux”. La estructura de directoriosbásica va a contener los siguientes elementos:cocotero_delux/ _sql/ README.mdEn el fichero Readme.md guadaremos un registro de los cambios que le vamos haciendoa las distintas releases y en el directorio sql deberíamos guardar un fichero schema.sql enel que iríamos almacenando la estructura de datos completa de nuestro plugin. Tambiénpodríamos almacenar un fixtures.sql en el caso de que quisiéramos que nuestro plugintuviera algo de información de partida en dicha estructura y por cada release que noscambiara la estructura tendríamos un par de ficheros con alters para realizar el upgrade yel downgrade sobre la base de datos de producción.Repo: ThemeAl igual que con los plugins, contiene un único directorio donde ponemos los ficheros ydirectorios de nuestro temaRepo: Blog de nuestro clienteLo creamos y copiamos los ficheros de Wordpress en él. Hacemos commit y añadimosnuestros plugins y nuestro tema como submódulos de Git con el comando git-remote.En este caso no vamos a tener un directorio para los sql ya que es Wordpress quien seencarga de los upgrades de base de datos.De cara a las puestas en producción o las actualizaciones automágicas de Wordpress,automatizaremos mediante un script la generación de un backup completo (¿idea para unplugin?)