Salesforce CLI: la herramienta de automatización para todos

Existen muchos artículos sobre los comandos que podemos lanzar con la linea de comandos de Salesforce, la llamada Salesforce CLI.

Pero en muchas ocasiones, me pregunto si al mostrar todos esos comandos, conseguimos realmente transmitir las capacidades y los beneficios que la CLI puede aportar a todos, sin excepción.

Por este motivo, este artículo tiene un enfoque completamente distinto.

Este artículo tiene una aproximación completamente distinta, ya que pretende transmitir las capacidades de la CLI, sin mostrar ni una línea de comando, y enumerar las capacidades y profundizar en los beneficios, de su uso.

Como explicaré en este artículo, la CLI nos aplica a todos, y seguramente será una de las herramientas, que marcará la diferencia entre los equipos que la internalicen en sus procesos y en los que no lo hagan.

A nivel personal, quiero ya enfatizarte que esta herramienta aplica a cualquier rol que ejerzas, tanto de Administrador, Desarrollador, Devops ó Arquitecto.

¿Para qué sirve la CLI? ¿Cómo me puede ayudar?

Existe cierta confusión, a que esta CLI está asociada al desarrollo exclusivo de proyectos DX, por lo que muchos no la abordamos en nuestros proyectos actuales. Para ahondar en este malentendido, su invocación se realiza con el comando sfdx, con lo que cualquier miembro de la comunidad expuesto a una presentación de CLI, lo descarta si no está involucrado en proyectos DX, y Zasca (como diría mi hija mayor).

Capacidades de la CLI

• La Salesforce CLI permite la automatización de tareas de Salesforce, tanto a nivel de infraestructura, programación, despliegue y mantenimiento de datos. Del grado de automatización depende de las tareas repetitivas que nos gustaría liberarnos.
• La Salesforce CLI ayuda a reducir los tiempos de ejecución de tareas, e incluso construir nuevos flujos complejos de tareas, que la CLI aporta nativamente.

Coste-Beneficio

Si aplicamos el principio del Obispo Amish nos deberíamos preguntar: ¿Cuál es la relación coste-beneficio de esta nueva herramienta y por qué es bueno para nosotros adoptarla?

• La automatización de tareas que permite la CLI, nos libera de la ejecución de procesos manuales, que siendo valiosos, son tediosos y consumen tiempo que podríamos dedicar a otras tareas de más valor.
• Mover datos, crear entornos, despliegue de metadata, son tareas fundamentales en un proyecto, de gran valor, pero que deben ser automatizadas y repetibles por cualquier miembro del equipo, con el mismo resultado (deben ser idempotentes).
  Desafortunadamente, la mayoría de equipos dependen de la buena voluntad, ó de las capacidades de scripting que alguno de ellos tuviera, y se apañan como pueden individualmente. Esto supone un riesgo, dado que no existe un modelo sobre el que vayamos creciendo y mejorando, sinó creando islas de procesos distintos.
• La curva de aprendizaje de la CLI es realmente baja, no es una CLI como la de un sistema operativo, como cientos de comandos, con infinidad de parámetros, sino que está estructurada y pensada para ser absorbida rápidamente por cualquiera expuesto a Salesforce.
• La CLI no tiene coste de licenciamiento, puede ser usada en cualquier entorno, desde un ordenador personal, hasta servidores de integración continua.

Por tanto, el coste-beneficio es positivo casi en cualquier situación, su exposición no comporta riesgos, y en cambio nos libera tiempo. Incluso podemos realizar tareas que no éramos capaces de realizar hasta ahora, o que no considerábamos por el coste que nos suponían.

¿A quién puede ayudar? ¿Es únicamente para desarrolladores?

Esta respuesta para mi es la clave: es PARA TODOS, sin excepción, y no está destinada exclusivamente a desarrolladores para nada.

Dado que la CLI permite automatizar tareas en cualquiera de las fases en las que estés participando, obtendrás optimizaciones de tus flujos casi en cualquier área.

A modo de ejemplo, te expongo algunas de los automatizaciones que nos permite la CLI:

