Una buena práctica, común en equipos de desarrollo ágil, es asegurar que los desarrolladores poseen su propio entorno donde trabajar. Un entorno es un espacio técnico que posee un alcance bien definido y respetado. La principal ventaja de los entornos es que ayudan a reducir los riesgos debido a errores técnicos que puedan afectar de forma adversa a un grupo de personas mayor al absolutamente necesario.

El modelo de desarrollo, testing y producción es esencial para proveer los controles y el balance necesario para ejecutar un entorno de producción de alta disponibilidad de forma eficiente.



Creando aplicaciones en cuatro capas

Desarrollo: Opcional. Es el entorno de trabajo para desarrolladores individuales o pequeños equipos de desarrolladores. Trabajando de forma aislada con el resto de las capas, los desarrolladores pueden probar cambios radicales en el código sin afectar de forma adversa al resto del equipo de desarrollo. Estos entornos suelen estar ubicados directamente en las estaciones de trabajo de cada desarrollador.

Integración: Un entorno común donde todos los desarrolladores hacen "commits" de los cambios en el código. La meta de este entorno es combinar y validar el trabajo del equipo completo del proyecto para que pueda ser testeado antes de ser promovido al entorno de testing. Es posible que los entornos de desarrollo e integración sean el mismo entorno.

Testing: La capa de testing es un entorno lo más idéntico posible al entorno de producción. El propósito principal del entorno de testing es simular al entorno de producción con el fin de testear las actualizaciones (en un entorno similar al de producción) para asegurar que las mismas no corrompen la aplicación existente en los servidores en producción. De esta forma se minimizan las caídas del sistema en producción. Además, este entorno puede funcionar tanto como demo como para entrenamiento y capacitación de los usuarios.

Producción: La capa de producción puede incluir un servidor único o un cluster de servidores. Es el entorno donde trabajan los usuarios finales y se trabaja con los datos de negocio.

Estas capas hablan de "entornos" en lugar de "máquinas" o "servidores". Es posible que se encuentren en el mismo servidor físico múltiples entornos de desarrollo y el entorno de integración, o el entorno de integración y el entorno de testing. El entorno de producción debe estar aislado y no debe compartirse con cualquiera de los otros entornos.

Recursos en cada capa

Testing

• El entorno de testing debe poseer una configuración de software idéntica a la del entorno en producción y una copia completa e independiente de la base de datos de producción para que sea una base real para el análisis QA ("Quality Assurance", control de calidad).

• La configuración de hardware debe ser comparable a la del entorno de producción para que se pueda realizar una predicción precisa de la capacidad del sistema mediante tests de performance.

Integración

• El entorno de integración debe funcionar con un subconjunto limitado de datos que se utiliza para testear la aplicación. Es recomendable refrescar este conjunto de datos frecuentemente para eliminar artefactos producidos por el desarrollo y testeo del software.

Desarrollo

• Similar al entorno de integración

Moviendo entre capas

Los desarrolladores de software escriben código en su entorno de desarrollo y hacen "commits" en el entorno de integración. Aunque los entornos de desarrollo e integración pueden ser un mismo entorno.

Cuando los desarrolladores están conformes con el comportamiento del entorno de integración (ha alcanzado una cierta estabilidad), se actualiza el entorno de testing ("deploy"). A partir de este momento los testers QA comienzan una nueva revisión. Los testers QA están formados por miembros internos del staff y revisores externos (por ejemplo, usuarios clave). El entorno de testing sirve además como entorno de entrenamiento cuando está listo para liberar una actualización en producción (llamada "release").

Los reportes QA se envían de vuelta a los desarrolladores, quienes se encargan de resolver los errores ("bugs"). Luego de que todos los errores son resueltos, se entrega una nueva versión en testing.

Este proceso continúa hasta que el equipo QA declara que la versión en testing está "lista para ser liberada a producción". El administrador de entornos (llamado "release manager") aplica la versión de testing en los servidores en producción.

A medida que avanza el tiempo, se hacen reportes de errores y pedidos de nuevas características y funcionalidades ("features") por los cuales los desarrolladores escriben nuevo código y comienza nuevamente el ciclo de desarrollo-testing-producción. Este proceso se repite hasta que los usuarios finales están completamente satisfechos ("forever").

