Secciones

@Internet

Algo sobre mi

Bienvenido a frangarcia.net. Mi nombre es Fran García y soy un analista programador web que actualmente trabaja como programador Freelance. En esta web encontrarás sobre todo noticias relacionadas con las nuevas tecnologías, Internet, programación y de vez en cuando soltaré algo sobre mi vida privada, aunque no esperes que esto sea un blog demasiado íntimo.
Espero que lo que veas y leas aquí, sea de tu interés.

Consejos para emigrar al Reino Unido

18. octubre 2013, 11:33
Se han desactivado los comentarios a este artículo.


Emigrar para trabajar al Reino Unido no es algo sencillo y con la experiencia de haberlo hecho ya dos veces en el último año, me siento en condiciones de escribir un artículo que pueda ayudar a otras personas a hacer ese proceso más sencillo.

Continue reading »


Menea esta noticia Busca en Technorati enlaces a esta nota Diggea esta noticia Añádeme a tu del.icio.us

Actualizando aplicaciones a Grails 2.3.0

11. septiembre 2013, 19:35
Se han desactivado los comentarios a este artículo.


Ayer mismo salió la nueva versión de Grails, la 2.3.0 que destaca, entre otros aspectos por las mejoras en el soporte a los servicios REST y el aumento de la seguridad para evitar ataques XSS.

Esta misma mañana he intentado actualizar una aplicación que estoy desarrollando y de la que por el momento no puedo hablar y me he encontrado con el problema de que se desaconseja el uso el típico comando grails upgrade puesto que está en estado de deprecated. A partir de ahora debemos utilizar el comando

Continue reading »


Menea esta noticia Busca en Technorati enlaces a esta nota Diggea esta noticia Añádeme a tu del.icio.us

Dejo Secret Escapes en Londres para volver a Alicante

25. junio 2013, 11:51
Se han desactivado los comentarios a este artículo.


Si hace 8 meses escribía un post para anunciar que dejaba la Universidad de Alicante para empezar a trabajar para Secret Escapes en Londres, ahora es el momento de escribir un nuevo post para decir que dejo Londres, para volver a Alicante y empezar una nueva aventura como programador freelance.

Continue reading »


Menea esta noticia Busca en Technorati enlaces a esta nota Diggea esta noticia Añádeme a tu del.icio.us

Mis primeros dos meses en Secret Escapes

24. diciembre 2012, 11:11
Se han desactivado los comentarios a este artículo.


Después de más de dos meses en mi nuevo puesto de trabajo y casi diría yo en mi nueva vida lo único que puedo decir es que no nos hemos equivocado en la decisión tomada. Hablo en plural porque esta decisión ha sido conjunta entre mi mujer y yo y aunque ella todavía está en España, en breve me acompañará en esta aventura.

Pero vamos a lo que quería os contar en este post. El título de mi puesto de trabajo es Senior Software Developer en Secret Escapes, una start-up con base en Londres que se dedica al mercado de los viajes de lujo con grandes descuentos.

Os cuento un poco la estructura actual del departamento técnico de la empresa. A la cabeza está el CTO de la compañía que dirije a 4 programadores, dos de ellos seniors, y dos diseñadores gráficos.

Las teorías ágiles están al orden del día en nuestro departamento y todas las mañanas tenemos nuestra reunión stand-up en la que todos los miembros del equipo cuentan brevemente que hicieron el día anterior y que tienen previsto para ese día. Por supuesto, en esta reunión nada de estar sentados y suele durar unos 10-15 minutos.

Para organizarnos las tareas y saber que está haciendo cada uno de nosotros utilizamos Trello, el típico tablero Scrum con las diferentes fases por las que pasan las tareas antes de ser desplegadas ( backlog, doing, done, staged y deployed). Para tareas complejas utilizamos un único tablero para esa tarea y así fragmentar mejor la misma.

