La puesta en marcha es un paso fundamental en cualquier proceso. Una buena comprensión de la diferencia entre los entornos de desarrollo y producción es fundamental para ayudar a todos a evaluar los riesgos y cómo abordarlos.
El equipo de desarrollo reunió los requisitos. Durante semanas trabajaron sin parar, modificando el código, realizando pruebas unitarias, realizando controles de calidad y preparándose para el momento del lanzamiento del proyecto. Tomaron en cuenta todas las eventualidades, entonces, ¿qué podría salir mal?
Todo desarrollador de software que alguna vez haya puesto en marcha conoce la ansiedad que conlleva el paso a producción. No importa cuánta preparación y pruebas hayas hecho de antemano, existe esa terrible sensación de que te has perdido algo o de que algo va a salir mal.
Podría ser algo tan tonto como olvidar actualizar la ruta del archivo estático o podría ser algo tan misterioso como no tener la misma versión de una biblioteca en el servidor en vivo (sí, la gente todavía implementa sus proyectos sin usar contenedores).
Cuando un proyecto aún está en desarrollo, los ingenieros de software tienen la flexibilidad de cambiar el código o refactorizarlo según sea necesario. Cuando el proyecto está activo, los desarrolladores están restringidos, algunos errores se pueden corregir en caliente, mientras que otros requerirán que el proyecto se retire para realizar tareas de mantenimiento.
La pregunta es: ¿qué significa todo esto para el cliente? ¿Cómo cambiará su relación con el proyecto una vez que entre en producción? ¿A qué debes prestar atención? ¿Qué puede hacer para garantizar que el proceso se desarrolle sin problemas?
¿Cómo se hace el software?
El ciclo de vida del desarrollo de software (SDLC para abreviar) es el nombre de un conjunto de prácticas estándar que tienen como objetivo facilitar la creación de software. Dependiendo de a quién le pregunte, este proceso se divide en 6 a 8 pasos: Planificación, Requisitos, Diseño, Construcción, Documentación, Pruebas, Implementación, Mantenimiento.
En los primeros pasos, el equipo de desarrollo recopila información sobre el producto. Los ingenieros intentan resolver las siguientes preguntas: ¿Qué intenta resolver esto? ¿Con qué tipo de datos funcionará? ¿Necesita interactuar con otros sistemas o será independiente? ¿Estará alojado en la nube o el cliente utilizará servidores personales?
Este proceso sienta las bases para lo que viene después. Comprender la naturaleza del proyecto y las necesidades del cliente desde el principio significa que el equipo tendrá una mejor idea de cómo abordar el proceso de diseño.
Desde la etapa de diseño/prototipo en adelante, los desarrolladores deben configurar un entorno. Un entorno es, a falta de un término mejor, un espacio virtual donde se desarrolla la aplicación.
Por ejemplo, si construyo un sofá en mi sala de estar, el espacio físico que uso, las herramientas con las que trabajo y los materiales son el entorno . En el caso del desarrollo de software, el entorno son las herramientas de hardware y software que se utilizan en el proceso de desarrollo, a menudo denominado entorno de desarrollo de software (SDE).
Tradicionalmente, hay tres entornos diferentes dentro del propio SDE: el entorno de desarrollo, el entorno de ensayo y el entorno de producción.
El entorno de desarrollo
Imagine por un segundo que un chef está intentando crear un plato nuevo. ¿Harían esto cuando el restaurante esté lleno y tengan que cocinar para los clientes? ¿O tendría más sentido ser creativo cuando el restaurante está cerrado y tienen tiempo suficiente para pensar y probar nuevas combinaciones?
El entorno de desarrollo es simplemente eso: un espacio controlado donde los desarrolladores pueden comenzar a diseñar, crear prototipos y dar forma al proyecto. En la mayoría de los casos, el entorno de desarrollo se configura en hardware local y se facilita a través de un repositorio Git. En esta etapa, el proyecto está en su infancia, tiene errores, carece de características críticas y apenas funciona, si es que funciona.
Existen diferentes paradigmas sobre cómo configurar un entorno de desarrollo, pero a la mayoría de los desarrolladores les gusta que este entorno esté lo más aislado posible. De esta forma se evitan errores debidos a software y hardware desconocidos.
Como ejemplo rápido, la mayoría de los desarrolladores de Python configuran un entorno virtual con una copia nueva de Python al iniciar un nuevo proyecto. De esta manera pueden mantener un estricto control sobre qué bibliotecas se utilizan.
Desde el diseño hasta la documentación, el cliente puede ver extractos del proyecto: capturas de pantalla, presentaciones guiadas o incluso un prototipo funcional de algunos de los módulos. En este punto, los desarrolladores buscan comentarios sobre cómo se alinea el proyecto con los objetivos del cliente; las pruebas se realizarán más adelante.
Entorno de producción
Llevar el proyecto al entorno de producción es lo que la gente suele llamar "puesta en marcha". El proyecto está listo para ser utilizado, pero el proceso aún está lejos de finalizar. En términos de SDLC, el proyecto se traslada al entorno de producción al final de la etapa de prueba y se activa cuando se logra la implementación.
Existe un entorno intermedio llamado entorno de prueba que actúa como puente entre el desarrollo y la producción. El entorno de prueba es lo más cercano que se puede llegar a la producción sin entrar en funcionamiento.
Es decir, el proyecto se transfiere a los servidores y se configura como si fuera a desplegarse. En este paso, se realizan los preparativos finales, se migran las bases de datos necesarias y se realiza una serie final pero muy importante de pruebas.
Piénselo de esta manera: hasta ahora el proyecto ha existido en un laboratorio especialmente diseñado para preservar su integridad, pero una vez trasladado a otra ubicación las cosas pueden salir mal. Existen herramientas como Docker que ayudan con el proceso de migración, creando un entorno de producción lo más cercano posible al entorno de desarrollo.
Pero incluso entonces, se ejecuta un conjunto completo de pruebas para garantizar que el proyecto funcione como se espera y que no haya conflictos.
En esta etapa, los desarrolladores pueden compartir el acceso con el cliente. Entonces, puedes ver esto como una “demostración” donde el cliente experimenta el proyecto en su totalidad. La idea aquí es obtener una ronda final de comentarios y, si todo funciona según sus expectativas, se le dará el visto bueno para comenzar a funcionar.
La producción es el entorno donde las pequeñas cosas pueden salir mal y saldrán mal, pero también es la etapa donde el proyecto debe cumplir sus objetivos. Este es el punto donde cualquier error crítico le costará tiempo y dinero al cliente. Como tal, es imperativo que incluso si se encuentran errores, el proyecto pueda continuar mientras se implementan las correcciones.
La forma en que se manejan las actualizaciones depende de la naturaleza del proyecto y de la metodología del equipo. Por ejemplo, los equipos ágiles se esfuerzan por realizar cambios lo más rápido posible, pero las soluciones críticas pueden requerir un tiempo de inactividad que debe programarse durante períodos de baja carga de trabajo.
En este punto, el cliente es un usuario y un tester beta. A medida que se encuentran errores, TI monitorea los tickets y las soluciones se implementan lo más rápido posible. Una vez que se resuelven los problemas, el proyecto pasa a la fase de mantenimiento y todos pueden respirar aliviados cuando la parte más crítica del proyecto haya terminado.
Pasar del desarrollo a la producción es un proceso muy delicado que requiere dedicación y el uso de herramientas como el mencionado Docker para facilitar el proceso. Es una de esas áreas en las que un experto en DevOps puede brillar y ayudar a impulsar el proyecto.
La transición del desarrollo a la producción puede ser tensa, pero una comunicación sólida entre el cliente y los desarrolladores, así como una buena estrategia de planificación/prueba, pueden ayudar al proceso y llevarlo a su finalización.
