Desmitificando la cadena de desarrollo de Software

Muchos no encontrarán nada nuevo en lo que voy a decir, pero me veo con ganas de comentarlo porque aunque a veces pueden parecer cosas obvias, me encuentro por un lado mucho desconocimiento general en las empresas acerca del propio desarrollo del Software y ya de paso, tampoco está nada mal hacer un repaso general a los conceptos propios de la cadena de desarrollo del Software.

Dejando de lado a las metodologías y las arquitecturas, por debajo hay algo que es prácticamente idéntico a cualquier desarrollo del Software, ya sea en Java, en .NET, en ensamblador y en lo que se nos ocurra decir.

Ese «algo» es muy repetitivo,… como una cadena de montaje, de ahí que se me haya ocurrido titular a esta entrada como cadena de desarrollo Software.

Cuando trabajamos en proyectos Software y dentro de un equipo de trabajo, tiene un valor muy importante que la información fluya.

Tareas como comentar el código son fundamentales, un rollo sí (lo admito y levanto la mano el primero), pero una tarea obligada y necesaria para el bien común (pensad siempre que haceis una tarea en la palabra equipo 😉 ).

Pero si decimos que la información debe fluir… ¿qué pensáis que es el código fuente de un desarrollo Software?.
Pues justamente eso, información. Información que en este caso está traducida a modo de instrucciones o comandos, pero no deja de ser información. Información que hay que pulir, cuidar y preparar, como si de un documento Microsoft Word o similar se tratara a la hora de preparar una documentación o preparar una oferta.

Así que si queremos compartir esa información y trabajar de forma colaborativa entre varias personas, lo lógico es pensar en productos tipo Visual Studio SourceSafe y como no, Visual Studio Team Foundation Server y sus complementos.
Este tipo de productos nos permitirán colaborar entre los miembros de un equipo y compartir los avances del proyecto sin supuestamente, tropezar unos miembros con otros dentro de las mismas parcelas o porciones de código (sin pisarnos el trabajo sin querer).

Sin entrar en más detalles (que entradas y contenidos hay para hacerlo), el desarrollo del Software se inicia con unos documentos necesarios previos (requerimientos, diseño técnico, etc).
Con posterioridad y ya más metidos en harina, no debemos limitar las tareas tan solo a colaborar y compartir el avance del proyecto.
Por supuesto, debemos tener siempre en mente las pruebas unitarias, otras de las tareas de obligado cumplimiento (otro rollo sí, pero también tan necesario para el desarrollo Software como el respirar para vivir).

Hay o existen muchas partes muy importantes. Aquí estamos desmenuzando las principales a vista de pájaro. Los detalles son muy profundos evidentemente.

Otro de esas partes generales es que continuando con nuestro proceso o con nuestra cadena de desarrollo del Software, el repositorio de código debe generar un resultado final. A ese resultado se le denomina build.
A veces esa build se ve y se toca (interfaz de usuario).
En otras ocasiones, esa build existe pero ni se toca ni se ve de forma directa o casi física (un ensamblado o un servicio que debe ser consumido). Esta es quizás la parte más amarga del desarrollador, ya que en muchas ocasiones la gente de alrededor piensa en que estas tocándote las narices porque no se ve «nada» cuando en realidad, por debajo hay un gran monstruo.

Aún y así y continuando con la cadena de desarrollo del Software, esas partes separadas de builds, pueden ser reutilizadas en un producto para empaquetarlo como versión final de un producto.

De ahí extraemos o debemos extraer una nueva etapa en la cadea, la etapa de las pruebas funcionales.

Hemos partido del código, de sus pruebas, de sus builds, y finalmente de la creación de un producto, pero… ¿hace realmente ese producto lo que esperamos que haga de acuerdo a los requerimientos?.

Las pruebas funcionales o el cumplimiento de las tareas de acuerdo a los requerimientos deben ser cubiertas de forma completa. Es decir, que el producto final haga lo que tiene que hacer tal y como estaba pensado que lo hiciera.

Cuando todo eso ha sido superado de forma positiva, debemos poner el producto en el entorno de producción.

Evidentemente, aquí surgen muchas puntualizaciones que deben ser realizadas como por ejemplo tener entornos de prueba y entornos de producción parejos o lo más similares posibles. Aquí a veces, las máquinas virtuales juegan papeles fundamentales, aunque para algunos escenarios es más recomendable utilizar un entorno físico exacto al que va a tener producción.

Pero como todas estas palabrejas pueden parecer un poco extrañas, lo mejor es mostrar una imagen que explique claramente todo este popurrí de conceptos e ideas.

Por suerte, hoy me he encontrado en Internet una imagen que explica de forma excelente esto que os comento. Como me ha parecido tan bueno, me he animado a escribir esta entrada dejándoos para el final, la imagen que resumen esto que he querido compartir con vosotros.

Pensad siempre en dos palabras complementarias que estarían por encima de todas estas tareas… EQUIPO y PERSONAS.