Una vez ya sabemos que tenemos que hacer ese día, es hora de programar y en muchas ocasiones no lo hacemos solos sino que hacemos pair programming bastante a menudo. Es la primera vez que practico esta técnica y la verdad es que todos son ventajas, en primer lugar porque es una forma de involucrar a todos los miembros del equipo en el desarrollo de todas las tareas y que luego no aparezca la típica frase de “es que eso sólo lo sabe hacer Pepito”.

En todo momento la empresa y su CTO aboga por seguir la metodología TDD (Test Driven Dvelopment), que también era la primera vez que lo utilizaba y de nuevo, tiene muchas ventajas aunque el programador debe cambiar su manera de afrontar los problemas y la verdad es que al principio me ha costado un poco (Recomendar libro) y en más de una ocasión me han cogido algún trozo de código nuevo y me lo han borrado por completo porque no había hecho primero los test. Al principio jode, pero luego te das cuenta de lo importante que son los test en un entorno tan cambiante como es una start-up.

Esto ya no sé si se enmarca dentro de las meotodologías ágiles pero una hora y media antes de terminar la jornada de trabajo, debemos cortar de forma bastante radical lo que estamos haciendo para hacer cualquier otra tarea que aparezca en el tablero Scrum. En ocasiones no te gusta cuando estás con un tarea y no puedes terminarla porque toca cambiar, pero en la mayoría de las veces, ese cambio supone un descanso en una tarea en la que muchas veces estás atascado para pasar a otra y refrescar la mente al mismo tiempo que ir sacando pequeñas tareas pendientes y que casi nunca hay tiempo para desarrollar.

Para analizar como ha ido el día a día, cada dos semanas, los viernes a última hora de la tarde, en un ambiente muy relajado, tenemos lo que llamamos las reuniones retrospectivas en la que cada miembro del equipo expone brevemente y por medio de post-its 5 aspectos (start, stop, more, less, continue) en el que se definen que ideas se deben empezar, parar, ampliar, relajar o continuar en la próxima iteración. Con todas estas ideas puestas en un tablero, cada miembro escoje 3 de esas ideas y posteriormente el CTO las recopila para extraer las 3 más importantes.

Ya en la parte menos relativa al agilismo, comentaros que como gestor de repositorios del código fuente utilizamos git y nos ayudamos de git-flow para gestionar las features, los hotfixes y las releases.

Y ya por último el ambiente en el departamento técnico es increíble y prácticamente todo los días comemos juntos y los viernes tras el trabajo solemos ir a tomar algo junto. Así que lo que decía al principio, estoy muy satisfecho con la decisión tomada.


Menea esta noticia Busca en Technorati enlaces a esta nota Diggea esta noticia Añádeme a tu del.icio.us

Dejo la Universidad de Alicante para trabajar en Londres

16. octubre 2012, 11:57
Se han desactivado los comentarios a este artículo.


Este próximo 2 de Noviembre iba a cumplir ya 8 años en el Laboratorio de Idiomas de la Universidad de Alicante, el lugar donde me he desarrollado como profesional y donde he descubierto que el mundo del funcionariado, quizás no sea todo lo bonito que muchos lo pintan, más aún con los últimos acontecimientos acaecidos en España.

Voy a tratar de explicar los motivos por los cuales he tomado esta decisión. El pasado lunes 15 de Octubre concluía el plazo para presentar la instancia a la oposición de la que actualmente estoy ocupando el puesto, lo que todo el mundo diría ‘mi plaza’. Pues bien, en los últimos 4-5 años hemos luchado desde el Laboratorio de Idiomas para que se nos reconozca el trabajo que hemos llevado a cabo como programadores de aplicaciones, valorado como excelente por la mayoría de la comunidad universitaria de la Facultad y otras entidades de la Universidad.

