¡Añade aislamiento a tus despliegues con Environments!

Regresando, en plena cuarentena, a las arenas del CI/CD para hablar algo que curiosamente ayuda a lograr cierto aislamiento a tus recursos en la nube al momento de desplegar: Los Environments en Azure Pipelines, así que vamos a ello.

Repasemos un poco, cuando hemos tenido pipelines usando Designer Mode, hemos definido el despliegue (en este ejemplo hacia un Web App) mas o menos así:

Y en el caso de Multi-stage pipelines, el paso de despliegue se define así:

Si nos fijamos en ambos casos, veremos que corresponde al Pipeline definir el recurso “destino” donde haremos nuestro despliegue:Subscripción, Grupo de Recursos y Recurso (en este caso una WebApp), o sea que toda la responsabilidad recae sobre el pipeline y quienes tienen acceso a desarrollar sobre el.

Si, es cierto que podemos establecer una cierta seguridad si, cuando enlazamos nuestro Team Project contra los recursos de Azure, lo hacemos contra Grupos de Recursos acotados y no contra toda una Subscripción, algo de eso lo vimos anteriormente, pero lo que vamos a ver proporciona una abstracción adicional y funcionalidades que nos ayudaran al seguimiento de nuestros procesos de despliegue. Finish Reading: ¡Añade aislamiento a tus despliegues con Environments!

“Poquitecto” ¿realidad, broma o necesidad?

Desde hace un tiempo, en un grupo de amigos desarrolladores, bromeamos acerca de como uno de nosotros tiene el rol de “Poquitecto“, la razón de esta broma deriva del hecho de que nuestro amigo tiene el rol de Product Owner, siendo que esta adscrito a un departamento de Arquitectura en su organización, y claro en esta época de “cargo cult agil” nunca esta de mas hacer una broma respecto a que nuevo rol puede inventarse dentro de las organizaciones…

La verdad es que esto no hubiera pasado de una broma o anécdota, si no fuera porque la conversación me hizo recordar que ¡Yo trabaje con un poquitecto!, ¿como así?, bueno, resulta que hace poco mas de un año el equipo en que me encontraba paso por un cambio radical de Product Owner, pasando de alguien con mucho enfoque en la funcionalidad de negocio a agregar y la facilidad de uso respectiva (vamos, un PO “clásico” *), a uno con fuerte base técnica (pero involucrado en la organización y el producto por varios años) que priorizaba y enfocaba las Historias de Usuario con un claro enfoque hacia la arquitectura de la integración tecnológica de nuestra aplicación con otra que estaba siendo desarrollada por otro equipo.

Y claro, las reuniones incluían conversaciones respecto a lo que implicaba el conectarse con la otra aplicación, el como estaba construida nuestra aplicación, diálogos en los que nuestro nuevo PO se implicaba directamente; cabe agregar que nuestro Scrum Master era uno de los que te acompañaba en la depuración de código cuando había que meter un cambio radical a lo que ya se tenia desarrollado y en producción.

¿Que cual de los dos perfiles de PO es el mejor? pues, a riesgo de hablar como consultor daré la respuesta clásica: “depende”, pues en una etapa del ciclo de desarrollo se requería un enfoque totalmente orientado al negocio y a la funcionalidad a agregar, pero en otro estadío dicha visión tecnológica era de gran utilidad (y hasta de necesidad) para lograr orientar adecuadamente los cambios esperados.

Desconozco los detalles del rol de nuestro amigo, pero esta experiencia me indica que a veces puede ser necesario que haya una “fusión” entre las actividades correspondiente a un Product Owner y las de un Arquitecto, tenga esta mezcla el nombre que tenga (llámalo poquitecto si quieres), que en un momento ese nombre se consolide… depende de como siga el cargo cult en nuestras organizaciones(**).

(*) Ya lo he mencionado antes, personalmente creo que es imprescindible que un Scrum Master tenga un conocimiento del ámbito técnico en el que se va a mover con su equipo (sin llegar a ser experto), requerimiento que no considero mandatario para un Product Owner.

