Developing Frogtek

El blog del Departamento de Tecnología

Etiqueta: bash

Afinando GIT

Después de varios meses trabajando en la migración a GIT, finalmente podemos decir que todo ha salido a pedir de Milhouse. Además nos ha servido para darnos cuenta de que vamos a tener que acostumbrarnos a que el sistema de control de versiones sea una parte fundamental de nuestra metodología de trabajo. Principalmente por el gráfico que aparece a continuación. Está extraído de este gran artículo sobre control de ramas con GIT. De él obtuvimos la inspiración para realizar nuestro sistema de branching, pero no es de esto de lo que queremos hablar…

Más bien queremos contar algunos ajustes que hicimos a la configuración de git para que nos sea más usable.

  1. Crear unos cuantos útiles “alias”:
  2. Lo primero es editar nuestro archivo .gitconfig, añadiendo algunas versiones cortas de los comandos más usados.

    [alias]
            co = checkout
            ci = commit
            st = status
            br = branch
            brancha = branch -a

    Aquí va uno muy útil: mostrar el listado de commits en una línea cada uno y mostrando los autores al principio (todo ello a color):

    hist = log --graph --decorate --pretty=format:'%C(bold blue)%Creset
    %Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr)'
    --abbrev-commit --date=relative

    Los dos siguientes son muy útiles para gestionar los archivos y carpetas marcados como unchanged:

    unchange = update-index --assume-unchanged
    unchanged = !git ls-files -v | grep ^[a-z]

    El primero nos permite marcar un archivo como “assume unchanged”, en caso de que no queramos que tenga control de versiones. El segundo nos muestra qué archivos de nuestro repositorio están marcados de esta forma.

    Crear una nueva branch asociada a una nueva historia de usuario:

    us = "!f() { git checkout -b US$1; }; f"

    Este comando funciona de la siguiente manera. Si tecleamos US 13, nos creará una nueva branch (desde la que estemos en ese momento) con el nombre US13. Muy útil.

    Y para acabar, activar el color para todos los comandos de GIT:

    [color]
            ui = true
  3. Pasarnos a bash y crear más “alias“:
  4. alias go='git checkout'
    alias gp='git pull'
    alias gs='git status'

    Cambié mi terminal para que usara bash como intérprete, ya que me permitía funciones adicionales como la del punto 3. Después añadí unos cuantos alias entrando en el home y editando el archivo .bash_profile

    Hay gente que prefiere utilizar el comando completo, es cuestión de gustos. He añadido git pull y git status porque son algunos de los comandos que más uso en consola.

  5. Mostrar la rama actual en el shell de bash. Esto ya lo vimos en capítulos anteriores.

Y esto es todo. Recordad que lo principal es que cada uno configure sus instrumentos a su voluntad. Al fin y al cabo, se trata de estar a gusto con las herramientas que utilizas.

Bloqueo de SVN en caso de build fallida

Hace poco tuvimos una agradable visita aquí en Frogtek. Una de las muchas aportaciones de Emma fue hacernos replantear nuestro sistema de lanzamiento de builds en Jenkins, pasando de uno más pesado en recursos a otro más eficiente. A raíz de dicho cambio hemos aprovechado y mejorado el procedimiento de bloqueo que tenemos configurado en Jenkins y la forma en la que lo realizamos. Vamos a explicarlo para que nos ayudéis a mejorarlo todavía mas.

En sí, el procedimiento consiste en no permitir commits al servidor SVN si hay una build rota. Excepto al usuario que haya provocado dicha rotura. De esta forma nos aseguramos de varias cosas:

  • No se avanza en el desarrollo si el código subido no es de una calidad mínima, pasa los test y se construye correctamente.
  • Los desarrolladores se hacen responsables de los problemas que ellos han generado y los arreglan.
  • Cuando existe un problema en una parte del proyecto, y dicho problema tarda en resolverse, todo el equipo se preocupa por saber qué pasa y ayudar a resolverlo para poder seguir avanzando.

Seguir leyendo

Automatización

Gracias a la costumbre en Frogtek de fomentar la formación a través de la compra libros, he podido leer “The Pragmatic Programmer” magnífico libro recomendable para cualquier programdor con ganas de mejorar.

En el mismo dan un par de consejos que me han parecido muy interesantes y que aparte de estar muy ligados, creo que seguimos bastante aquí en Frogtek. El primero:

Use the power of command shells

Indica que debemos usar los comandos shell como herramientas para facilitar nuestro trabajo. Por ejemplo en mi caso utilizo scripts shell para eliminar nuestro software del emulador y cargar la última versión de nuestro servidor, consiguiendo con un solo comando algo que si hiciera a través de la interfaz me llevaría el doble o el triple de tiempo. El segundo:

Don’t use manual procedures

Nos dice que no hagamos de forma manual nada que pueda hacer un script o programa. Será más propenso a errores y dará más quebraderos de cabeza a la hora de ser repetido en diferentes entornos. En este caso el ejemplo es nuestro proceso de paso a producción a través de Hudson, la compilación de todos los proyectos y paso de test, etc.

En resumidas cuentas automatización, todo lo que sea susceptible de ser automático debería serlo. Será más rápido, más confiable y menos propenso a errores. No tengas miedo al coste de configuración, si lo vas ha hacer más de dos veces, vale la pena automatizar. Vamos o eso nos dice la experiencia en Frogtek …