Finalmente y tras mucho pelear, la plaza salió con una pírrica categoría C, algo que no estaba dispuesto a aceptar, por mucho que la situación actual sea la que es y que mucha gente pensara que estoy loco por dejar un puesto fijo para toda la vida. Un puesto fijo sí, ¿y qué más?. Nulas posibilidades de prosperar laboralmente en función de tus logros y ambiente enrarecido en los actuales momentos de crisis.

Entiendo a toda esa gente que mataría por tener una situación como la que yo tenía, pero mis motivaciones van más alla de la de recibir un sueldo a final de mes, tener las tardes libres y muchas vacaciones y días libres. Quiero sentirme parte de un proyecto en el que me sienta valorado económicamente. Sí, económicamente, porque de las palmaditas en la espalda y las palabras no se vive y si para poder alcanzar un sueldo que yo considero justo tengo que matarme a trabajar por las tardes/noches/sabados/domingos, porque mi trabajo de funcionario no da para más, posiblemente es que no estaba en el trabajo adecuado.

¿Dónde voy a trabajar ahora?

Pues me marcho al Reino Unido, concretamente a Londres, donde trabajaré para Secret Escapes como Senior Grails Developer donde espero aprender muchísimo con grandes profesionales del sector.

Agradecimientos

Pues me gustaría empezar por mi compañero del Laboratorio de Idiomas Fernando López, un crack de la programación de escritorio y que ha hecho un trabajo increíble con unos recursos muy limitados dentro del laboratorio. Su sistema de interpretación no está más explotado porque desde dentro de la facultad parece que todavía no se han dado cuenta de lo que tienen en casa y como suele pasar, te valoran más fuera que en casa por tu trabajo. Por cierto, a paciencia nadie le gana a Fer.

Al resto de mi compañeros de laboratorio (Santi, Vicen, Carlos, Jesús y David), porque a pesar de que en algunos momentos hemos tenido nuestras diferencias, ha habido otros muchos momentos buenos y que os quede claro que hemos hecho un trabajo increible, desde el primero al último.

A los profesores con los que he trabajado estos años, Miguel Tolosa, Daniel Gallego, Pedro Mogorrón, Patrick Martínez, Paola Masseau, Elisa Barrajón, Ascensión Sierra y muy especialmente a Mireia López, una profesora a quien sus ganas de trabajar superan con creces las de cualquier ser humano.

Al equipo del Experto de desarrollo de aplicaciones con Java Enterprise, Domingo, Otto, Boyan, Miguel Ángel, Eli, José Luís, Alex y especialmente a mi gran amigo Aitor, que como él dice, fue quien me introdujo en el mundo de Grails, que ahora me ha proporcionado esta increible oportunidad. Todas las personas que forman el experto son increibles tanto en lo profesional como personal y ha sido un placer trabajar con vosotros estos 2 años. Aunque bueno, ahora que lo pienso, si con el experto si voy a seguir trabajando. Volveré a dar esas clases los dos fines de semana, aunque me perderé esas reuniones tan amenas.

Me queda un agradecimiento muy importante que dar a una persona relacionada con la Universidad de Alicante, pero no lo haré en público, sino que mejor lo haré cuando llegue a casa.


Menea esta noticia Busca en Technorati enlaces a esta nota Diggea esta noticia Añádeme a tu del.icio.us

Utilizar correo electrónico con Spring Security Core

12. agosto 2012, 09:35
Se han desactivado los comentarios a este artículo.


Actualmente estoy trabajando en un proyecto del que en breve esperamos tener una primera release y del que todavía no puedo comentar nada. En este proyecto, he tenido que realizar una serie de modificaciones a un plugin que siempre utilizo en cualquier proyecto de Grails que requiera de autenticación mediante usuario y contraseña. Este plugin es Spring Security Core.

Este plugin permite fácilmente implementar todo un sistema de seguridad en una aplicación desarrollada en Grails mediante nombre de usuario y contraseña. En este proyecto necesitaba ampliar este plugin para que en además de poder identificarse mediante nombre de usuario también se pudiera hacer mediante el correo electrónico.

