/**

@file
@page flujo_trabajo Flujo de trabajo 

A continuación se explica la forma de trabajar habitual del equipo de
desarrollo de IntegralCES y los recursos que el equipo utiliza.

### Comunicación

Disponemos y utilizamos los siguientes canales de comunicación:

* **Canal #integralces** en Freenode, servidor de IRC. Éste es el canal más immediato y más informal, entra y prueba suerte.

* **Lista de correo**. `integralces@llistes.cooperativa.cat` Lista de distribución dónde se comenta y coordina el desarrollo del proyecto, principalmente a nivel de desarrollo pero también a nivel de comunicación, etc. La lista es pública y te puedes inscribir en http://llistes.cooperativa.cat:8081/mailman/subscribe/integralces. El idioma habitual de la lista es catalan y español, aunque si escribes en inglés también responderemos.

* **Issue queue de drupal.org**. Utilizamos la lista de _issues_ de drupal.org para mantener organizadas las tareas pendientes, quien es responsable de efectuarlas, etc. Este contenido es en inglés. Hay listas separada para los módulos (https://drupal.org/project/issues/ices) y para el tema (https://drupal.org/project/issues/1866046). Cualquier desarrollo mínimamente relevante tiene que tener su _issue_ associada.

### Flujo de desarrollo

Por flujo de desarrollo entendemos los pasos que seguimos desde que decidimos
cambiar el código del proyeto para realizar alguna mejora hasta que este
código está publicdo y integrado en el proyecto. El flujo está basado en la
recomendación de drupal.org que se encuentra en
https://drupal.org/node/711070.

Tenemos las siguientes consideraciones:

  * La única rama general y común con la que trabajaremos será la rama con nombre **7.x-1.x**. Esta es la rama que podemos llamar de desarrollo. La rama master está vacía. No hay rama estable (serán tags a esta rama).
  * Cuando queremos tocar código, hacemos una rama nueva para aquella _issue_ siguiendo el convenio de que el nombre de la rama es `[issue-number]-[short description]`. Por ejemplo: 
    
    $git branch 1916476-migration
    $git checkout 1916476-migration  
    

  * Hasta que aquella issue no esté completamente acabada y revisada o lo que se necesite para darla por buena no haremos el _merge_ a la rama principal **7.x-1.x**. En particular, pueden haber funcionalidades importantes que estén mucho tiempo separadas de la rama principal. En el caso de arreglar bugs o hacer pequeñas cosas, hacemos directamente el merge a la rama principal. Nos tenemos que asegurar que la rama principal siempre pasa los test automáticos. Esto no significa que tengamos que trabajar en local: podemos subir las ramas que sean necesarias al repositorio de drupal.org. 
  * Cuando queramos lanzar una versión estable, haremos un tag en la rama 7.x-1.x. Así pues, no es necesario mantener dos líneas, la estable y la de desarrollo. 

### Ejemplo de flujo de desarrollo

Recogemos una incidencia (issue) del proyecto o lo creamos si es necesario.
https://drupal.org/project/issues/ices

Creamos una rama con la referencia de la incidencia:

    
    $git branch 2207369-Notice_messages
    $git checkout 2207369-Notice_messages
    

Hacemos el desarrollo, corregimos el bug, etc.

Pasamos los test. Desde la web:

`/#.overlay=admin/config/development/testing`

o desde drush:

    
    $drush test-run --xml CES
    

Generando archivo xml con los detalles del test en testsuite...xml

Si todo va bien fusionamos rama con principal:

    
    
    $git fetch origin                    # Actualizamos local con remoto
    $git rebase origin/7.x-1.x           # Combinar cambios de 7.x-1.x a la rama actual
    $git checkout 7.x-1.x                # Nos colocamos en la rama principal
    $git pull                            # Combinar local con remoto
    $git rebase 2207369-Notice_messagesi # Combinar rama con los cambios a 7.x-1.x
    

Subimos cambios al servidor:

    
    $git push
    

Cerramos incidencia (issue) en drupal.org

*/
