marzo 11, 2010 General

Creando una startup. Definiendo el entorno de desarrollo

Hace unos días, a través de no recuerdo qué agregador de blogs, mi navegador me dirigió a un interesante post titulado Starting with the Startup – Setting Up Development Environment. Este post me llevó a otras entradas del mismo blog, en las cuales se explican las decisiones adoptadas por un equipo técnico a la hora de definir los procesos de desarrollo que se van a seguir en el seno de la startup.

La primera decisión que tomaron fue el uso de SCRUM como metodología de desarrollo de software. La siguiente cuestión que abordaron fue acerca del entorno y frameworks de desarrollo que utilizaría el equipo y que les permitiera conseguir un nivel de productividad elevado.

A continuación comento las decisiones que en este sentido adoptaron:

– Framework web: Comenta el autor que inicialmente tenían dos opciones por las que decantarse; una era Grails y la otra era Wicket. La decisión final fue Grails. Personalmente, mis últimos proyectos los estoy realizando con Grails y tengo que decir que se consigue un aumento de productividad importante programando con este framework. También considero muy interesante tener presente en una elección de este tipo la herramienta Spring Roo, que también ayuda a aumentar la productividad notablemente, sin la necesidad de utilizar lenguajes dinámicos como Groovy.

– Sistemas de build: Grails dispone de comandos para hacer los build de forma muy sencilla, pero dado que tenían que integrar los builds de Grails con los de otros proyectos, decidieron utilizar otra herramienta. Finalmente tuvieron que decidir entre maven e ivy, y dado que el soporte de ivy por parte de Grails es mejor que el de maven, optaron por utilizar ivy como herramienta para hacer los build. Personalmente considero que una herramienta muy a tener en cuenta actualmente entre los sistemas de construcción, y a la cual espero dedicar un post en un futuro, es Gradle, que reúne lo mejor de Ant, Ivy y Maven.

– Integración contiua: Deciden utilizar Hudson como servidor de integración continua debido a su facilidad a la hora de instalarlo, debido a su potente interfaz de gestión y al número de plugins que tiene.

– Bug tracker: Dado que gran parte del equipo ha trabajado con Mantis, deciden utilizar esta herramienta para gestionar los bugs. Es una herramienta que, personalmente, no he utilizado, así que me la anoto para probarla en cuanto pueda.

– Repositorio de librerías: Como utilizan librerías externas para el desarrollo de sus proyectos, deciden utilizar una herramienta que les permita gestionar las dependencias de las mismas, seleccionando Nexus para tal propósito.

– Sistema de control de versiones: Han decidido utilizar el que probablemente sea el sistema de control de versiones más extendido del mercado,  Subversion, a pesar de la existencia de nuevos sistemas, tales como Git.

– IDE: A pesar de no tener expeirencia con el IDE elegido, el equipo de desarrollo ha decidido utilizar IntelliJ Idea dado que este IDE proporciona un buen soporte para Grails. La verdad es que personalmente estoy bastante satisfecho con SpringSource Tool Suite para programar con Grails.

¿Qué os parece el conjunto de herramientas comentado en este post para llevar a cabo el proceso de desarrollo de software? ¿Qué herramientas utilizáis vosotros que os faciliten el proceso de desarrollo y que os permitan obtener un alto nivel de productividad?

  1. Me parece una propuesta acertada y en línea con lo que yo haría. Personalmente apuesto por la siguiente pila tecnológica:

    – Springsource Tool Suite
    – Spring Roo
    – Vaadin para la capa de presentación (permite programar las interfaces con Java, sin necesidad de agregar más perfiles al equipo), aunque si el proyecto requiere ser enormemente escalable apostaría por capa de servicios REST con Javascript.
    – Maven, Nexus, Hudson y Sonar, sin duda.
    – Subversion
    – JIRA y GreenHooper para la gestión.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Back to top