Android conoce a Jenkins

La integración continua es una técnica software en la cual se integran los cambios muy frecuentemente (generalmente horas), tratando de detectar errores lo mas pronto posible, automatizando la compilación y la ejecución de las pruebas.

Para poder desarrollar nuestra aplicación en un entorno de integración continua haremos uso de

• Ant que se encargara de la automatización 
• Jenkins sera el encargado de la integración continua.
• En este caso Git y Bitbucket como control de versiones

Como punto de partida tendremos un proyecto Android con su respectivo proyecto de pruebas, para mas detalles consultar la documentación.

Configuración de Ant

Primero que nada necesitamos indicar que nuestro proyecto va a ser compilado con Ant y donde queremos despegarlo, para ello abrimos el terminal, vamos a la carpeta donde se encuentra nuestro proyecto y ejecutamos:



Como resultado se creara el archivo build.xml 

Jenkins

Hay dos posibles maneras de instalar Jenkins: desde un repositorio o desplegando un war en apache, las instrucciones las podemos encontrar en la documentación.

Una vez instalado Jenkins  abrimos el navegador y entramos a localhost:8080 si vemos la pagina inicial de Jenkins es que todo esta bien, sino tendremos que iniciar el servicio.

Ahora si, ya tenemos a Jenkins ejecutándose y el siguiente paso a dar es añadir el soporte de Git (o el repositorio escogido), lo cual puede hacer fácilmente instalando el plugin Jenkins Git plugin.

Creación de la tarea

Jenkins se encarga de ejecutar tareas, por lo tanto todo lo que queramos hacer tendrá que ser definido como tal. En el panel izquierdo tendremos la opción de crear una tarea, y a continuación nos mostrara una serie de opciones. Para nuestro proyecto Android tendremos que elegir Free-style Project. Ya en la pantalla de creación de la tarea tendremos que configurar lo que queremos hacer, en este caso compilar e instalar la aplicación.

Repositorio

Esta parte no tiene mucho misterio, simplemente es especificar los datos de nuestro repositorio.

• URL: de tipo git@bitbucket.org:usuario/proyecto.git
• Browser:  bitbucketweb
• Browser URL: de la forma https://bitbucket.org/usuario/proyecto 

Ignoren los posibles errores que surjan al indicar la web de repositorio, mas adelante se explicara como solucionarlo.

Planificación

Jenkins tendrá que saber cuando se compilara la aplicación, para integración continua lo más adecuado es que se haga ni bien se detecta un cambio en el código, es decir cada vez que se haga un commit. Por lo que en Build Triggers tendremos que marcar Poll SCM, para que Jenkins consulte el repositorio cada cierto tiempo en busca de cambios, la frecuencia de la consulta se define siguiendo el formato de cron. Por ejemplo "15 * * * *" comprobara el repositorio pasados los 15 minutos de cada hora, es decir 12:15, 13:15, 14:15, etc.

Bitbucket brinda un servicio en el cual es el propio Bitbucket el que notifica a Jenkins de que hubo algún cambio en el código, pero para esto se necesita una url publica para Jenkins.

Compilación e Instalación

A esta altura Jenkins ya sabe de donde obtener el código y cada cuanto comprobar si hay algún cambio, nos faltaría definir como compilar y que hacer después de compilar. La compilación se hará mediante Ant para ello añadiremos dos pasos clean debug para limpiar el proyecto y compilar en modo debug; y debug install para instalar el .apk generado.

Para poder instalar la aplicación tendremos dos opciones usar un dispositivo real o el emulador, en este caso usaremos el emulador. Para ello dependeremos de Android Emulator Plugin podemos hacer el propio plugin cree el emulador en tiempo de ejecución o definirlo nosotros mismo. Si decidimos crearlo a mano en el documento Managing AVDs from the Command line esta muy bien explicado.

Dentro de las opciones avanzadas de compilación encontraremos un campo llamado Properties, en el cual tendremos que indicar donde se encuentra el SDK de Android y la plataforma sobre la que trabajaremos.



