Compila una canalización de DevOps sin servidores para Salesforce con Cloud Build

Last reviewed 2021-02-22 UTC

En este instructivo, se muestra cómo compilar una canalización de integración continua/implementación continua (CI/CD) sin servidores para Salesforce medianteSalesforce Developer Experience (SFDX) y Cloud Build. Las canalizaciones de Cloud Build usan creación de contenedores. Las canalizaciones ejecutan compilaciones como una serie de pasos de compilación, en la que cada paso de compilación se ejecuta en un contenedor de Docker. La canalización puede aumentar o disminuir la escala en respuesta a la carga sin necesidad de aprovisionar servidores con anterioridad, y ofrece compilaciones rápidas, coherentes y automatizadas.

Este instructivo está destinado a cualquier persona responsable de diseñar, desarrollar y mantener flujos de trabajo de DevOps en una organización. Estas funciones pueden incluir arquitectos, ingenieros y equipos de DevOps. Diferentes secciones del documento ilustran partes de la canalización para diferentes funciones. Por ejemplo, una parte es para administradores y líderes de DevOps y otra parte es para los desarrolladores de Salesforce.

En el documento, suponemos que estás familiarizado con Salesforce DX, la CLI de Salesforce, Git, GitHub, Docker, los productos de Google Cloud, como Cloud Build y conceptos de creación de contenedores. También se supone que tienes una cuenta de GitHub.

Los ciclos de vida de desarrollo de software pueden variar mucho. En este instructivo, suponemos que sigues una metodología de actualización ágil.

Objetivos

Configura Salesforce Developer Experience de Salesforce.
Configura una estrategia de ramificación de Git.
Configura Cloud Build.
Ejecuta la canalización de CI/CD para Salesforce mediante las herramientas de compilación de Google Cloud y GitHub.

Costos

En este instructivo, se usan los siguientes componentes facturables de Google Cloud:

Usa la calculadora de precios para generar una estimación de los costos según el uso previsto.

También podrías incurrir en costos de Salesforce. En el instructivo, usas una organización de Salesforce Developer Edition, que puede ser gratuita. Para obtener más información, consulta la página de Salesforce sobre Developer Edition.

Antes de comenzar

En la página del selector de proyectos de la consola de Google Cloud, selecciona o crea un proyecto de Google Cloud.

Nota: Si no planeas conservar los recursos que creaste durante este procedimiento, crea un proyecto en lugar de seleccionar uno existente. Cuando termines, puedes borrar el proyecto y quitar todos los recursos asociados con él.

Ir al selector de proyectos
Asegúrate de que la facturación esté habilitada para tu proyecto de Google Cloud.
Habilita la API de Cloud Build.
Habilita la API
En la consola de Google Cloud, activa Cloud Shell.

Activar Cloud Shell
Asegúrate de tener una cuenta de Salesforce que pueda usar la función de la organización de Dev Hub. Si no tienes una organización, puedes crear una cuenta de Developer Edition en el sitio para desarrolladores de Salesforce.

Cuando finalices este instructivo, puedes borrar los recursos creados para evitar que se te siga facturando. Para obtener más información, consulta Realiza una limpieza

Arquitectura

En el siguiente diagrama, se ilustra la arquitectura del flujo de trabajo de CI/CD que crearás en este instructivo. En esta arquitectura, los proyectos se organizan como versiones. Los desarrolladores que deseen trabajar en una característica crean una nueva rama de características a partir de una rama de la versión.

Arquitectura de la canalización que muestra el flujo de la creación de una rama, la realización de una solicitud de extracción y la combinación del cambio en la rama principal. Varios pasos activan trabajos de Cloud Build.

En el siguiente diagrama, se ilustra el flujo:

Los desarrolladores crean ramas de características en GitHub para las características que están desarrollando.
Los desarrolladores completan el trabajo de desarrollo y ejecutan pruebas de unidades en organizaciones borrador de Salesforce.
Los desarrolladores confirman y envían su trabajo de desarrollo a su repositorio de código fuente (GitHub en este instructivo).
Los desarrolladores crean una solicitud de extracción para fusionar su trabajo en la rama de versión.
La creación de una solicitud de extracción activa de forma automática un trabajo de Cloud Build para ejecutar pruebas.
El personal responsable (generalmente líderes de equipo) revisa y aprueba las solicitudes de extracción para fusionar el trabajo de desarrollo en la rama de versión.
Una combinación en la rama de versión activa de forma automática un trabajo de Cloud Build para implementar la base de código en el control de calidad o en otros entornos de Salesforce.
De manera opcional, las pruebas y revisiones manuales se realizan en un entorno de control de calidad.
El personal responsable crea una solicitud de extracción para combinar el código en la rama main.
La solicitud de extracción a la rama main activa un trabajo de Cloud Build para implementar código en producción.