(**) Las cuales hablan de la importancia del Agile Technical Coach (si, otro cargo) y de la excelencia técnica, pero a la hora de la verdad no efectúan las acciones reales.

¿Reactivos o proactivos con la nueva tecnología?

Cuando se trabaja desde la consultoría a empresas uno debe tener claro la actitud que se debe de tener ante la tecnología emergente y como reaccionar ante ella de cara a lo que se ofrecerá a nuestros clientes, es probable que si nuestro cliente es un banco y aun siguen anclados al COBOL no haya muchos incentivos para proponer cambios y nuevas tecnologías core según que áreas (*), pero si el rubro de clientes apunta a los mal llamados proyectos “llave en mano” o “time and materials” en que se espera colaboración el escenario puede ser muy diferente, y el modo de proceder tiene que ser acorde a el.

Un error demasiado frecuente es dejar que sean las necesidades inmediatas de nuestros clientes las que condicionen la adopción tecnológica en una consultoría, como consecuencia los fichajes se hacen basados en si el desarrollador tiene los skills de los proyectos que se están haciendo en este momento, lo cual permite ir dentro de la ruta segura… por un tiempo, aunque puede generar situaciones extremas en las que por querer atender a un “cliente importante” se realicen fichajes de emergencia, o un aprendizaje a marchas forzadas, sin garantía de que luego de que ese proyecto acabe habrá nuevo uso de esa tecnología, pero bueno… lo importante es que se consiguió llegar a ese cliente (**). Otra situación común es que ante un potencial proyecto nuevo se este preguntando al equipo existente “¿alguien sabe xxx?” lo cual denota una falta de mapeo sobre los skills del equipo, pero eso es otra cosa.

El caso opuesto se da cuando alguien se emociona por una tecnología que se vio en Internet, y no se vio la curva de adopción, por lo que uno puede terminar casi sin soporte en Internet pues eres uno de los pocos que usa la tecnología, paso con lenguajes e IDEs en los 90s y ahora pasa con frameworks de JavaScript.

Entonces ¿que hacer? La respuesta esta tal vez en el medio, pero de una manera proactiva, no dejar de mirar los avances tecnológicos, en lugar de estar pendientes de lo que usa el cliente, apuntar a lo que la tecnología actual y emergente puede hacer por solucionar sus problemas y sus necesidades de crecimiento, investigar y hacer pilotos aun antes de que haya clientes que pidan algo (eso evita que el requerimiento o el boom nos coja desprevenidos) y como decia Eduard no pretender dominar todo y por ende aspirar a todos los clientes.

Adicionalmente, una “ventaja” de no estar en USA es que hasta cierto punto se puede sacar partido del retraso en adopción tecnológica, pues da tiempo para ver por donde se están consolidando las tendencias y ser novedosos (con algo seguro) de cara a lo que se le puede ofrecer al cliente.

¿Que opinan? ¿Reactivos o proactivos?

(*) A pesar de tener el core en COBOL muchas organizaciones han desarrollado productos con nuevas tecnología que llaman a ese backend, así que por ahí pueden salir las innovaciones a proponer.

(**) si a veces se esta en esa tesitura es necesario dedicar buen tiempo al estudio de lo nuevo, y no pretender que todos los desarrollos son similares ni con igual riesgo.

No todo tiene igual riesgo

Mucho se habla de gestión de riesgos, ya sea en metodologías ágiles como en, cof cof, waterfall, y claro, mucho se colocan tablas y con una mayor o menor pericia se indican los impactos y probabilidades respectivas, hasta ahí “lo normal”.

Lo usual es que por lo usual los criterios de experiencia que se toman están basados en el tipo de proyecto: ERP, almacén, web o desktop o también en el grado de complejidad del negocio, estado de las relaciones con el cliente, primera vez, time to market etc, nada fuera de lo habitual.

