Configure la integración continua para sus proyectos de Salesforce ☁️

Esta es una traducción que desde EGA Futura ofrecemos como cortesía a toda la Ohana y comunidad de programadores , consultores , administradores y arquitectos de Salesforce para toda Iberoamérica .

El enlace a la publicación original, lo encontrarás al final de este artículo.

…

Crear aplicaciones robustas es difícil. Los desarrolladores pueden esforzarse mucho en escribir código, probar y realizar revisiones por pares, pero los errores aún pueden afectar la producción. Para reducir este riesgo y mejorar la calidad del código, confiamos en la integración continua (CI). En esta publicación, presentaremos CI y sus conceptos básicos, luego analizaremos cómo puede configurar flujos de trabajo de CI para sus proyectos de Salesforce.

Una introducción al desarrollo continuo

Antes de pasar a los detalles de CI aplicados al ecosistema de Salesforce, debemos ver qué es CI desde un punto de vista independiente de la tecnología. Nos centraremos en CI en aras de la brevedad, pero este es solo el primer paso de tres en el camino hacia el desarrollo continuo :

La integración continua (a menudo denominada CI) le permite crear, implementar y probar su proyecto automáticamente.
La entrega continua va más allá al basarse en CI y automatizar el empaquetado de los entregables de su proyecto. Por ejemplo, la entrega continua es responsable de crear paquetes instalables de nuestras aplicaciones de muestra una vez que las solicitudes de extracción se fusionan en nuestra rama principal de Git.
La implementación continua (a menudo denominada CD) implementa automáticamente los entregables producidos durante la entrega continua a sus diversos entornos: desde su entorno de desarrollo hasta la prueba de aceptación del usuario (UAT) hasta la producción.

CI requiere al menos dos componentes de software: un sistema de control de versiones (VCS) y un sistema CI (una herramienta que le permite automatizar flujos de trabajo). Un flujo de trabajo de CI generalmente se compone de unos pocos pasos básicos: comienza recuperando las fuentes de su proyecto de su VCS; luego construye e implementa su proyecto en un entorno de prueba, luego ejecuta pruebas; y finalmente limpia o desecha el medio ambiente.

Los sistemas de CI aportan automatización, previsibilidad y rendimiento al proceso. Hay varias herramientas disponibles en el mercado, pero a un alto nivel, todas funcionan con el mismo patrón. Una compilación de CI comienza cuando ocurre un evento en Git (o cualquier otro VCS), que generalmente es algún código que se guarda en el VCS. Esto desencadena un flujo de trabajo de CI (un grupo de trabajos que se componen de pasos) y los pasos producen y/o consumen recursos y entornos a medida que se ejecutan.

Un ejemplo práctico de esto podría ser:

Flujo de trabajo: verifica que una nueva solicitud de extracción no introduzca regresiones en tu proyecto
1. Trabajo: verificar el front-end de la aplicación
  1. Paso: consulte el código fuente
  2. Paso: verificar el formato de origen del front-end
  3. Paso: pela la fuente del front-end
  4. Paso: Probar la fuente del front-end
  5. ….
2. Trabajo: verificar el back-end de la aplicación
  1. Paso: consulte el código fuente
  2. …

Definir la granularidad de los trabajos de CI en un flujo de trabajo es algo subjetivo, pero querrá garantizar una separación de preocupaciones como hicimos en el ejemplo anterior al dividir las comprobaciones de front-end y back-end. Si elige muy pocos trabajos, es probable que termine con trabajos complejos con una gran cantidad de pasos, y esto puede ser difícil de mantener. Por otro lado, si tiene muchos trabajos con pocos pasos, puede perder el tiempo de ejecución de CI con tareas redundantes (revisar fuentes, instalar dependencias/herramientas, etc.).

Como regla general, el tiempo de ejecución de CI se considera un gasto (ya sea que lo pague con un sistema alojado o no). Para reducir costos, desea reducir la duración de la compilación con flujos de trabajo optimizados que fallan rápidamente en caso de errores.

Veamos cómo se aplican estos conceptos de CI a los proyectos de Salesforce.

Configure su flujo de trabajo de CI

Hay dos tipos de desarrollo de proyectos de Salesforce: impulsado por la organización o impulsado por la fuente . En el desarrollo dirigido por organizaciones, su organización de producción se considera la única fuente de verdad y usted recupera metadatos de ella para desarrollar con sandboxes. En el desarrollo basado en el código fuente, su sistema de control de versiones es la única fuente de verdad y usted crea a partir del código fuente y las organizaciones temporales (o un espacio aislado para desarrolladores con el seguimiento del código fuente habilitado). En esta publicación, nos centraremos en el desarrollo basado en fuentes con organizaciones temporales, pero la mayoría de los pasos de CI se aplican a ambos tipos de desarrollo.