• Automatización de la Creación de entornos de desarrollo, test, e integración.
• Automatización de las tareas que forman parte de los procesos de CI/CD.
• Automatización de la creación de Packages tanto de 1a como de 2a generación.
• Automatización de lectura y escritura de datos entre entornos.
• Automatización de ejecución de Tests.
• Automatización para la obtención de datos de uso.
• Automatización para obtención de información del esquema de objetos.
• etc.

Por tanto, NO son capacidades exclusivas del ámbito de desarrollo, sino que pueden eficientar muchas de las fases del proyecto y puede ser usada por todos.

Sino uso la CLI, ¿me estoy perdiendo alguna cosa?

Desde mi punto de vista si. Al no automatizar tareas repetitivas, el tiempo invertido en estas tareas no se destina a otras tareas de mayor valor personales o del proyecto.

Pero no solo hablo de eficiencia, en cuanto a calidad, disponer de procesos automatizados, supone que en los momentos de mayor presión, evitaremos omisiones y errores, y falsos atajos siendo capaces de repetir los mismos procesos y comparar resultados etc.

Además, la profesionalidad percibida por el destinatario del proyecto, es completamente distinta, ya que ofreciendo procesos repetibles, damos poder a los procesos y disminuimos las dependencias con las personas. Además, los procesos automatizados, son susceptibles de ser adaptados a nuevas necesidades, en cambio los procesos manuales que realizaba un miembro que ya no está no lo son, es decir, mayor valor para el cliente.

En proyectos con equipos de varias personas, los mecanismos de automatización disminuyen la fricción, los errores y las confusiones, y permiten socializar procedimientos para su mejora continua con la aportaciones de todos los miembros o incluso del destinatario del proyecto.

Finalmente me llama mucho la atención que la penetración de metodologías ágiles sea muy elevada en la mayoría de empresas, pero los proyectos de Salesforce no dispongan habitualmente de procesos automatizados que alivien la carga en los Sprints, aportando procesos de automatización de creación de entornos, movimiento de datos, ejecución de tests, despliegues automatizados, etc.

Por tanto, no usando la CLI, si estás perdiendo algo, quizás demasiado.

Salesforce CLI no es (únicamente) para Salesforce DX

It’s the Salesforce CLI–not the Salesforce DX CLI

Esta frase extraída del título del post publicado por René Winkelmeyer (evangelista de DX y de la CLI) deja claro que no es necesario conocer DX, ni tener proyectos DX, para aprovechar las funcionalidades de la CLI.

Como verás a continuación, muchos de los comandos de CLI, son ejecutables en cualquier proyecto sea DX o tradicional.

De hecho, para algunos comandos no hace falta ni tener un proyecto, con tan solo autorizar una de las Sandboxes u Orgs productivas con las que trabajamos, es suficiente para utilizar muchos comandos con los que realizar automatizaciones de nuestras tareas.
Sin embargo, es cierto, que existen comandos que solo pueden utilizarse con Scratch Orgs por ejemplo, pero ni son la mayoría y a cada nueva versión de la CLI se van disminuyendo.

La CLI permite la automatización de tareas en cualquier proyecto, sea o no en formato DX, por tanto, destierra la idea de que no es para tí, porque casi con total seguridad te puede ayudar en tus flujos de trabajo.

¿Qué necesito para usarla y cuales son sus requerimientos?

Para ejecutar la CLI solo necesitas un ordenador con sistema operativo Windows, Linux o MacOS. Instalarla te llevará unos minutos, y ya la tendrás disponible para su uso.

Por supuesto, también puedes realizar su instalación en servidores, para establecer procesos de automatización a nivel de proyecto, departamento, empresa, etc. Los comandos, estan pensados para ello, y por ejemplo, el flujo de autorización puede ser mediante Login interactivo en la Org, pero también mediante un token JWT, generado previamente.

Los requerimientos de la CLI son realmente básicos, pero sobretodo, conocerla y querer usarla.

Habiendo establecido quienes podemos beneficiarnos, cual es la relación coste-beneficio y los requerimientos de ejecución, veamos a nivel detallado cuales son sus capacidades.

Apartados de la CLI

Otro objetivo de esta entrada consiste en reducir la curva de aprendizaje de lo que ofrece la CLI a 15′, lo que tardarás en leerlo.

