Como generamos las releases en Plain Concepts, el caso de las aplicaciones de Windows Phone de Prisa.

Como generamos las releases en Plain Concepts, el caso de las aplicaciones de Windows Phone de Prisa.

Como dije anteriormente en mi artículo, ya están disponibles las aplicaciones de El País, As.com y CincoDías.com en el Marketplace de Windows Phone 7. Estas aplicaciones han sido desarrolladas y diseñadas íntegramente por Plain Concepts, en este artículo explicaré cuales son los procesos de desarrollo que seguidos dentro de PlainConcepts para asegurar la calidad de la aplicación y las técnicas empleadas.

Las aplicaciones están desarrolladas en C# usando Visual Studio 2010 y la metodología usada es Scrum, adaptándola para el desarrollo con un equipo tan pequeño y a las particularidades del proyecto en cuestion. Durante su desarrollo han participado un equipo de dos programadores, un diseñador y un scrum master. Se han empleado 7 iteraciones a aproximadamente 2 semanas cada una para completar el desarrollo, más una iteración final para estabilizar código. Durante la penúltima y última iteración una persona fuera del equipo se encargó del testing en la aplicación en dispositivos físicos.

Aquí os muestro la gráfica de Burndown and Burn Rate del proyecto:

clip_image002

Como se puede ver, conforme se iban generando trabajo se iba completando y aunque hay muchos picos, que indican que se ha ido bajando las horas de las tareas adecuadamente, en general la progresión de la aplicación ha sido buena. Conforme se iba cerrando trabajo se iba generando nuevo. La banda de color azul de fondo indica tareas que se quedaron fuera de la funcionalidad final de la aplicación, pero que no se eliminaron del TFS.

La gráfica del estado de todas las iteraciones, muestra cómo se fueron cerrando las tareas de cada iteración de manera correcta. Además podemos observar como al principio el equipo era demasiado optimista en cuanto a las estimaciones que se hacían, pero conforme las iteraciones fueron avanzando la confianza, la experiencia y el mayor conocimiento del proyecto hacen que las estimaciones y el reparto de tareas sean cada vez más cercanas a la realidad. Aunque como he dicho se iban generando tareas fuera de la iteración con trabajo de fondo que no se fueron cerrando en el TFS.

clip_image004

Como está el proyecto organizado

Al desarrollar una aplicación en Silverlight para Windows Phone 7, el patrón principal a la hora de desarrollar todas la aplicación ha sido MVVM, este patrón permite tener una vista hecha en xaml sin apenas nada de código y llevarse toda la lógica de la aplicación al ViewModel donde se realizaba todo el trabajo, en este desarrollo no se ha usado ningún framework de terceros para MVVM ya nosotros mismo hemos generado las utilidades que necesitábamos para el proyecto en un proyecto común a las 3 aplicaciones. Así el diagrama de arquitectura general se queda así:

clip_image006

Donde PlainConcepts.Common está la funcionalidad común a los tres proyectos; convertes, controles, tipos de datos comunes, parseadores de xml, navegación, serialización, comandos y viewmodels.

En cada uno de los proyectos están sus respectivas vistas, controles de usuario, páginas del teléfono y demás artefactos específicos, imágenes, iconos, etc.

Configuración del TFS, políticas de check-in, ramas y builds.

Para manejar el ciclo de vida del desarrollo y la integración continua durante el proyecto se han usado diferentes artefactos para asegurar que el desarrollo era incremental.

Políticas de check-in

El proyecto tenia habilitado el multiple chech-out y como políticas de check-in teníamos, requerir asocial un work ítem en cada check-in y requerir agregar un comentario en cada check-in. Eso nos permite tener trazabilidad de como el proyecto se ha desarrollado y que changeset del servidor está asociado a cada work ítem. Por no decir que también de esta manera sabemos que work ítems están asociados a cada compilación.

Políticas de ramas (branching)

Durante el desarrollo inicial de la aplicación no había ninguna configuración especial en el servidor sobre ramas, es decir únicamente teníamos una rama dev (Developer) en la que se trabajaba. Pero conforme el cliente fue pidiendo versiones estables para ver el progreso del desarrollo, se optó por esta configuración:

clip_image007