Para poder implementar estos cambios, lo primero que debemos hacer es ampliar la clase relativa a los usuarios del plugin Spring Security Core. Habitualmente esta clase se llama User y quedaría algo así:

Groovy:
class User {

        transient springSecurityService

        String username
        String password
        boolean enabled
        boolean accountExpired
        boolean accountLocked
        boolean passwordExpired
    String email


        static constraints = {
                username blank: false, unique: true
        password blank: false
        email blank:false, unique:true, email:true
        }
       
        ....
}

Posteriormente, debemos crear una clase en el directorio src/groovy para extender la clase GrailsUser que a su vez extiende a la clase User.

Groovy:
import org.codehaus.groovy.grails.plugins.springsecurity.GrailsUser

import org.springframework.security.core.GrantedAuthority
import org.springframework.security.core.userdetails.User

class MyUserDetails extends GrailsUser {

    final String email
    final String name
    final String surnames

    MyUserDetails(String username,
                  String password,
                  boolean enabled,
                  boolean accountNonExpired,
                  boolean credentialsNonExpired,
                  boolean accountNonLocked,
                  Collection<GrantedAuthority> authorities,
                  long id,
                  String email) {
        super(username, password, enabled, accountNonExpired, credentialsNonExpired, accountNonLocked, authorities, id)

        this.email = email
    }
}

Por último, debemos crear un servicio de Grails donde modificaremos el comportamiento de la autenticación en Grails para que en lugar de comprobar únicamente por el nombre de usuario, lo haga también con el email que acabamos de añadir.

Groovy:
import org.codehaus.groovy.grails.plugins.springsecurity.GrailsUser
import org.codehaus.groovy.grails.plugins.springsecurity.SpringSecurityUtils
import org.codehaus.groovy.grails.plugins.springsecurity.GrailsUserDetailsService
import org.springframework.security.core.authority.GrantedAuthorityImpl
import org.springframework.security.core.userdetails.UserDetails
import org.springframework.security.core.userdetails.UsernameNotFoundException

class MyUserDetailsService implements GrailsUserDetailsService {

/** * Some Spring Security classes (e.g. RoleHierarchyVoter) expect at least * one role, so we give a user with no granted roles this one which gets * past that restriction but doesn't grant anything. */
    static final List NO_ROLES = [new GrantedAuthorityImpl(SpringSecurityUtils.NO_ROLE)]

    UserDetails loadUserByUsername(String username, boolean loadRoles) throws UsernameNotFoundException {
        return loadUserByUsername(username)
    }

    UserDetails loadUserByUsername(String username) throws UsernameNotFoundException {

        User.withTransaction { status ->

            User user = User.findByUsernameOrEmail(username, username)

            if (!user)
                throw new UsernameNotFoundException( 'User not found', username)

            def authorities = user.authorities.collect {
                new GrantedAuthorityImpl(it.authority)
            }

            return new MyUserDetails(user.username,
                    user.password,
                    user.enabled,
                    !user.accountExpired,
                    !user.passwordExpired,
                    !user.accountLocked,
                    authorities ?: NO_ROLES,
                    user.id,
                    user.email)
        }
    }
}

Con estos cambios, ya podremos identificar a los usuarios de nuestra aplicación tanto con el nombre de usuario como por el correo electrónico. Incluso vamos a poder utilizar la etiqueta loggedInUserInfo para mostrar el correo electrónico del usuario identificado en el sistema.

Groovy:
<sec:loggedInUserInfo field="email"/>

Podéis encontrar más información al respecto en la documentación del plugin Spring Security Core y en el blog de Omar Marji.


Menea esta noticia Busca en Technorati enlaces a esta nota Diggea esta noticia Añádeme a tu del.icio.us

Agrupar por fecha y año con Criteria en Grails

14. mayo 2012, 12:44
Se han desactivado los comentarios a este artículo.


