Prólogo
Todo comenzó hace más de 2 años, y pasé al cuarto año de la especialidad "Informática empresarial" de la Universidad Estatal de Sistemas de Control y Radioelectrónica de Tomsk (TUSUR). No quedaba mucho tiempo hasta el final de la universidad, y la perspectiva de escribir un diploma ya se avecinaba ante nuestros ojos. La idea de comprar trabajos terminados no fue considerada. Tenía muchas ganas de hacer algo yo mismo. Había muchas opciones para los temas de los proyectos de diploma: tanto los proyectos de configuración para automatizar las necesidades de producción de la empresa como el proyecto para la implementación de Gestión de Documentos por sí solo para 3 unidades territoriales y más de 500 usuarios activos y la introducción de EDI. En resumen, mucho de todo estaba en mi cabeza, pero nada de esto inspiró. Y eso fue lo principal.
En ese momento trabajaba en una empresa de renombre y en asuntos comerciales conocí a un programador genial y, en general, una buena persona Andrei Shcheglov (¡Hola Andrei!) Y de alguna manera = durante una conversación me preguntó si escuché algo sobre OneScript y Lenguaje de scripting de pepinillo. A lo que recibí una respuesta que no, no escuché. Naturalmente, la noche google / Yandex y la noche sin dormir llevaron a la idea de que aquí está: el mundo de lo desconocido. Pero la idea de que esto podría ser el tema de una tesis aún no ha surgido. El círculo de tareas de rutina era el trabajo habitual en el 1C Configurator en cuanto a tareas, tal como lo entiendes con las pruebas manuales y no te permitía sumergirte por completo en un nuevo enfoque en el mundo de 1C.
Conceptos desconocidos
La primera dificultad que encontré fue una increíble cantidad de diferentes terminologías y herramientas de las que no había oído hablar en absoluto, ya que en ese momento era un "odnosnik típico" (en este momento comienza el holivar ...) Especialmente sin conocer ningún otro lenguaje de programación, y Además, las metodologías de las grandes TI no me eran familiares, tuve que saltar de un tema a otro para al menos llenar mi glosario de alguna manera.
Casi en el mismo momento, yo (nosotros y mis colegas) enfrentamos un problema bastante específico. Tomaron el módulo de software del contratista y buscaron copias. Todo parece funcionar. Pero como había mucho trabajo, firmaron un acto de trabajo completado y lo arrojaron a la productividad. Todo estuvo bien durante seis meses, hasta que los datos en este subsistema no excedieron lo permitido. Y comenzaron a suceder cosas muy extrañas. La realización de un documento desde el módulo comenzó a ocurrir durante 5-10 minutos, aparecieron un montón de errores, bueno, etc. Ver el código del programa fue horrible (no pregunte por qué esto no se hizo antes al aceptar ...). El número de ciclos anidados fue más allá de lo razonable. La única solicitud en el cuarto ciclo y la apelación a través de 4 puntos fueron insignificantes, iterando sobre todos los documentos anteriores para completar el documento actual, copiar y pegar 10 veces el mismo bloque y mucho más.
Ejemplo de anidamiento:
Duplicación de campos en el diseño:
Además, para completar estos campos, una copia-copia de 14 veces .
Inicio de ciclo:
Y hasta que la variable FF llegue a 15:
Bueno, y un montón de otras obras de arte igualmente únicas.
De repente recordé que para OneScript hay una biblioteca simple para calcular la "ciclomaticidad" del módulo (1) (la complejidad de un módulo o método). Encontrado, calculado. Obtuve un valor de 163 unidades, con un valor válido de no más de 10. Y llegué a la conclusión de que la prueba de aceptación del código del programa debería ser obligatoria y debería ser automática y continua. Luego me enteré de la inspección continua y, como resultó en 2006, IBM hizo (2) una publicación sobre este tema.
Más más. Probablemente, muchas personas que trabajan en grandes empresas han encontrado el problema de implementar una copia de la base de trabajo en la máquina local del desarrollador. Cuando esta base pesa entre 5 y 10 gigabytes, esto no es un problema, y cuando pesa casi un terabyte solo en la copia de seguridad, esto ya es grave. Como resultado, llevó entre 5 y 6 horas de tiempo de trabajo implementar una copia nueva. Cuando me cansé de ello, comencé a usar una muy buena herramienta 1C-Deploy-and-CopyDB (¡Anton, gracias!) Luego me di cuenta de que la automatización es genial.
Además, había otras tareas, por ejemplo, actualización periódica de la base principal y distribuida desde el almacenamiento por la noche, pruebas de formularios, pruebas de escenarios, etc. Algo de esto se realizó, pero otros no.
Pero todo esto era necesario solo para mí. Al buscar personas con ideas afines en su ciudad, prácticamente fracasó. No estan ahi. Aunque terriblemente extraño, ya que los problemas son típicos. En ese momento ya sabía que quería escribir mi tesis sobre este tema. Pero no sabía qué escribir. Por lo tanto, tuve que unirme a la comunidad no solo leyendo, sino al menos escribiendo y haciendo preguntas. Los principales lugares donde puede hacer preguntas fueron
Proyectos de Github:
• https://github.com/silverbulleters/add
• https://github.com/oscript-library/opm
• https://github.com/EvilBeaver/OneScript
• https://github.com/silverbulleters/vanessa-runner/
Foro XDD:
• sección 1Script
• sección de prueba
• sección de automatización de procesos
Bueno y como medio de comunicación rápida: grupos de perfiles en Gitter
La colección de material ha comenzado. Como el destino lo tendría, logré contactar a Alexey Lustin alexey-lustin (¡Hola Alexey!) Y hablar sobre mi idea de diploma en el foro XDD. A lo que me sorprendió escuchar comentarios de aprobación e incluso una invitación para someterme a la práctica de pregrado en Silver Bullet. Ya era una victoria. Durante varias horas, se nos ocurrió el tema y el contenido del diploma. Establecemos tareas para el trabajo práctico. Obtuve el jefe del proyecto de diploma de la compañía: Arthur Ayukhanov (¡Arthur, hola!) Cómo el joven Padawan tuvo acceso al curso de video del ingeniero de lanzamiento y la capacidad de obtener Nikita Gryzlov (¡Hola Nikita!) Ilimitado con sus preguntas, por lo cual está muy agradecido.
En resumen:
El tema del diploma es "Gestión automatizada del ciclo de vida de los sistemas de información: ingeniería de soluciones de sistemas y software en la plataforma 1C: Enterprise en condiciones de mejora continua de la calidad del proceso de producción".
El propósito del trabajo de calificación final (WRC) es identificar la relación de las herramientas de software y una descripción del proceso de negocio del circuito DevOps en el área 1C.
La justificación teórica del proyecto fue el estándar para la mejora continua de la calidad de servicio de ITIL 3.0, y el objetivo práctico fue la construcción de un bucle de integración continua para la nueva solución de aplicación que desarrollamos: la cuenta personal del cliente. Para hacer esto, se desplegaron el servidor de origen GitLab y el bucle de compilación Jenkins. Las pruebas se ejecutaron en un servidor dedicado (Windows Slave). La configuración se descargó del repositorio 1C utilizando la biblioteca Gitsync , versión 3.0
(actualmente ubicado en la rama de desarrollo) ya con los logros de Alexei Khorev (¡Lech hola!) con una frecuencia de 30 minutos en la rama de desarrollo. La razón para elegir esta versión en particular fue la capacidad de conectarse al repositorio a través del protocolo tcp, que, desafortunadamente, no era compatible con GitSync 2.x típico en ese momento. Si se registraron cambios en GitLab, la ejecución del bucle de integración continua se inició automáticamente.
Como el presupuesto de todo el evento era cero, y la capacidad de construir un control de calidad completo del código del programa sin comprar un módulo para SonarQube era imposible, se utilizó una verificación de sintaxis estándar de 1C como una solución simplificada. Aunque se realizó una descarga única, los resultados se obtuvieron y analizaron. También se utilizaron comprobaciones adicionales para la ciclicidad y la presencia de código reutilizable.
En la etapa de prueba de la funcionalidad, se usaron 2 frameworks Vanessa-Behavior y XUnitFor1C en su versión combinada llamada Vanessa Automation Driven Development (Vanessa ADD). El primero se usó para comenzar a probar el comportamiento esperado, el segundo fue verificar la apertura de los formularios (prueba de humo). Pasar el ciclo de integración continua resultó en informes generados automáticamente.
Según los resultados de la prueba, el ingeniero de lanzamiento tomó la decisión de fusionar las ramas de desarrollo y maestría, y lanzó (ya manualmente) la tercera tarea: la publicación de cambios en la base de datos productiva. La base de datos productiva no está conectada al repositorio y está completamente cerrada por cambios manuales. La actualización se lleva a cabo solo a través de la entrega, y en modo automático.
Para describir el proceso de negocio del circuito, se formó un diagrama IDEF0 que consta de 4 bloques consecutivos que forman el paso del circuito. Un error que ocurre al pasar por cualquiera de las etapas interrumpe el proceso de ensamblaje con una notificación al ingeniero de lanzamiento y transfiere el control al quinto bloque del proceso de ensamblaje, donde los informes se generan en formato ALLURE, JUNIT y, por supuesto, cucumber.json.
IDEF0 Descripción del modelo
El proceso de "Descarga de código fuente en GIT"
Datos de entrada: - repositorio de configuración
Salida (Salida): - Código fuente
Control: instrucciones para trabajar con software, script de ensamblaje
Mecanismo: 1C: Enterprise, Gitsync .
Un requisito previo para la existencia del contorno es la presencia de archivos fuente. Desde la versión de plataforma 8.3.6, 1C proporcionó la capacidad de cargar códigos fuente de configuración en archivos. Cabe señalar que este proceso puede tener varias opciones, dependiendo de los detalles del desarrollo en el departamento de TI. En la versión actual, para simplificar el proceso de transición de los empleados a la nueva metodología, se realizó la integración con el proceso de desarrollo actual a través del repositorio de configuración y el uso del configurador 1C.
En la etapa del proceso "Descarga de fuentes en GIT", se creará el archivo, base de información de servicio 1C; estaba conectado al almacén de configuración bajo la cuenta de servicio; todos los cambios se reciben en el momento actual (o hasta la última confirmación en el repositorio); los códigos fuente se descargaron en el directorio de ensamblado; comprometido con el sistema de almacenamiento de versión GIT; los cambios se envían al servidor de origen de GitLab
El proceso de "probar la calidad del código fuente"
Datos de entrada: - Código fuente
Salida (Salida): - Código fuente
Control: instrucciones para trabajar con software, script de ensamblaje
Mecanismo: 1C: Enterprise, Deployka , SonarQube , Cyclo.os - (desafortunadamente no hay enlace)
Al comienzo de este proceso, el código fuente se almacena en el repositorio de GitLab. Usando el script de control (ensamblaje), se recibe en el directorio de ensamblaje. Mediante la plataforma 1C: Enterprise, basada en estos códigos fuente, se implementa una base de información de servicio. Se realiza un análisis de errores utilizando las herramientas de la plataforma. Si durante el análisis se detectan errores en el código del programa que no permiten ensamblar la configuración, el proceso se interrumpirá. El objetivo de este paso es eliminar el tiempo perdido analizando el código del programa de una configuración inoperativa.
Después de verificar los errores, se inicia el cálculo de la complejidad ciclomática del código del programa. Un aumento en este coeficiente afecta significativamente la depuración y el análisis del código del programa. El valor máximo permitido es 10. Si se excede, se genera una excepción y el código se devuelve para su revisión.
El último paso para analizar la calidad del código del programa es verificar el cumplimiento de los estándares de desarrollo. Para estos fines, el esquema propuesto utiliza el servicio SonarQube y el módulo de soporte de sintaxis 1C desarrollado por él de Silver Bullet. Con base en los resultados del análisis, el sistema calcula el valor de la deuda técnica para cada empleado que publicó el código del programa.
Proceso de prueba funcional
Datos de entrada: - Código fuente
Salida (Salida): - Código fuente
Control: instrucciones para trabajar con software, script de ensamblaje
Mecanismo: 1C: Enterprise, Vanessa-Behavior, XunitFor1C .
Durante el proceso de desarrollo, pueden ocurrir situaciones en las que una nueva funcionalidad puede interrumpir la operación de los subsistemas existentes. Esto puede manifestarse tanto en la formación de excepciones como en la conclusión del resultado no esperado. Para estos fines, se prueba el comportamiento esperado del sistema.
Varios métodos de desarrollo y prueba son aplicables para este circuito: TDD (Test Driven Development) y BDD (Behavior Driven Development)
Al momento de escribir WRC, el marco de comportamiento de Vanessa se utilizó para realizar pruebas usando la Metodología BDD y el XunitFor1C para TDD. Actualmente están fusionados bajo un producto Vanessa-ADD. El soporte de desarrollador para productos más antiguos ha sido descontinuado. Los resultados de la prueba se envían a los archivos de informe Yandex Allure y Xunit.
Proceso "Montaje de entrega"
Datos de entrada: - Código fuente
Datos de salida: - Entrega de configuración
Control: instrucciones para trabajar con software, script de ensamblaje
Mecanismo: 1C: Enterprise, packman .
En este proceso, se produce la entrega final de la entrega de configuración para la implementación en el sistema de destino. El código fuente verificado se encuentra en la rama de desarrollo del repositorio de código fuente de GitLab. Para formar una entrega, es necesario que los cambios desde la rama de desarrollo aparezcan en la rama maestra . Esta acción puede ocurrir tanto manual como automáticamente y está regulada por los requisitos del departamento de TI utilizando el bucle CI / CD. Después de fusionar sucursales, comienza el proceso de ensamblaje de la entrega terminada. Para hacer esto, nuevamente, en el directorio de ensamblaje, sobre la base de las fuentes existentes, se crea una base de información de servicio, y luego, utilizando las herramientas de la plataforma 1C: Enterprise, se genera y archiva una entrega de configuración. La entrega de la configuración es el producto final del proceso de ensamblaje y se entrega al cliente a través de canales de comunicación establecidos o se instala directamente en un sistema de información productivo.
Proceso de publicación de resultados
Datos de entrada: - Descargar resultado, archivos de informe
Datos de salida: - Informe
Control: instrucciones para trabajar con software, script de ensamblaje
Mecanismo: Yandex Allure , Xunit .
Al realizar los pasos del proceso, las herramientas de prueba crean archivos de informe en ciertos formatos como subproducto. La tarea de este proceso es agrupar, transformar y publicar para la conveniencia del análisis de datos. En el caso de que se genere una excepción en alguna etapa del ensamblaje y con la configuración necesaria, el sistema debe notificar automáticamente al administrador del bucle de los problemas. Esta etapa se realiza en el procesamiento posterior del proceso de ensamblaje y debe realizarse independientemente de los resultados de los procesos anteriores.
Para obtener comentarios, además de la lista de correo, se utilizó la integración con el gerente corporativo de Slack, donde se enviaron todos los mensajes de información sobre el estado de la compilación, la aparición de nuevos compromisos, la formación de copias de seguridad, así como el monitoreo del funcionamiento de los servicios relacionados con el circuito DevOps y de 1C a todo
Los resultados de mi proyecto fueron la protección de WRC a finales de mayo de este año con el resultado "excelente". Además, se actualizó la información metodológica sobre la formación del contorno.
Conclusiones generales:
- El efecto económico solo es posible a largo plazo. Por experiencia, se observó que cuando se lanza el proyecto de implementación de prácticas de ingeniería, se registra una disminución en la productividad del desarrollo en un 20-30% desde el nivel actual. Este período es temporal y, por regla general, el rendimiento vuelve a sus valores iniciales después de tres o cuatro meses de funcionamiento. La disminución en el rendimiento se debe principalmente al hecho de que el desarrollador tiene que acostumbrarse a los nuevos requisitos de desarrollo: escribir scripts, pruebas y crear documentación técnica.
- La estabilidad de un sistema de información productivo ha aumentado significativamente debido a la prueba del código del programa. El funcionamiento garantizado de los subsistemas críticos es proporcionado por la cobertura de prueba de escenarios. Debido a esto, se redujeron los riesgos de la empresa en un área crítica: la interacción operativa con los clientes.
- La exclusión de las correcciones dinámicas en una base de información productiva hizo posible planificar de manera más constructiva el desarrollo y evitar que el código de software se saliera del ciclo de prueba.
- Costos laborales reducidos para el servicio de la base de información debido a la automatización del circuito de ensamblaje.
- El uso de la retroalimentación a través de Slack hizo posible monitorear y corregir los problemas del ciclo de vida del sistema en línea. Según las revisiones del equipo, usar un mensajero es más conveniente que enviarlo por correo (aunque también está presente).
- El uso de la inspección automática de código continuo (Inspección continua) para cumplir con los estándares de desarrollo (SonarQube) obliga a los desarrolladores a aumentar de manera independiente su competencia, y la fijación de la deuda técnica identificada directamente durante el desarrollo de un módulo de software es mucho más rápido, ya que no tiene que perder tiempo restaurando el contexto de la tarea.
- Habilitar la funcionalidad de la documentación automática y la generación de instrucciones en video puede reducir la cantidad de solicitudes de los usuarios.
- Durante el curso del proyecto, se formó un proceso comercial que describe el ciclo de vida del desarrollo y prueba de las soluciones de aplicación 1C, lo que a su vez influyó en la formación de un proyecto para la implementación de prácticas de ingeniería . , 1.
, . 90% .
, :
- , " 1. - , , ( 5 ).
- “ 1”. . ( , " ". ).
- CICD 1 , 5.5.0 .
, , 1 , DevOps. , — DevOps 1 .
, DevOps 1. ?