La carpeta dev se pasó a llamar Main. A partir de esta rama Main se generaron, dev y todas las releases de las diferentes aplicaciones.´

Esto nos permitía tener en la rama Main versiones estables de las tres aplicaciones entregables al cliente, libre de bugs, estabilizadas y fuera del ciclo de desarrollo. El tener una rama Main te permite que el equipo de desarrollo siga trabajando en dev, pero conforme la funcionalidad vaya generándose que se vayan mezclándose (merge) la funcionalidad de dev a Main y así hacer un entregable al cliente.

Las ramas de reléase de cada aplicación tienes las versiones reléase publicadas en el Marketplace y las sucesivas actualizaciones que se vayan generando. Así si encontramos un bug en la versión del servidor, tenemos el changeset etiquetado podemos generar un fix en la rama reléase de esa aplicación, sin tener que impactar en las demás aplicaciones y cuando el bug este corregido y testeado, propagar ese cambio de la rama reléase de la aplicación, a la rama Main y de ahí a dev y el resto de releases (en caso de que el bug sea de algo común).

Compilaciones (Builds)

Otra requisito importante para seguir integración continua durante el desarrollo son las compilaciones, en el proyecto hay 5 compilaciones creadas y todas ellas activas.

  • As Release 1.0: gated checking en la rama de release (modo release).
  • CincoDias Release 1.0: gated checkin en la rama de release (modo release).
  • ElPais Release 1.0: gated checkin en la rama de reléase (modo release).
  • Prisa.WP7: continuous integration en la rama de dev (modo debug y release).
  • Prisa.WP7 Main: gated checkin en la rama de main (modo debug y release).

Con esta lista de compilaciones en el equipo nos podíamos asegurar de que cada checkin era incremental, porque podíamos verificar que la compilación era correcta por lo menos en Main y en las ramas de release. Esto nos permitía saber que el código que teníamos en Main y Release compilaba sin problemas para que en cualquier momento se pudiera hacer un cambio, además de eliminar el molesto “Works on my machine” ayudando así a los tester a tener versiones incrementales de la funcionalidad compilada por el servidor y poder ir generando bugs sobre las versiones generadas.

Aquí podemos ver el estado de las compilaciones correctas a través del tiempo:

clip_image009

Otra de las cosas interesantes de tener un servidor de compilaciones es que conforme la funcionalidad va generándose se van generando binarios de la aplicación que se pueden consumir, así que el equipo de Plain Concepts decidió dar acceso al cliente, a través de http a la carpeta de salida de todos los binarios de las aplicaciones. De esta manera el cliente puede tener acceso ubicuo a su producto y desplegarse la última versión siempre que lo desee.

Testing

Aunque no es posible integrar el testing de Visual Studio en proyecto de Silverlight para Windows Phone 7, el testing de la aplicación se definió como tesing manual que se hacía por personas independientes del proyecto en terminales físicos y nunca sobre el emulador, con conexiones 2G (GPRS), 3G, 3.5G y WiFi, sobre varios terminales diferentes.

Como se publica una versión en el Marketplace

El proceso para publicar una versión en el Marketplace implica tener los cambios solicitados por el cliente en la rama reléase de la aplicación, que la compilación en modo reléase, desplegar esa fichero generado por el servidor de compilación en el teléfono y testear que todos los cambios que el cliente había solicitado están integrados y que de la lista de test previos que todo este correcto, para que se no se no se hayan introducido nuevos bugs.

Una vez hecho esto tenemos que subir el número de versión de la aplicación y hacer checkin, este último check-in con el cambio de versión, es el xap que se sube al Marketplace. Se etiqueta la build con una etiqueta de calidad “Published in WP7 Marketplace” y se retiene la build.

clip_image011

Además de eso se aplica una etiqueta en la rama de la aplicación con la versión de la aplicación para en caso de que haya un bug saber el changeset asociado.

Conclusiones

El desarrollo de software es una disciplina muy complicada y que no se debe infravalorar, en Plain Concepts nos gusta hacer las cosas bien y sabemos lo complicado que es montar un proyecto, mantenerlo y sobre todo desarrollar funcionalidad. Así que con este post queremos mostrar un poco cual es el proceso que seguimos internamente para desarrollar. Eso no significa que todos los proyectos se montan de la misma manera, sino que cada proyecto es único a la hora de crearse y desarrollarse, y no existen reglas fijas de metodologías y artefactos que utilizar. Estas deben ser adecuadas al proyecto en cuestión haciendo que sean útiles para el equipo y para el proceso en sí. Lo difícil de todo esto es saber que metodologías usar, que tecnologías usar y cómo gestionar todo ese flujo. Como dice Rodrigo Corral, “los proyectos no fracasan por la solución tecnológica, sino por la gestión en sí”, es decir, que confiar en que el proyecto va a ser un éxito simplemente por usar todas las últimas tecnologías y herramientas, es simplemente un error, porque no te elimina la necesidad de gestionar personas y recursos.

Si tenéis alguna pregunta, o queréis comentar algo sobre el proceso podéis hacerlo en los comentarios.

Saludos.

Luis Guerrero.

Published 5/7/2011 11:19 por Luis Guerrero
Comparte este post:

Comentarios

# re: Como generamos las releases en Plain Concepts, el caso de las aplicaciones de Windows Phone de Prisa.

Tuesday, July 5, 2011 11:55 AM por Sifri Garcia

Muchas gracias por el articulo, es muy interesante.

Me ha impresionado la disciplina a la hora de utilizar Scrum y como la habeis aplicado a un desarrollo de WindowsPhone.

Ojala mi trabajo fuese asi ;(

En mi caso de momento me tengo que conformar con desarrollar cutreaplicaciones en mi tiempo libre para WindowsPhone7 y soñar con publicar alguna en marketplace...

# re: Como generamos las releases en Plain Concepts, el caso de las aplicaciones de Windows Phone de Prisa.

Tuesday, July 5, 2011 1:43 PM por El Bruno

Luis ... excelente post !!! buenas prácticas aplicadas por doquier, a seguir con el buen ejemplo :D

Salu2

# re: Como generamos las releases en Plain Concepts, el caso de las aplicaciones de Windows Phone de Prisa.

Tuesday, July 5, 2011 3:29 PM por Jesús Bosch

interesante artículo, más empresas deberían trabajar así :)

# re: Como generamos las releases en Plain Concepts, el caso de las aplicaciones de Windows Phone de Prisa.

Tuesday, July 5, 2011 3:39 PM por Luis Guerrero

Gracias a todos por los comentarios :)

# re: Como generamos las releases en Plain Concepts, el caso de las aplicaciones de Windows Phone de Prisa.

Tuesday, July 5, 2011 8:20 PM por Victor Sanchez

Muy buen articulo Luis. Sólo tengo un par de preguntas:

- De acuerdo a tu diagrama de arquitectura general, tendrías una sola solución en el Visual Studio con todos los proyectos?

- Si tendrias todos los proyectos en una sola solución entonces cada vez que necesites generar una nueva rama para la empresa XXX, esta rama contendra todos los proyectos de tu diagrama de arquitectura?

# re: Como generamos las releases en Plain Concepts, el caso de las aplicaciones de Windows Phone de Prisa.

Wednesday, July 6, 2011 12:26 AM por Luis Guerrero

Hola Victor!

Efectivamente, como el diagrama indica (sacado de Visual Studio) en mi solución tengo todos los proyectos de las tres aplicaciones, El Pais, As y Cinco Días. Esto es así porque como comenté al principio del artículo, el proyecto era de las tres aplicaciones a la vez por eso consideré oportuno tener en la misma solución las tres. Una vez que se hicieron las ramas, ya no tenía tanto sentido tener todos los proyectos juntos, pero bueno eso me permitía hacer un merge de una rama reléase, de por ejemplo El Pais, a la rama de Main sin cambiar el .sln.

Y sobre la segunda pregunta volvemos a lo mismo, el proyecto no se pensó para más aplicaciones sino para esas tres, con lo cual no voy a tener ese escenario de tener que generar más proyectos y más ramas. Lo suyo hubiera sido quitar los proyectos de As y Cinco Días de la solución de El Pais, pero como estábamos comodos con eso nos pareció bien, además el tener ramas nos permitía cambiar cosas del proyecto de PlainConcepts.Common en la rama de El Pais sin que esto afectase a la rama de As (por poner un ejemplo) y después hacer un merge de todo eso a Main y testear que ese cambio no ha impactado en el resto de aplicaciones. Una de las cosas buenas que tiene tener un ensablado común es que te ahorras código, pero tienes el problema de que cada cambio impacta más partes de otro software, y esto con las ramas lo minimizábamos.