Si queremos conservar los .apk generados en cada compilación, tendremos que ir a la sección Post-build Actions, la opción que nos interesa es Archive the artifacts. Especificando la ruta donde queremos guardarlo, por ejemplo para guardarlo en la ruta asignada por defecto y agregando "-debug" al final del nombre del fichero seria: **/*-debug.apk

Ya tenemos la tarea configurada, pero si compilamos ahora mismo fallara. Viendo el log generado veremos que se debe a que no tenemos los permisos necesarios para acceder al repositorio, obviamente si es un repositorio publico esto no pasara.

Dando permisos a Jenkins

Una vez creada la tarea realizar la configuración necesaria para que el usuario Jenkins (desde le cual se ejecuta la aplicación) tenga los permisos necesarios para acceder al repositorio. No sera necesario crear un nuevo usuario en Bitbucket exclusivo para Jenkins ya que se puede configurar una clave ssh otorgando acceso de solo lectura mediante una Deployment Key. El primero paso sera iniciar sesión con el usuario Jenkins, pero por defecto viene desactivado así que tendremos que habilitar el inicio de sesión modificando el fichero /etc/passwd

Una vez tengamos ubicada la linea del usuario Jenkins, cambiaremos /bin/false por /bin/bash para poder iniciar sesión con dicho usuario.



Por ultimo queda asegurarnos que Jenkins tiene permisos para acceder a las herramientas proporcionadas por el SDK de Android, es decir que tiene permisos de lectura en Android-SDK/tools/

Ya terminamos con la configuración en el lado del cliente, solo queda agregar la clave creada en Bitbucket para eso accedemos al panel de administración de nuestro proyecto en Bitbucket creamos una Deploymente key nueva y pegamos el contenido del fichero /var/lib/jenkins/.ssh/id_rsa.pub

Si el repositorio no esta en la lista de host conocidos (.ssh/known_hosts) debemos clonar el repositorio manualmente en una carpeta temporal y cuando se nos pregunte si queremos añadirlo a la lista de host conocidos tendremos que decir que si, ya que Jenkins no es capaz de gestionar dicho escenario.

Y por hoy eso es todo, en el próximo articulo veremos como crear pruebas automatizadas con Jenkins.

Sincronizando Android con la Nube

Viendo la presentación Developing Android REST client applications se habla dos errores muy grandes que todo principiante comete al implementar servicios web con Android:

• ejecutar el servicio web en el hilo principal
• alojar los recursos obtenidos en la memoria en lugar de en almacenamiento permanente

La parte negativa del primer punto es que las transferencias de datos pueden llevar bastante tiempo derivando en una UI lenta y en ocasiones que esta deje de responder. Por otro lado el no persistir los datos se pude pensar que hará nuestra aplicación mas rápida. Pero ¿que pasa si el S.O. decide expulsar de memoria a nuestra aplicación para darle lugar a otra? Que tendremos que volver a pedir los datos al servidor conllevando mas gasto de CPU por lo tanto de batería y el esperar tiempo necesario para volver a transferir el recurso.

En la charla se proponen tres patrones de diseño diferentes:

• Service
• Content Provider
• Content Provider y SyncAdapter

Cada uno de las diseños se pueden ver las transparencias de la charla.

En este caso veamos como se implementa el ultimo de ellos. En los dos primeros patrones tenemos que encargarnos manualmente del estado de los recursos y de las transacciones, pero en el ultimo caso todo esto se hace automáticamente a través de SyncAdapter. SyncAdapter sera el encargado de gestionar el estado de los recursos y actualizarlos cuando sea conveniente, este es el patrón usado por Gmal, Facebook, LastFM, por citar algunos.

Imagen tomada de las transparencias de la presentación.

Como vemos la estructura se divide en cinco partes. La capa mas alta se encarga de mostrar los datos al usuario. La actividad es una actividad común y corriente, que interactúa con el usuario guardando pidiéndole o mostrando los datos que nos interesen. El CursorAdaptar es quien refresca los datos que están en el ContentProvider con la interfaz, mostrando siempre los datos mas recientes. Los datos son almacenados en un ContentProvider, si no quieren usar un content provider para guardar los datos deberán engañar al sistema, creando uno que no haga nada, en StackOverflow se explica mas o menos como hacerlo.

ContentProvider

Como crear un ContentProvider ya se explico en un post anterior así que como es de suponer no se volverá a explicar. Es más, dicho post fue pensado para usarlo como base para este.

Account Authenticator
Para poder sincronizar nuestra aplicación con un servidor primero debemos agregar una cuenta al sistema.  Para ello que mejor que echarle un vistazo a los ejemplos de Google, en concreto a este. El ejemplo también se puede encontrar dentro del SDK que tenemos instalado, pero no es exactamente igual a la versión online, traten de usar la versión online que es la mas actual.

Dentro del paquete authenticator se implementa la gestión de cuentas haciendo uso de tres clases:

• Authenticator: implementa la gestión de la cuenta.
• AuthenticationService: define un servicio que instancia a Authenticator para realizar las tareas en el background.
• AuthenticatorActivity: la actividad mostrada para pedir las claves al usuario.

Para tener todo la gestión de cuentas haremos uso del viejo y querido copy & paste, en un mundo ideal funcionaria sin ninguna modificación pero es demasiado bueno para ser verdad asi que hay que hacer algunas modificaciones. En el ejemplo usa otra dos clases, Constants y NetworkUtilities. Si quieren también las pueden copiar, sino:

• definir las dos constantes definidas en Constants en la clase Authenticator
• reemplazar Networkutilities por la clase donde este implementado el acceso al servidor, el método authenticate es el que nos interesa, ya que es con el que se validan las credenciales del usuario.

Si usaron AuthenticatorActivity en lugar de una actividad propia, hay que copiar el fichero xml/authenticator.xml, el contenido de values/strings.xml, y añadir al Manifest la definición del servicio y de la actividad.
La variable android:name indica la ruta de la clase AuthenticatorService.


Con eso si instalamos nuestra aplicación al ir a Settings > Accounts and sync > Add account saldrá nuestro el tipo de cuenta que acabamos de definir.

Tengan muchísimo cuidado al declarar el servicio ya que al estar trabajando con XML es muy fácil meter la pata, en mi caso cuando se creaba la cuenta se iniciaba la sesión sin problema pero mas tarde al volver a intentarlo no se iniciaba la sesión porque no estaba guardando el password de usuario. Todo eso por tener mal los ficheros XML.


SyncAdapter
Con lo anterior ya esta la gestión de la cuenta ahora viene lo que realmente nos interesa como sincronizar nuestro teléfono con un servidor. Nuevamente tendremos que crear un servicio para que se ejecute ocultamente sin molestar a nadie. Para eso se precisan dos clases SyncAdapter y SyncService.

SyncAdapter define las acciones a realizar cuando se lleva a cabo la sincronizacion, en este caso llama al metodo syncLog de la clase VideoLogger.

syncLog implementa lo que realmente se hace al sincronizar, esto puede ir dentro de syncAdapter, pero pero claridad y facilidad de mantenimiento decididí gestionarlo aparte. Como veran primero obtiene todos los objetos PendingMovie que hay almacenados y luego va iterando sobre ellos y subiendolos al servidor, en este caso en concreto el metodo upload, borrara el objeto del ContentProvider una vez recibido el ACK del servidor.


Y SyncService instancia a SyncAdapter comom un singleton y lo vincula al servicio.

Finalmente hay que crear un XML con la definición del syncadapter y definir el servicio en el Manifest.


res/xml/syncadapter.xml

Y eso es todo.

Scrum II: Scrum Team

Imagen obtenida de openclipart

Luego de haber comentado un poco la teoría en la que se basa Scrum, es posible hablar de quienes son los responsables de llevarlo a cabo. La puesta en practica se lleva a cabo en equipos denominados Scrum Team, cada equipo esta formado por Product Owner, Development Team (o equipo de desarrollo) y Scrum Master. Estos equipos son completamente autónomos, multidisciplinarios y auto-organizados. Con este modelo se pretende tener flexibilidad, creatividad y productividad. Entremos un poco en los detalles de cada perfil.

Product Owner

El Product Owner es quien gestiona el valor del producto, es decir quien decide que es lo que hay que hacer, se podría comparar con la figura tradicional del Jefe de proyecto. Product Owner hay uno y solo uno, ni dos, ni tres; únicamente una persona determinada es quien puede cumplir este rol. 

Para realizar la tarea con éxito, toda la organización debe respetar las decisiones tomadas por el Product Owner. Nada de el jefe del jefe del jefe dice A o B, el que quiera cambiar algo que hable con el Product owner, tan sencillo como eso. Si lo convencen bien, sino mala suerte, si esta en ese puesto sabrá lo que esta haciendo.

Las tareas que tiene a cargo son:

• Definir los elementos del Product Backlog
• Ordenar el Product Backlog para lograr los objetivos establecidos
• Asegurarse que el equipo de desarrollo cumple con su trabajo
• Asegurarse que el Product Backlog es visible, transparente y comprensible para todos
• Asegurarse que el Product Backlog muestra realmente el trabajo planificado
• Asegurarse que el equipo entiende un elemento del Product Backlog al nivel necesario

Development Team

Los integrantes del equipo de desarrollo serán los que llevaran a cabo las tareas para poder implementar el incremento del producto. Para poder realizar el desarrollo completo de un incremente logicamente tendrán que ser grupos multi-disciplinarios. La organización del grupo depende de si mismos y las relaciones internas son de igual a igual, no hay diferencias de roles, todos son considerados como desarrollador. A pesar de que cada persona tenga un conjunto de habilidades especifico, la regla anterior tiene que cumplirse por lo que cada uno tiene que ser capaz de saber cuales son sus puntos fuertes y sus puntos débiles. 

El tamaño de los equipos es algo que siempre se discute en cualquier metodología, Scrum particularmente no define una cifra concreta sino que determina dos rangos, uno inferior y otro superior. No es aconsejable que el equipo tenga menos de tres personas, aunque a primera vista parezca algo bueno ya que se reduce el tiempo de comunicación aumentando un poquito la productividad, es muy probable que la productividad ganada se desperdicie cuando el equipo se encuentre con un problema que no es el mas adecuado para sus habilidades. Y en el caso contrario equipos de de más de nueve personas requiere mucha comunicación llevando a una reducción de la productividad.

Una posible combinación para un equipo podría tener los siguientes roles: ingeniero de software, arquitecto, analista, programador, tester y diseñador de UI.

Scrum Master
El Scrum Master es el director de la orquesta, tiene que ser capaz de sincronizarse a la perfeccion con el equipo tratando de eliminar todos los posibles obstaculos que aparezcan por el camino. Gran parte de su tarea es estar pendiente de que el equipo de desarrollo siga las pautas de Scrum (teoria, practicas y reglas). Otra de sus funcionalidades es de actuar como un enlace entre el equipo y el mundo exterior, decidiendo cuando el equipo puede o no interactuar con alguien del exterior.
Brinda tres tipos de servicio:

• Servicios para el Product Owner
• Proveer de técnicas eficaces para la gestión del Product Backlog
• Comunicar el objetivo del Product Backlog al equipo de desarrollo
• Enseñar a todo el equipo como diseñar elementos del Product Backlog
• Servicios para el Equipo de desarrollo
• Ayudar con la organización del equipo
• Ayudar con la creación de un producto de gran valor
• Eliminación de obstáculos
• Servicios a la organización
• Guiar a la organización a adoptar Scrum como metodología
• Generar cambios que produzcan un aumento en la productividad de equipo
• Trabajar coordinadamente con otros Scum Masters para aumenta la eficacia de Scrum en la organización.
• Planificar la implementación de Scrum con la organización

Los servicios que brinda un Scrum Master como puede verse son muchos y muy variados, sin duda que es un perfil muy flexible. Es una pieza clave para el desarrollo de Scrum, al principio sera un guía, un instructor enseñando al equipo con mucha frecuencia, luego que el equipo adquiera experiencia tendrá que enfocarse en la motivación, para que esta no decaiga.

Para la próxima eventos y artifactos.

Android: Creación de un ContentProvider

Un ContentProvider es una interfaz que nos brinda Android para acceder a una base de datos que se encuentre en nuestro teléfono. Y hacer que las aplicaciones puedan compartir información fácilmente.

Los pasos a seguir para la implementación son los siguientes:

1. Extender la clase ContentProvider
2. Crear la base de datos
3. Implementar getType
4. Implementar onCreate
5. Implementar los metodos CRUD
6. Registar el ContentProvider en AndroidManifest.xml

Se va a explicar como crear un Content Provider que llevara un registro de los ficheros que abre un usuario.

Extender la clase ContentProvider
Al definir que nuestra clase extiende ContentProvider se nos crear el esqueleto básico de nuestra clase.
Que debería ser algo así:


Crear la base de datos
Ya con la estructura creada, tenemos que definir una URI para nuestra base de datos, para que el sistema pueda identificarla. En el futuro cuando llegue el momento que queramos realizar alguna consulta a la base de datos se hará a través del URI que vamos a definir. Se definen en la linea 2 y 3.

Ademas del URI, hay que definir una serie de propiedades, entre paréntesis se indica el numero de linea:

• Tipos de URI, un ítem especifico o un conjunto de ellos (6 - 11)
• La base de datos, nombre, versión y nombre de la tabla (14 - 20)
• Columnas de la tabla y su respectivo indice (23 - 28)
• Controlador de peticiones (30-36)

Ahora hay que pasar a la creación de la BD, para ello hay que implementar SQLiteOpenHelper como una clase privada. Y como pueden ver en la constante CREATE_TABLE se define la creación de la tabla con SQL usando las columnas definidas anteriormente. Mediante SQLiteOpenHelper el inicio de la base de datos se hace de manera perezosa, es decir hasta que no se necesita no se inicia. Evitando que nuestra aplicación se inicie mas lentamente, y que surjan errores relacionados con la base de datos al iniciar la aplicación.



Implementar getType
Este metodo se encarga de analizar la consulta y decidir que tipo de datos se esta consultando. Los dos tipos de datos fueron definidos en CONTENT_TYPE_LIST y CONTENT_TYPE_ITEM, el tipo de datos debe empezar por vnd.android.cursor.dir/ y vnd.android.cursor.item/ para una lista y un item especifico, respectivamente.



Implementar onCreate
Como estamos usando SQLiteOpenHelper, tan solo le indicamos que queremos crear la base de datos y  este mismo ya se encarga de hacerlo cuando sea necesario.


Implementar los metodos CRUD
Al definir como realizar las consultas a la base de datos tenemos que ver si se trata de un item especifico  o de todos.

Registar el ContentProvider
Suponiendo que nuestro ContentProvider se encuentra en un paquete llamado provider, tenemos que registrarlo en el Manifest

Scrum I: La base

Scrum es un framework para la gestión y desarrollo de proyectos software mediante un enfoque iterativo e incremental. El objetivo de Scrum es poder resolver problemas complejos de manera productiva y creativa, creando un producto con la mayor calidad posible. Al ser un proceso con iteraciones de corta duración (como máximo un mes) el feedback obtenido del cliente es constante y la evolución es mas cercana a lo que desea el cliente.

Scrum esta compuesto de cinco elementos: equipo, roles, eventos, artefactos y reglas; siendo cada uno de ellos esencial para su funcionamiento. Estos elementos se cubrirán en detalle en otros articulos.

Hay tres pilares que hay que tener siempre en cuenta a la hora de trabajar con Scrum: transparencia, inspección y adaptación.

Transparencia
Los aspectos importantes del proyecto deben ser visibles para todo el entorno, usando un lenguaje común y bien definido asegurándonos que todos entienden lo mismo por el mismo termino.

Un clásico ¿Cuando algo esta terminado? Cada persona puede dar una respuesta diferente a esa pregunta.

Lo que se pretende con la transparencia es saber en todo momento en que punto nos encontramos con nuestro proyecto y hacia donde vamos.

Inspección
Sino tenemos transparencia llevar a cabo una inspección seria una tarea extremadamente tediosa, improductiva y seria realmente difícil evaluar la situación actual. Por eso al tener un proceso transparente facilita enormemente la inspección de nuestra situación actual y de como vamos avanzando hacia nuestro objetivo.

La inspecciones deben realizarse con frecuenta pero sin llegar al punto de que obstruya el trabajo. Las inspecciones van de la mano con las adaptaciones, en el siguiente punto se explicara como ponerlas en practica.

Adaptación
Luego de una inspección, los errores o desviaciones detectados que sobrepasen los limites de aceptación deben solucionarse.  Los ajustes deben hacerse cuanto antes mejor, minimizando así el grado de desviación, la cantidad de errores actuales, y se evita el arrastre de errores; todo esto ayuda a mantener la planificación y el coste inicial.

Formalmente Scrum define cuatro puntos de inspección y adaptación:

• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective

Protocolos de arranque y configuración

Address Resolution Protocol
Primero que nada aclara que el protocolo de arranque y configuración seria RARP, pero es mucho mas claro explicar ARP para entender RARP, ya que es su caso inverso.

Address Resolution Protocol o ARP, es un protocolo que partiendo de una dirección de un protocolo de nivel superior (TCP, FTP, TELNET, etc) nos permite obtener la dirección Ethernet de un dispositivo.

Generación de paquetes ARP

Supongamos que trabajamos con el protocolo IP a nivel de red. Al enviar un mensaje desde el host A al host B, solo conocemos la direccion IP de la maquina de destino, pero a nivel de enlace el paquete es encapsulado en una trama Ethernet, por lo que sera necesario saber la dirección Ethernet de nuestra maquina destino (en caso de estar en la misma red) o de la maquina a través de la cual se hará el enrutamiento. Este proceso se hace media broadcasting, al ser un procedimiento muy costoso cada cliente mantiene una tabla de correspondencia con con los pares IP-Ethernet.

Recepción de paquetes ARP 

Como se dijo anteriormente cuando un terminal necesita determinar la dirección Ethernet de una maquina,  lo hará mediante un broadcast. Cuando una petición de resolución llega a un cliente, primero se actualiza la tabla de correspondencia (para evitar futuros broadcast) y luego se comprueba si nuestra dirección de protocolo es la buscada. Si el mensaje no va dirigido a nosotros se descarta, en caso contrario se responde al dispositivo que genero el mensaje indicándole nuestra dirección Ethernet.

Para consultar la tabla de correspondencia podemos ejecutar arp -a


Como se dijo al principio el caso inverso, es RARP, es decir conocemos la dirección física del dispositivo y queremos saber la dirección IP.

Suponiendo que tenemos que mandar un mensaje desde A (.10) a B (.20), la secuencia de mensajes de ARP es la siguiente:

1. arp who-has 192.168.1.10 tell  192.168.1.20
2. arp reply   192.168.1.20 is-at 00:11:22:33:44:55

Esto se puede ver perfectamente con Wireshark.

Bootstrap Protocol
Para lidiar con los problemas del broadcast limitado de RARP (255.255.255.255) surge BOOTPl objetivo de este protocolo es saber la IP de un host a partir de su dirección física. Se basa en UDP usando los puertos 67 y 68  para el servidor y el cliente respectivamente. 

El mayor problema de BOOTP es que el administrador de la red debe introducir manualmente la tabla de correspondencia IP y Ethernet, para evitar eso BOOTP evoluciono a DHCP.

Dynamic Host Configuration Protocol

DHCP se encarga de automatizar la configuración (IP, gateway, mascaras, etc) de los dispositivos. Para el cliente es como si usara BOOTP, ya que usa los mismos puertos y protocolo. La gran diferencia con los protocolos anteriores es que el servidor DHCP no tiene porque estar en la misma red, siendo necesario un agente re-transmisor. Cuando el cliente desea saber su IP genera un mensaje DHCP discover mediante broadcast, en caso de que el servidor se encuentre en la misma red le responde directamente sino el agente de retransmisión re enviara el mensaje al servidor.

• discover: enviado desde al servidor para solicitar una IP, puede sugerir la IP deseada.
• decline: rechaza la IP solicitada por el cliente.
• offer: el servidor le ofrece una configuración al cliente.
• request: es un mensaje generado por el cliente para confirmar/rechazar ofertas.
• ack / nak: confirmación / negación de un mensaje de tipo request

Permisos de acceso y Capifony

En el ultimo post se explico como desplegar un proyecto Symfony 2 con Capifony. Dependiendo del servidor con el que estemos trabajando debemos tener mas o menos cuidado con los permisos de usuario. Git en concreto solo guarda información sobre el bit ejecutable de un archivo. En mi caso al desplegar me encuentro con que el servidor se queja de los siguiente:

• Carpetas 775 en lugar de 755
• Archivos 664 en lugar de 644

Al intentar servir una pagina web en la que el archivo o la carpeta no tenga los permisos adecuados , se genera un error 500. Así que hay que hacer algo para realizar los cambios pertinentes. Seria bastante estúpido, montar todo Capifony para desplegar cómodamente con la ejecución de un comando para tener que cambiar los permisos de los ficheros manualmente.

Por defecto Capifony le dará permisos de escritura al grupo, asi que para ello hay que agregar a Deploy.rb la opción:

 set :group_writable, false  

Con eso están solucionados los permisos de las carpetas, sin embargo para los ficheros no hay una opción que podamos modificar. Mirando el código de Symfony2.rb, cuando se despliega el código la ultima tarea ejecutada antes del commit es deploy:symlink asi que teniendo esto en cuenta podemos modificar deploy.rb para que cambie los permisos de los ficheros cuando termine de desplegar. Yo solo necesito eliminar los permisos de escritura para todos los que no sean el propietario.

 after "deploy:symlink" do  
  run "cd #{latest_release} && chmod -R go-w web/"  
 end