Lograr una CLI de Salesforce de código abierto ☁️

Esta es la tercera y última publicación de blog que relata el progreso del equipo de CLI de Salesforce hacia el código abierto de la interfaz de línea de comandos (CLI) de sfdx . Si no ha leído las publicaciones anteriores, consulte la primera y la segunda para refrescarse y comprender dónde comenzamos, qué tan lejos hemos llegado y hacia dónde vamos. ¡Este ha sido un largo viaje y estamos muy felices de cerrar este capítulo y poner nuestra mirada en el futuro!

CLI + OSS

Nos gustaría celebrar y decir: “¡Lo hemos logrado!” Hemos estado trabajando para desmantelar el complemento salesforce-alm (también conocido como Toolbelt) durante los últimos dos años y estamos a punto de eliminarlo por completo. El complemento salesforce-alm solía contener todos los comandos, ¡aproximadamente 201 en total! Ahora, la CLI sfdx está organizada en complementos que contienen comandos agrupados lógicamente. Por ejemplo, plugin-packaging contiene todos los comandos sfdx force:source:package(1):* . No solo movimos el código de un repositorio a otro y lo llamamos bueno, aprovechamos esta oportunidad para refactorizar todo. Modernizamos nuestro código, movimos la funcionalidad a bibliotecas que se pueden compartir entre equipos de herramientas, agregamos pruebas sólidas y confiables y reescribimos nuestro sistema CI/CD para pruebas y lanzamiento. Este fue un esfuerzo mayor de lo que habíamos supuesto inicialmente.

Para cada complemento nosotros:

1. Se agregaron muchas pruebas unitarias y de integración para garantizar que no romperíamos los flujos de trabajo y la CI existentes.
   1. Aproximadamente 2700 pruebas unitarias que incluyen complementos y bibliotecas
   2. Aproximadamente 850 pruebas de integración para complementos y bibliotecas
2. Se refactorizó una gran cantidad de código y funcionalidad, por lo que estamos orgullosos de ello.
   1. Reducción de una gran cantidad de redundancia y código enrevesado
   2. Como es de código abierto, puedes ver todo lo que escribimos.
3. Se migró a las últimas versiones de nuestras bibliotecas para reducir los errores y descartar las versiones antiguas que ya no admitimos.
   1. Mismas versiones de bibliotecas para admitir sf y sfdx
   2. Una corrección de errores da como resultado dos errores corregidos
4. Para algunos complementos más grandes, los dividimos en un complemento y una biblioteca. Esto nos permitió separar nuestras áreas de interés, crear una funcionalidad coherente en todas nuestras herramientas y permitir que otros desarrolladores de Salesforce utilicen estas bibliotecas. A partir de eso, hemos creado las siguientes bibliotecas.
   1. fuente-implementar-recuperar
   2. Seguimiento de la fuente
   3. embalaje
   4. plantillas-salesforcedx
   5. ventasforcedx-apex
   6. plugins-testkit
   7. fuente-testkit
   8. sfdx-núcleo

¡Ahora, imagina hacer eso para los 20 complementos principales que ahora instalamos cuando instalas el sfdx-cli ! Teníamos mucho trabajo por hacer, ¡pero estamos muy felices de decir que lo hemos hecho! A partir de este mes, ya no incluiremos el complemento salesforce-alm de forma predeterminada, pero siempre puede usar sfdx plugins:install salesforce-alm si realmente necesita un comando que todavía está allí.

Si recuerda las publicaciones de blog anteriores, hay un gif en cada uno que muestra la salida de sfdx plugins --core y lo usamos para mostrar cómo el complemento salesforce-alm se dividía en complementos. Ahora, si ejecuta ese comando, verá todos nuestros complementos como los describimos en la primera publicación del blog.

[contenido incrustado]

Construyendo una CLI confiable

Un tema común que escuchamos de nuestra comunidad a lo largo de los años ha sido "la confiabilidad sobre las funciones", y lo hemos tomado muy en serio. A medida que desglosamos el complemento Toolbelt, aumentamos la confiabilidad, por lo que podemos proporcionarle una herramienta de línea de comandos en la que puede confiar.

Para mejorar la confiabilidad, adoptamos un enfoque cuádruple desde el punto de vista de la ingeniería y la arquitectura.

Complementos, complementos y más complementos

Tomamos el complemento Toolbelt y lo dividimos en complementos individuales. También tenemos otros complementos de Salesforce que no están incluidos directamente con la CLI, pero están disponibles para que los instale y los ejecute si está interesado. No nos detuvimos allí, le hemos dado el poder de crear sus propios comandos a través de complementos.

