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.
…
Esta es la segunda publicación del blog que detalla el progreso del equipo de Salesforce CLI hacia el 100% de código abierto de la CLI. Si no ha leído el primer artículo, o necesita un repaso, consúltelo aquí.
Ahora que te has puesto al día y te has refrescado, probablemente tengas dos preguntas: «Han pasado ocho meses, ¿qué ha pasado?» y «¿Qué progresos se han hecho en este tiempo?» Nos complace compartir que han pasado muchas cosas. Escribimos la primera entrada del blog para explicar dónde estábamos y hacia dónde queríamos ir. Desde entonces, el equipo de CLI ha creado un marco fácilmente extensible para que otros equipos de ingeniería puedan seguir nuestro ejemplo y abrir sus comandos. El desarrollo del marco implicó la creación de plantillas de plug-in y CircleCI orbs para permitir a otros equipos de desarrollo saltarse los pasos de configuración e integración y empezar a codificar sus plug-ins de inmediato. Estos marcos fueron la base para trasladar todo a los plugins – entraré en más detalle sobre cómo ayudaron más adelante.
Antes de sumergirnos en nuestro estado actual, vamos a repasar algunas de las promesas y objetivos de la primera entrada del blog y comprobar nuestro progreso hacia la finalización.
Comprobando
En la primera entrada del blog, nos burlamos de que crearíamos «Una organización GitHub para Salesforce CLI». Buenas noticias, ¡hemos logrado ese objetivo! Puede consultar la organización GitHub aquí: https://github.com/salesforcecli. Aquí es donde ponemos todos nuestros nuevos plug-ins, orbs, templates, agregadores, y monitorización de repositorios. Cuando creemos algo nuevo, lo pondremos en esa organización para que le eches un ojo y veas cómo construimos las cosas en abierto.
Hemos mantenido nuestro actual repositorio de incidencias (https://github.com/forcedotcom/cli/issues) y hemos trasladado las notas de la versión al mismo repositorio (https://github.com/forcedotcom/cli/tree/main/releasenotes.)
Estamos metidos de lleno en el proceso de desmantelamiento del plugin salesforce-alm. En el momento de escribir este artículo, hay al menos 40 comandos de código abierto en el repositorio de la organización repartidos en 11 plug-ins diferentes, y no tenemos intención de reducir la velocidad pronto. Entraré en más detalles sobre este proceso más adelante en esta entrada del blog.
También hemos creado un repositorio de estado (https://github.com/salesforcecli/status) que monitoriza los demás repositorios de la organización de GitHub. Aquí se puede comprobar la versión de un plugin específico, cuando se publicó por última vez, su estado de construcción actual, y la salud general de la CLI y sus componentes.
Cualquier código o repositorio nuevo que cree el equipo se hará en abierto. Nuestro equipo se ha comprometido plenamente a trabajar al 100% en código abierto a partir de ahora.
Descartando el plugin salesforce-alm
Sólo tienes que echar un vistazo a https://github.com/salesforcecli para ver todo lo que hemos estado trabajando en los últimos ocho meses. Una vez que nos acomodamos al ritmo, el equipo empezó a migrar a nuevos plugins muy rápidamente. Cada repositorio corresponde a un plugin. Este es el estado actual de los plugins que hemos abierto:
Completo Actualmente en curso Reservas alias datos mdapi auth fuente org (parte 2) configuración org (parte 1) empaquetado esquema proyecto usuario comunidades límites apex plantillas metadatos personalizados escáner orb ventasforzadas cli
Algunos plug-ins han sido llevados al nivel superior, lo que significa, por ejemplo, que ahora se ejecuta sfdx config:set en lugar del antiguo sfdx force:config:set. Hemos completado este trabajo para los temas auth, alias y config. Pero no te preocupes, les hemos puesto un alias para que también funcionen bajo el espacio de nombres force, lo que significa que tus scripts actuales no se romperán. Sin embargo, le recomendamos encarecidamente que empiece a utilizar los nuevos nombres de comandos lo antes posible.
Desde la tabla anterior, puedes ver que hemos hecho un gran progreso hacia el open-sourcing de todo Lamentablemente, algunos de los temas que quedan por desglosar, concretamente source, son los más complejos y los que más tardarán en abrirse. Les estamos dando prioridad durante el próximo año.
Ya en la primera entrada del blog, dijimos que cada vez más plugins estarían bajo salesforcedx e incluso fuera de él también. Ejecuta sfdx plugins --core para ver nuestro progreso y cómo hemos conseguido lo que dijimos.
Ahora liberando: plugins y la CLI
Cuando empezamos a hacer open-sourcing del código de la CLI, sabíamos que también tendríamos que cambiar la forma de liberar la CLI. En lugar de liberar una estructura mono-repo, ahora liberamos nuevas versiones de múltiples plug-ins. Estos son consumidos por uno o más agregadores y enviamos el resultado final. En teoría, este proceso no es demasiado difícil de implementar, pero en la práctica ha costado mucho trabajo crear un orbe CircleCI fiable y reutilizable. Ahora, una fusión de PR de una rama de desarrollo en la rama principal de cualquier repositorio de plug-in inicia automáticamente una versión de ese plug-in. A continuación, se publica automáticamente y se promueve a una nueva versión en npm, y luego aparece como una dependencia de uno de los agregadores. Aquí puedes ver el plugin plugin-user listado como dependencia del plugin salesforcedx.
Colocamos todos los comandos que están bajo el espacio de nombres force (como force:schema:*) en el agregador salesforcedx. Los complementos para los comandos fuera del espacio de nombres force (como plugin-auth) se incluyen directamente desde el repositorio cli, por lo que se ejecutan estos comandos utilizando sfdx auth:*.
Actualmente la versión latest-rc sólo está disponible vía npm. Para probarla deberías ejecutar npm install sfdx-cli@latest-rc. Todavía no está disponible para la versión estándar instalada de la cli, pero está por llegar. En el futuro podrías ejecutar sfdx update stable-rc . Aunque stable-rc y latest-rc apuntarán a la misma versión, los nombres son diferentes porque el uso de latest y latest-rc es una convención de npm, así que lo estamos usando para instalaciones basadas en npm. El stable y stable-rc son una convención de OCLIF. Así que tienes una ventana de una semana para probarlo y, si encuentras algún error, asegúrate de publicarlo en el repositorio de problemas de CLI con la etiqueta latest-rc y el número de versión. A continuación puedes ver que la etiqueta latest-rc apunta a la versión 7.87.0 y la etiqueta latest apunta a la 7.86.3.
Proporcionamos la etiqueta latest-rc para que la gente pueda previsualizar lo que viene, probar las nuevas características y asegurarse de que está listo para su promoción a latest. Una vez promovido a latest es «vivo» y la versión actual. El equipo de la CLI anima a todo el mundo a utilizar la etiqueta latest-rc en la medida de lo posible. Para asegurar la compatibilidad, le sugerimos que actualice sus procesos de liberación o scripts para utilizar ambas etiquetas. Echa un vistazo a https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_ci_org_dev_repos.htm para ver una variedad de plataformas CI/CD y sus respectivos archivos de configuración.
Contribuir
Cerremos los ojos e imaginemos este escenario: se te ocurre una funcionalidad que beneficiará a otros usuarios, o se te ocurre una corrección de errores, o se te ocurre una mejora de la calidad de vida que a todos les encantaría. En lugar de abrir una incidencia y marcarla como «solicitud de función», te animamos a que te adentres en el código fuente y trabajes en él tú mismo Obtendrás una gran experiencia entendiendo cómo funciona un comando específico entre bastidores, lo que a su vez puede ayudarte a optimizar tu propio flujo de trabajo. Aceptamos pull requests en todos nuestros repositorios de código abierto. Si creas un PR, trabajarás estrechamente con el equipo de CLI mientras realizamos iteraciones y revisiones. Si su PR se fusiona y se libera, estoy seguro de que será feliz usando su nueva característica. Y el equipo de la CLI estará encantado de ver a un colaborador externo cerrando con éxito un pull request
¿Qué pasa si tienes algunos condicionales muy complejos e interacciones personalizadas que estás ejecutando en un script? O estás haciendo algún tipo de magia de la API que podría beneficiarse de ser colocado dentro de un comando? No es una lógica que todo el mundo necesite, pero para algunos sería un cambio de juego. ¿Cómo puedes distribuir esto fácilmente a otros miembros de tu equipo o de la comunidad para que lo utilicen? ¡Un plug-in sfdx! Por suerte, tenemos el repositorio plugin-template, que contiene todo lo que necesitas para empezar a codificar tu propio plugin. Esto incluye orbes de CircleCI para usar, reglas de eslinting, validación de commit, comprobación de compatibilidad con versiones anteriores y soporte de OCLIF directamente. La plantilla está configurada para utilizar los últimos objetivos de TypeScript y eslint. El repositorio plugin-template fue creado usando el comando sfdx plugins:generate. Después se añadió para crear un repositorio estandarizado para el resto de los plugins. Si quieres ver el poder de los plugins por ti mismo, echa un vistazo a lo que uno de nuestros ingenieros, Shane, ha creado con su shane-sfdx-plugins plugin.
Conclusión
Hemos dado grandes pasos hacia la consecución de una CLI 100% de código abierto de Salesforce. Quedan algunos obstáculos, pero en este punto hemos hecho la mayor parte del trabajo duro y la pista está despejada para que podamos continuar. No nos detendremos hasta que hayamos abierto tantos comandos como sea posible
Esperamos que ahora, como lector, te sientas más cómodo creando un pull request para arreglar un error o añadir una nueva característica, y que luego entiendas cómo se publicará y cuándo puedes esperar ver tu cambio en vivo. Todos estamos increíblemente entusiasmados con nuestro progreso y hacia dónde vamos. No podemos esperar a que veas en qué hemos estado trabajando
Recuerda consultar las notas de la versión cada semana para estar al día de las nuevas funciones, las correcciones y las solicitudes de comentarios (RFC), en las que puedes influir en nuestro proceso de diseño.
…
Esta es una traducción realizada por EGA Futura, y este es el link a la publicación original: https://developer.salesforce.com/blogs/2021/02/open-sourcing-salesforce-cli-update-feb-2021.html