Actualmente estoy desarrollando un par de aplicaciones en que las estadísticas son fundamentales para la correcta realización de las mismas. En primer lugar, aconsejaros que utilicéis Google Chart para pintar todo tipo de gráficas de una forma muy sencilla.

En una de las gráficas necesitaba obtener una gráfica para saber el trabajo de los usuario registrados en la misma en un espacio de tiempo. Concretamente necesitaba saber cuantas entradas había insertado cada usuario en cada mes. Para ello me decidí a utilizar una namedQueries y por lo tanto utilizar criteria. Este sería el código para realizar esta consulta agrupada tanto por usuario como por mes y año.

Groovy:
import org.hibernate.criterion.Projections
import org.hibernate.type.Type
import org.hibernate.Hibernate

static namedQueries = {
  statsByUserAndMonth {
    isNotNull("createdBy")
    projections {
        rowCount()
        groupProperty "createdBy"//Agrupamos por usuario
        addProjectionsToList(Projections.sqlGroupProjection(
            "month(date_created) as month, year(date_created) as year",
            "month(date_created), year(date_created)",
            ["month","year"].toArray(new String[2]),
            [Hibernate.INTEGER, Hibernate.INTEGER].toArray(new Type[2])),
            "dateCreated"
        )
    }
  }
}
 

Es importante tener en cuenta que en la parte de sqlGroupProjection se hace referencia a la columna creada en la base de datos.


Menea esta noticia Busca en Technorati enlaces a esta nota Diggea esta noticia Añádeme a tu del.icio.us

¿Qué hay de nuevo en Grails 2.0? HTML5 y GORM

23. noviembre 2011, 14:39
Se han desactivado los comentarios a este artículo.


Tras el primer artículo que escribí sobre las nuevas características de Grails 2.0 en las que comentaba básicamente aquellas nuevas características que ayudaban al desarrollador a ser más productivo todavía si cabe, en este nuevo artículo comentaré otros aspectos novedosos en la nueva versión de Grails como son la introducción de HTML5 y otras mejoras relativas a la generación del contenido de nuestras aplicaciones así como de otras mejoras en lo relativo a GORM.

Quizás el aspecto que más llama la atención cuando generamos una aplicación en Grails 2.0 utilizando su scaffolding es el cambio de interfaz que ha habido en relación a versiones anteriores. Este cambio es debido principalmente a que en esta nueva versión se ha empezado a utilizar HTML5. Este scaffolding es mucho mejor que en versiones anteriores y representa lo que se conocen como buenas prácticas a la hora de diseñar aplicaciones web.

En la nueva versión de Grails también se facilita la creación de páginas para por ejemplo ser envíadas a través de emails (tipo newsletter) a través del API de la clase PageRenderer. Esta generación de emails se hacía complicada en versiones anteriores debido a la falta de una petición HTTP en la que basarse.

Del mismo, si en estos emails queremos generar enlaces dinámicos hacía partes de nuestras aplicaciones, podemos utilizar el API de la clase LinkGenerator.

Por otro lado, el plugin resources ha sido integrado en el nucleo de Grails 2.0. Este plugin permite declarar recursos estáticos en nuestras páginas de forma sencilla y además, optimizando incluso las llamadas a los mismos para no repetir peticiones a un mismo recurso.

Todo esto en lo relativo a la parte web de nuestras aplicaciones en Grails 2.0. Pasemos a ver ahora las nuevas características en lo relativo a la gestión de los datos de nuestras aplicaciones.

La características más importante es que GORM ya no se basa únicamente en Hibernate sino que puede ser utilizada con otros entornos como Mongo DB, Redis, Riak, Amazon SimpleDB, Neo4j o Cassandra.

Se ha creado para GORM lo que se conoce como las Where queries que no es más que un DSL para realizar consultas a nuestras clases de dominio.


def query = Person.where { firstName == “Fran”
}

def fran = query.find()