Los desarrolladores que deseen trabajar en proyectos comienzan por clonar el repositorio del proyecto desde la herramienta de control de fuentes empresariales (GitHub de este instructivo). En el siguiente diagrama, se representa esta estrategia como un grafo.

Estrategia de ramificación ilustrada como un conjunto de versiones, con una rama que se divide en varias ramas de características que luego se fusionan de nuevo en una rama de versión y, a partir de allí, en la rama principal.

Como se ilustra en el diagrama, la estrategia de ramificación consta de los siguientes elementos:

Una rama principal. El código en la rama principal refleja la versión actual del código que se ejecuta en producción.
Una rama de versión. Una rama de versión es una rama de larga duración (en comparación con una rama de características) que coordina todos los cambios y el código que no es pertinente para una versión. Una organización crea una rama de versión nueva para cada versión nueva.
Una o más ramas de funciones. Las ramas de funciones ayudan a aislar el trabajo que está en curso de la versión más actualizada del código de la rama principal. Por lo general, varias ramas de funciones conforman una rama de la actualización. Se recomienda que los desarrolladores creen ramas de funciones para corregir errores.

Después de clonar un repositorio de proyecto, los desarrolladores trabajan en sus máquinas locales o en una organización borrador de Salesforce. Pueden usar una organización borrador para ejecutar pruebas de unidades sobre los cambios que realicen. Si se superan las pruebas de unidades, confirman su código y lo envían al repositorio del código fuente. Luego, generan una solicitud de extracción para que su código se combine en la rama de versión superior.

La solicitud de extracción activa de forma automática un trabajo de Cloud Build que realiza las siguientes acciones:

Crea una organización borrador nueva para ejecutar pruebas de unidades.
Actualiza la solicitud de extracción con el resultado de las pruebas.

En este punto, los líderes de equipo y los propietarios de productos pueden revisar la solicitud de extracción. Si se aprueba la solicitud, los cambios se combinan en la rama de la actualización.

Según el ciclo de vida de desarrollo de software, puedes tener pasos automatizados adicionales que se activan en función de una combinación en la rama de versión. Algunos ejemplos de pasos automatizados son implementar el código validado en una zona de pruebas más alta, como control de calidad o zonas de prueba de integración del sistema.

También puedes configurar Cloud Build para enviar notificaciones de compilación y realizar acciones adicionales con Cloud Functions, Cloud Run o con otras herramientas de Google Cloud. (Estas acciones adicionales no se abordarán en este instructivo). En este enfoque, se proporciona la flexibilidad de personalizar la canalización para que se adapte al framework de DevOps empresarial.

Para simplificar, en este instructivo implementarás la base del código de muestra en una sola organización de Salesforce (Dev Hub). Cuando compilas una canalización de CI/CD para producción, usas la arquitectura ilustrada de forma previa y automatizas las implementaciones en zonas de pruebas que forman parte del ciclo de vida del desarrollo de software.

Personas que por lo general participan en el desarrollo de software

Cada organización es diferente y cada una tiene su propio array de funciones y equipos. En la siguiente tabla, se enumeran las personas clave (funciones) que generalmente interactúan con las canalizaciones de DevOps de Salesforce como la que se describe en este instructivo.

Las personas con diferentes funciones tienen diferentes responsabilidades en la configuración de las canalizaciones de Salesforce. Por lo tanto, el instructivo tiene dos rutas. Una es para los administradores y los clientes potenciales de DevOps, y la otra para desarrolladores.

Persona	Responsibilities
Administrador o líder de DevOps	Configura la organización de Dev Hub. Genera certificados que permiten a los usuarios conectarse a la organización de Dev Hub desde la CLI de Salesforce. Crea apps conectadas en todos los entornos de Salesforce en los que se implementa el código mediante la canalización de DevOps. Configura cuentas de desarrollador en la organización de Dev Hub. Configura la canalización de DevOps y los activadores necesarios. Inicializa el repositorio de código fuente. Configura activadores de Cloud Build.
Desarrollador de Salesforce	Clona el repositorio de código fuente. Configura la CLI de Salesforce para el desarrollo. Desarrolla y prueba características en una versión. Cuando se finalizan las características, se genera una solicitud de extracción para combinar características en la rama de versión.
Responsable de control de calidad	Revisa y aprueba las solicitudes de extracción para combinar el trabajo del desarrollador en una características dentro la rama de versión.
Líder de versión	Administra y aprueba las solicitudes de extracción para combinarlas en la rama principal, que promueve el código a producción.

Configura canalizaciones para administradores de Salesforce y líderes de DevOps

En esta sección, se describen las tareas que los administradores y los equipos de DevOps siguen para configurar el flujo de trabajo de CI/CD.

Habilita la organización de Dev Hub

Accede a tu organización de producción de Salesforce.
En la pestaña Configuración, en el cuadro Búsqueda rápida, ingresa Dev Hub y, luego, selecciona Dev Hub.
Habilita Dev Hub.

Este paso te permite configurar una organización borrador. Debes usar la organización borrador para implementar el código de muestra en el instructivo en una organización de Developer Edition de Salesforce.

Crea un certificado y un par de claves

Después de habilitar la organización de Dev Hub, debes generar un certificado y un par de claves que se puedan usar para autenticarse en la organización de Dev Hub de Salesforce. Usa este certificado y este par de claves cuando configures Cloud Build en pasos posteriores.

Para las canalizaciones de CI/CD de producción, debes generar certificados adicionales a fin de autenticar la zona de pruebas de Salesforce. (No crees estos certificados adicionales como parte de este instructivo). Cuando generes certificados y pares de claves para cada entorno, asegúrate de asignarles nombres identificables, como en los siguientes ejemplos:

Producción (organización de Dev Hub): salesforce.key y salesforce.crt. Usa estos nombres en el procedimiento que aparece a continuación.
Zona de pruebas de control de calidad (QA): salesforce_qa.key y salesforce_qa.crt.
Zona de pruebas de desarrollo integrado (IMS): salesforce_dev.key y salesforce_dev.crt.

Para generar un certificado y un par de claves, sigue estos pasos:

En Cloud Shell, genera un certificado y un par de claves para que Cloud Build pueda autenticarse en tu organización de Dev Hub de Salesforce desde la CLI de Salesforce:
```
openssl req -x509 -sha256 -nodes -days 36500 -newkey \
rsa:2048 -keyout salesforce.key -out \
salesforce.crt
```
Se te pedirá que ingreses los detalles para identificar el certificado. A los fines de este instructivo, estos valores no son importantes, por lo que debes presionar Intro para aceptar los valores predeterminados.

Ten en cuenta que, en el comando, usas los nombres salesforce.key y salesforce.crt, porque creas el certificado y el par de claves para la organización de Dev Hub.
Haz clic en Más y selecciona Descargar archivo.
En el cuadro Ruta de acceso al archivo completamente calificada, ingresa el siguiente nombre de archivo y haz clic en Descargar:
```
salesforce.crt
```
En este paso, se descarga el certificado que generaste en tu máquina local. Debes subir el certificado a tu organización de Salesforce en la siguiente sección.

Crea apps conectadas en Salesforce

En esta sección, crearás una aplicación conectada que Cloud Build puede usar para implementar tu código de Salesforce. Para este instructivo, implementarás código solo en la organización de Dev Hub. En un entorno de producción, implementa el código para cada zona de pruebas y para la organización de producción en la que quieres que Cloud Build implemente tu código de Salesforce para la canalización de DevOps.

Como parte de este proceso, usa el certificado y el par de claves que generaste en la sección anterior. El certificado es la clave pública para autenticar el cliente de Salesforce en una sesión de Cloud Shell de la organización de Dev Hub de Salesforce (zona de pruebas de Salesforce). El certificado también se usa a fin de autenticar Cloud Build para implementaciones automatizadas.

Los detalles de algunos de los pasos del siguiente procedimiento dependen de la edición de Salesforce que uses. Asegúrate de usar el certificado y los pares de claves correctos para el entorno seleccionado.

Si usas Salesforce Lightning Experience, usa el administrador de apps para crear apps conectadas. Sigue estos pasos desde la Configuración de tu organización de Salesforce:
1. En el cuadro Búsqueda rápida, ingresa App.
2. Selecciona Administrador de apps.
3. Haz clic en Nueva app conectada.
Si usas Salesforce Classic, desde la Configuración en tu organización de Salesforce, haz lo siguiente:
1. En el cuadro Búsqueda rápida, ingresa Apps.
2. En Compilar > Crear, selecciona Apps.
3. En Apps conectadas, haz clic en Nuevo.
Para el nombre de tu aplicación, ingresa Google Cloud DevOps.

Esto completa Google_Cloud_DevOps en el cuadro Nombre de la API.
Ingresa la información del correo electrónico de contacto y cualquier otra información que sea apropiada para tu aplicación.
Selecciona Habilitar configuración de OAuth.
Para el valor URL de devolución de llamada, ingresa la siguiente URL:
```
http://localhost:1717/OauthRedirect
```
Para habilitar la opción de usar firmas digitales, haz clic en Elegir archivo y, luego, selecciona el archivo salesforce.crt que descargaste antes.
Agrega los siguientes alcances de OAuth a Permisos de OAuth seleccionados:
- Acceder y administrar datos (API)
- Realizar solicitudes en tu nombre en cualquier momento (refresh_token, offline_access)
- Proporcionar acceso a los datos a través de la Web (web)
Haz clic en Guardar y, luego, haz clic en Continuar.
Anota el valor de la Clave del consumidor que se muestra en la sección de la API. La necesitarás más adelante cuando configures el manifiesto de Cloud Build.

Si trabajas en un entorno de producción, tienes una clave para cada entorno de implementación.
Haz clic en Administrar y, para cambiar las políticas de OAuth, haz clic en Editar políticas.
Configura los Usuarios permitidos como Usuarios autorizados por el administrador con autorización previa y confirma la elección.
Establece la relajación de IP en Restricciones de relajación de IP.
Haz clic en Guardar.
Haz clic en Administrar perfiles y selecciona la opción Administrador del sistema.

Después de este paso, los usuarios que usan este perfil pueden acceder a la CLI de Salesforce.
Haz clic en Guardar.

Inicializa el entorno de Google Cloud

En Cloud Shell, establece el proyecto que creaste o seleccionaste como predeterminado.
```
gcloud config set project PROJECT_ID
```
Reemplaza PROJECT_ID por el ID del proyecto de Google Cloud.
Asigna parámetros de configuración de región y zona:
```
gcloud config set compute/region us-central1
gcloud config set compute/zone us-central1-a
```
En este instructivo, usa us-central1 como la región y us-central1-a como la zona.

Exporta el ID del proyecto de Google actual a una variable de entorno llamada GCP_PROJECT_NUMBER:

export GCP_PROJECT_NUMBER=$(gcloud projects describe $DEVSHELL_PROJECT_ID --format='value(projectNumber)')

Sube claves de Salesforce a Cloud Storage

En Cloud Shell, crea un bucket de Cloud Storage en tu proyecto de compilación para almacenar los archivos de claves privadas de Salesforce:
```
gsutil mb -p ${DEVSHELL_PROJECT_ID} -l us-central1 \
    gs://salesforce-ref-${DEVSHELL_PROJECT_ID}
```
El bucket debe tener un nombre global único. Este comando crea un nombre de bucket que incluye tu ID del proyecto de Google Cloud.
Copia las claves privadas de Salesforce que generaste en la sección Habilita la organización de Dev Hub en el bucket de Cloud Storage nuevo:
```
gsutil cp salesforce.key gs://salesforce-ref-${DEVSHELL_PROJECT_ID}
```

Crea tu repositorio de GitHub

En Cloud Shell, clona el repositorio asociado con este instructivo:

git clone https://github.com/GoogleCloudPlatform/salesforce-serverless-cicd-cloudbuild

Crea un nuevo repositorio de GitHub llamado DEV_REPO_NAME.

Reemplaza DEV_REPO_NAME por el nombre que deseas asignar al repositorio de forma local.

Este es el repositorio en el que los desarrolladores extraen código o envían código. A los fines de este instructivo, crearás este repositorio en tu propia cuenta de GitHub.

Ve al repositorio clonado:

cd salesforce-serverless-cicd-cloudbuild

Agrega tu repositorio de GitHub para desarrolladores como repositorio remoto:
```
git remote add github DEV_REPO_NAME
```

Configura Cloud Build

En esta sección, completarás los pasos de configuración necesarios para activar los trabajos de Cloud Build cuando los desarrolladores generen solicitudes de extracción para fusionar su trabajo en una rama de versión.

Configura los dos activadores para la canalización de CI/CD que crees en este instructivo:

Un activador que ejecuta un trabajo de Cloud Build cuando un desarrollador crea una solicitud de extracción para fusionar el código en la rama de la actualización. Un uso típico de este activador es ejecutar pruebas de unidades.
Un activador que ejecuta un trabajo de Cloud Build cuando se combina una solicitud de extracción en la rama de versión. Un uso típico de este activador es implementar cambios en una zona de pruebas de destino (Dev Hub en este instructivo).

Compila una imagen base que incluya Salesforce DX

Cloud Build ejecuta la compilación como un conjunto de pasos, en el que cada paso se ejecuta en un contenedor de Docker. Debes crear una imagen base de contenedor de Docker que incluya la CLI de Salesforce, y Cloud Build usa los comandos de la CLI de Salesforce para ejecutar el trabajo.

En Cloud Shell, crea un Dockerfile para la imagen que necesitas compilar:

cat <<EOF > Dockerfile
FROM debian:buster
RUN apt-get update && \
apt-get install -y wget xz-utils
RUN wget https://developer.salesforce.com/media/salesforce-cli/sfdx-linux-amd64.tar.xz && \
mkdir sfdx && \
tar xJf sfdx-linux-amd64.tar.xz -C sfdx --strip-components 1 && \
./sfdx/install
ENTRYPOINT [ "sfdx" ]
EOF

Exporta el nombre de la imagen de Docker a una variable de entorno llamada SFDX_BASE_IMAGE:
```
export SFDX_BASE_IMAGE="gcr.io/${DEVSHELL_PROJECT_ID}/salesforcedx-base-image:1"
```
Compila el contenedor con Cloud Build y publica la imagen en Container Registry:
```
gcloud builds submit --tag ${SFDX_BASE_IMAGE}
```

Configura el trabajo de Cloud Build

Para definir un trabajo de Cloud Build, edita un archivo cloudbuild.yaml.

En Cloud Shell, crea un archivo cloudbuild.yaml para definir los pasos del trabajo que se deben ejecutar cuando Cloud Build implemente el código en tu organización de Salesforce Dev Hub:
```
cat <<EOF > cloudbuild.yaml
steps:
- name: gcr.io/cloud-builders/gsutil
  args: ['cp', 'gs://\${_BUCKET_NAME}/salesforce.key', 'salesforce.key']
- name: "${SFDX_BASE_IMAGE}"
  args:
  - force:auth:jwt:grant
  - --setdefaultusername
  - -u
  - \${_SF_USERNAME}
  - -f
  - ./salesforce.key
  - -i
  - \${_CONSUMER_KEY}
- name: "${SFDX_BASE_IMAGE}"
  args: ['force:source:deploy', '-p', './force-app/']
substitutions:
  _BUCKET_NAME: __BUCKET_NAME__
  _SF_USERNAME: __USERNAME__
  _CONSUMER_KEY: __CONSUMER_KEY__
EOF
```
El archivo configura Cloud Build para realizar las siguientes tareas:
1. Descargar el archivo salesforce.key que Cloud Build usa para autenticarse en la organización de Dev Hub.
2. Inicia un contenedor de Docker que tenga instalada la CLI de Salesforce y, luego, conéctate a la organización de Dev Hub mediante un otorgamiento de JWT. Cloud Build usa parámetros de configuración, como la clave de consumidor y el nombre de usuario de Salesforce que se encuentra en la definición del activador de Cloud Build.
3. Implementar el código que envió el desarrollador en la organización de Dev Hub o a otra zona de pruebas de destino en las canalizaciones de CI/CD de producción.
Nota: Para que este instructivo sea breve, en este paso se muestra cómo puedes implementar de forma directa en tu organización de Dev Hub. En las canalizaciones de CI/CD de producción, normalmente se usa un activador para implementar en entornos de prueba, como control de calidad (QA) o pruebas de aceptación de usuario (UAT).
Crea otro archivo llamado cloudbuild_pr.yaml a fin de definir los pasos del trabajo que se deben ejecutar cuando Cloud Build implementa código de una solicitud de extracción en una organización temporal o de zona de pruebas temporal de Salesforce para realizar pruebas:
```
cat <<EOF > cloudbuild_pr.yaml
steps:
- name: gcr.io/cloud-builders/gsutil
  args: ['cp', 'gs://\${_BUCKET_NAME}/salesforce.key', 'salesforce.key']
- name: "${SFDX_BASE_IMAGE}"
  args:
  - force:auth:jwt:grant
  - -u
  - \${_SF_USERNAME}
  - -f
  - ./salesforce.key
  - -i
  - \${_CONSUMER_KEY}
- name: "${SFDX_BASE_IMAGE}"
  args:
  - force:org:create
  - --setdefaultusername
  - --definitionfile
  - config/project-scratch-def.json
  - --targetdevhubusername
  - \${_SF_USERNAME}
  - --setalias
  - testing org
- name: "${SFDX_BASE_IMAGE}"
  args: ['force:source:push']
- name: "${SFDX_BASE_IMAGE}"
  args: ['force:apex:test:run', '--resultformat', 'tap', '--codecoverage']
- name: "${SFDX_BASE_IMAGE}"
  args: ['force:org:delete', '--noprompt']
substitutions:
  _BUCKET_NAME: __BUCKET_NAME__
  _SF_USERNAME: __USERNAME__
  _CONSUMER_KEY: __CONSUMER_KEY__
EOF
```
El archivo configura Cloud Build para realizar las siguientes tareas:
1. Descargar el archivo salesforce.key que Cloud Build usa para autenticarse en la organización de Dev Hub.
2. Inicia un contenedor de Docker que tenga instalada la CLI de Salesforce DX y conéctate a la organización de Dev Hub mediante un otorgamiento de JWT. Cloud Build usa parámetros de configuración, como la clave de consumidor y el nombre de usuario de Salesforce en la definición del activador de Cloud Build.
3. Crear una organización borrador nueva a fin de implementar el código del desarrollador para pruebas automatizadas.
4. Ejecutar textos Apex en la organización borrador.
5. Mostrar el resultado del texto de Apex, que está disponible en el resumen de la solicitud de extracción de GitHub.
6. Borrar la organización borrador temporal.

Envía tu repositorio a GitHub

En Cloud Shell, agrega el archivo cloudbuild yaml nuevo y el Dockerfile al repositorio y envía los archivos a la rama principal del repositorio DEV_REPO_NAME. Cuando se te solicite, accede a GitHub.
```
git add .
git commit -m "Added cloud build configuration"
git push github main
```
Crea una rama de actualización a la que los desarrolladores puedan extraer código o enviársela. Para este instructivo, asigna un nombre a la rama release-sample.
```
git checkout -b release-sample
```
Envía la rama a GitHub:
```
git push github release-sample
```

Conecta tu repositorio de GitHub a Cloud Build

Ve a la página Aplicación de Cloud Build en GitHub Marketplace.
Desplázate hacia abajo y haz clic en Configurar con Google Cloud Build. Si se te solicita, accede a GitHub.
Conecta tu repositorio a Cloud Build:
1. Selecciona Only select repositories.
2. En la lista Seleccionar repositorios, selecciona repositorio.
Haz clic en Install.
Accede a Google Cloud.

Se muestra la página Autorización, en la que se te pide que autorices a la aplicación de Google Cloud Build para que se conecte a Google Cloud.
Haz clic en Autorizar Google Cloud Build a través de GoogleCloudBuild.

Se te redireccionará a la consola de Google Cloud.
Selecciona tu proyecto de Google Cloud.
Si estás de acuerdo, acepta los términos y, luego, haz clic en Siguiente.
En la página Seleccionar un repositorio, selecciona el repositorio de GitHub DEV_REPO_NAME.
Haz clic en Conectar repositorio.
Haz clic en Crear activador de envío.

Actualiza la definición del activador de Cloud Build

Define los detalles del activador nuevo que se creó cuando hiciste clic en Crear activador de envío en la sección anterior.

En la consola de Google Cloud, abre la página Activadores de Cloud Build.

Ir a la página Activadores de Cloud Build
Haz clic en Menú para activar el activador nuevo y, luego, en Editar.
Establece el Nombre en pull-request-to-release-branch.
Cambia la descripción a Run unit tests when a pull request is created from a feature branch.
Cambia el Evento a Solicitud de extracción (solo en la app de GitHub).
En Fuente, en el cuadro de texto Rama base, ingresa la siguiente expresión:
```
^release.*
```
En Configuración, selecciona Archivo de configuración de Cloud Build (yaml o json) y, luego, ingresa cloudbuild_pr.yaml en el cuadro de texto.

En Variables de sustitución, crea tres variables. Para cada variable, haz lo siguiente:

Haz clic en Agregar elemento.

Configura los campos Variable y Valor como se muestra en la siguiente tabla:

Variable	Valor
`_BUCKET_NAME`	El nombre del bucket de Cloud Storage para el archivo de claves de Salesforce en el siguiente formato: `salesforce-ref-PROJECT_ID` Reemplaza `PROJECT_ID` por el ID de tu proyecto de Google Cloud.
`_CONSUMER_KEY`	La clave de consumidor en la aplicación conectada que creaste en la organización de Dev Hub de Salesforce.
`_SF_USERNAME`	Nombre de usuario de Salesforce para la organización Dev Hub

Haz clic en Guardar.

No cierres esta página. Realizarás más trabajos en esta página en el procedimiento siguiente.

Crea un segundo activador de Cloud Build

El siguiente paso es crear otro activador para iniciar trabajos de Cloud Build cuando se realizan confirmaciones a la rama de actualización. Este activador invoca un trabajo de Cloud Build para enviar los cambios a tu organización de Dev Hub. En tu canalización de DevOps, debes asegurarte de que solo el personal y los procesos autorizados puedan confirmar los cambios en la rama de lanzamiento.

En la página Activadores de Cloud Build, haz clic en Crear activador para crear un activador nuevo.
Establece el Nombre en commits-to-release-branch.
En Tipo de activador, selecciona Enviar a una rama.
En la lista Repositorio, selecciona tu repositorio de GitHub de Salesforce.
En el cuadro de texto Rama (regex), ingresa la siguiente expresión:
```
^release.*
```
En Configuración de compilación, selecciona Archivo de configuración de Cloud Build y, luego, ingresa cloudbuild.yaml.

En Variables de sustitución, crea tres variables. Para cada variable, haz lo siguiente:

Haz clic en Agregar elemento.

Configura los campos Variable y Valor como se muestra en la siguiente tabla.

Variable	Valor
`_BUCKET_NAME`	Ingresa el nombre del bucket para el archivo de claves de Salesforce con el siguiente formato: `salesforce-ref-PROJECT_ID` Reemplaza`PROJECT_ID` con el ID de tu proyecto de Google Cloud.
`_CONSUMER_KEY`	La clave de consumidor en la aplicación conectada que creaste en la organización de Dev Hub de Salesforce.
`_SF_USERNAME`	Nombre de usuario de Salesforce para la organización Dev Hub

Haz clic en Guardar.

Agrega permisos para permitir que Cloud Build lea las claves de Salesforce

En Cloud Shell, agrega permisos a tu cuenta de servicio de Cloud Build para permitir que la cuenta lea las claves de Salesforce del bucket de Cloud Storage que creaste:
```
gsutil iam ch serviceAccount:$GCP_PROJECT_NUMBER@cloudbuild.gserviceaccount.com:objectViewer \
    gs://salesforce-ref-${DEVSHELL_PROJECT_ID}
```

Configura canalizaciones para desarrolladores de Salesforce

Las tareas que se describen en esta sección son para los desarrolladores de Salesforce.

