Etiqueta: configuration management

No todo es IA & JS: mi proyecto con Oracle forms

Desde hace un par de semanas estoy ayudando a una organización a mejorar su proceso de delivery. Se trata de una organización que ofrece una plataforma de software que fue construida hace más de 20 años y que hoy en día sigue en operación, dando soporte a un negocio y resultando rentable para sus creadores.

Las tecnologías populares en aquella época (año ~2000), eran bastante distintas a las actuales. Una tecnología bastante popular por aquellos años era Oracle Forms que fue la tecnología elegida por esta empresa para desarrollar su software. Dudo mucho que en la actualidad se sigan haciendo nuevos desarrollos con Oracle Forms, pero sin duda hay varias soluciones construidas con esta tecnología que aún siguen operativas.

En el caso particular de mi cliente, el core de su plataforma está construido con tecnología Oracle pero con el correr de los años han ido generan «nuevas capas» con tecnologías más actuales como ser Java y JavaScript/TypeScript. Esta es una estrategia muchas veces utilizadas en los bancos con sus core bancarios construidos en tecnologías como COBOL.

Entre otras cuestiones lo que estamos haciendo es estandarizar el esquema de versionado y automatizar el proceso de despliegue. Venimos bien, aún me quedan unas 6 semanas de trabajo lo cual creo que es suficiente para completar la tarea.

Continuará…

Git se ha convertido, hace ya un par de años, en el estándar de facto en lo que refiere a versionado de código. De hecho hay muchos «nativos Git», gente que desde un comienzo ha trabajado solo con Git sin tener ningún acercamiento a otra herramienta de versionado. Al mismo tiempo, si bien hay gente que hoy en día trabajada con otros sistemas de versionado anteriores a Git como Subversion o CVS, muchos ya tienen en vista la migración a Git.

Sin embargo, más allá de su popularidad, yo tengo la sensación que muchos usuarios de Git desconocen su potencialidad. He visto muchos programadores utilizando Git desde sus IDEs o con alguna herramienta visual (tipo SourceTree), lo cual hace que en cierto modo uno «no se entere» si está usando Git, Subversion o cualquier otros sistema de versionado.

A partir de esto es que se me ocurrió armar este taller, con un enfoque muy práctico para explorar algunas funcionalidades de Git que pueden resultar no tan conocidas. Entre las cuestiones que tengo en mente cubrir están: stash, squash, blame, submodules, cherry-pick, clean y reset entre otras.

Para participar de este taller es necesario que los participantes estén familiarizados con el uso básico de Git (commit, pull y push) y cuenten con una cuenta de GitHub. Adicionalmente les recomiendo ver esta serie de videos que armé hace ya varios años para explicar el uso básico de Git.

La primera edición de este taller será en el contexto de Nerdearla, en cuanto tenga confirmado día y horario lo estaré compartiendo en redes.

De Subversion a Git, el problema no es la herramienta

Luego de varios años volví a encontrarme en un cliente con Subversion y la decisión de migrar a Git.

La principal dificultad que he encontrado en este tipo de migraciones viene dado por un uso incorrecto de Subversion. Este uso incorrecto creo que es consecuencia de varias cuestiones:

  1. Desconocimiento de prácticas básicas de configuración management
  2. La flexibilidad (o permisividad) de Subversion en lo referente a la estructura de directorios
  3. La «tentación» de usar el Subversion como si fuera simplemente un file-system compartido

Es a partir de estas cuestiones que es factible encontrarse con repositorios Subversion sin una linea base y/o con una cantidad de sin sentido de branches. A esto se suma el hecho de utilizar un único repositorio Subversion para todos los proyectos de la organización.

Como suele ocurrir, el problema no radica en la herramienta sino en la forma en la que utilizamos. Un martillo no parece ser una herramienta apropiada cuando lo queremos utilizar para revolver el té.

Por otro lado Git ya tiene incluido en su diseño algunas cuestiones que «obligan» a tener ciertas prácticas básicas de configuration management o que al menos limitan ciertas barbaridades que el usuario pueda tentarse de hacer.

En mi experiencia cuando se utiliza Subversion de acuerdo a las recomendaciones del SvnBook la migración a Git resulta bastante simple. Al mismo tiempo, si bien existen herramientas para migrar de Subversion a Git la estrategia que más he utilizado es «congelar el Subversion», mantenerlo como almacenamiento de versiones históricas y arrancar con un repositorio Git con tan solo la versión de la línea base.

Finalmente un detalle importante al empezar con Git es hacer el esfuerzo de entender mínimamente como funciona. Si lo usamos integrado con un IDE, corremos el riesgo de utilizar Git como si fuera Subversion y comprarnos así varios problemas o simplemente desperdiciar ciertas capacidades de Git. Luego de trabajar en varios proyecto de migración, en 2015 grabé una serie de videos sobre Git para explicar algunos principios básicos de su funcionamiento, los pueden encontrar aquí.