Este tipo de consultas se comprueban en tiempo de compilación lo que nos adelanta posibles problemas de nuestras consultas. Además, te habrás dado cuenta de que incluso podemos utilizar caracteres como ==, >=, <=, <, >, != en estas consultas que posteriormente serán traducidas al lenguaje SQL correspondiente.

Además, también vamos a poder utilizar funciones agregadas como avg(), sum(), max(), min(), etc. En la siguiente consulta obtendremos aquellas personas cuya edad sea superior a la media.

def query = Person.where{ age > avg(age) }

También podemos definir varias fuentes de datos de nuestra aplicación que como siempre definiremos en el archivo de configuración DataSource.groovy. Además, en Grails 2.0 también vamos a poder hacer ingeniería inversa a partir de un esquema de base de datos para ahorrarnos tener crear a mano todas las clases de dominio de la aplicación.

Por último, se han creado dos nuevas funciones de GORM que son findOrCreateWhere() y findOrSaveWhere() que como su propio nombre indica, en primer lugar buscar en las clases de dominio un registro que cumpla las condiciones pasadas en el método y en caso de que no exista lo crea o lo modifica en función del método utilizado.


Menea esta noticia Busca en Technorati enlaces a esta nota Diggea esta noticia Añádeme a tu del.icio.us

¿Qué hay de nuevo en Grails 2.0? Ayudando al desarrollador.

10. noviembre 2011, 08:41
Se han desactivado los comentarios a este artículo.


Ayer estuve viendo un screencast presentado por Peter Ledbrook en el que presentaba las nuevas características que vendrán con la nueva versión de Grails 2.0, así que me he decidido a escribir unos pequeños artículos en los que comentaré esas nuevas características.

En este artículo veremos algunas características introducidas en el entorno de desarrollo de Grails. En primer lugar hay que comentar que se ha mejorado la interfaz de la consola en el modo interactivo en la cual podremos ejecutar cualquier comando de Grails y ayudarnos al mismo tiempo de su autocompletado. Llama la atención que incluso vamos a poder ejecutar comandos externos a Grails como si estuviéramos en el shell de Linux.

Se han mejorado también las plantillas que muestran los resultados de los tests para que sea más intuitivo saber que ha sucedido en la última ejecución de dichos tests. Siguiendo con las plantillas utilizadas en el proyecto Grails, desde la versión 1.3 la documentación seguía una estructura muy sencilla de consultar (IMHO). Pues bien, desde la versión 2.0 vamos a poder utilizar estas plantillas para realizar la documentación de nuestras aplicaciones en Grails.

Algo que nos ayudará a ser incluso más productivos es la mejora que se ha introducido en Grails 2.0 en el mostrado de los errores por pantalla. En esta versión se mostrará no sólo la línea en la que se produce un error en el controler sino que también se mostrará el error producido en el servicio en caso de que el controlador invoque a un servicio con lo que encontrar el error será una tarea mucho más sencilla.

Por otro lado, en Grails 2.0 se cambia la base de datos que viene por defecto para desarrollo, que hasta ahora era HSQLDB por H2. Pues bien, desde la versión Grails 2.0 vamos a poder consultar el esquema de base de datos creado automáticamente a partir de las clases de dominio accediendo a la URL http://localhost:8080/app/dbconsole y así hacernos una idea de lo que está creando Grails por detrás de las cortinas. Lo bueno de esto es que no sólo está disponible para una base de H2, sino que podremos hacerlo con cualquier base de datos que se pueda conectar mediante JDBC.

Algo que también me gusta mucho y que ayudará a saber que plugins son los mejores en cada categoría es que a partir de ahora se hará un seguimiento del uso de los plugins en proyectos reales, por supuesto, siempre y cuando demos permiso para esto. Con lo que ahora además de la propia valoración de los plugins podremos ver el uso que se está haciendo del mismo en otros proyectos.