Actualmente, en la versión en la que escribo este artículo (6.51.1), la CLI está formada por 17 grupos de comandos. Todos ellos agrupados bajo un super-apartado denominado force. La nomenclatura correcta es:

• force es lo que se denomina el namespace
• Cada uno de los 17 apartados lo llamamos grupos de comandos ó topics

A mi personalmente, me cuesta entender cuando tengo que analizar 17 apartados distintos relativos a un tema, y automáticamente me surgen las dudas: ¿Son todos importantes?, ¿Existen dependencias entre ellos que debo respetar para entenderlos y/o usarlos?

Por tanto, para facilitar tu curva de aprendizaje, mi propuesta es la siguiente:

• He agrupado todos los topics en 5 áreas
• Cada área agrupa topics por funcionalidad o afinidad, por lo que podrás centrarte en los que más te apliquen
• En cada área comento sus capacidades, mi entendimiento si vas a utilizarlo inmediatamente, y si es imprescindible que la conozcas.

Las 5 áreas son:

1. Mecanización de la CLI: tecnicismos que debes conocer para el uso correcto y eficiente de la CLI, entender que debo autorizar las Orgs, que es más eficiente y fácil utilizar alias y usernames, etc.
2. Creación de código: permite la creación/gestión de elementos funcionales, como la creación de clases Apex, de Tests, etc.
3. Manipulación de datos: permite la manipulación de datos, para consultarlos, exportarlos e importarlos.
4. Gestión de despliegues: permite el aprovisionamiento de elementos funcionales hacía instancias (Scratch ORGs, Dev Orgs, etc.), realizando operaciones de retrieve, deploy, push, pull, merge, etc., tanto en el modelo tradicional como DX.
5. Gestión de ORGs: permite la gestión del ciclo de vida de ORGs, para creación de Orgs de distintos tipos y controlar su ciclo de vida.

La clasificación de los topics en las Áreas anteriores queda de la siguiente manera:

¿Qué topics engloba cada área y qué topics la conforman?

Veamos ahora las funciones principales de cada una de las áreas y sus topics:

Área 1: Mecanización de la CLI

Esta área debes conocerla porque es la base del uso de la CLI. Los conceptos son muy simples:

• Para usar una Org existente debo autorizarla y/o crearla.
• Para crear Scratch Orgs debo tener una Org de tipo Dev Hub que debo autorizar.
• Para simplificar la escritura de comandos, en lugar de escribir URLs larguísimas, utilizamos usernames y alias.
• Existen numerosas variables de entorno que podemos modificar para tunear algunos comandos e incluso simplificarlos.
• Para todos los comandos de la CLI, tienes documentación en linea, que debes si o si saber invocar y utilizar (es trivial).
• Finalmente puedes automatizar la creación de proyectos, que únicamente te aplicará si vas a automatizar ese aspecto.

Grupo de comandos force:auth
Los comandos de este topic permiten:

• Autorizar ORGs existentes y así ya quedan registradas para su uso.
• Su usa el típico flujo interactivo del navegador con usuario y password (Web-based Flow), pero también permite el flujo de la utilización de un token Json generado con certificado (JWT-based Flow), pensado para el uso en servidores.
• El de-registro es otra de las funcionalidades y puede realizarse de forma unitaria o de todas las Orgs.

Las opciones de este apartado son imprescindibles, debes conocerlas a fondo y no te llevará más de 15′ y muy pocos comandos.

Grupo de comandos force:alias
Los comandos de este topic permiten:

• Para facilitar el trabajo se registran los usernames de las Orgs autorizadas y se asignan alias que simplifican la escritura de los comandos.

Los comandos de este apartado debes conocerlos y dominarlos, son muy poquitos y en cambio te serán de mucha utilidad.

Grupo de comandos force:config
Los comandos de este topic permiten:

• Configuración de las variables de ejecución de la CLI, tanto a nivel global como proyecto.

Mi recomendación es que conozcas qué variables existen, y como su modificación puede afectar a tus scripts de automatización. Teniendo esto en mente, a medida, que te vayas adentrando en el uso de la CLI, recordarás o re-visitarás estas variables para adaptarlas a tus casos de uso.

Grupo de comandos force:doc
Los comandos de este topic permiten:

• Obtención de ayuda de los comandos de la CLI.

Familiarizarte con ellos te llevará solo unos minutos y en cambio te serán de muchísima ayuda, son imprescindibles, debes usarlos desde el 1r minuto.

Grupo de comandos force:project
Los comandos de este topic permiten:

• Crear proyectos DX que pueden incluir la definición del Package que vas a desarrollar. La creación del proyecto, puede incluir la descarga de metadata (package.xml) o la creación de un paquete completo que se esté desarrollando.

• Nuevamente las características específicas de este proyecto no quedan al libre albedrío de cada desarrollador, sinó que quedan detalladas en un fichero de configuración denominado sfdx-project.json.

Es decir, ya no dependemos de documentación obsoleta e incompleta que un compañero elaboró hace unos meses para crear nuestro entorno de desarrollo, sinó que mediante la ejecución de un script lo podremos repetir una y otra vez, y como formará parte de nuestro repositorio de código, como un artefacto más, lo iremos evolucionando en el tiempo.

Área 2: Creación de código

En esta área he agrupado los grupos de comandos que nos facilitan la creación de código: apex, ligthning y visualforce. Estas capacidades quedan claramente enfocadas a su utilización dentro de herramientas como IDEs, ALM, etc., pero puedes encarar casos de uso donde su uso simplifique tus procesos.

Dudo que sea el caso de uso de muchos de nosotros, y por lo tanto, solo deberás plantearte ahondar en ella, si contemplas la creación de código al vuelo. No confundas las creación de código, con despliegue de metadata o transferencia de elementos entre entornos, esas capacidades están disponibles en la siguiente área.

Grupo de comandos force:apex
Los comandos de este topic permiten:

• Crear de clases Apex y triggers..
• Ejecutar bloques de código APEX anónimos.
• Ejecución de Tests. Con este mecanismo podemos solicitar la ejecución de todos los tests, los de una/s clase/s concreta/s o solicitar la ejecución asíncrona/síncrona de los Tests.
• Obtener los Logs de debug, y poderlos analizar, comunicar, etc.

Grupo de comandos force:lightning
Los comandos de este topic permiten:

• Creación y Test de componentes Aura y Lightning Web Components y linting de código.

Grupo de comandos force:visualforce
Los comandos de este topic permiten:

• Creación de componentes y páginas Visualforce.

Con la idea puesta en la automatización de procesos de CI/CD, este grupo de comandos es altamente relevante, entiéndelo bien, sobretodo en lo que respecta a automatización de tests.

Área 3: Gestión de despliegues

Esta es la área con más capacidades de las 5 y seguramente la que estoy seguro vas a utilizar in crescendo.
Permite la automatización de cualquiera de los mecanismos de despliegue entre entornos, ya sea en proyectos tradicionales con Metadata o en modelo DX. Permite la creación de paquetes de 1a y 2a generación y automatizar tareas de inspección de metadata, creación de usuarios, etc., que son funcionalidades que habitualmente se requieren para automatizar un proceso de CI/CD.

Grupo de comandos force:mdapi
Desplegar es uno de los procesos más costosos, problemáticos y estresantes que realizamos en un proyecto. Para ello utilizamos habitualmente la Metadata API. Estos comandos permiten:

• Automatizar la transformación del formato DX al formato Metadata clásico y así aprovechar los comandos disponibles de Dx.
• Utilizar los comandos clásicos de Deploy y Retrieve de metadata, sin necesidad de disponer de un proyecto DX.

Grupo de comandos force:package
Este topic, proporciona los comandos para la ejecución del nuevo paradigma de paquetes que aparecen con la 2nd Generation Package. Básicamente evolucionan los Unmanaged y Managed packages en nuevos homónimos: Unlocked y Managed 2GP respectivamente. Es decir:

• Disponemos de comandos para crear los 2 nuevos tipos de packages. Mediante ficheros de descripción, detallamos las características del paquete y compartirlo con cualquier miembro del equipo para que pueda reproducir su creación de la misma manera.
• Por supuesto existen comandos para la gestión de versiones, y obtener el escandallo de estas.

