 |
|
A continuación se explica la forma de trabajar habitual del equipo de desarrollo de IntegralCES y los recursos que el equipo utiliza.
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.
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.
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
1.8.8