Hace un tiempo escribí una especie de manuales para una empresa que vendía un supuesto producto a muy buen precio. Lo de supuesto sólo se entendería si se viese el código (a distancia y con gafas de protección) y se hubiese disfrutado del proceso de instalación en un nuevo cliente. El proceso de desarrollo en sí… digamos que no tenía proceso. El código se vomitaba sobre un editor y se machacaba con una bayeta sucia hasta que el navegador mostraba algo. Toda la empresa funcionaba, a partes iguales, gracias a grandes dosis de buenrollismo y un gran despliegue de cancamusa ante los clientes.
Engañado por vagas esperanzas de remuneración económica, intenté que entendiesen una serie de cosas sobre cómo debería funcionar la cosa. Obviedades todas ellas. Pero que parecen magia negra para los “expertos”.
Sobre el entorno de desarrollo
Cada programador tiene sus preferencias, tanto en plataforma como en herramientas. Eso es normal y, hasta cierto punto, aceptable. En la medida de lo económicamente posible incluso aconsejable: cuando un “artesano” está cómodo con sus herramientas la productividad aumenta. Y si tiene dos pantallas aún mejor.
Lo que no es negociable es que cada máquina de desarrollo tiene que contar con un entorno servidor normalizado:
- Cada ordenador tiene que tener activo un servidor Apache con PHP (y los módulos de PHP necesarios para el tipo de producto que se desarrolle) y un servidor MySQL.
- Todas las versiones han de estar sincronizadas. La versión de PHP y de MySQL en cada máquina ha de ser la misma. Y estas han de ser la misma que en el servidor de producción.
- Aunque lo deseable es que ambas estén relativamente actualizadas (sin caer en el error de estar siempre a la última) hay que alcanzar un compromiso en función de la plataforma sobre la que se instalará el producto. Una solución para esto es tener múltiples entornos de prueba y tener un único entorno de desarrollo.
Aparte de este entorno de desarrollo normalizado hay que disponer de una serie de heramientas o utilidades comunes para automatizar la gestión de versiones y la realización de copias de seguridad. Algo tan sencillo como homogeneizar los compresores a rar o gzip, que son gratuitos, en lugar de winzip o de tener un cliente de subversion en cada máquina.
Sobre el entorno de pruebas
Es INDISPENSABLE que, para cada servidor de producción exista un servidor de pruebas con las mismas versiones del software servidor. Desarrollar para MySQL 5.0 y encontrarse con que el cliente tiene 4.0 o incluso programar con una versión 4.24 y encontrarse con que el servidor de producción se quedó en la 4.12… El producto dará fallos.
Lo ideal es que el servidor de producción esté actualizado al menos hasta las versiones mínimas soportadas por cada producto pero eso no siempre es posible. En el caso en que sea nuestra propia plataforma es posible que haya productos viejos que no funcionen correctamente con nuevas versiones de MySQL (puede haber problemas al pasar de 4.x a 5). En el caso de que el servidor del cliente esté en un ISP es posible que no se puedan actualizar los servidores.
Aquí tenemos que trabajar en distintos niveles:
- A la hora de presupuestar el producto hay que adjuntar las especificaciones y requisitos técnicos. El producto o servicio X se instala sobre un servidor que tenga instalado el software Y, Z y Q con estas versiones.
- En caso de que no se pueda cumplir con la primera premisa hay que instalar un entorno de pruebas con la misma configuración de software que el servidor del cliente, instalar el producto, testear y hacer las modificaciones oportunas. Tanto este entorno de pruebas como la versión modificada para el mismo han de conservarse.
Este entorno de pruebas tampoco es negociable. Cada implantación se realizará primero sobre el entorno de pruebas antes de pasar al entorno de producción. Hay que invertir en software de virtualización para poder instalar distintos servidores sobre la misma caja Linux y tener los entornos de pruebas necesarios operativos.
Sobre las especificaciones y requisitos de cada producto
Al hilo de lo escrito más arriba surje una necesidad: para cada producto hay que definir cláramente sus requisitos, tanto de hardware como de software. Estos requisitos no se limitan a saber que requiere la versión tal o cual de PHP y de MySQL. Además hay que saber:
- los módulos de PHP necesarios para su correcto funcionamiento y
- los privilegios de acceso necesarios en los distintos directorios.
De esta manera es sencillo preparar un script que determine la idoneidad de un servidor para instalar cada producto.
Sobre instaladores y otros automatismos
Hay que huir de las instalaciones manuales e ir hacia un modelo de instalador automático. Este instalador debe, una vez copiado el paquete y descomprimido en el servidor correspondiente:
- Comprobar que el servidor tiene las versiones necesarias para instalar el producto,
- preguntar al usuario los detalles de la instalación (claves de MySQL, nombre, colores, lo que haga falta),
- crear las tablas necesarias y
- escribir el archivo de configuración.
Los productos irán empaquetados con tar y gzip, de manera que la instalación sea tan sencilla como:
- Copiar el paquete en el directorio correcto del servidor,
- ejecutar tar –xvf producto.tar.gz y
- desde el navegador ejecutar el script de instalación, algo como www.producto.tal/_admin/setup.php.
Esto era ello, más o menos.
Para muchos que se dedican a esto de la programaçao en serio les sonará a obvio. A lógico. Para muchos “expertos” sigue siendo magia negra.