Por supuesto, Grails 2.0 viene con las librerías actualizadas de los paquetes utilizados como son Groovy 1.8, Spring 3.1 y Hibernate cuyas versiones irán desde la 3.3 hasta la 3.6. Además, el plugin de Tomcat funcionará con la versión 7.

Los desarrolladores de Grails ya sabéis que en la mayoría de los casos no hace falta reiniciar la aplicación cada vez que introducimos un caso, pero esto no sucede en ocasiones y toca parar la aplicación. Pues bien, en Grails 2.0 no es necesario para la aplicación cada vez que hagamos referencia a un servicio desde un controlador, modifiquemos una clase de dominio o cambiemos una clase de los directorios src/groovy o src/java, ya no será necesario reiniciar la aplicación en desarrollo con lo que también ahorraremos tiempo. Además, también tenemos la posibilidad de añadir el parámetro -reloading en cualquier comando Grails.

Por último, si queremos desarrollar un plugin, hasta el momento no había más remedio que publicarlo en formato zip e incluir los archivos fuente de dicho plugin. Lo bueno que tiene esto es que si un plugin no hace exactamente lo que queremos podemos modificarlo a nuestro gusto y lo malo, es que nadie que quiera proteger su desarrollo, iba a subirlo como un plugin, con lo que muchas empresas no se implicaban en el desarrollo de estos plugins. Esto puede hacer que estas empresas terminen desarrollando plugins, aunque también será muy probable que terminemos pagando por ellos. Aunque como dicen por ahí, Nada es gratis y si algo nos soluciona un problema o nos ahorra horas de trabajo, es normal que tengamos que pagar por ello, ¿no?

La próxima semana veremos algunas mejoras introducidas en la parte web y GORM de Grails 2.0.


Menea esta noticia Busca en Technorati enlaces a esta nota Diggea esta noticia Añádeme a tu del.icio.us

CloudBees, BitBucket, Grails e Integración Continúa

22. junio 2011, 10:45
Se han desactivado los comentarios a este artículo.


En muchas ocasiones, el éxito de una idea reside en la rapidez con la que sepas llevarla a cabo y si esta idea además requiere de una aplicación, debes saber elegir que tecnologías y metodologías utilizar. Si por si fuera poco, el presupuesto inicial con el que cuentas es prácticamente nulo, debes acudir a soluciones gratuitas no significando esto que sean malas.

En este artículo voy a explicar como podemos utilizar CloudBees para desplegar nuestras aplicaciones en Grails utilizando como repositorio BitBucket y desplegando automáticamente las nuevas versiones de la aplicación a partir de los cambios subidos a nuestro repositorio.

Comencemos por BitBucket. BitBucket es un repositorio gratuito y privado (esto es muy importante ya que la mayoría no nos ofrecen esta privacidad) basado en Mercurial. Sí, ya sé que Mercurial no es de los sistemas de control de versiones más extendidos, pero si queremos esta privacidad y este precio (gratis), tenemos que conformarnos con esto.

BitBucket ofrece incluso colaboración entre usuarios hasta cinco de forma gratuita. Repito, pocos servicios ofrecen esto gratis. También puedes utilizar un wiki para generar documentación del proyecto e incluso tienen sistema de tickets integrado.

Pasemos al siguiente elemento de nuestro stack de aplicaciones que es “CloudBees”. CloudBees no es más que un servicio que te permite desplegar aplicaciones Java (o Grails en nuestro caso) en un servidor en producción. Esto se conoce como el RUN@Cloud. En la cuenta gratuita te permiten hasta 5 aplicaciones diferentes. Además de las aplicaciones, CloudBees también te ofrece la posibilidad de utilizar sus servidores de base de datos MySQL, también hasta 5 como máximo. Aquí es donde viene un problema con CloudBees y es que el tamaño máximo de estas bases de datos es únicamente 5 MB en la versión gratuita y el paso a la versión de pago la verdad es que me parece un poco cara (25$/mes por 1 GB). Ahí, no hay término medio.