Espero que te sirva, si tienes alguna duda más no dudes en contestar.

Saludos. Luis.

# re: Como generamos las releases en Plain Concepts, el caso de las aplicaciones de Windows Phone de Prisa.

Wednesday, July 6, 2011 8:29 AM por preguntoncojonero

Más posts de builds de servidor, deploy, etc serían de agradecer. Muy bueno señor.

Qué significa "que la compilación en modo reléase, desplegar esa fichero generado por el servidor de compilación en el teléfono..."

teléfono ? mi casa ?

salu2grz

# re: Como generamos las releases en Plain Concepts, el caso de las aplicaciones de Windows Phone de Prisa.

Wednesday, July 6, 2011 10:08 AM por Luis Guerrero

Hola preguntoncojonero!

Pues que si tenemos un servidor de build, la gente de testing puede obtener el binario recién compilado de ahí, sin tener que instalarse nada de desarrollador en sus máquinas. El tester no tiene que bajarse la solución de Visual Studio y compilarla en local. Además de que así si encuentra algún error puede asociarlo a una build especifica.

Saludos. Luis.

# re: Como generamos las releases en Plain Concepts, el caso de las aplicaciones de Windows Phone de Prisa.

Wednesday, July 6, 2011 10:53 AM por Victor Sanchez

Hola Luis,

Muchas gracias por tu respuesta. Te hice esas preguntas porque yo tengo un caso parecido a tu post, con la única diferencia, a parte de ser aplicaciones web, es que en mi proyecto existe el caso que puedo tener un nuevo cliente con sus funcionalidades particulares (images, estilos, controles, etc.) por lo que me preocupaba el hecho de tener todos los proyectos en una solucion. Por lo tanto, había pensado tener una solución por cada cliente pero todas las soluciones tendrian añadido los proyectos comunes.

Básicamente, habia pensado en esta estructura:

> COMMON CORE (Bibliotecas de clases comunes)

---->MAIN

> Cliente 1

---->DEV

---->MAIN

---->RELEASE

> Cliente 2 (Esta misma estructura se repetiria por cada cliente)

---->DEV

---->MAIN

---->RELEASE

De esta forma evitaria tener ramas del proyecto común pero habría un riesgo muy alto ya que se estaría desarrollando sobre la main.

Cúal sería la mejor forma de estructurar el código para mi caso?

Espero haberme explicado.

Gracias y saludos,

Victor

# re: Como generamos las releases en Plain Concepts, el caso de las aplicaciones de Windows Phone de Prisa.

Wednesday, July 6, 2011 11:41 AM por Luis Guerrero

Hola Victor!

El tema que comentas es radicalmente diferente, porque tu escenario difiere mucho del mio. Por lo que entiendo tienes como dos 1…n ramas de desarrollo. Tienes por un lado el desarrollo de tu librería Common Core que supongo que seguirá un versionado también de DEV, MAIN y RELEASE, y luego todas las ramas de los clientes, que también pueden estar con estas tres ramas, que deberían de consumir la rama RELEASE de tu proyecto Common Core. Eso te permite seguir con el desarrollo de tu librería común a las tres aplicaciones, ir sacando versiones estables sin molestarte en las incompatibilidades de esa librería con respecto a los demás desarrollos y después ir integrando en Main y RELEASE de Common core. Tienes que planteártelo de manera que sean como dos proyectos completamente separados, e internamente que vayas sacando reléase de una librería que los proyectos de los demás clientes consuman.

No dudes en seguir preguntado.

Saludos. Luis.

# re: Como generamos las releases en Plain Concepts, el caso de las aplicaciones de Windows Phone de Prisa.

Thursday, November 29, 2012 9:01 AM por Kiquenet

En estos temas, el evento de Pucela Tech Day es interesante,lástima no se emita vía streaming.

geeks.ms/.../pucela-tech-day.aspx

Trata en parte de  un escenario de integración continúa , aunque creo no tratará parte de este proceso de generación de releases.

Saludos.