Entradas en la categoría “Calidad”

Desarrollo con Git basado en branches

26 de enero, 2011 - por | | Calidad, Desarrollo, Linux, Proyectos

Cuando trabajas con código y manejas un sistema de control de versiones para gestionar los cambios del primero, pronto te ves tomando decisiones que tienen que ver en definitiva con cómo se va a trabajar a diario. Ésto es especialmente importante en entornos de trabajo con numerosos desarrolladores, y cobra aún más importancia cuando se tiene que manejar un ciclo de vida completo (desde la fase de desarrollo hasta la fase de release/producción).

En Grosshat utilizamos Git de una forma bastante flexible, con la intención de que nos sirva para distintos proyectos, pues hemos ido aprendiendo que realmente un proyecto siempre son varios en cuanto que lo dejas evolucionar un poco. :)

Nuestras dos reglas básicas: 1) no desarrollar en la branch master; 2) no utilizar la branch master más que para mover cambios entre el repositorio externo y las branches locales. En definitiva, mantener la branch master limpia con el fin de evitar futuros conflictos y disgustos.

¿Cómo funcionamos con esas dos reglas? Veamos un ejemplo. Imaginemos que vamos a añadir una función a un repositorio de código basado en WordPress. Esta función va a consistir en evaluar si una página es subpágina de otra (algo muy útil cuando le das uso a WordPress en plan CMS). Utilizaremos el fichero de funciones globales de WordPress para que así podamos utilizarla cómodamente desde cualquiera de los templates. Al lío.

Empezamos desde 0


    $ git checkout master
    $ git pull

Creamos una nueva branch sobre la que trabajar


    $ git checkout -b function_check_child_page

Hacemos todos los commits que hagan falta

En este caso vamos a suponer que tiramos todo el código necesario para la función (no más de 10 líneas) en un mismo commit. Posteriores commits podrían incluir mejoras, limpiezas de código, etc.


    $ git commit -am "Global function is_subpage: returns boolean value
    for checkin if the current page is child of a parent page"

Hacemos merge con la branch master

Podemos empezar por revisar todas las diferencias antes de hacer el merge, de ese modo tenemos otra oportunidad de revisar posibles errores, marcas de debug, etc.


    $ git diff master

Si todo está como queremos, vamos con el merge.


    $ git checkout master
    $ git pull
    $ git checkout function_check_child_page
    $ git rebase master

Esta forma de hacer el merge, mediante rebase, permite mantener una historia continua de cambios.

Push

Una vez que hemos integrado la branch master con nuestra branch de desarrollo, podemos volver a la primera, obtener la segunda y enviar al repositorio externo.


    $ git checkout master
    $ git merge function_check_child_page
    $ git push

Limpiamos la branch


    $ git branch -d function_check_child_page

Todo este flujo de trabajo respeta las 2 reglas que mencionamos al principio, pero también supone algunas otras cosas como las siguientes:

  • pequeño mejor que grande (para commits y para merges)
  • muchos mejor que pocos (para merges)
  • pronto mejor que tarde (para merges)

La principal pega que se le suele plantear a este procedimiento es que da un poco de pereza, y que en entornos pequeños puede resultar algo barroco. Sin duda requiere maś pasos que trabajar directamente sobre la branch master, pero siempre se puede adoptar cuando se juzgue necesario -entran nuevos desarrolladores, hay trabajo a distancia, etc.-, y mientras tanto seguir con la master para todo.

Herramientas para la calidad front

20 de agosto, 2009 - por | | Calidad, Frontend

Cuando se dispone de cierta cantidad de código funcionando y estable, es conveniente empezar a pensar en términos de calidad. Del lado front la cosa no es distinta, y existen varias herramientas plenamente funcionales que nos pueden hacer la vida más fácil, al menos para empezar a poner las bases.

Para que todo nos resulte más manejable, es conveniente separar 3 partes del área front:

  • el marcado (html/derivados y css)
  • la interacción (javascript)
  • la disponibilidad (pesos, cabeceras, peticiones)

Para la primera parte existen algunos principios generales que permiten definir una orientación general de cara a la calidad, así como varias herramientas que ayudan a concretar esos principios. De éstas sin duda la que ha llegado a hacerse más popular ha sido la que tiene que ver con la validación del marcado html/xhtml, que se refleja en los conocidos iconos del W3C indicando si el documento ha pasado cierta validación.

Para la segunda parte se han ido asentando, con el tiempo, varias directrices generales, así como diferentes herramientas a nivel de análisis sintáctico, debugging y testing. La popularización de librerías marco, asociadas a plugins para funcionalidades concretas, ha introducido mayores niveles de calidad como punto de partida, pero también ha conducido el desarrollo a un entorno más complejo y, por lo tanto, potencialmente más difícil de mantener.

Por último, de cara a la disponibilidad el creciente uso intensivo de interacción ha llevado progresivamente a una mayor conciencia sobre la importancia de establecer rangos de pesos, tiempos de expiración para las cabeceras, y máximos de peticiones asumibles. Y estas ideas cuentan ya con algunas herramientas que permiten analizarlas y cuantificarlas, haciendo que la optimización sea un objetivo pragmático.

Voy a intentar recorrer esas 3 partes en diferentes entradas con la intención de:

  1. llamar la atención sobre los procesos de calidad en el área front;
  2. ayudar a que se entienda un poco mejor la interrelación entre las 3 partes mencionadas;
  3. recopilar ideas comunes y herramientas frecuentes del trabajo diario;
  4. poner mi granito de arena para que se entienda qué consigue cada proceso de calidad, de forma que no se mezclen ni se asocie burdamente calidad con eliminación completa de problemas.