Categoría: Arquitectura & DevSecOps

El décimo punto del decálogo de la industrialización del software con respecto a los traspasos a la infraestructura del cliente es que: «No se traspasa ningún proyecto sin que hay sido aprobado por el responsable del proyecto».

Este es el punto más burocrático y se refiere a que el traspaso, que básicamente es una entrega de un producto, o de una parte de un producto, debe ser autorizada por el responsable de ese proyecto.

Si algo va mal a el le van a pedir cuentas, así que lo normal es que quiera tener un cierto control sobre ese paso.

El noveno punto del decálogo de la industrialización del software con respecto a los traspasos a la infraestructura del cliente es que: «No se traspasa nada sin que haya pasado los controles de calidad».

Si no pasas los controles de calidad es que no has terminado. Y si no has terminado ¿porque traspasas?

El cliente te va a parar el traspaso en algún entorno posterior a los tuyos y vas a tener que volver a hacer el trabajo. O lo peor de todo, si el cliente no tiene un buen control de calidad, te lo van a poner en producción, y luego va a haber fuegos artificiales y según Murfy en el peor momento cuando te pille a contra pie.

El octavo punto del decálogo de la industrialización del software con respecto a los traspasos a la infraestructura del cliente es que: «Cada tarea recogida en el gestor de tareas debe contener toda la información para realizar el traspaso».

Como hemos comentado en otros puntos no siempre una tarea se pone en producción nada más terminada, que es cuando tienes fresco lo que has hecho. También hay que tener en cuenta que si algo va mal en un traspaso cuanta más información tengas recogida de forma accesible más fácil va a ser recordar que es lo que si hizo y porque.

Es por ello que en el gestor de tareas en cada tarea hay que recoger la información necesaria para poder reconstruir la tarea.

He tenido compañeros muy diligentes que se apuntaban en la libretita todos los ficheros que iban cambiando y todo lo que iban haciendo. Me parece genial esa actitud, pero lo que les decía a esos compañeros es que si en vez de hacerlo en su libretita, que solo la conoce la persona, si lo haces, exactamente el mismo trabajo, en el gestor de tareas queda recogido para cualquiera que tenga que continuar esa tarea.

Estuve en un proyecto en el que en un periodo de tiempo muy corto tuvimos dos bajas médicas inesperadas de una cierta duración, que nos hizo un roto muy grande, ya que el equipo no era muy amplio, así que una baja de una persona suponía una perdida grande.

Si no llega a ser porque teníamos todo recogido en el gestor de tareas y otra persona pudo retomar el trabajo, ciertamente con dificultades, pero muchas menos de las que hubiese tenido si no lo hubiésemos tenido todo recogido.

El séptimo punto del decálogo de la industrialización del software con respecto a los traspasos a la infraestructura del cliente es que: «Se debe poder realizar traspasos parciales de un proyecto».

A veces pasa,que una vez preparado un traspaso, alguna tarea no funciona bien y hay que quitarla. Aunque no debiera de suceder en muchas ocasiones, porque significaría que algo no funciona en nuestro proceso, a veces pasa y hay que estar preparado.

Hay que estar preparado para este tipo de contingencias y tener definido cual es el procedimiento que se va a seguir. Quitar el código de la tarea de la etiqueta del repositorio, ya que esa tarea no va a ir y actualizar el estado de la tarea en el gestor de tareas.

El sexto punto del decálogo de la industrialización del software con respecto a los traspasos a la infraestructura del cliente es que: «Los traspasos entre entornos deben estar automatizados completamente o realizarse lanzando un script o similar, nunca manualmente moviendo ficheros».

Todas las reglas anteriores están bien, pero tenemos que tener un mecanismo que nos asegure que hacemos las cosas bien, es decir que si queremos reproducir el traspaso no vamos a hacerlo en las mismas condiciones. Si dejamos pasos manuales es posible que alguien con prisas o que no conozca bien el procedimiento no lo realice bien y por ejemplo traspase ficheros de su ordenador, sin que estén en el repositorio.

Aparte de tener la seguridad de que hacemos las cosas bien también nos interesa el que el  proceso sea lo más rápido posible.

Es por ello que debemos buscarnos automatismos. Bien desde sencillos scripts de shell (en caso de Linux) hasta herramientas como AntHillPro o Jenkins

El quinto punto del decálogo de la industrialización del software con respecto a los traspasos a la infraestructura del cliente es que: «Todas las tareas deben estar recogidas en el gestor de tareas».

El motivo de este punto es el saber en cada traspaso que es lo que se ha enviado, para ello debemos tener recogido en el gestor de tareas todas aquellas tareas que se traspasan, o que deben ser realizadas para poner el producto.

Esto nos permitirá saber en caso de problema todo lo que realizamos para poner ese desarrollo en producción.

Hay proyectos en los que nada más se termina una incidencia se pone en producción, pero hay otros proyectos en los que esto no es así. Yo he estado en alguno. Nunca entendí el motivo de no poner algo hecho en producción hasta bastante después de haberlo terminado (y hablo de meses).

Ya vamos avanzando en poner orden y tomar el control de la situación. Con los dos pasos anteriores ya debieras de tener lo más importante controlado. Que la aplicación haga lo que tiene que hacer.

Ahora, a mi modo de ver, debieras de empezar a mirar un poco los temas internos. Para mi lo primero a controlar es el código. Por eso es lo primero en el decálogo.

Es vital que tengas el control del código fuente, sino vas a tener problemas. Créeme, he estado en sitios en los que se ha perdido código y no es una situación agradable.

Debieras de organizar el repositorio de tal forma que te permita automatizar la compilación. Aunque no lo hagas al principio de todo, en algún momento querrás optimizar el proceso productivo y la automatización es esencial. Además el automatizar te garantizará que lo que tienes en el repositorio es lo correcto, y que están todos los ficheros que necesitas.

En este punto casi se podría seguir el orden del decálogo. Siempre adecuando las prioridades a lo que en el proyecto en el que estés veas que es más sangrante.