ARQUITECTURA DEDESARROLLO EN

PROYECTOS DRUPALDRUPALCAMP SPAIN 2015

Por / Ramon Vilar @rvilar

SOBRE MI

Ramon Vilar@rvilar

http://ymbra.com

ÍNDICE1. El proceso de desarrollo ideal2. Buenas prácticas iniciales3. Flujos de desarrollo en las distintas fases de un proyecto4. El desarrollo5. El testing6. Integración contínua y entornos7. Otras buenas prácticas

EL PROCESO DE DESARROLLO IDEAL

AS A DEVELOPER, I WOULD LIKE...Como equipo de desarrollo, si hiciésemos una carta a los

reyes, nos gustaría:

Código versionadoDespliegues automatizadosPruebas automatizadasFácil de probar manualmenteQue todo el equipo tenga conocimiento de todo el códigoFácilmente mantenible

Y todo de forma transparente a nosotros

ESTO ES UNA UTOPÍA?Puede parecerlo, pero no! Nosotros lo hacemos

Lo primero, y lo más importante de todo, es:

Preparar al equipo para el cambioTener complicidad y ganas por parte de todos losimplicadosNo tener prisa en la adopciónIr paso a paso

BUENAS PRÁCTICAS INICIALES

CONOCIMIENTOS NECESARIOS PARASEGUIR

Conocemos y usamos GitConocemos y usamos DrushConocemos y usamos Featuresy ...

CUÁL ES NUESTRA FINALIDADNuestro proyecto debe poderse instalar de un entorno aotro sin requerir ninguna tarea manualEsto implica trabajar siempre con códigoToda configuración y funcionalidad debe residir en elcódigo y no en base de datos (features y código deinstalación)

ESTRUCTURA DE DIRECTORIOSSeguimos una mínima estuctura para nuestros módulos y

temas:

/contrib/custom

Y tenemos nuestras features dentro de un directorio/features. Este también lo podemos estructurar a su vez:

/content_types/general/entity_types

ENCAPSULAR EL DESARROLLODebemos pensar en una forma de encapsular nuestrodesarrollo y hacer fácil el flujoLos perfiles de instalación son una herramienta Drupalnacida para elloInstalar el proyecto es tan fácil como instalar el perfil

MAKEFILEDocumentación rápida de los módulos, temas y libreríasusadasIdentificación rápida de las versiones usadas y los patchesaplicadosEvita tener código duplicado en nuestro repositorioAsegura a nuestro cliente que no hemos modificadoningún contrib

FLUJOS DE DESARROLLO EN LASDISTINTAS FASES DE UN PROYECTO

FASES DE UN PROYECTODesarrollo sin intervención de agentes externos: flujo deinstalaciónDesarrollo mientras el cliente interactua con laaplicación: flujo de actualización

FLUJO DE INSTALACIÓNSi sólo los desarrolladores estan trabajando en elproyecto, entonces podemos borrar y manipular la basede datos sin problemasPara asegurarnos que toda la configuración está encódigo, debemos instalar nuestra aplicación a menudoDesplegar nuestra aplicación en un nuevo entorno es algotan sencillo cómo:

drush site-install <profile>

FLUJO DE ACTUALIZACIÓNEn cuanto el cliente empieza a añadir contenido al sitio,ya no podemos seguir con un flujo de instalación(machacaríamos la base de datos)Debemos pasar a un flujo de actualización usandofeatures como hasta ahora pero pasando a usarhook_update_N() cuando se requieraPara hacer nuevos despliegues, hay que actualizarla, ypor tanto hacer:

drush updatedb -y

drush features-revert-all -y

EL DESARROLLO

DIVIDE Y VENCERÁSTrabajar con metodologías ágiles es un winDividimos cada história de usuario en tareasUna tarea equivale a un commit (cuanto más unitario,más fácil de revisar)

QUÉ EXPORTAR Y QUE NODebemos ir con cuidado con aquello que exportamosSólo debemos exportar aquellas cosas que sonprópiamente configuración que no dependa delmomento o del entorno (por eso nace State API en Drupal8)Especial cuidado con las variables: debemos serconscientes de cuando usar strongarm o cuando hacervariable_set en nuestra función de instalación

QUÉ EXPORTARCamposTipos de contenidoTaxonomíasMenúsVistasPanels (siempre y cuando no puedan ser modificados porel editor)Variables (sólo las de configuración)...

QUÉ NO EXPORTAREnlaces de menúRolesPermisosVariables (aquellas que dependan del entorno o seanmodificables por el editor)Contenido (nodos, términos, etc.)

CUIDADO AL CREAR VISTASEn D7, si creamos vistas con algunos filtros estos pasarana depender de identificadores en vez de nombresmáquinaFiltrar por término: se exporta el tid. Filtra mejor pornombre o por machine_nameFiltro o control de acceso por rol: se exporta el rid. Usarel nombre para el filtro o un permiso especial para elcontrol de acceso