La primera aplicación que desplegué en CloudBees fue el ManagerT1, esa aplicación que te permite jugar a la Fórmula1 con tu cuenta de Twitter y que la verdad es que no ha tenido mucho éxito, aunque ahí seguimos jugando un grupo de amigos (hasta que no regale un coche al ganador, creo que no voy a conseguir repercusión ;=)) y en ese momento, todavía no había nada de Integración Continua.

Sin embargo, recientemente y a raiz del artículo de Marco Vermeulen en el que hablaba de Integración Continua en CloudBees con Grails, me decidí a utilizarlo en las dos últimas aplicaciones que estoy realizando en la Universidad de Alicante (que por privacidad, no voy a poner aquí).

La integración continua de CloudBees se basa principalmente en una instancia de Jenkins (nuevamente gratuita) a la que puede agregarle tantas tareas quieras. Es lo que se conoce en CloudBees como el DEV@Cloud. Nosotros vamos crear una tarea, de tal forma que cada vez que se detecte un cambio en nuestro repositorio, se genere un nuevo archivo WAR y automáticamente se despliegue en nuestro servidor en producción. Por el momento no nos vamos a meter pruebas de cobertura, para no complicar demasiado el tema.

Pero antes de continuar, necesitamos instalar el plugin de cloudbees en nuestra aplicación Grails para facilitar el despliegue de la misma en nuestro servidor en producción. Para ello, simplemente ejecutamos en nuestro proyecto Grails el comando grails install-plugin cloud-bees que nos permitirá una serie de nuevos comandos en nuestra aplicación. Posteriormente a instalar el plugin, debemos también añadir unas entradas a nuestro conf/Config.groovy con unos datos que nos ofrece cloudbees en la página privada https://grandcentral.cloudbees.com/user/keys

cloudbees.api.url='https://api.cloudbees.com/api' cloudbees.api.key='CLOUD_BEES_API_KEY' cloudbees.api.secret='CLOUD_BEES_API_SECRET'

Básicamente, vamos a crear una tarea en Jenkins y la configuraremos de la siguiente forma (sólo especificaré aquellos campos donde debemos introducir información, el resto quedarán en blanco por defecto):

Datos generales
  • Nombre del proyecto: ManagerT1
  • Marcaremos Crear un proyecto de estilo libre
Configuración del origen del código fuente
  • Marcaremos sobre Mercurial
  • Repository URL: https://frangarcia:contraseña@bitbucket.org/frangarcia/managert1
  • Branch: default
  • Navegador del repositorio: BitBucket
  • URL : https://frangarcia:contraseña@bitbucket.org/frangarcia/managert1
Disparadores de ejecuciones
  • Marcaremos Consultar repositorio (SCM)
  • Programador: */5 * * * *
Ejecutar
  • De la lista Añadir un nuevo paso seleccionamos Build with Grails
  • Grails Installation: Grails 1.3.7
  • Marcaremos Force upgrade
  • Targets: clean test-app war “bees-app-deploy frangarcia/managert1 0.1.${env[‘BUILD_NUMBER’]} target/managert1-0.1.war”
Acciones para ejecutar después
  • Activate Chuck Norris (sí, lo tengo instalado, que pasa)
  • Marcar Notificación por correo
  • Destinatarios: Vuestra dirección de correo electrónico

Con esta configuración le estamos diciendo a Jenkins que cada 5 minutos compruebe si se ha producido algún cambio en el repositorio y en caso afirmativo realizará todas las operaciones especificadas en el target que terminarán por desplegar la nueva versión de nuestra aplicación, siempre y cuando todos los tests se pasen correctamente, esperando por supuesto que un maravilloso sol se pose sobre vuestra tarea en Jenkins lo que indicará que el despliegue ha ido perfectamente y que podéis seguir con el desarrollo de vuestra aplicación.


Menea esta noticia Busca en Technorati enlaces a esta nota Diggea esta noticia Añádeme a tu del.icio.us

« Entradas antiguas