Muchas veces surge la pregunta de que igual que tenemos un único entorno de test, de pre-producción, de producción…¿podemos tener un único entorno de desarrollo compartido para los desarrolladores?
A excepciones de casos particulares, en los que sea muy complicado replicar ciertas características del entorno, lo que me suelo encontrar, es que si hablamos de código, tenemos asumido que un único entorno compartido para todos no es bueno.
Por ejemplo, tener un único servidor de aplicaciones en remoto, compartido por todos los desarrolladores, donde vayamos a subir nuestros cambios no es buena idea.
Primero porque al estar en remoto, es muy probable que al desplegar código en ese entorno tardemos más tiempo que si estuviera en local.
Y en desarrollo solemos hacer muchos cambios y muchas pruebas, por lo que perderíamos tiempo continuamente.
Pero lo más importante de todo es que ese entorno se va a usar continuamente por todo el equipo.
Yo programaré, y querré ver en un entorno real que las cosas que he programado funcionan como yo espero.
A la vez, otro compañero programará algo y querrá probarlo. Y para ello lo subirá a ese entorno, sobreescribiendo mis cambios.
O simplemente alguien subirá algo que romperá el entorno. Estamos en desarrollo, equivocarnos, experimentar, solucionar las cosas y llegar a la solución buena es la norma.
Por ello tener un único servidor de aplicaciones en remoto para todos es un caos.
El enfoque que más me encuentro es que esto lo solemos tener asumido. Así que aunque tengamos un entorno común para probar los cambios de todo el equipo, cada desarrollador suele tener su servidor de aplicaciones, su tomcat (o lo que tu aplicación utilice), en local, para ir probando todo esto.
Peero…lo más frecuente que veo es que esos servidores apunten a un único servidor de base de datos, donde están todos los datos de prueba de desarrollo y donde todo el equipo puede hacer modificaciones.
La verdad es que es tentador. Tendremos la última versión del esquema de base de datos de todo el equipo de desarrollo en ese servidor, y cualquier cambio de base de datos puede verlo todo el equipo.
Además de que tenemos un conjunto de datos de prueba comunes para el equipo.
Pero, igual que tenemos asumido que debemos tener un servidor de aplicaciones en local porque el código va a cambiar muy a menudo para no perjudicar al resto del equipo, ¿por qué no vemos igual la base de datos?
Es cierto que en ciertos desarrollos el esquema no suele variar muchísimo y los cambios que se hacen no suelen afectar a los otros desarrolladores.
Pero puede pasar. Si no hay comunicación, puede que un cambio de base de datos haga que no funcione el código de otro compañero en local (ya que su entorno apunta a esa base de datos común).
Mi opinión suele ser: o tenemos una buena comunicación entre todos, o tenemos un DBA al que le notifiquemos los cambios y avise al resto del equipo…O que cada desarrollador tenga su entorno local, con su base de datos en local, con un conjunto de datos de prueba comunes para todos.
Facilitémonos la vida. ¡Existen herramientas para recrear dichos entornos! ¡Y para recrear automáticamente la base de datos con sus datos de prueba!
¿Qué opináis vosotros?
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Por experiencia NO es bueno tener que un servidor de BD compartido para todo el equipo de desarrollo. Se puede armar un enredo considerable dependiendo de la envergadura del proyecto.
Lo que SI me pareció una buena práctica en un proyecto fue que el director del proyecto ajustara los roles al equipo de desarrollo, como un administrador del servidor de la base de datos que dé permisos en función de los roles de los programadores que se dedicaban a varios segmentos del proyecto.
Claro que el director del proyecto dio especificaciones muy claras del diseño del proyecto, al igual para asignar a cada desarrollador o equipos de desarrollo su función, algo que he visto muy poco en jefes de proyectos y SI ha resultado muy efectivo a la par de productivo.
¡Gracias! Interesante iniciativa. En poco sitios he visto que cada uno tenga super clara su función. Al final creo yo, una gran parte de los problemas vienen por temas de coordinación/comunicación/no tener las cosas claras.
Hola Ana… muy buen artículo. ¿A cuales te refieres con «Existen herramientas para recrear dichos entornos! ¡Y para recrear automáticamente la base de datos con sus datos de prueba!» ?
Gracias !!
Hola! Y gracias 🙂
Pues por ejemplo (claro está que tendrás que ver si puedes adaptarlo a las condiciones de tu entorno de desarrollo) me refiero a herramientas como:
– Vagrant (https://www.vagrantup.com/) para gestionar máquinas virtuales. Lo usaría como base.
– Herramientas como Puppet (http://puppetlabs.com/puppet/what-is-puppet), o Ansible (http://www.ansible.com/configuration-management) para automatizar las configuraciones de las máquinas del entorno. O Docker (https://www.docker.com/whatisdocker/).
Para recrear las bases de datos con sus datos de prueba:
– Un buen versionado de la base de datos puede facilitarte mucho la creación de nuevos entornos. Tienes que ser capaz de coger del control de versiones la última versión de código y su base de datos asociada.
Hablo tanto de un buen versionado manual, como Flyway (http://flywaydb.org/), Liquidbase (http://www.liquibase.org/) etc.
– Si no, una herramienta que me resulta bastante útil es DbUnit (http://dbunit.sourceforge.net/). La idea de esta herramienta es crear un conjunto de datos de prueba e insertarlos en la base de datos antes de ejecutar un test y luego borrarlos (o no).
Se puede utilizar esta funcionalidad también para lo que me preguntabas, aunque tienes que indicar el conjunto de datos en formato XML para que DBUnit lo entienda, y puede ser algo tedioso.
Aún así en este punto sigo probando herramientas, a ver si encuentro alguna mejor que ésta 🙂
Hola Ana, en mi experiencia, al inicio tuvimos la base de datos centralizada en un solo servidor, pero al pasar el tiempo y estar trabajando en desarrollos paralelos, nos fue un tanto difícil continuar y es nos paso justamente lo que mencionas en el artículo «puede que un cambio de base de datos haga que no funcione el código de otro compañero en local», nos hemos visto por que cada programador tenga su propia replica tanto de base de datos, como su código (centralizado a nivel de repositorio).
Ahora los problemas son distintos y es mas que todo a tener los cambios de esquema centralizado, así como las configuraciones de cada aplicación en particular.
Tecnología: PHP+MySQL
Saludos y buen post!
José
Tengo mucho tiempo trabajando de manera remota y no encontre una manera más ágil de trabajar que recreandome localmente mi ambiente de desarrollo, tal vez no sea posible en todos los casos, pero eso me ahorro mucho tiempo, afortunadamente resultaba fácil recrear los ambientes de trabajo, pero si me gustaría conocer las herramientas de las que hablas.
Como todo en este mundo, creo que depende del tipo de desarrollo que estemos hablando. Cuando lo que tenemos delante es sistemas o productos con cientos de tablas relacionadas, muchas dependiendo de productos ajenos al nuestro, mantener un entorno local puede ser una tarea de titanes.
Hola Javier,
De normal nosotros tenemos un entorno MAMP en nuestro local con nuestras respectivas BBDD ya que llegamos a la misma conclusión que tu, por ahora es lo que mejor nos funciona, aparte que cada uno puede trabajar desde casa y sin necesidad de internet.
Saludos,