Aprenda MOAR en Winter '23 con DevOps Center ☁️

Siga y complete un trailmix de Learn MOAR Winter '23 para administradores o desarrolladores antes del 30 de noviembre de 2022 a las 11:59 p. Se aplican restricciones. Aprenda cómo participar y revise las reglas oficiales visitando la página de Trailhead Quests .

DevOps Center es nuestro nuevo producto que mejora enormemente el proceso de gestión de cambios y versiones cuando se desarrolla con Salesforce. Permite que equipos completos aprovechen las mejores prácticas modernas de DevOps, ya sea que elijan usar la nueva interfaz de usuario basada en clics del DevOps Center o las herramientas modernas existentes como Salesforce CLI o IDE.

Por qué DevOps Center es ideal para equipos

DevOps Center se basa en la misma base que nuestra SFDX CLI. Esto significa que DevOps Center utiliza el mismo proyecto, comandos y principios generales de SFDX que se han introducido a lo largo de los años con Salesforce DX. Más importante aún, esto también significa que DevOps Center es compatible con las metodologías que se utilizan con Salesforce DX. Esta es una mejora significativa con respecto a los conjuntos de cambios, que son básicamente incompatibles con la CLI de SFDX y el desarrollo basado en código fuente en general.

Ahora, equipos completos pueden aprovechar las capacidades modernas, como el desarrollo basado en código fuente, el uso de control de código fuente y la automatización, pero utilizando las herramientas que prefieran. Pueden usar interfaces de línea de comandos como la CLI, IDE como VS Code o Code Builder y GitHub, O una interfaz de usuario declarativa/basada en clics. Llamamos a este tipo de equipos "equipos híbridos" y, como hemos estado desarrollando DevOps Center, uno de nuestros objetivos ha sido brindarles una experiencia sólida.

¿Quién está en el equipo?

Al diseñar DevOps Center, nos hemos centrado en algunas personas de usuarios clave para quienes estamos trabajando para ofrecer una sólida experiencia de administración de cambios y versiones de extremo a extremo:

• DeeDee : una desarrolladora declarativa, o administradora, que utiliza principalmente herramientas de código bajo y basadas en clics para realizar su desarrollo.
• Pedro: un desarrollador programático que utiliza metodologías más pro-código, incluidos Salesforce CLI y Source Control
• Romeo: un administrador de versiones, que puede estar utilizando interfaces basadas en clics o interfaces de línea de comandos para realizar implementaciones.

Ejemplos de casos de uso de equipos híbridos

Veamos algunos casos de uso comunes que resaltan cómo estos equipos híbridos pueden unirse mediante el uso de DevOps Center.

Caso de uso n.° 1: DeeDee contribuye con sus cambios a un repositorio de proyecto compartido mediante una interfaz declarativa/basada en IU

Esta es una de las luchas de equipo más comunes de las que escuchamos hoy.

La situación actual:
Una parte del equipo ha adoptado prácticas de desarrollo basadas en fuentes y está utilizando un repositorio de control de fuentes para administrar su fuente de metadatos. Los desarrolladores declarativos del equipo usan conjuntos de cambios para administrar sus cambios. Todos estos cambios, ya sea mediante control de código fuente o conjuntos de cambios, terminan en las mismas organizaciones de prueba y producción.

Desafíos con la situación actual:
Los metadatos administrados por el conjunto de cambios nunca ingresan al repositorio de control de código fuente, ya que el proceso declarativo de los desarrolladores no proporciona una interfaz que les facilite introducir sus cambios en el repositorio. Por lo tanto…

• El repositorio en realidad no refleja todos los cambios para todo el equipo.
• Los conflictos son difíciles de manejar
• Es difícil entender lo que está pasando en el lanzamiento.

Centro DevOps al rescate:
Con DevOps Center, DeeDee puede confirmar sus cambios en el mismo repositorio de control de código fuente que usa el equipo con simples clics. Incluso puede crear una solicitud de incorporación de cambios en GitHub con solo hacer clic en un botón en DevOps Center, indicando a otros en el equipo que su cambio está confirmado y listo para revisión. Cuando Pedro u otra persona de su equipo revisa y aprueba el cambio, se puede marcar como "Listo para promocionar" en DevOps Center, lo que lo hace disponible para su promoción (implementación) por parte de Romeo (o DeeDee, según el proceso de gobierno del equipo) para las organizaciones de prueba compartidas en la canalización.

Beneficios realizados:
DeeDee ahora puede trabajar dentro de DevOps Center mediante clics y sus cambios se administran en el repositorio de control de código fuente centralizado del equipo. Por lo tanto…

• El repositorio incluye el trabajo de todo el equipo.
• Los conflictos se pueden identificar antes
• Hay una mayor visibilidad de los cambios que se realizan en el lanzamiento.
• El equipo logra una mejor gobernanza y gestión del cambio.

Caso de uso n.º 2: Pedro y DeeDee contribuyen al mismo proyecto, pero Pedro quiere usar la CLI y el IDE, y DeeDee quiere usar una interfaz declarativa basada en clics. Y quieren visibilidad de los cambios de los demás.

Esto es similar al caso de uso n.º 1 desde la perspectiva de DeeDee, pero este caso de uso agrega el escenario en el que Pedro está haciendo su propio desarrollo a través de sus metodologías existentes basadas en CLI e IDE. Con DevOps Center, todos pueden tener visibilidad de lo que está sucediendo con el proyecto y los cambios que se están realizando.

Cómo el modelo de proyecto de DevOps Center facilita la colaboración