Mejores bibliotecas

Abstraer la funcionalidad común en las bibliotecas nos ha ayudado mucho con la coherencia, ya que todas nuestras herramientas de desarrollo (incluidas las Extensiones para VSCode, CodeBuilder, DevOps Center, etc.) usan las mismas bibliotecas comunes. Incluso hemos visto a otros desarrolladores de Salesforce usar estas bibliotecas para resolver sus propios casos de uso.

TUERCAS para pruebas

Mejoramos las pruebas al agregar más NUT (pruebas no unitarias) que incluyen todo lo que no es una prueba unitaria, como pruebas E2E, pruebas de humo, pruebas de integración, etc. No solo probamos los complementos, sino también las bibliotecas mismas. Proporcionamos el mismo kit de prueba NUTs (que usamos internamente para escribir nuestras pruebas) para cualquier persona que quiera escribir un complemento y probar sus comandos. ¡Hemos visto que este tipo de pruebas bloquean múltiples errores y regresiones para que nunca se publiquen!

Adiós cinturón de herramientas

A partir de este mes, salesforce-alm (también conocido como Toolbelt) ya no aparecerá en la lista. Queremos tomarnos un minuto para agradecer a todos y cada uno de ustedes que se tomaron el tiempo para probar una beta: comando(s). Hubiera sido imposible entregar una herramienta CLI completamente reescrita sin muchos cambios importantes si no hubiera sido por su ayuda. Todos en el equipo de CLI y el resto de los equipos de herramientas para desarrolladores están humildemente agradecidos con todos ustedes por usar nuestras herramientas y ser parte de la comunidad.

Hablando de la comunidad, comenzamos a tener discusiones de GitHub sobre nuevas funciones, formas de corregir errores o comportamientos antiguos, preguntas o comentarios. Descubrimos que estas son formas muy útiles de recopilar ideas de todos en la comunidad y planeamos continuar usándolas en el futuro. También comenzamos a agregar la etiqueta Help Wanted a los problemas en los que una contribución de código abierto sería una forma sencilla y rápida de solucionar el problema. Por lo general, dejaremos un comentario con material de inicio para orientarlo en la dirección correcta.

Hemos visto un gran éxito de esto, por ejemplo, este problema se marcó como Help Wanted con algunos comentarios sobre dónde podría ocurrir la solución, y luego llegó esta contribución que solucionó el problema. Nos encanta ver estas interacciones y continuaremos construyendo la comunidad a su alrededor. Si desea participar, consulte la pestaña de problemas de nuestro repositorio de GitHub para ver todos los problemas Help Wanted .

¿Qué pasa con el futuro?

Puede leer más sobre las formas en que introduciremos nuevas funciones y estilos en sfdx en una publicación reciente del blog (algunas de estas ya se han introducido en sfdx ). ¡Lo alentamos a que adopte los nuevos estilos, los pruebe y comparta sus comentarios!

Conclusión

Ha sido todo un viaje lograr una CLI de código abierto en la que pueda confiar, ¡y estamos contentos de haberlo logrado finalmente! Hemos aprendido mucho en el camino, y han sido unos años locos desde que comenzamos este gran proyecto. Ya sea que haya estado usando la CLI desde antes de que comenzáramos o se unió a nosotros a la mitad de esta serie, todos en el equipo y en Salesforce están increíblemente agradecidos por usted y siempre asombrados por las formas en que continúa mejorando las herramientas. sfdx ahora es de código abierto y la CLI sf es de código abierto de forma predeterminada. Cerramos este capítulo y abrimos el siguiente capítulo sobre sf : ¡estamos llenos de energía para el próximo año y listos para traerte nuevos y emocionantes comandos!

Sobre los autores

Willie Ruemmele ha sido ingeniero en el equipo de CLI de Salesforce durante más de 3 años y ha supervisado este viaje hacia el código abierto de principio a fin. Está muy emocionado de hacer la transición del enfoque a la CLI sf y crear una gran cantidad de funciones útiles que la comunidad quiere ver. Cuando no está trabajando, le gusta estar activo al aire libre, pasar tiempo con amigos y viajar.

Pooja Reddivari es gerente sénior de gestión de productos en la organización Herramientas y experiencia para desarrolladores de plataformas en Salesforce. Le apasiona crear productos escalables y resistentes que deleiten a desarrolladores y clientes. Pooja ha trabajado en las verticales de empresa, educación y fintech con más de 12 años de experiencia como profesional de ingeniería y gestión de productos. Ella es @poojasalesforc1 en Twitter y en/poojareddivari/ en LinkedIn.