Entornos en el desarrollo de software

En lo que a desarrollo de software se refiere, como en casi cualquier otra profesión, disponer de un entorno de trabajo adecuado puede marcar la diferencia entre obtener un gran resultado o que nuestro trabajo sea un completo desastre.

Al respecto de esto, uno de los aspectos al que más atención deberemos de prestar es al diseño de los distintos entornos que participan en el ciclo de vida del software y a los procedimientos que definen el flujo de trabajo entre ellos.

Diseño flujo

Y para que todos tengamos en mente el mismo concepto de la palabra entorno, lo definiremos cómo un sistema formado por hardware y software, así como la configuración, circunstancias y estados relativos a él. En el diseño de nuestro procedimiento podemos establecer varios entornos con distintos fines por los que debe pasar el software durante su ciclo de vida antes de llegar al definitivo entorno de producción.

Un diseño para cada necesidad

El número de etapas, los procesos que las definen y los softwares que utilizamos pueden variar en función de las características de cada proyecto y la idiosincrasia de cada compañía.

Algunos de los factores que pueden influir a la hora de decidir que entornos incluiremos en nuestro flujo de trabajo y que procedimientos los definirán son el tamaño del proyecto, la complejidad del software, las tecnologías utilizadas para el desarrollo, la cantidad de desarrolladores implicados en el proyecto, la metodología de desarrollo elegida o la criticidad del software.

Los tipos de entorno

En esta entrada repasaremos un conjunto de entornos bastante común, muy completo y que funciona bien en el desarrollo de aplicaciones web con equipos pequeños o medianos y  metodologías de desarrollo ágiles. Esta configuración es solo un ejemplo, es perfectamente adaptable a otras necesidades y trasladable otros proyectos con similares (e incluso distintas) características.

Entorno de desarrollo

Es el lugar dónde programamos, lo más habitual es que esté localizado en la propia máquina de cada desarrollador de forma que varias personas pueden estar trabajando en un mismo proyecto a la vez sin molestarse.

Para minimizar incidencias en etapas posteriores es recomendable que este entorno disponga de un software y una configuración lo más parecida posible a la que nos encontraremos en el entorno de producción. Situaciones como desarrollar sobre php 7.2 y que el entorno de producción se encuentre corriendo php 5.6 o hacerlo sobre windows con el driver «x» de sql server y que el servidor de producción sea una máquina linux con el driver «y» suelen acabar generando muchos quebraderos de cabeza fácilmente evitables.

Solo cuando el desarrollador completa un código perfectamente funcional e integrable en el entorno de pre-producción y tras realizar las pruebas necesarias para asegurar que el software desarrollado tiene la estabilidad suficiente  se podrá pasar al entorno de integración continua.

Entorno de integración continua

Este entorno cumple un triple objetivo:

  1. Integrar el trabajo de los diferentes desarrolladores en un repositorio central, dando como resultado una versión del código actualizada y consolidada.
  2. Automatizar las pruebas de integración y su validación antes de ser movido al siguiente entorno.
  3. Enviar el código al siguiente entorno si las pruebas han sido superadas satisfactoriamente.

La forma más habitual de implementar este entorno es mediante un software de control de versiones, dónde Git es la opción más popular. Una vez consolidado el código utilizamos los hooks para ejecutar las pruebas definidas, notificar los resultados y enviar a pre-producción si es preciso.

Entorno de pre-producción

Una vez superadas las pruebas de integración en el entorno de integración continua, el código será movido al entorno de pre-producción. Aquí se realizarán las pruebas de validación al conjunto del software, teniendo como objetivo localizar cualquier error antes de llegar al entorno de producción y evitar así los problemas derivados de ellos.

Este entorno será completamente funcional a nivel de usuario, y si hemos recomendado que el entorno de desarrollo fuese lo más similar posible al entorno de producción, aquí se convierte en algo crítico. Tanto el software, dónde no solo hablamos de las aplicaciones si no también de sus versiones y configuraciones, como el hardware y los sets de datos. Cuanto mayor sea la similitud con el entorno de producción menor será el número de  incidencias que nos encontremos cuando el software esté en productivo.

Entorno de demo

Es un entorno muy similar al de pre-producción, y por lo tanto al de producción. Lo habilitamos para que el cliente final pueda probar la nueva aplicación o las modificaciones o correcciones realizadas a la aplicación existente. De aquí extraeremos las impresiones del cliente y localizaremos de una forma temprana posibles carencias en los requisitos iniciales, en el diseño o en su implementación.

Si en nuestro proyecto la validación del cliente es necesaria, no disponer de este entorno puede suponer que el cliente valide contra el entorno de pre-producción (o mucho peor aun contra el de desarrollo o de producción), en cuyo caso pueden darse varias situaciones:

  1. Que todo salga maravillosamente bien, improbable pero posible.
  2. Que una nueva actualización en el entorno de pre-producción, esté o no relacionada con la funcionalidad que estamos probando, provoque errores y demos la validación por fallida.
  3. Que congelemos la actualización del entorno de pre-producción incurriendo en molestias y dificultades extra para el equipo de desarrollo y retrasando las fechas del proyecto.

Estos problemas se verán aumentados si trabajamos en base a una metodología de desarrollo ágil con entregas iterativas.

Entorno de producción

Es la culminación de nuestro esfuerzo, el entorno dónde se verán las virtudes y defectos de nuestro trabajo, el objeto por el que seremos valorados. Los cuatro entornos anteriores están pensados para llegar aquí de la forma más eficiente posible garantizando la fiabilidad, y la diferencia de calidad sobre el resultado final puede ser realmente significativa significativa de disponer de un circuito de entornos adecuado a no disponer de él.

Las pruebas

Uno de los aspectos más significativos de este circuito es que cada entorno debe tener su propio tipo validación y por lo tanto de pruebas. Lo más habitual es realizar test unitarios en el entorno de desarrollo, test de integración en el entorno de integración continua y pruebas de validación sobre el conjunto de la aplicación en el entorno de pre-producción.

Para los test unitarios existen varias herramientas entre las que destacar PHPUnit, aunque si usamos frameworks como Laravel, el propio framework ya nos proporciona herramientas para realizar este tipo de pruebas. A partir de ahí existe un amplio abanico de herramientas para ayudarnos a realizar todo tipo de comprobaciones, en la página PHP Quality Assurance podemos encontrar algunas.

Conclusión

Concedamos la importancia que se merece al diseño y la implementación de los entornos implicados en el desarrollo del software, de ellos dependerán en gran medida la calidad de los resultados y la velocidad de desarrollo.

Y como siempre me gustaría conocer sobre tu experiencia, ¿trabajas sobre un circuito con más o menos entornos? ¿qué tipo de pruebas realizas? ¿Con qué softwares?

Créditos, referencias y artículos relacionados

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *