Probar e implementar cambios

• Crear un archivo de manifiesto (package.xml) que enumere los componentes que se deben implementar.
• Explicar los comandos que se utilizan para implementar cambios en su organización.
• Describir cómo acelerar implementaciones mediante la Implementación rápida.

Extraer los cambios del repositorio

Juan sabe que la fuente de información (todos los cambios de este lanzamiento) ahora se encuentran en su repositorio de GitHub.

1. En VS Code, haga clic en el icono de Source Control (Control de fuentes) (1). 
2. Haga clic en el icono More Actions (Más acciones) (2) y, luego, seleccione Pull from (Extraer de) (3).
3. Seleccione origin (origen).
4. El repositorio contiene el objeto personalizado, el campo personalizado y los desencadenadores nuevos. Todos los cambios de Ella y Juan se encuentran aquí.

Autorizar el entorno sandbox de Developer Pro

Si está siguiendo los pasos, regístrese en una organización de Developer Edition o un Trailhead Playground para utilizar en lugar del entorno sandbox de Developer Pro.

1. En VS Code, inicie sesión en el entorno sandbox de Developer Pro. Seleccione SFDX: Autorizar una organización.
2. Seleccione Sandbox para la URL de inicio de sesión (test.salesforce.com).
3. Ingrese un alias para el entorno sandbox, por ejemplo, dev_pro_sandbox.
4. Inicie sesión con el nombre de usuario y la contraseña de su entorno sandbox.

Compilar el artefacto de lanzamiento

La primera tarea de Juan es compilar el artefacto de lanzamiento para poder implementar los cambios en el entorno sandbox de Developer Pro. Juan decide crear un archivo de manifiesto, por lo general llamado package.xml, que enumera los componentes de metadatos que desea implementar.  

1. Desde una ventana de comandos, asegúrese de estar en el directorio del proyecto de Salesforce DX.
2. En la línea de comandos, consulte la ayuda del comando project generate manifest.

   sf project generate manifest --help

   --help le indica a Juan el formato del comando. Juan desea implementar solo los componentes de metadatos nuevos, por lo que determina que necesita el indicador --metadata.
3. Ejecute el comando project generate manifest y especifique los componentes que se deben implementar, como el nuevo objeto personalizado Language Course Instructor (Instructor del curso de idiomas) y los otros cambios en su lista de cambios:

   sf project generate manifest --metadata CustomObject:Language_Course_Instructor__c --metadata CustomField:Language_Course__c.Course_Instructor__c --metadata ApexTrigger:LanguageCourseTrigger --metadata ApexClass:TestLanguageCourseTrigger

   El comando genera el archivo de manifiesto llamado package.xml en el directorio actual.
4. Pruebe el archivo package.xml en el entorno sandbox de Developer Pro para asegurarse de que implemente todos los componentes.
   

   sf project deploy start --manifest package.xml --target-org dev-pro-sandbox

Detengámonos por un momento y analicemos el archivo package.xml.  Abra el que acaba de generar en un editor de texto, si lo desea.  El archivo simplemente enumera los componentes de metadatos que se deben implementar. No contiene el código Apex en sí ni la estructura completa del objeto personalizado.  Cuando realiza una implementación mediante el archivo de manifiesto, el comando de implementación utiliza los archivos de fuentes que encuentra en ese momento en su proyecto local.  Si ejecuta el comando desde una sucursal diferente de VCS o cambia los archivos de fuentes locales por estos componentes, se implementarán estos archivos en su lugar. En resumen, cuando utiliza un archivo de manifiesto, debe tener en cuenta los archivos de fuentes que en verdad implementa.   

También puede utilizar un archivo de manifiesto para eliminar componentes durante una implementación. Utilice el indicador --type del comando project generate manifest para generar un archivo de manifiesto de cambios de eliminación que enumere los componentes que se deben eliminar. Luego, especifique este archivo con una de los indicadores de eliminación de project deploy start|validate, como --post-destructive-changes. 

Si está siguiendo los pasos, su trayectoria termina aquí. Para los siguientes pasos, se requiere la clase de prueba, TestLanguageCourseTrigger, que no se aborda en este módulo.

Probar el artefacto de lanzamiento en el entorno sandbox de prueba (parcial)

Juan utiliza una ventana de comandos o un terminal una vez más para ejecutar un comando de Salesforce CLI con el fin de implementar los cambios en el entorno sandbox. Juan implementa sus cambios mediante el mismo comando que antes: project deploy start.

1. Realice la autorización en el entorno sandbox parcial.
2. Asegúrese de estar en el directorio del proyecto de Salesforce DX.
3. En la línea de comandos, consulte la ayuda del comando de implementación.

   sf project deploy start --help 

   --help le indica a Juan el formato del comando y qué indicadores se deben incluir, en particular --manifest, para implementar mediante el archivo de manifiesto package.xml.
4. Ejecute el comando de implementación que simula lo que implementará en la fase de producción:

   sf project deploy start --manifest package.xml --target-org partial-sandbox --test-level RunSpecifiedTests --tests TestLanguageCourseTrigger

5. Ejecute sus pruebas de interfaz de usuario (IU), como las pruebas de Selenium, de ser necesario.
6. Abra el entorno sandbox:

   sf org open --target-org partial-sandbox