El problema es que muchas veces la visión “de negocio” logra opacar al criterio técnico en un factor muy importante: no todas las tecnologías tienen igual riesgo, y no, no me refiero al hecho de que por ejemplo un consultor de SAP cobre mas que un diseñador gráfico (llevándolo a extremos), sino que las diversas tecnologías tienen diferentes niveles de disponibilidad de recursos de aprendizaje, lo cual quieras que no, impacta en las previsiones que se requieren tomar para un proyecto.

En algunos casos es evidente que hay muchos mas recursos (ojo, en este blog nunca hablamos de personas como “recursos”, ¿ok?) para SQL Server y Oracle que para Informix o Sybase, por lo cual el tiempo en que un equipo puede llegar a ser productivo en un proyecto con estas dos tecnologías “raras” es mayor, pero mal que bien se puede solventar con la experiencia previa en otros motores de base de datos, así que tenemos un riesgo ligeramente mayor, pero justificable.

Visto a este contexto debemos pasar a un diferente tipo de escenario, los frameworks o soluciones “listas para usar”, productos que se espera que puedan ser usados directamente por un usuario final, “casi” sin necesidad de desarrollo, pero claro eventualmente terminan pidiendose personalizaciones y como la aplicación tiene una API en un lenguaje “conocido” como PHP, C# o Java pues se empieza el desarrollo tomando los mismo criterios que cualquier otro proyecto a medida y .. ahi empiezan los problemas.

En concreto estas aplicaciones (concretamente los CMS que son con los que he tenido experiencia) presentan dos problemas que los hacen “bestias” diferentes a cualquier desarrollo a medida:

  1. Esfuerzo extra para configurar los entornos, tanto de desarrollo, como de producción, en el caso de SharePoint por ejemplo era muy complicado, tan así que no se podía trabajar contra un servidor compartido sino que cada desarrollador debía de tener una Maquina Virtual para tener un entorno de trabajo, todo lo cual involucraba un esfuerzo que no era trivial.
  2. Cambio de paradigma respecto a como desarrollar y/o depurar, pues aquí no eres tu desarrollando una aplicación, estas intentando construir algo sobre los cimientos que alguien mas hizo, y que le puso reglas que pueden ser no usuales (y sobre todo contraintuitivas), pero necesarias para que el producto funcione, lo cual deriva en una necesidad de conocimiento (y tiempo de aprendizaje) mas allá de cuan experto uno crea ser en el lenguaje en cuestión.

Queda claro que estos dos factores tienen alta probabilidad de incidir sobre el tiempo que le puede tomar al equipo implementar la solución, por lo que seria un grave error asumir proyecciones sin tomar en cuenta el esfuerzo extra mencionado, si, es difícil acometer estas cosas que nos dejan productos como Magnolia, Vignette, o SharePoint, pero al final son retos técnicos que terminan siendo superados, a menos claro que la dirección asuma que “.net es .net” y no tome en cuenta detalles como estos en sus proyecciones, ahora que si a estas dos cosas, se le suma la poca experiencia local, o poca documentación actualizada en foros, asumimos grandes riesgos que no podemos dejar de informar de antemano, y créanme, en el caso de CMS (salvo que tengas miembros del equipo que actúen como pilares del resto) siempre pasa algo de lo mencionado, por lo que debemos estar alertas, regresando al titulo de este post, no todo tiene igual riesgo (técnico).

Cual seria el perfil de un Ing. Informatico?

Hace unos dias en una reunion conoci a un egresado de Ing. Informatica de una de las universidades surgidas a la amparo de la Ley de Promoción de la Inversión en la Educación durante el fujimorismo, y sin querer la conversacion derivo a conversar sobre el enfoque que se da a nuestra carrera en las universidades.. y fue mas o menos asi.