El proyecto DevOps Center está asociado con un repositorio en GitHub. Este es el mismo repositorio de proyectos que usa todo el equipo para administrar la fuente de metadatos. El proyecto DevOps Center también contiene una canalización que define las etapas por las que pasan los cambios desde el desarrollo, las pruebas y la producción. Cada una de estas etapas está asociada con una organización de Salesforce, así como con una rama en el repositorio de control de código fuente. DevOps Center también utiliza "elementos de trabajo" como objeto principal para definir los cambios que se realizarán y realizar un seguimiento a lo largo del ciclo de vida. Cada elemento de trabajo tiene una rama de función asociada en el repositorio. Esta rama de funciones la crea automáticamente DevOps Center cuando se inicia el elemento de trabajo y el nombre de la rama coincide con el ID del elemento de trabajo (p. ej., WI-00001).

Por lo tanto, la clave para hacer que este caso de uso funcione es asegurarse de que las ramas con las que trabaja Pedro en el sistema de control de código fuente estén alineadas con las ramas con las que está configurado el proyecto DevOps Center (o viceversa). Los cambios que se realicen en el repositorio de control de código fuente en cualquiera de las ramas que conoce DevOps Center se reflejarán en DevOps Center.

Veamos un flujo de trabajo típico para ver cómo funciona.

1. Empezar a trabajar

Pedro recoge su elemento de trabajo en DevOps Center. Selecciona la opción para "… desarrollar y confirmar mis cambios en la rama de características del elemento de trabajo desde fuera del DevOps Center". Esto pone el elemento de trabajo en el estado "En progreso" Y crea una rama de funciones en el repositorio con un nombre que coincide con el elemento de trabajo. Como alternativa, Pedro podría simplemente crear la rama en el repositorio, pero debe tener el mismo nombre que el elemento de trabajo para que la sincronización funcione correctamente.

2. Realice cambios en IDE y confirme cambios en la rama de características en el repositorio

Ahora Pedro puede hacer sus cambios como quiera. Por ejemplo, podría usar VS Code con extensiones de Salesforce, o el nuevo Code Builder, un IDE basado en web que proporciona las mismas capacidades que VS Code, pero en una interfaz basada en web fácil de configurar. Desprotege la rama de funciones del elemento de trabajo, realiza sus cambios y luego confirma esos cambios en la rama de funciones del elemento de trabajo.

Ahora, si alguien mirara este elemento de trabajo en DevOps Center, vería la confirmación que acaba de hacer Pedro. También mostrará los archivos que formaron parte de la confirmación. ¡Resbaloso!

3. Crear solicitud de extracción

Ahora, cuando Pedro esté listo para crear una solicitud de extracción para iniciar una revisión y fusionar sus cambios en la rama de la siguiente etapa, puede hacerlo directamente desde GitHub, el IDE o la CLI, según lo desee. La solicitud de extracción debe crearse entre la rama de función del elemento de trabajo en la que ha estado confirmando sus cambios y la rama que corresponde a la primera etapa de la canalización. En nuestro ejemplo a continuación, esta es la rama de integración.

Después de que Pedro crea esta solicitud de extracción, sus compañeros de equipo pueden ver en DevOps Center que el elemento de trabajo está "En revisión" y tienen fácil acceso a la solicitud de extracción directamente desde el elemento de trabajo. ¿Qué tal eso para facilitar la colaboración en equipo?

4. Combinar la solicitud de extracción

Una vez que se revisa y aprueba la solicitud de incorporación de cambios, alguien del equipo puede optar por fusionarla directamente desde GitHub.

Ahora, en DevOps Center, el equipo puede ver que los cambios se fusionaron "externamente" o desde fuera de DevOps Center. Y dado que el paso Promoción en DevOps Center realiza tanto la fusión como la implementación, debido a que el elemento de trabajo ahora se ha fusionado, le dice al usuario que los cambios ahora deben implementarse para mantener la rama de integración y la organización sincronizadas entre sí.

5. Completar la promoción del elemento de trabajo

En la versión beta abierta actualmente disponible de DevOps Center, la implementación debe completarse desde DevOps Center. En el marco de tiempo de GA, entregaremos un complemento de CLI que permite que la implementación se realice a través de la CLI y, por lo tanto, desde fuera de DevOps Center, según se desee. Esto permitirá que todo el flujo se realice dentro de DevOps Center, fuera de DevOps Center o mediante una combinación de ambos.

¡Obtenga DevOps Center ahora!

DevOps Center está actualmente disponible en versión beta abierta y se puede habilitar e instalar en cualquier organización de producción con una edición Professional, Enterprise o Unlimited. También está disponible en las organizaciones de zona de juegos de Trailhead y Developer Edition. Para obtener información sobre cómo habilitar, instalar, configurar y usar DevOps Center, consulte:

Para obtener más información, demostraciones en video y para ser parte de la conversación, visite nuestro grupo comunitario Trailblazer de DevOps Center .

¡Vea estas nuevas funciones en acción!

No se olvide de ver la vista previa para desarrolladores de Winter '23 el 22 de septiembre durante Release Readiness Live para ver demostraciones de un subconjunto de estas nuevas y emocionantes funciones. Y si asistes a Dreamforce, ¡ únete a nosotros EN VIVO ! ¡Asegúrese de consultar Learn MOAR Winter '23 for Developers Trailmix y siga el blog esta semana para obtener más información sobre Learn MOAR!

Sobre el Autor

Karen Fidelak es directora sénior de gestión de productos para DevOps Center en Salesforce. Cuando no está trabajando para llevar excelentes productos a la comunidad de desarrolladores de Salesforce, disfruta explorando el aire libre en su hermoso estado natal de Colorado.