Este es uno de los temas, que más me interesa especialmente, porque tanto ISVs pero especialmente clientes finales, tenemos ahora las capacidades de abordar el empaquetamiento de funcionalidades como lo realizan otros lenguajes (Java, PHP, etc.), independizando el despliegue entre paquetes (próximas entradas de este blog hablarán ampliamente de este tema).

Grupo de comandos force:package1
Se refiere a los comandos que ya utilizamos para la construcción de Managed y Unmanaged packages que conocemos históricamente. Los comandos de este topic permiten:

• Creación y despliegue de Packages siguiendo el modelo de 1a generación.
• Permite la conversión y empaquetado de código en un package.
• También permite la creación de versiones Beta del package y mediante el uso de los mecanismos de creación de Orgs y ejecución de Tests, crear una ORG, desplegar los Tests correspondientes y ejecutarlos.

Si pudiste consultar el artículo que dediqué a la creación de Managed Packages, te garantizo que el proceso de modificación y despliegue es realmente tedioso cuando no se automatiza y consume una cantidad de tiempo ingente, donde no tienes la sensación de ser muy productivo.

Grupo de comandos force:schema
Permite la consulta de los objetos que tenemos en la ORG. No creo que utilices estos comandos en las primeras fases de adopción de la CLI, pero ten presente que tienes la posibilidad del Describe vía CLI. Por tanto, las funcionalidades de las que disponemos son:

• Obtención de la información de los objetos Standard y Custom.
  Nota: podría pertenecer a otras áreas, ya que conocer el esquema de metadata puede tener muchas utilidades distintas

Grupo de comandos force:source
Para su uso exclusivo con el modelo DX y Scratch Orgs, sinó estás trabajando bajo este modelo, échale un vistazo pero no será tu foco de uso en primera instancia. Los comandos de este topic permiten:

• Push y Pull para sincronizar el código/objetos/etc con nuestras Scratch Orgs (los elementos están traceados).
• Deploy y Retrieve con las ORGs en las que no tenemos nuestros elementos traceados.

Grupo de comandos force:user
Este topic nos permite la gestión de usuarios y la gestión de sus credenciales, que seguro vas a necesitar si tu intención es automatizar etapas de Testing, CI/CD, etc.

• Nos permite la creación de usuarios, mantenimiento de sus credenciales y asignación de Permission Sets.
  Nota: podría pertenecer a otras áreas, ya que la creación de usuarios puede ser útil en varios ámbitos, tests funcionales, etc., pero creo que tiene afinidad con los otros topics del área.
• La creación puede ser un simple comando o partir de una definición detallada en un fichero de configuración. Dado que podemos tener tantos ficheros de configuración como usuarios deseemos, esto permite el aprovisionamiento de usuarios de manera eficaz y simplificada.

Área 4: Manipulación de datos

La gestión de datos, es una tarea imprescindible y dependiendo de como la llevemos a cabo, nos permitirá encontrar situaciones inesperadas… pero es una tarea tediosa y repetitiva.
Sin ninguna duda, familiarízate con este topic y domínalo.

Grupo de comandos force:data
Los comandos de este topic permiten:

• Manipulación de registros simples.
• Importación y exportación de datos en volúmenes, incluyendo el uso de la BULK API.

Seguramente durante el desarrollo de funcionalidades, o testing del proyecto desees utilizar datos reales o ligeramente modificados (masking) para detectar situaciones inesperadas. Con estas funciones, puedes automatizar tanto la extracción del origen como la importación en destino e incluso utilizar los mecanismos de la Bulk API para acelerar estas acciones.

Área 5: Gestión de ORGs

La gestión de ORGs está claramente orientada a la gestión de las Scratch Orgs y su punto de referencia que es la Dev Hub Org. Nuevamente si no trabajas con DX, dudo que el topic Org te aplique desde el principio.

Grupo de comandos force:org
Los comandos de este topic permiten:

• Crear y Eliminar Orgs de tipo Scratch, por supuesto puedes listarlas y quedan asignadas a la Org padre, que denominamos Dev Hub.
• Se utilizan ficheros de definición (project-scratch-def.json), permitiendo características como Edition que queremos usar (Professional, Enterprise), el idioma, y las features (Communities, Apex, etc.).

Super interesante, no te digo más.

Grupo de comandos force:limits
Los comandos de este topic permiten:

• Obtener el consumo de recursos consumidos en las Orgs.

Imprescindible para detectar procesos que están causando un consumo excesivo inesperado y reportar al destinatario que todo seguirá en orden cuando lleguemos a Producción.

Flujos completos con uso de la CLI

Ahora, con una pincelada de las capacidades de la CLI, veamos algunas flujos ejemplo que podemos conseguir si orquestamos estos comandos de forma conjunta. Algunos casos reales son:

Caso de uso 1: automatización de la creación del puesto de trabajo

1. Autorizamos la Sandbox en la que vamos a trabajar
2. Creamos un nuevo proyecto
3. Obtenemos el código de nuestro repositorio
4. Transferimos metadata y código a nuestra Sandbox

Caso de uso 2: automatización de pruebas

1. Autorizamos la Sandbox en la que vamos a trabajar si no lo está o creamos una Scratch Org
2. Obtenemos el código de nuestro repositorio
3. Transferimos metadata y código a nuestra Org
4. Ejecutamos los Test de una clase o de todas
5. Obtenemos resultados y si existen caos, obtenemos su último autor y lo notificamos

Caso de uso 3: automatización de paquetes y despliegue

1. Creamos varias Scratch Org, de diferentes ediciones: Enterprise, Professional y Developer
2. Obtenemos el código de nuestro repositorio
3. Transferimos metadata y código a nuestras Orgs creadas
4. Creamos UnManaged Packages para desplegar
5. Desplegamos el mismo paquete en las 3 ORgs
6. Lanzamos los Tests en todas las Orgs
7. Obtenemos resultados y así conocemos si los paquetes sufren diferencias dependiendo de la edición
8. Destruimos la Scratch Org

Mejor paro aquí, seguro que ya tienes una idea de lo que puedes llegar a automatizar en tu proyecto, y las posibilidades que se abren ante ti.

Una cosa más… es ampliable

Pues si, ya existe la posibilidad de ampliar la CLI con nuestros propios comandos en forma de plugins que podemos crear, y para los cuales Salesforce proporciona una API y procedimiento definido.

Por tanto, puedes crear tus propios plugins y adaptar la CLI u ofrecer plugins complementarios a la comunidad. Por supuesto, ya existen ejemplos de miembros de la comunidad, que son unos cracks, y ya han creado plugins de ejemplo, aunque si te estás iniciando yo dejaría este aspecto para más adelante.

Conclusiones

The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency. Bill Gates.

Un artículo de CLI sin un solo comando.. no sé si es buena idea, pero mi intención si lo era.

La CLI nos abre la puerta a la creación de flujos automatizados de desarrollo, testing, CI/CD, liberándonos de tareas repetitivas y consiguiendo nuevas niveles de calidad y profesionalidad en nuestros proyectos.

Mi recomendación es empezar por la mecanización de un proceso muy simple, en tu propia máquina, y expón tus hallazgos a tus compañeros, y posteriormente a tus responsables para llegar a si al acuerdo de dedicar tiempo a la mecanización de procesos del equipo. Te habrás convertido en el banco del tiempo de tus compañeros.

Creo que la relación coste-beneficio con la CLI, es un coeficiente muy favorable. Aquellos equipos que entiendan y promulguen su uso, obtendrán beneficios y transmitirán una calidad en sus procesos que el resto no podrá aportar sin costes mucho más elevados.

Si como yo estás interesado, puedes empezar ahora mismo, con el repositorio sfdx-simple que ofrece Salesforce y los otros proyectos de la Samples Gallery como Dreamhouse, etc.

No podía acabar sinó con un: sfdx:espero:quesea:deayuda --json

Enlaces Interesantes

• Getting Started with the Salesforce CLI – René Winkelmeyer
• Scripting and the CLI – René Winkelmeyer
• Salesforce DX Developer Guide
• Video: Do not fear the command line, you’re smarter than it with Peter Chittum – Londons Calling 2017º
• Video: Become a Salesforce DX CLI Ninja
• Video: Boost Developer Productivity with Salesforce DX CLI Customized Tools
• Create Your First Salesforce CLI Plugin
• Repositorio del proyecto sfdx-simple

Anuncio publicitario