Recomendamos que los flujos de trabajo de CI de Salesforce se dividan en al menos dos trabajos principales. El primer trabajo aprovecha los scripts de Node.js para formatear, aplicar lint y probar Lightning Web Components (LWC) tal como lo haría en su máquina. El segundo trabajo utiliza la CLI de Salesforce y una organización temporal (o un espacio aislado) para implementar los metadatos del proyecto y probar el código Apex. Además, puede agregar un tercer trabajo que maneje empaques , pero lo dejaremos como un ejercicio de lectura.

Aquí hay una descripción general de un flujo de trabajo de CI de Salesforce para un proyecto de desarrollo basado en fuentes:

Formatear fuentes, lint y probar LWC

El primer paso de cualquier trabajo de CI generalmente es verificar el código fuente para la confirmación actual. Luego, configurará su entorno con las herramientas especiales necesarias (como la CLI de Salesforce).

Para nuestro primer trabajo, queremos instalar el proyecto Node.js que viene con la plantilla de proyecto predeterminada de Salesforce. La instalación de las dependencias de desarrollo de Node nos brinda acceso a una variedad de herramientas y scripts que podemos usar en nuestra máquina de desarrollo y durante CI. Vea más detalles sobre cómo aprovechar al máximo los scripts de Node.js.

Deberá instalar el proyecto con npm ci ( consulte los documentos ) en lugar del npm install ( consulte los documentos ). El npm ci está dedicado a entornos automatizados y garantiza una instalación limpia en lugar de una instalación incremental.

Una vez que se instala el proyecto Node, el trabajo ejecuta los siguientes scripts de Node en tres pasos:

 # Verificar formato con Prettier
# (esto falla si el código no está bien formateado, no modifica el código)
npm ejecutar más bonito: verificar # Pelusa con ESLint
npm ejecutar pelusa # Pruebe LWC con Jest y recupere la cobertura del código
npm ejecutar prueba: unidad: cobertura

Estos pasos están organizados en este orden para que los más propensos a fallar y los más cortos se ubiquen primero: formatear, eliminar pelusas y luego probar.

Implemente metadatos y pruebe Apex

El segundo trabajo de su flujo de trabajo de CI se centrará en tareas que involucran la CLI de Salesforce. Al igual que con el primer trabajo, comenzará revisando el código fuente y luego instalando las herramientas. Puede trabajar con una imagen de máquina virtual que tenga herramientas preinstaladas o puede instalarlas dinámicamente como parte del flujo de trabajo de CI.

Opcionalmente, puede instalar un escáner, como PMD , para realizar análisis de código estático de Apex. El escáner analiza su código e informa sobre posibles errores, código demasiado complejo o problemas de seguridad en función de un conjunto de reglas que usted configura. Las infracciones de reglas se pueden utilizar para detener el flujo de trabajo de CI.

Aquí hay un ejemplo de cómo puede instalar PMD y ejecutar un análisis:

 # Lea la versión PMD de un archivo de configuración y guárdelo en una variable
PMD_VERSION=`cat pmd/pmd-version.txt` # Descargar versión PMD
wget https://github.com/pmd/pmd/releases/download/pmd_releases%2F$PMD_VERSION/pmd-bin-$PMD_VERSION.zip # Extraiga el archivo y cambie el nombre del directorio de instalación para eliminar la versión
descomprima pmd-bin-$PMD_VERSION.zip -d ~
mv ~/pmd-bin-$PMD_VERSION ~/pmd # Ejecute 'pmd --version' para probar la instalación
# y mantener un seguimiento de la versión en los registros con fines de depuración
~/pmd/bin/run.sh pmd --versión # Ejecutar escaneo PMD con un conjunto de reglas
~/pmd/bin/run.sh pmd -- dir force-app -- rulesets pmd/ruleset.xml --format texto

Después de esto, instalará la CLI de Salesforce. Aquí hay un ejemplo en el que puede hacer esto en un paso de CI:

 # Descargue el instalador CLI de Salesforce
wget https://developer.salesforce.com/media/salesforce-cli/sfdx/channels/stable/sfdx-linux-x64.tar.xz # Crear el directorio de instalación
mkdir ~/sfdx # Extraiga el archivo del instalador sin el directorio de nivel superior
tar xJf sfdx-linux-x64.tar.xz -C ~/sfdx --strip-components 1 # Agregue el comando sfdx a la ruta (este es un ejemplo específico de GitHub)
echo "$HOME/sfdx/bin" >> $GITHUB_PATH # Ejecute 'versión sfdx' para probar la instalación
# y mantener un seguimiento de la versión en los registros con fines de depuración
~/sfdx/bin/versión sfdx

Una vez que se instala la CLI de Salesforce, debe autorizarla con su DevHub (o su sandbox). Hay un par de formas de hacer esto, pero está limitado a las opciones que admiten el modo sin cabeza ya que el flujo de trabajo de CI está automatizado. La forma más segura de hacer esto es con el flujo de JWT Bearer con un certificado autofirmado, pero también puede usar el auth:sfdxurl:store ( consulte los documentos ) como lo hicimos en las aplicaciones de muestra .

