En la comida en Barcelona que hizo la empresa por el mes de Junio, un programador de una de las empresas invitadas, nos planteo a Edu y a mí un problema que le acuciaba y creo que todo el mundo que ha desarrollado aplicaciones web, se ha enfrentado al mismo problema.
Uno va creando el programa en su ordenador local, alli tiene su servidor web y de base de datos, donde va escribiendo líneas y más líneas de código. Llega un momento, en que eso que tienes, lo llevas al servidor 'de producción'. Utilizando un programa de FTP lo llevas todo, luego inicializas la base de datos y retocas algún que otro fichero de configuración. Si todo va bien, tienes tu aplicación funcionando en el servidor.
Pasado un tiempo, continuas con el desarrollo en el ordenador local, y tocas varios ficheros fuentes para solventar errores y añadir cosas nuevas. Evidentemente, esto tienes que subirlo al servidor de producción. Es justamente cuando surge el problema. No recuerdas que ficheros han sido los que has actualizado, ni cuales has añadido. Entonces terminas hecho un lío, y por el caminio te olvidas de algún que otro fichero, actualizas innecesariamente otros, etc. Es un jaleo de cuidado.
Esto todavía se complica cuando son varias personas las que estan desarrollando conjuntamente. Que si no sabes que ficheros se han actualizado, que si machacas la version del servidor por tu copia local que era mas antigua. Mucho más jaleo.
Para eso se inventó el CVS. Todo el mundo tira del CVS para sincronizar la versión que tiene en local, con la que existe en el CVS que contiene las últimas versiones de todo el mundo. Y cuando alguien hace algún cambio, el cliente de CVS realizar los commits de los ficheros que han sido modificados. Hasta aqui nada raro, es describir la funcion del CVS.
Mirando un poco más lejos, ¿por qué no llevar el contenido del CVS al propio servidor en produccion?. Igual que los programadores hacen updates para sincronizar la versión que tienen de su código respecto a la última existente, hacer que el propio servidor (o servidores) sea el que haga esos mismos checkout/update del código para llevar los últimos cambios a su DocumentRoot, evitando todo el problema del FTP anterior y con la ventaja, de no ser necesario acceder por ftp al código del servidor.
Con esto te despreocupas, de esos momentos de dudas frente al ftp. ¿Fin de la historia? Aún hay algo más, la sincronización con el servidor se puede hacer automatica programada en crontab o manual, en la que el responsable del proyecto sea el encargado de hacer los updates.
Resumiendo ventajas de lo anterior:
Uno va creando el programa en su ordenador local, alli tiene su servidor web y de base de datos, donde va escribiendo líneas y más líneas de código. Llega un momento, en que eso que tienes, lo llevas al servidor 'de producción'. Utilizando un programa de FTP lo llevas todo, luego inicializas la base de datos y retocas algún que otro fichero de configuración. Si todo va bien, tienes tu aplicación funcionando en el servidor.
Pasado un tiempo, continuas con el desarrollo en el ordenador local, y tocas varios ficheros fuentes para solventar errores y añadir cosas nuevas. Evidentemente, esto tienes que subirlo al servidor de producción. Es justamente cuando surge el problema. No recuerdas que ficheros han sido los que has actualizado, ni cuales has añadido. Entonces terminas hecho un lío, y por el caminio te olvidas de algún que otro fichero, actualizas innecesariamente otros, etc. Es un jaleo de cuidado.
Esto todavía se complica cuando son varias personas las que estan desarrollando conjuntamente. Que si no sabes que ficheros se han actualizado, que si machacas la version del servidor por tu copia local que era mas antigua. Mucho más jaleo.
Para eso se inventó el CVS. Todo el mundo tira del CVS para sincronizar la versión que tiene en local, con la que existe en el CVS que contiene las últimas versiones de todo el mundo. Y cuando alguien hace algún cambio, el cliente de CVS realizar los commits de los ficheros que han sido modificados. Hasta aqui nada raro, es describir la funcion del CVS.
Mirando un poco más lejos, ¿por qué no llevar el contenido del CVS al propio servidor en produccion?. Igual que los programadores hacen updates para sincronizar la versión que tienen de su código respecto a la última existente, hacer que el propio servidor (o servidores) sea el que haga esos mismos checkout/update del código para llevar los últimos cambios a su DocumentRoot, evitando todo el problema del FTP anterior y con la ventaja, de no ser necesario acceder por ftp al código del servidor.
Con esto te despreocupas, de esos momentos de dudas frente al ftp. ¿Fin de la historia? Aún hay algo más, la sincronización con el servidor se puede hacer automatica programada en crontab o manual, en la que el responsable del proyecto sea el encargado de hacer los updates.
Resumiendo ventajas de lo anterior:
- Control del código en desarrollo. El CVS te permite tener controlado los cambios que se van produciendo, con su histórico y quien lo hizo.
- Seguridad del fuente en desarrollo. El código del desarrollo esta en un máquina que no tiene nada que ver con la de producción, que esta dando la cara.
- Control de lo que hay en produccion. En produccion siempre tienes lo último, nadie toca alli, salvo cuando se hagan los updates para actualizarlo.
- Mayor seguridad del código en producción. Al hacerse las actualizaciones del fuente por CVS, no es necesario tener FTP para acceder a donde esté el desarrollo, ni que se toque por FTP.
- Ahorra tiempo de desarrollo e implantación.
- Soluciona el problema de la sincronización entre el código del servidor en producción, respecto a la última versión disponible.
Y los inconvenientes:
- Aprender una forma nueva de hacer las cosas. Utilizar un CVS no es trivial, además de que su forma de utilizarlo obliga a ser más ordenadito.
[Esta es la publicación de un pequeño draft que tenia guardado y sobre el que iré ampliando para hacer algo más interesante y completo]
No hay comentarios:
Publicar un comentario