ROLES Y PERMISOSSi exportamos los permisos y más tarde, el cliente losmodifica, pasaremos a tener nuestras featuressobreescritasLo mejor es exportar los roles y luego crear los permisosen la función de instalación de nuestro perfil

TRADUCCIONES DE CADENASDebemos usar siempre cadenas en inglésLa suite i18n permite traducir y exportar fácilmente lastraduccionesTendremos un directorio /translations en nuestroperfil de instalación con las traducciones de las cadenasnecesariasNuestro proceso de instalación importará todas lastraducciones una vez instalados todos los módulos yfeatures

EL TESTING

FACILITAR LAS PRUEBASEn un entorno ágil, cómo desarrolladores, debemosfacilitar un entorno de pruebas a nuestro PO, que a suvez, deberá poder hacer demos a clienteSi en nuestro flujo de desarrollo instalamos en cadadespliegue, cómo podemos proveer de contenido deforma fácil para que se puedan hacer las pruebas?Para ello nace migrate_default_content

MIGRATE_DEFAULT_CONTENTMódulo basado en Migrate para crear contenido depruebaAPI sencilla para crear migraciones de nuevos tipos decontenido, términos, menús, etc.Importar y eliminar este contenido por defecto es tan fácilcomo:

drush mi --group=migrate_default_content

drush mr --group=migrate_default_content

CONTENIDO NO POR DEFECTOPor requisito de algunos proyectos hay contenido quedebe proveerse con la aplicaciónEjemplos de ello pueden ser elementos de menú,términos, alguna página, etc.La creación de estos contenidos debe estar programadoen nuestra función de instalación del perfil

INTEGRACIÓN CONTÍNUA YENTORNOS

INTEGRACIÓN CONTÍNUAEl equipo debe de trabajar de forma que no sepa que haymás entornosSe debe montar un sistema transparente al equipo quehaga el trabajo de integración y que sólo informe delresultado

ENTORNOSDesarrollo

Este entorno se lanza a cada push al respositorio.Integra el código, pasa los tests e informa si todo ha idobien

TestUna vez aprobados los commits, y cada ciertas horas,se integra todo el código para que pueda ser probadopor el PO

StageEste entorno es el accesible por el cliente. Se construyebajo demanda

HERRAMIENTASCapistrano

Es el software que usamos para crear las tareas dedespliegue basadas en su . Desarrollado en Ruby ymuy fácil de usar

JenkinsLa usamos para lanzar las builds en los distintiosentornos. Hace llamadas a capistrano e informa anuestras herramientas del resultado

IRCSí IRC. Lo usamos para tener un canal todo el equipo yes dónde las builds lanzan los resultados al finalizarcada una de ellas. Muy útil para no perder el foco.

flow

LARGA VIDA A LAS BUILDSAl lanzar nuestras tareas de construcción en cadaentorno, podemos aprovechar para lanzar otras cosasNosotros lanzamos tests, sacamos estadísticas sobrecoding standards, revisamos la calidad del código, etc.Lo hace una máquina, así que aprovechad para darletrabajoPero no nos pasemos que una build larga puede llegar aser un cuello de botella

OTRAS BUENAS PRÁCTICAS

TRAZABILIDADDesde una tarea debo tener enlazado el commit que laresuelve para futuras revisionesEso es fácil usando algunas herramientas, perosobretodo, documentando bienPor ejemplo, en nuestro mensaje de commit, debemosincluir el identificador de la tareaRedmine y jenkins tienen plugins para integrarse entre síy con nuestro repositorio y facilitar la nevegación entreellos

REVISIÓN DE CÓDIGOIncluir revisión de código es una de las mejores prácticasque hemos añadido en nuestro procesoMejora la calidad del código, el control de errores,...Ayuda a mejorar como desarrollador y a aprender muchode todosFacilita la propiedad del código por parte de todo elequipo, no sólo por parte de la persona que lo desarrolla

AGILEAgile, agile y agile; no hay másAunque no se pueda usar agile con el cliente, usarlointernamente facilita mucho el trabajo con el equipo dedesarrolloDefinir cada una de las funcionalidades, dividirlas, perosobretodo discutirlas, hace que se entienda mucho más elproyecto y se puedan prevenir errores

FUTUROCrear un entorno por cada commitMáquinas virtualesAplicar agile en el proceso de diseño... somos mentes inquietas y nunca paramos de pensar encomo mejorar

CONCLUSIONESInterpretar esto como un recetario, no como una normaLo mejor es adoptar poco a pocoEmpezar por cambiar la forma de desarrollo, luegoempezar con revisión de código y dejar para el final laspeleas con la integración contínua y los entornos

DUDAS?