Una vez que se autoriza la CLI, el trabajo de CI ejecuta los siguientes comandos en pasos separados (estos son ejemplos y deben adaptarse a su proyecto):

 # Crear una organización borrador
sfdx force:org:create --definitionfile config/project-scratch-def.json --setdefaultusername --durationdays 1 # Implementar fuentes de proyectos en la organización borrador
fuerza sfdx:fuente:empuje # Asigne conjuntos de permisos al usuario predeterminado de la CLI (opcional) sfdx force:usuario:permset:asignar --permsetname "perm1, perm2, perm3" # Importar datos de muestra (opcional)
sfdx force:datos:árbol:importar --plan ./data/data-plan.json # Ejecute pruebas de Apex, muestre los resultados en un formato legible por humanos
# y recuperar la cobertura del código
sfdx force:apex:test:run --codecoverage --resultformat human --wait 20

Una vez más, puede agregar un paso opcional que cargue la cobertura del código Apex en una herramienta de informes de cobertura del código.

Finalmente, querrá tener un último paso que siempre se ejecute sin importar el resultado del trabajo. Este paso limpia su organización de Salesforce. Si está trabajando con una organización borrador, todo lo que necesita hacer es simplemente eliminarla ejecutando el sfdx force:org:delete --noprompt . La eliminación de organizaciones borrador no utilizadas es importante, ya que existen límites en la cantidad de organizaciones borrador activas que puede contener un DevHub. Sin embargo, si está trabajando con un espacio aislado, tendrá que revertir cualquier modificación que haya realizado durante el flujo de trabajo de CI para que los flujos de trabajo futuros comiencen desde una organización limpia. El hecho de que las organizaciones borrador sean descartables es una gran ventaja cuando se trabaja con CI.

Ir más allá de la integración continua

Lo ideal es detectar los problemas lo antes posible. El mejor lugar para hacer esto es en su máquina antes de que su código fuente entre en el control de código fuente y CI se active. Esto le ahorra un valioso tiempo de ejecución de CI y evita que contamine el historial de control de código fuente con pequeñas correcciones.

Fail Fast for the Win: cuando se trabaja en CI

La mejor manera de hacer esto es usar ganchos de confirmación previa que ejecutan comprobaciones automáticas antes de que se confirmen los cambios. No desea ejecutar un flujo de trabajo de CI exhaustivo en su máquina porque consumiría mucho tiempo y recursos, pero puede ejecutar algunas tareas específicamente en los archivos que está a punto de cambiar.

En la plantilla de proyecto predeterminada de Salesforce, usamos Husky y lint-staged para lograr esto. Husky nos permite registrar un gancho de confirmación previa de Git que ejecuta un script personalizado. Usamos este script para llamar a lint-staged. Luego, Lint-staged ejecuta pruebas de formato, pelusa y LWC para nosotros. Sin embargo, a diferencia de CI, lint-staged solo ejecuta estas tareas en archivos que están preparados en Git: los archivos que ha modificado y que están a punto de confirmarse, no todos los archivos del proyecto. Esto hace una diferencia significativa en términos de velocidad de ejecución.

Si alguna de las comprobaciones por etapas de lint falla, se cancela la confirmación y puede solucionar los problemas antes de volver a intentar la confirmación. Si todas las comprobaciones tienen éxito, la confirmación de Git se completa y se versionan los cambios.

palabras de cierre

El desarrollo continuo y el desarrollo de Salesforce son temas extensos, y ninguna publicación de blog puede cubrir todo en profundidad. Pero esperamos que esta introducción le haya dado consejos valiosos para su viaje de aprendizaje.

Le proporcionamos un marco de CI base que puede adaptar y ampliar para ajustarse a los requisitos de su proyecto. Con esto, ahora puede elegir sus herramientas preferidas y crear flujos de trabajo de CI optimizados. Lo dejaremos con una colección de recursos que lo ayudarán a comenzar.

No olvide unirse a nuestra próxima sesión "Pregúnteme cualquier cosa" el 26 de enero, ¡el tema de este mes es CI/CD y DevOps! Agrégalo a tu calendario aquí mismo.

Recursos

Publicaciones de blog

Vídeos

Aplicaciones de muestra

Recetas de LWC : por ejemplo, cómo configurar las acciones de CI GitHub

Instrumentos

CLI de Salesforce
PMD : para ejecutar el análisis de código estático de Apex
jq : para analizar JSON con una CLI

Sobre el Autor

Philippe Ozil es un defensor principal de desarrolladores en Salesforce, donde se enfoca en la plataforma de Salesforce. Escribe contenido técnico y habla con frecuencia en conferencias. Es un desarrollador de pila completa y disfruta trabajar en proyectos DevOps, robótica y realidad virtual. Sígalo en Twitter @PhilippeOzil o consulte sus proyectos de GitHub @pozil .