Afortunadamente ya hice mi articulo de opinion de Git , y puedo referenciarlo en mis publicacion de forma que mi critica a derivados tenga fundamento.
Git, ese sistema distribuido, que permite versionar sistemas, directorios, y archivos de texto. Basicamente permite version linux. Que permite el control autoritario de integraciones independientes. Es sumamente potente y estable, para soportar procesos diseñados por un preescolar como Gitops.
¿Cuál es la idea de GitOps? Como cualquier otro OPS se trata de llevar la operacion en un proceso o workload de Git.
Y se preguntaran ¿Espera de Git? ¿Pero Git no es un gestor de contenido? Si, si es un gestor de contenido. Pero Github, Gitlab entre otras plataformas, dentro de sus productos, dan la capacidad de generar mecanismos de aprobacion, compilacion y despliegue. Los sistemas que en DevOps, se consideran las etapas de Development crear el codigo y unirlo, Build compilarlo en un servidor remoto y crear diferentes empaquetados o versiones, Test ejecutar pruebas automatizadas sobre los binarios y Deploy conectarse a host e instalar.
Y hace todo el sentido del mundo que las integraciones de codigo en esta caso los Pull Request o los Merge Request, que se hacen la carpiteria de ‘git merge rama’ una vez se cumplen algunas condiciones, genere eventos que disparen flujos. Entonces podemos tener un perfecto ciclo de desarrollo de software con Git de hecho siempre ha sido asi.
El origen de GitOps es, mas que nada para la infraestructura, usando tecnologias ‘cloud native’ que permiten usar los artecfactos del ciclo de vida de desarrollo, y almacenar en un repositorio separado (preferiblemente) la informacion de despliegue, como ConfigMaps de Kubernetes, Despliegues generados Ansible, o con Terraform. U otras herramientas de configuracion por codigo. Y gestionar flujos. Esto puede parecer riesgoso, y aveces lo es, pero los planes de despliegue se incluyen en la configuracion, y es facil navegar en el tiempo. Si un despliegue falla y fallan sus pruebas normalmente en un sistema complementario, se puede retornar al estado anterior. Todavia hace sentido, todavia son flujos con razon. Y eso nos lleva a evolucionar. Y tener ideas.
Oh oh oh, ¿pero qué flujos puede disparar? Por ejemplo profesor Moises, si el código que hacemos son usuarios, ¿podría el deploy ejecutarlos sobre un directorio activo? ¡OH SI! Si puede. Nada como conectar un archivo Git con nombres de usuarios, y en cada ‘merge’, usar el paso de deploy para ejecutar en un Active Directory, un listar todo, comparar con la lista ‘delete’ de todo lo que no está, y un ‘create’ de todo lo que si está en la lista, solo necesitamos un nodo de computo con Ansible o Bash o Powershell o Python ustedes digan, facil, simple, delicioso, brillante, exquisito, riesgoso, ¡IDIOTA!
¿Colocar la operacion de procesos generales en un gestor de archivos? Radical, eso NO es GitOps, no es algo tan arriesgado, inseguro, si me preguntan, y nadie lo hace porque no quieren mi respuesta esta mas cerca de GitPopo, y no solo he visto ejemplos como el de los usuarios que puede ser banal o critico e visto resolucion de incidencias.
Si , si escribi bien, Incidientes, no de Software tipo necesitamos una nueva version de codigo, de Plataforma de helpdesk, se crea un incidente, alguien hace un codigo para digamos reiniciar un equipo en la red, se publica se ejecuta. Y EL COMMIT es la evidencia de resolucion y el trigger que ejecuta el comando remoto.
¿Por que? ¿Por que? se usa un sistema de gestion de contenido de texto, como una base de datos transaccional, como un sistema de tickets, como un disparador de eventos y señales.
Si, si tengo problemas existenciales cada vez que veo ese tipo de sistemas, cada vez que los proponen, en algunas ocaciones normalmente cuando hago de consultor, tengo la autoridad para decirle a la persona con la ideota (de gran idea) que hagamos un ejemplo. Y todo se va al infierno. En otras ocasiones normalmente cuando soy el implementdor, solo me toca reir, y decir ‘vamos a crear tu pequeño infierno’.
Git soporta ser usado como una base de datos transaccional, con el pequeñito problema, de que no permite revertir, porque git esta hecho para manejar archivos de texto de software, no archivos de texto como base de datos con timestamps. Incluso usar un blockchain que es un Ledger (un libro diario) es mejor, sigue siendo cuestionable, porque un libro diario no se puede reparar cuando pasa un problema, pero es mejor que git.
Las transacciones, y las operaciones. Deben exitir o al menos es preferible que existan, en conceptos que soporten una transaccion, como una base de datos relacional o no relacional por ironias de la vida. Las cuales tambien pueden tener timestamps, las cuales pueden permitir multiples estados. Pero un CSV controlado por un repositorio en una plataforma colaboratiba de Git (por Git solo no permite semejante aberracion).
Hay cualquier cantidad de sistemas de ticket, que soportan cualquier metodologia de cambios y resolucion de problemas, procesos, y pare de contar, por decir alguna ITIL, COBIT, TOGAF, todas alguna, lo que quieran. (Se que esas 3 son complementarias no tanto equivalentes). Pero los sistemas de tickets, y los sistemas de planificacion resuelven las metodologias de gestion de servicios y planificacion. No Git, No Github, No Gitlab, los sistemas para desarrollar software.