Introducción: ¿por qué 1C necesita CI/CD?
Si trabajas con la plataforma 1C, probablemente te hayas encontrado con una situación en la que, después de la siguiente actualización, algo se rompe en la base de producción y no es posible revertir los cambios rápidamente. O cuando el equipo de desarrollo está trabajando en una configuración y el código de un programador sobrescribe los cambios de otro. ¿Te suena?
Para resolver estos problemas existe CI/CD (Continuous Integration / Continuous Delivery), un conjunto de prácticas que automatizan el proceso de desarrollo, prueba e implementación de software. Aunque estos enfoques se han convertido en el estándar en el desarrollo web durante mucho tiempo, en el mundo de 1C solo están ganando popularidad. Y esto es comprensible: el ecosistema 1C es específico, funciona con sus propios formatos de configuración y requiere un enfoque especial para el control de versiones.
En este artículo, analizaremos cómo construir una canalización CI/CD simple pero efectiva para 1C, que automatiza las operaciones de rutina y hace que tu trabajo sea más predecible y seguro.
¿Qué es CI/CD en palabras sencillas?
Continuous Integration (integración continua) significa que todos los cambios en el código se combinan regularmente en una rama de desarrollo común, y el sistema verifica automáticamente si estos cambios han roto algo importante. Imagina que cada vez que guardas los cambios en la configuración, el robot comprueba automáticamente la sintaxis, ejecuta pruebas y te informa si algo ha fallado.
Continuous Delivery (entrega continua) es el siguiente paso, cuando tu código se prepara automáticamente para su implementación en un servidor de prueba o de producción. En lugar de exportar manualmente la configuración, copiar archivos y actualizar bases de datos, todo este proceso se realiza automáticamente con solo presionar un botón o incluso sin tu participación.
Características de 1C que se deben tener en cuenta
La plataforma 1C tiene una serie de características que hacen que la implementación de CI/CD sea un poco más complicada que en el desarrollo web convencional. En primer lugar, las configuraciones de 1C se almacenan en archivos binarios (.cf), que son difíciles de versionar con las herramientas habituales de Git. En segundo lugar, para trabajar con 1C se necesita una plataforma instalada, lo que complica la configuración de entornos automatizados. En tercer lugar, 1C tiene sus propias características con bloqueos de objetos, modo de monopolio y características de actualización de la base de datos.
Sin embargo, todas estas dificultades se pueden resolver. Hay un formato para cargar configuraciones en XML que es perfecto para Git. La plataforma 1C se puede ejecutar en modo cliente ligero o incluso sin una interfaz gráfica de usuario, lo que permite su uso en escenarios automatizados. Y para resolver tareas específicas, 1C ha creado varias herramientas de código abierto, de las que hablaremos más adelante.
Herramientas de automatización
Para construir un pipeline CI/CD para 1C, necesitarás varias herramientas. Empecemos por el sistema de control de versiones: aquí la elección es obvia: Git. Este es el estándar de la industria, y es ideal para trabajar con 1C si se configura correctamente el formato de almacenamiento de las configuraciones.
La herramienta clave es OneScript, un intérprete del lenguaje 1C que funciona fuera de la plataforma 1C. Le permite escribir scripts en un lenguaje familiar y realizar varias operaciones con configuraciones. Sobre la base de OneScript se han creado herramientas útiles como vanessa-automation para pruebas automatizadas y gitsync para la sincronización con Git.
Para el servidor CI/CD, puedes utilizar soluciones populares: GitLab CI, Jenkins, GitHub Actions o incluso TeamCity. La elección depende de tus preferencias y de la infraestructura de la empresa. Para los principiantes, recomiendo GitLab CI o GitHub Actions, ya que proporcionan soluciones de alojamiento gratuitas y tienen una configuración sencilla a través de archivos YAML.
También necesitará una herramienta para trabajar con configuraciones desde la línea de comandos. Aquí se pueden utilizar las capacidades estándar de la plataforma 1C (configurador en modo /C) o utilidades especializadas como v8unpack para desempaquetar configuraciones en XML.
Configuración de la estructura básica del proyecto
El primer paso hacia la automatización es la organización adecuada del proyecto. En lugar de almacenar archivos binarios .cf en Git, debe cargar la configuración en formato XML. Para ello, cree una carpeta src en la raíz de su proyecto, donde se cargará el código fuente de la configuración en forma de archivos XML separados para cada objeto de metadatos.
La estructura de un proyecto típico de 1C en Git puede verse así: la carpeta raíz contiene el directorio src con la configuración cargada, la carpeta tests con pruebas automáticas, la carpeta scripts con scripts de servicio para ensamblar e implementar, así como archivos de configuración para el sistema CI/CD, por ejemplo .gitlab-ci.yml o .github/workflows/main.yml.
Es importante añadir a .gitignore los archivos que no necesitan ser versionados: archivos temporales 1C con extensión .tmp, archivos de bloqueo .1CV8, carpetas con caché y registros. Tampoco se deben almacenar las bases de datos de información en el repositorio, solo el código fuente de las configuraciones.
Creación de la primera canalización
Creemos una canalización CI/CD simple que realizará comprobaciones básicas en cada confirmación. Para el ejemplo, usaremos GitLab CI, pero la lógica también se aplica a otros sistemas.
Crea un archivo .gitlab-ci.yml en la raíz del proyecto y define varios pasos: verificación de la sintaxis, compilación de la configuración, ejecución de pruebas e implementación. En la primera etapa, el pipeline comprueba la sintaxis de la configuración: esta es una operación rápida que le permite detectar errores obvios, como paréntesis no cerrados o nombres de variables incorrectos.
Para verificar la sintaxis, puedes usar el configurador 1C en modo de línea de comandos. Crea un script que cargue la configuración de los archivos XML en una base de datos vacía y ejecute una comprobación de la configuración. Si el configurador encuentra errores, el script debe terminar con un código de retorno distinto de cero y el pipeline se detendrá.
La segunda etapa es el ensamblaje de la configuración. Aquí, a partir de los archivos XML, se ensambla un archivo cf completo que se puede utilizar para la implementación. Este archivo se guarda como un artefacto de pipeline y se puede utilizar en los siguientes pasos o descargarse manualmente.
La tercera etapa es el lanzamiento de pruebas automáticas. Si está utilizando un marco de pruebas como Vanessa-Automation o ADD, todas las pruebas escritas se ejecutan aquí. Las pruebas se realizan en una base de datos temporal, que se crea específicamente para esta etapa y se elimina después de su finalización.
La etapa final es el despliegue. Esta etapa solo se puede ejecutar para ciertas ramas (por ejemplo, master o release) y actualiza la base de datos de prueba o productiva. Es importante implementar esta etapa de manera que, en caso de problemas, sea posible revertir rápidamente a la versión anterior.
Automatización de pruebas
Uno de los principales valores de CI/CD son las pruebas automatizadas. Hay varios marcos para 1C que permiten escribir pruebas automáticas. El más popular es Vanessa-Automation, que admite el estilo de escritura de pruebas BDD (Behavior Driven Development).
Las pruebas BDD se escriben en lenguaje natural en formato Gherkin: dado (Given), cuando (When), entonces (Then). Por ejemplo, una prueba podría ser la siguiente: dado que abrí el formulario de creación de documentos, cuando rellené el campo "Contraparte" con el valor "OOO Rog i Kopita" y pulsé el botón "Guardar", entonces el documento debería guardarse sin errores. Estos escenarios son comprensibles no solo para los programadores, sino también para los analistas o los evaluadores.
Cada uno de estos escenarios está asociado con una implementación en el lenguaje integrado 1C, que realiza acciones y verifica los resultados. Es importante cubrir con pruebas los procesos críticos del negocio: contabilización de documentos, cálculo de registros, generación de informes. Incluso un pequeño conjunto de estas pruebas aumenta significativamente la estabilidad del desarrollo.
Estrategias de ramificación y lanzamiento
Para que CI/CD funcione de manera efectiva, se necesita una estrategia de ramificación correcta en Git. Para los equipos que trabajan con 1C, el flujo simplificado de Git es una buena opción: la rama principal (o master) contiene un código estable, listo para su implementación en producción, la rama de desarrollo se utiliza para integrar nuevas características y se crean ramas de características separadas para cada tarea.
Cuando un desarrollador comienza a trabajar en una nueva tarea, crea una rama desde develop con un nombre claro como feature/add-inventory-report. Una vez finalizado el trabajo, se crea una solicitud de fusión (o solicitud de extracción), que inicia automáticamente el pipeline de CI. Si todas las comprobaciones se han realizado correctamente y la revisión del código se ha completado, la rama se fusiona en develop.
Para crear una versión a partir de develop, se crea una rama release en la que se realizan las comprobaciones finales y la corrección de errores. Después de una prueba exitosa, la rama de lanzamiento se fusiona en el maestro, se marca con una etiqueta con el número de versión y se inicia automáticamente la implementación en el sistema productivo.
Implementación y reversión de cambios
El proceso de implementación de la configuración de 1C tiene sus propios matices. No se puede simplemente tomar y reemplazar archivos: se debe actualizar correctamente la base de información, procesar los cambios en la estructura de datos y verificar la compatibilidad. Para automatizar este proceso, se utilizan scripts que actualizan la base de datos a través de una conexión COM o en modo /C.
Es de vital importancia crear una copia de seguridad de la base de datos antes de actualizar. En el script de implementación, el primer paso debe ser crear una copia de seguridad que se guarde con una marca de tiempo y un número de versión. Si algo sale mal después de la actualización, esta copia de seguridad le permitirá volver rápidamente a la versión anterior.
Después de actualizar la configuración, se recomienda ejecutar pruebas de humo, un pequeño conjunto de comprobaciones que verifican rápidamente el rendimiento de las funciones principales del sistema. Por ejemplo, puedes intentar abrir el formulario principal, crear un documento simple, realizar un cálculo típico. Si las pruebas de humo fallan, la implementación debe considerarse fallida y se debe realizar una reversión automática.
Seguimiento y notificaciones
Una parte importante de cualquier canalización de CI/CD es el sistema de notificación. Los desarrolladores deben saber de inmediato si su confirmación ha roto la compilación o no ha superado las pruebas. La mayoría de los sistemas de CI/CD se integran con mensajeros como Telegram, Slack o sistemas corporativos.
Configura las notificaciones para que sean informativas, pero no spam. Por ejemplo, puedes enviar mensajes solo cuando las pruebas fallan o cuando la implementación en producción se realiza correctamente. La notificación debe contener información básica: qué rama, quién es el autor del commit, qué etapa del pipeline ha fallado, un enlace a los registros detallados.
También es útil recopilar métricas: cuánto tiempo se tarda en ejecutar el pipeline completo, con qué frecuencia fallan las pruebas, cuánto tiempo transcurre desde el commit hasta la implementación en producción. Estos datos ayudan a encontrar cuellos de botella y mejorar los procesos de desarrollo.
Consejos prácticos para principiantes
Empiece poco a poco. No intente construir inmediatamente un CI/CD perfecto con todas las comprobaciones posibles. Comienza con la validación básica de la sintaxis y la compilación automática de la configuración. Cuando funcione de forma estable, añade algunas pruebas sencillas. A continuación, automatiza la implementación en un servidor de prueba. Y solo cuando se haya trabajado toda la cadena, proceda a la implementación automática en producción.
Documenta los procesos. Crea un archivo README en la raíz del proyecto, donde describas cómo funciona tu CI/CD, qué comandos necesitas ejecutar para el desarrollo local, cómo crear versiones. Esto es especialmente importante si hay varios desarrolladores en el equipo o si el proyecto se transfiere a otro equipo.
No ignores las pruebas fallidas. Si el pipeline muestra rojo, esta debería ser la prioridad número uno. El pipeline «rojo» normaliza la situación cuando las pruebas no se superan y, con el tiempo, el equipo deja de prestarle atención. La regla es simple: si la prueba falla, o bien hay que corregir el código, o bien hay que corregir la prueba, pero la pipeline debe volver a estar en verde.
Dedique tiempo a formar a su equipo. La implementación de CI/CD cambia los procesos de desarrollo, y no todos los desarrolladores pueden estar preparados para ello. Organiza varias reuniones en las que expliques por qué es necesario, cómo funciona y muestra ejemplos. Es mejor pasar unas horas aprendiendo que pasar meses luchando contra la resistencia al cambio.
Problemas típicos y sus soluciones
Uno de los problemas más comunes es el funcionamiento lento del pipeline. La compilación completa y las pruebas de configuración de 1C pueden tardar decenas de minutos. Para acelerar el proceso, utiliza la caché: guarda las configuraciones y bases de datos compiladas entre las ejecuciones de la canalización. Divide las pruebas en pruebas de humo rápidas que siempre se ejecutan y un conjunto completo de pruebas que solo se ejecutan para las ramas importantes.
Otro problema son los conflictos al fusionar archivos de configuración XML. Git no siempre resuelve correctamente los conflictos en XML, especialmente si dos desarrolladores han cambiado el mismo objeto de metadatos. La solución es utilizar herramientas especializadas para fusionar configuraciones 1C, como gitsync o EDT (1C: Enterprise Development Tools), que entienden la estructura de los metadatos.
A veces hay problemas con las licencias de 1C en el servidor de CI. Para los procesos automatizados, se requieren licencias que permitan la ejecución sin una interfaz gráfica de usuario. Discuta con su administrador de licencias qué opciones están disponibles para su configuración. Como alternativa, se pueden utilizar versiones de demostración de la plataforma para realizar pruebas, aunque esto tiene sus limitaciones.
Conclusión
Crear una CI/CD para 1C no es un proceso rápido, pero la inversión de tiempo se amortiza muchas veces. La automatización elimina la rutina, reduce los errores y hace que el proceso de desarrollo sea más predecible y profesional. Su equipo podrá lanzar actualizaciones con más frecuencia y confianza, y la calidad del código aumentará inevitablemente.
Empiece con lo básico: configure Git para almacenar configuraciones, añada una validación de sintaxis básica a CI, escriba las primeras pruebas automatizadas. Amplía gradualmente la funcionalidad de la pipeline añadiendo nuevas comprobaciones y automatizando más procesos. Y recuerda: el objetivo principal de CI/CD no es la tecnología compleja, sino mejorar la calidad del desarrollo y la vida de los desarrolladores.
¿Quieres saber más?
Puedes estudiar enfoques modernos para el desarrollo, la automatización de procesos, CI/CD y muchas otras tecnologías en la plataforma educativa KodikCreamos cursos prácticos para desarrolladores de cualquier nivel, desde principiantes hasta profesionales experimentados.
Y también tenemos un genial canal de Telegram con una comunidad amistosa donde puedes discutir cuestiones técnicas, compartir experiencias y encontrar personas afines. ¡Únete! 🚀