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.