Si realizaste los pasos de la parte anterior de este instructivo que están en la sección para administradores y líderes, asegúrate de usar un conjunto diferente de credenciales a fin de ejecutar los pasos en esta sección.

Los pasos de instalación de la CLI de Salesforce DX pueden variar según el SO que uses. En los pasos de esta sección, se describen los pasos para Debian Linux. Si deseas obtener instrucciones para macOS y Windows, consulta la sección para instalar la CLI de Salesforce en la documentación de Salesforce.

Configura la CLI de Salesforce DX

En esta sección, instalarás la CLI de Salesforce y configurarás la autorización correspondiente.

En tu máquina local (no en Cloud Shell), ve al directorio principal:
```
cd $HOME
```

Instala las herramientas xz-utils y wget:

sudo apt-get install --assume-yes xz-utils wget

Instala la CLI de Salesforce:

wget https://developer.salesforce.com/media/salesforce-cli/sfdx-linux-amd64.tar.xz

Crea un directorio de sfdx:
```
mkdir sfdx
```

Extrae el archivo tar descargado:

tar xJf sfdx-linux-amd64.tar.xz -C sfdx --strip-components 1

Instala la CLI:
```
./sfdx/install
```
La CLI de Salesforce está instalada en /usr/local/bin/sfdx.

Verifica que la CLI se haya configurado de forma correcta:

sfdx

El resultado es similar al siguiente:

VERSION
sfdx-cli/7.8.1-8f830784cc linux-x64 node-v10.15.3

USAGE
$ sfdx [COMMAND]

COMMANDS
commands  list all the commands
force     tools for the Salesforce developer
help      display help for sfdx
plugins   add/remove/create CLI plug-ins
update    update the sfdx CLI
which     show which plugin a command is in

TOPICS
Run help for each topic below to view subcommands

commands  list all the commands
force     tools for the Salesforce developer
plugins   add/remove/create CLI plug-ins

Conecta el entorno de desarrollo local a tu organización de Salesforce Dev Hub

Desde tu máquina local, accede a tu organización de Salesforce mediante credenciales para una función de desarrollador:
```
sfdx force:auth:web:login --setalias YOUR_HUB_ORG
```
Reemplaza YOUR_HUB_ORG por un alias adecuado para tu organización de Dev Hub.

Este comando abre un navegador web en tu máquina local, por lo que no puedes ejecutarlo en una VM a la que estés conectado.

Clona el repositorio de GitHub

Clona el repositorio de GitHub que creó el administrador de Salesforce:
```
git clone DEV_REPO_NAME -o github
```
Ve al directorio del repositorio clonado:
```
cd DEV_REPO_NAME
```

Envía la base de código y los metadatos de Salesforce a una organización borrador

En esta sección, debes enviar la base de código y los metadatos a una organización borrador para que se pueda probar la unidad.

En tu máquina local, exporta tu nombre de usuario de Dev Hub a una variable de entorno llamada SALESFORCE_USERNAME:
```
export SALESFORCE_USERNAME=YOUR_DEVHUB_USERNAME
```
Reemplaza YOUR_DEVHUB_USERNAME por el nombre de usuario que configuraste antes.

Crea una organización borrador a fin de probar el repositorio que clonaste para este instructivo.

sfdx force:org:create \
    --setdefaultusername \
    --definitionfile config/project-scratch-def.json \
    --targetdevhubusername ${SALESFORCE_USERNAME} \
    --setalias feature-test-scratch-org

Envía los metadatos y el código a la organización borrador:
```
sfdx force:source:push
```
Genera una URL para la organización borrador y navega hasta ella en una ventana del navegador:
```
sfdx force:org:open
```

Por lo general, el siguiente paso en el ciclo de vida de un proyecto es ejecutar pruebas de unidades y validar las características que desarrollaste. No lo harás en este instructivo porque trabajas con código de muestra validado previamente.

Envia tu código a un repositorio de código fuente

En tu máquina local, crea una rama nueva llamada feature-1:
```
git checkout -b feature-1
```
Envía los cambios a un repositorio de código fuente:
```
git add .
git commit -m "Feature 1 changes"
git push github feature-1
```
En este instructivo, debes usar GitHub como la herramienta de código fuente.

Prueba la implementación

En esta sección, se describen las pruebas que puedes ejecutar para verificar que los activadores que creaste sean funcionales. El repositorio que creó tu administrador de Salesforce contiene una clase de prueba de muestra.

En tu máquina local (no en Cloud Shell), crea una rama de Git nueva:
```
git checkout -b feature-1
```
Mediante un editor de texto, abre el siguiente archivo:
```
./force-app/main/default/classes/SampleTest.cls
```
Para que la prueba falle, en la declaración System.assertEquals, cambia el valor 101 a 102. Después de realizar el cambio, guarda el archivo, pero mantenlo abierto porque lo volverán a cambiar más adelante en este procedimiento.
```
@isTest
public class SampleTest {
static testmethod void testAddOne() {
    Test.startTest();
    System.assertEquals(Sample.addOne(100), 102); // Change to 102 from 101
    Test.stopTest();
  }
}
```

