Por José Othoniel Chamú Arias y Alberto González Guízar
En el desarrollo de los productos de software intervienen diversas etapas, una de ellas es la codificación de los requerimientos funcionales y no funcionales, conocida como desarrollo; posteriormente es la revisión del cumplimiento de dichos requerimientos en el software y la usabilidad que muestra para los usuarios, que se conoce como aseguramiento de la calidad o pruebas. Por último, es puesto en operación para brindar un servicio a los usuarios que lo utilizarán.
Para la ejecución de las actividades que comprenden las etapas antes mencionadas, se ocupan espacios de trabajo donde los equipos de desarrollo y pruebas puedan llevarlas a cabo, así como uno donde pueda operar el sistema o aplicación, conocidos como ambientes de trabajo, dentro de un servidor o ambiente virtual.
El ambiente de desarrollo se usa para integrar el código de los diferentes componentes del equipo de programación, así como los elementos que forman el sistema de información o aplicación, como son: lenguajes, librerías, frameworks, base de datos, entre otros. De igual manera, se puede hacer uso de herramientas que apoyen al entorno de desarrollo, como, por ejemplo, el Subversion o el GitLab, que ayudan a gestionar el código fuente, para el control de versiones y su reutilización.
Por otro lado, el ambiente de pruebas tendrá las mismas características de configuración y recursos que el ambiente de trabajo anterior, pero aquí se despliegan las versiones estables del sistema o aplicación para que el equipo de pruebas realice las verificaciones de calidad pertinentes, por ejemplo: pruebas de funcionalidad, usabilidad, entre otras, para su mejora o corrección, sin interferir con las actividades de trabajo del equipo de desarrollo. Otra actividad que se realiza en este ambiente son las pruebas de seguridad, para verificar que no existan vulnerabilidades que comprometan su integridad y disponibilidad, así como verificar el impacto de su mitigación en el sistema o aplicación.
En algunos casos, se puede considerar un ambiente de preproducción, sobre todo si se hará una actualización de un sistema o aplicación que ya esté en producción. Este es una versión parecida del ambiente final que se tendrá en operación, en cuanto a plataforma, aplicación y recursos de hardware. Su finalidad es la de probar actualizaciones del sistema, realizar pruebas de carga y desempeño, así como la validación de la seguridad, realizándose la afinación del ambiente en cuanto a parámetros a nivel del sistema operativo y de las herramientas utilizadas, como: Apache, Tomcat, Framework: CakePHP, Laravel, Spring, entre otros, y los ajustes necesarios de seguridad al sistema o aplicación. En este ambiente se verifican los criterios definidos para su puesta a producción, también se puede utilizar para validar los cambios solicitados al sistema o aplicación, así como a configuraciones en los ambientes de producción y poder observar comportamientos anómalos que pudieran presentarse, realizándose los ajustes que se requieran.
Por último, el ambiente de producción es el espacio donde operará el sistema o aplicación, es decir, es donde se hace uso del servicio por parte de los usuarios finales. Aquí se realizan los ajustes a los elementos necesarios para mantener la disponibilidad del servicio y se programan los respaldos del ambiente.
De acuerdo con lo anterior, se recomienda gestionar diferentes ambientes o entornos de trabajo en los servidores o equipos virtuales, para el desarrollo, pruebas y puesta en producción de los sistemas de información, debido a que cada equipo de trabajo requiere ciertas características específicas en cuanto a la configuración y recursos de cada uno.
Cabe señalar, que al utilizar un mismo ambiente de trabajo para desarrollo y pruebas puede afectarse el trabajo llevado a cabo por cada equipo, por ejemplo, al moverse el código que están desarrollando o modificando los programadores, pueden resultar afectadas las actividades de pruebas que se estén realizando al mismo tiempo, presentándose errores en la funcionalidad.
Así mismo, si el sistema ya está en producción y se están llevando a cabo cambios en la funcionalidad o configuración y/o efectuando pruebas de carga – desempeño, puede verse afectada la operación del servicio, lo cual da una mala imagen y crea desconfianza en cuanto a su utilidad.
Por ello, es importante mantener separados los ambientes de trabajo: desarrollo, pruebas y producción como una buena práctica.
Sin embargo, no necesariamente se tiene que tener un servidor físico por cada ambiente, como una alternativa a ello, se pueden virtualizar los servidores físicos con el uso de herramientas, algunas de las cuales son de licenciamiento comercial y otras de licencia pública. Para poder utilizarla se requiere que el equipo soporte la tecnología de virtualización, en Intel recibe la denominación VT-x y en AMD conocida como AMD-V, además se aconseja disponer al menos de un servidor de mediana capacidad (8 núcleos, 64 GB RAM) para implementar al menos 2 o 3 máquinas virtuales.
El hacer uso de la virtualización permite a los administradores aprovechar mejor la capacidad de los servidores, reduce el tiempo de inactividad, ahorra energía, reduce tiempos de recuperación o de instalación, al hacer respaldos de las máquinas virtuales o clonar ambientes.
Una de estas herramientas es el dúo KVM-Qemu, donde KVM es el software para implementar la virtualización en Linux, y Qemu es el hipervisor, el cual tiene una Licencia Pública General de GNU, por lo que se puede usar sin un costo, y se encuentra en diversas distribuciones de Linux: CentOS, Fedora, Debian, Ubuntu, por citar algunas.
Otra de las ventajas de esta herramienta, es que tiene la capacidad de ejecutar múltiples sistemas operativos simultáneamente: Windows y Linux, además al ser parte del kernel de Linux, KVM obtiene correcciones de errores y actualizaciones de seguridad a medida que la distribución de Linux utilizada publica nuevas versiones.
Como conclusión, se puede observar la importancia de mantener separados los ambientes de desarrollo, pruebas y producción para no afectar el trabajo entre los equipos, y en el caso de los usuarios finales no se afecte su acceso y utilización del sistema o aplicación, con la consecuente molestia y/o pérdida de confianza en el servicio.