7. Realice pruebas de aceptación de usuarios.

En esta etapa del proceso, a Juan solo le interesan las pruebas relacionadas con la aplicación o los cambios que se implementan. Solo ejecuta las pruebas del código que se encuentra en el artefacto de lanzamiento.

Si las pruebas de Juan dan resultados positivos, avanza a la fase de lanzamiento de prueba, en la que realiza pruebas de regresión en el entorno sandbox por etapas.

Probar el artefacto de lanzamiento en el entorno sandbox por etapas (completo)

Si Juan no realiza cambios en función de las pruebas de integración, el próximo paso será implementar los cambios en un entorno sandbox completo. Juan sigue un proceso similar para implementar los cambios en el entorno sandbox completo. Esta fase incluye una prueba de regresión y simula la forma en que Juan lanzará los cambios en la fase de producción.

Debido a que Juan no encuentra errores durante la fase de prueba, utiliza el mismo archivo package.xml y se asegura de realizar la implementación desde la misma sucursal que utilizó para las pruebas. Si hubiera errores durante la fase de prueba, los solucionaría y volvería a intentarlo.

Primero, ejecuta un análisis de regresión mediante una implementación validada en la organización que ejecuta todas las pruebas. Una implementación validada le permite verificar los resultados de las pruebas que se ejecutarían en una implementación, pero no confirma los cambios. La validación también garantiza que no haya olvidado un componente de metadatos del que dependa otro componente y que no haya metadatos no válidos. Luego de ejecutar todas las pruebas de regresión, ejecuta una implementación rápida para simular con exactitud los pasos que realizará para implementar en la fase de producción. Para hacer todo esto, utiliza Salesforce CLI.

Al validar correctamente los componentes en el entorno por etapas, Juan tiene un período de mantenimiento más corto que bloquea el acceso de los usuarios al sistema cuando se implementan las personalizaciones en producción.

1. Realice la autorización en el entorno sandbox completo.
2. Ejecute todas las pruebas locales (de regresión) para validar la implementación sin guardar los componentes en la organización de destino. 

   sf project deploy validate --manifest package.xml --target-org full-sandbox --test-level RunLocalTests

   Mediante este comando, se muestra el Id. del trabajo que necesitará para hacer referencia en la implementación rápida. Una validación exitosa significa que todas las pruebas de Apex dieron resultados positivos y que las pruebas cubren, por lo menos, el 75% del código que se implementa.
3. A continuación, complete la implementación rápida en el entorno sandbox completo mediante el Id. del trabajo que se obtuvo en el paso anterior. Esta implementación rápida simula lo que sucede luego en la fase de producción. 

   sf project deploy quick --job-id <jobID> --target-org full-sandbox 

Lanzamiento en producción

Juan y su equipo se encuentran en la recta final. Ahora que se aprobaron todas sus pruebas en el entorno sandbox completo, están listos para realizar la implementación en producción. El equipo de Ventas está muy entusiasmado por concretar su visión.

Juan comprueba la lista de ejecuciones de implementación y observa que no tiene tareas previas a la implementación que completar. Ya está preparado. Después de ejecutar la implementación de validación, tiene 10 días para realizar la implementación rápida en producción, siempre que no realice otra implementación ni cambios grandes en la organización. Juan configura la implementación de validación para la organización de producción a fin de garantizar que no ocurran problemas por diferencias con el entorno sandbox por etapas. Juan ejecuta la implementación de validación durante el horario de oficina, de forma que, si ocurre un problema, está disponible para solucionarlo. Cuando la validación finaliza correctamente y para minimizar el impacto en los clientes, realiza la implementación en la fase de producción durante esa misma tarde mediante una implementación rápida.

1. Realice la autorización en la organización de producción.
2. Primero, valide y configure la implementación rápida ejecutando project deploy validate:

   sf project deploy validate --manifest package.xml --target-org production-org --test-level RunLocalTests

   Mediante este comando, se muestra el Id. del trabajo que necesitará para hacer referencia en la implementación rápida.
3. Ejecute la implementación rápida:

   sf project deploy quick --job-id <jobID> --target-org production-org 

4. Abra la organización de producción para asegurarse de que sus cambios se hayan implementado allí.

Realizar las tareas posteriores a la implementación enumeradas en la lista de ejecuciones de implementación

Juan vuelve a observar la lista de ejecuciones de implementación para revisar qué tareas posteriores a la implementación debe realizar en la organización de producción.

Otra implementación exitosa

Calvin realiza una comprobación de estado rápida en la organización de producción. Agrega un instructor a uno de los cursos y valida que el email de notificación llegue a su bandeja de entrada.

Ahora que todos los cambios se reflejan en el sistema de control de fuentes, el equipo puede proporcionar a Calvin una lista definitiva de los cambios para documentar en las notas de la versión.

Calvin le indica al equipo de Ventas que la nueva función de notificación está lista. Felicita a Ella y Juan por la implementación exitosa de una función clave que ayudará al equipo de Ventas de Zephyrus a mantenerse actualizado con la información más reciente sobre los cursos. Está satisfecho con que los cambios ahora se almacenen en un repositorio y ve los beneficios que ofrece el repositorio a medida que el equipo asume más trabajo.