Agrega y confirma el cambio a la rama de funciones:

git add .
git commit -m "Changed test case"
git push github feature-1

Crea una solicitud de extracción para combinar tu código en la rama de versión de muestra.

Se activa un trabajo de Cloud Build nuevo. Sin embargo, el trabajo falla porque falla la prueba de unidades.
Para ver el estado de la compilación, abre la página de Cloud Build.

Ir a la página Cloud Build

Ve a la sección Historial de la página Cloud Build.

Verás el siguiente registro de compilación para el trabajo, que muestra que la aserción de prueba falló.

Step #4: not ok 1 SampleTest.testAddOne
Step #4: # System.AssertException: Assertion Failed: Expected: 101, Actual: 102
Step #4: # Class.SampleTest.testAddOne: line 24, column 1
Step #4: # Run "sfdx force:apex:test:report -i 7076300001gEzne --resultformat <format>" to retrieve test results in a different format.
[. . .]
Finished Step #4
ERROR
ERROR: build step 4 "gcr.io/serverless-devops-sf/salesforcedx-base-image:1" failed: step exited with non-zero status: 100

Para pasar la prueba, en el archivo ./force-app/main/default/classes/SampleTest.cls, cambia el valor 102 de nuevo a 101:

@isTest
public class SampleTest {
static testmethod void testAddOne() {
    Test.startTest();
    System.assertEquals(Sample.addOne(100), 101); //Change back to 101 from 102
    Test.stopTest();
  }
}

Agrega y confirma el cambio a la rama de funciones:
```
git add .
git commit -m "Changed test case to make it pass"
git push github feature-1
```
La operación de confirmación activa un trabajo de Cloud Build.
Cuando se complete el trabajo, revisa la solicitud de extracción en GitHub y combínala en la rama release-sample.

En los flujos de trabajo de producción, la autoridad para fusionar solicitudes de extracción suele estar limitada a los administradores y líderes de DevOps. Para obtener más información sobre cómo configurar esto, consulta Define la combinación de solicitudes de extracción en el sitio de GitHub.
En la consola de Google Cloud, revisa el trabajo de Cloud Build que se activa de forma automática cuando combinas la solicitud de extracción en la rama de versión de muestra.
Cuando se complete el trabajo, accede a la organización de Dev Hub. Puedes acceder como desarrollador o como administrador.

Las modificaciones del código del desarrollador están disponibles en esta organización de Salesforce. Para verlos, ve a la página Configuración y consulta las Custom Code/Apex classes.

Limpia

Para evitar que se apliquen cargos a tu cuenta de Google Cloud por los recursos usados en este instructivo, borra el proyecto que contiene los recursos o conserva el proyecto y borra los recursos individuales.

Borra el proyecto

Precaución: Borrar un proyecto tiene estas consecuencias:

Se borra todo en el proyecto. Si usaste un proyecto existente para las tareas de este documento, cuando lo borres, también se borrará cualquier otro trabajo que hayas realizado en el proyecto.
Se pierden los ID personalizados de proyectos. Cuando creaste este proyecto, es posible que hayas creado un ID del proyecto personalizado que desees utilizar en el futuro. Para conservar las URL que utilizan el ID del proyecto, como una URL appspot.com, borra los recursos seleccionados dentro del proyecto en lugar de borrar todo el proyecto.

Si planeas explorar varias infraestructuras, instructivos y guías de inicio rápido la reutilización de proyectos puede ayudarte a evitar exceder los límites de las cuotas del proyecto.

En la consola de Google Cloud, ve a la página Administrar recursos.
Ir a Administrar recursos
En la lista de proyectos, elige el proyecto que quieres borrar y haz clic en Borrar.
En el diálogo, escribe el ID del proyecto y, luego, haz clic en Cerrar para borrar el proyecto.

Borra recursos de Salesforce

También puedes borrar la organización de Salesforce Developer Edition y la organización borrador asociada que creaste para este instructivo.

Desactiva tu organización de Developer Edition

Ve a la organización de Salesforce Dev Hub.
En la configuración, en el cuadro Búsqueda rápida, ingresa Company y, luego, selecciona Información de la empresa.
Haz clic en Información de la empresa.
Haz clic en el botón Desactivar organización.

Borra la organización borrador

En Cloud Shell, ejecuta el siguiente comando para borrar la organización borrador de Salesforce:
```
sfdx force:org:delete -u feature-test-scratch-org
```

Borra el repositorio de GitHub

Ve a GitHub y borra el repositorio que creaste en tu cuenta personal para este instructivo.

¿Qué sigue?

Para obtener más información sobre las arquitecturas de referencia, los diagramas y las prácticas recomendadas, explora Cloud Architecture Center.