El trabajo en el entorno de desarrollo es altamente iterativo y se traslada frecuentemente al entorno de integración. El traslado al entorno de testing es menos frecuente, típicamente al final de una iteración o "sprint" (en terminología de desarrollo ágil o "scrum").

Hay mayor control sobre cuándo trasladar al entorno de testing debido a que es un recurso típicamente compartido entre equipos de desarrollo, testers QA y usuarios clave. Por lo tanto alguien debe verificar que el sistema ha sido lo suficientemente testeado de forma aislada y está listo para el pasaje a testing.

De forma similar debe ser aún más difícil migrar a producción, una actividad que es menos frecuente, debido a que debe demostrarse que la aplicación ha sido debidamente testeada y parece integrarse correctamente en la infraestructura.

Es común que se cumpla un proceso de aprobación para asegurarse que todas las partes interesadas han verificado la aplicación antes del pasaje desde testing a producción.

Una delgada línea divide quien debe tener autoridad de aprobación y quien debe supervisar el proceso. Como mínimo, el equipo de soporte técnico de servidores debe tener la autoridad de aprobación sobre cualquier actualización antes de pasar a producción. Necesita tener el poder de veto antes de que el contenido pase a producción, ya que el equipo de soporte es el principal responsable por el uptime de los servidores en producción.

Debido a que el equipo de soporte debe asegurar que el entorno de testing sea idéntico al de producción, se debe evitar que los desarrolladores puedan modificar código en testing de forma indiscriminada.

Si no se tienen bien delimitadas las responsabilidades y los desarrolladores tienen libre acceso al entorno de testing, se termina ejecutando un entorno en pobre estado de salud. La mejor evidencia de no tener definido un buen modelo desarrollo-testing-producción es el "dedo acusador". Cuando algo no funcione, el equipo de soporte acusará a los desarrolladores por trasladar código erróneo. Del mismo modo, los desarrolladores culparán al sistema operativo. Estas situaciones dificultan e incrementan los tiempos necesarios para determinar las causas de eventuales fallas en testing.

La situación se agrava aún más cuando se trata de un pasaje de testing a producción, debido a la criticidad de los entornos involucrados.

Principios importantes

Los desarrolladores sólo hacen cambios en los entornos de desarrollo e integración. Si se debe resolver un error, un desarrollador lo hace en la etapa de integración. Para mantener la integridad del repositorio de código fuente en ningún momento un desarrollador debe realizar cambios directamente en los entornos de testing o de producción.

Para cada traslado ("deploy") a producción, existen múltiples versiones en testing y por cada traslado a testing, existen múltiples versiones en desarrollo/integración. Por diseño, los usuarios finales están aislados del rápido y ocasionalmente inestable proceso de desarrollo de software. Se asume que la mayoría de los errores serán capturados de forma temprana y más rápidamente en las primeras etapas.

Sólo el administrador de entornos ("release manager") puede liberar versiones a la siguiente etapa. Pueden existir diferentes administradores para liberar desde integración a testing y de testing a producción. Aunque lo más importante es que siempre debe haber una única persona responsable para liberar una nueva versión.

Estándares de codificación

• Para facilitar la transferencia de aplicaciones desde los servidores de desarrollo a través de la etapa de testing hasta producción, el código debe ser libre de cualquier variable dependiente del servidor.

• De ser necesario, se debe determinar el hostname programáticamente en lugar de especificarlo explícitamente en el código o en la configuración.

• Para asegurar que el código es portable entre sistemas de archivos se deben utilizar rutas relativas y de ser necesario establecer el directorio base en la configuración de la aplicación (tanto para directorios en el FS como para direcciones URL). Esto permite que las aplicaciones y scripts puedan moverse de un directorio en el servidor de desarrollo a otro directorio (posiblemente con distinto path) en el servidor en producción.

• La configuración de base de datos debe estar centralizada en un único archivo para simplificar el proceso de migración.


Tal vez pueda interesarte


Compartí este artículo