Comentaba sobre el hecho de que algunos egresados de una tercera universidad tenian a honra el hecho de casi no haber programado, y que cuando les toco hacerlo contrataron a alguien para que lo hiciera por ellos, actitudes como esa serian desconcertantes en la UNI o en la PUCP pero a este caballero le parecia lo mas normal del mundo, arguia que lo importante era el negocio que todo formaba parte del negocio, etc etc, y que al final el programa final es lo de menos. Un poco mas y casi se dirige al lugar comun de que el codigo es la pieza mas basica del todo y que un Ing. Civil no necesita saber colocar ladrillos para hacer su trabajo. Eh??? Si, no es raro que se llegue a dicha peregrina conclusion, ignorando que los diversos modulos de una solucion tienen una tarea intelectual detras de ellos, que no homogenea precisamente.

Vayamos por partes, si… las aplicaciones informaticas al final de cuentas deben estar alineadas a los objetivos de la organizacion, y significar un medio para la mejora de sus procesos o para lograr ventajas competitivas, hasta ahi las cosas claras. El problema que ocurre es que a veces se llega a un nivel tan abstracto en el como implementar las cosas, todo diluido en pilas de documentacion e informes a la gerencia, que en la practica tratan de enmascarar que no se esta cumpliendo los objetivos que se tenia con la implementacion o desarrollo planificado. Y nos olvidamos que dentro de nuestro ambito de competencia lo que importa es la entrega de lo realizado, la obra visible y que sea de utilidad a la organizacion.

(Aprovecho para recordar los principios del Manifiesto Agil:

Estamos poniendo al descubierto mejores métodos para desarrollar software, haciéndolo y ayudando a otros a que lo hagan. Con este trabajo hemos llegado a valorar:

A los individuos y su interacción, por encima de los procesos y las herramientas.
El software que funciona, por encima de la documentación exhaustiva.
La colaboración con el cliente, por encima de la negociación contractual.
La respuesta al cambio, por encima del seguimiento de un plan.
Aunque hay valor en los elementos de la derecha, valoramos más los de la izquierda.
)

Parte de los problemas que se tiene en los procesos de desarrollo de aplicaciones vienen dados por malas estimaciones y una gestion irrealista de las expectativas del cliente, situaciones que en varios casos vienen dadas porque dichos pasos han sido dados por profesionales que han visto la informatica de manera muy ligera, osea: no saben la clase de complejidades que puede implicar el desarrollo de tal o cual funcionalidad, o no saber las limitaciones que puede tener cierta tecnologia y el impacto en los plazos de entrega que tendra el “puentear” dichas limitaciones. Se me dira que si, pero que un jefe de proyecto no esta para tirar lineas de codigo, y doy toda la razon, pero voy al hecho de la necesidad de este jefe de proyecto de haber tenido, ya sea en su educacion o experiencia previa, de un conocimiento interno de que es lo que hay detras de las aplicaciones informaticas.

Cierto, he tenido jefes que no han pasado por la programacion y han sido capaces de sacar adelante sus proyectos, pero en estos casos han tenido el suficiente sentido comun de saber escuchar a la gente tecnica que lo rodea, pero aun asi, de mi experiencia puedo decir que a un jefe que haya pasado por las trincheras es mucho mas dificil pasearlo, y que ademas te dara una estimacion fiable.

Por otro lado esta el otro perfil de nuestra carrera, el que permanece siempre detras de las lineas de codigo, si, es facil decir que con un curso de medio año ya se puede programar, pero olvidamos la importancia de una formacion matematica y logica en el perfil de un programador de calidad, la necesidad de introducir principios de eficiencia, programacion metodica, y por que no? algo de elegancia al momento de plantear las ideas en codigo.

Entonces, llegamos al punto de la importancia que tienen las bases (programacion, matematicas, logica, ciencias de la computacion) en la formacion de un ingeniero informatico, independientemente del curso profesional que luego se siga (gestion, programacion, comunicaciones), esas bases son las que nos definen y las que hacen que no seamos Administradores de Empresas con conocimientos de Informatica, que es lo que parecia el perfil de mi interlocutor de entonces.