About this video

• Video Title: Procedimiento básico pipeline COPADO
• Channel: antonio saenz
• Speakers: antonio saenz
• Duration: 01:00:04

Overview

This video provides a comprehensive walkthrough of the basic pipeline process using Copado, a DevOps and continuous integration tool for Salesforce. The presenter explains the tool's licensing, integration with Salesforce, version control using Git, and the typical deployment cycle within an organization like Kaisa Bank. It details how to create and manage user stories, handle metadata, perform validations, and manage promotions across different environments. The video also covers logging into Copado, navigating its interface, and best practices for using user stories and promotions effectively.

Key takeaways

• Copado as a Salesforce DevOps Tool: Copado is presented as Salesforce's own solution for continuous integration and automated deployments, though it requires separate licensing and can have challenges with conflict resolution.
• Version Control Integration: Copado integrates with Git for version control, allowing tracking of metadata changes and commits.
• Environment and Deployment Flow: The video outlines a typical deployment flow involving multiple environments (Dev, STG-INT, STR, PROD) and emphasizes continuous integration from Dev to STG-INT.
• User Stories (US) and Promotions: The core workflow in Copado revolves around User Stories, which group metadata changes, and Promotions, which are collections of User Stories used for deployment packages.
• Login and Interface Navigation: Access to Copado is through Salesforce production via Citrix. The primary interfaces to focus on are User Stories and Promotions.
• Metadata Management: User Stories contain lists of metadata (Apex classes, components, Data Cloud elements, etc.) and can also include manual tasks for the technical office.
• Deployment Steps: The process includes committing changes, associating Apex test classes, running quality scans, and performing deployments with a "validation only" option for STR.
• Manual Tasks and Promotions: Manual tasks can be defined within User Stories, and Promotions are created to bundle these User Stories for deployment, with a specific order sometimes required.
• Environment-Specific Deployments: The importance of specifying the correct deployment environment and using "validation only" for STR is highlighted.
• Conflict Resolution: While Copado aims to automate deployments, Git conflicts can arise and may require intervention from the technical office.

In Copado, a User Story (US) is the fundamental unit of work. It represents a specific requirement, bug fix, or piece of functionality and contains a list of the metadata components (like Apex classes, Lightning components, or Data Cloud elements) that need to be developed or modified for that specific item. User Stories can also include manual tasks for the technical office.

A Promotion, on the other hand, is a grouping of multiple User Stories. Promotions act as deployment packages, bundling together several User Stories that are intended to be deployed together. This allows for logical sequencing of deployments, such as deploying core components before dependent ones. You create a Promotion and then add the relevant User Stories to it before initiating a deployment.

Claro, aquí tienes un resumen de los pasos del procedimiento en Copado, explicado en castellano:

1. Crear una User Story (US):

   • Se inicia creando un registro de US en Copado.
   • Se define el tipo (User Story, Bugfix), un título claro (incluyendo prefijos de proyecto si aplica, como "COE", "MC", "CON"), y se asocia a una Release (IOP/Sprint).
   • Es importante verificar y usar la convención de nomenclatura correcta para el Proyecto (por ejemplo, "COE", "Mis Clientes", o "Cosmo/Conecta" según la información proporcionada).
   • Se configura la Credencial de Origen (el entorno de desarrollo desde donde se despliega) y el Entorno de Origen. Hay que confirmar los nombres exactos de estas credenciales/entornos con el equipo técnico.
   • Para tareas manuales, se usa la sección Deployment Tasks dentro de la US, especificando si es pre o post-despliegue y el entorno de destino.

2. Confirmar Metadatos y Clases de Test:

   • Una vez creada la US, se va a la sección Commit Changes.
   • Se seleccionan los metadatos exactos que componen la US.
   • Se utiliza la opción "Retrieve Only" para incluir metadatos que son dependencias necesarias para que otros componentes de la US funcionen, pero que no han sido modificados directamente.
   • Si se trabaja con clases de Apex, es crucial asociar las clases de test correspondientes en la sección Add Apex Test(s) para asegurar que las validaciones pasen. Si la clase de test también se ha modificado, debe incluirse en el "Commit Changes".

3. Marcar la US como "Ready to Promote":

   • Antes de poder añadir una US a una promoción, se debe marcar la casilla "Ready to Promote" en el registro de la User Story. Esto indica que está lista para ser incluida en un paquete de despliegue.

4. Crear una Promoción:

   • Se navega a la sección Promotions y se crea una nueva.
   • Se asocia la Promoción a la Release (IOP/Sprint) correcta y al Proyecto.
   • Se especifica el entorno de origen y destino (por ejemplo, de STG-INT a STR).
   • Una vez creada la Promoción, se añaden las User Stories que han sido marcadas como "Ready to Promote" y que pertenecen a esa promoción.

5. Validar Cambios en el Entorno de Pruebas (STR):

   • Para las Promociones destinadas a STR (entorno de pre-producción/UAT), se debe realizar un despliegue en modo "Validation Only".
   • Esto se hace creando un Deploy asociado a la Promoción y marcando explícitamente la opción "Only Validation".
   • Es importante ejecutar también el "Run Specified Tests" si hay clases de Apex involucradas.
   • Este paso verifica que el paquete de metadatos sea compatible y no cause errores al intentar desplegarlo en STR.

6. Notificar a la Oficina Técnica:

   • Una vez que los cambios han sido validados satisfactoriamente en STR (o antes de la promoción a PROD), se debe informar formalmente a la oficina técnica.
   • Esta notificación incluye detalles sobre las US y las Promociones que se desean desplegar en la próxima IOP. Esto asegura la trazabilidad y planificación para el despliegue final a producción.

7. Despliegue a Producción (Gestión de la Oficina Técnica):

   • El despliegue final a producción (de STR a PROD) es gestionado por la oficina técnica. Ellos se encargan de ejecutar las Promociones aprobadas.
   • En caso de conflictos de Git durante el proceso, la oficina técnica suele intervenir para resolverlos.

8. Ciclo de Integración Continua (Dev a STG-INT):

   • Desde el entorno de desarrollo (Dev), los cambios se despliegan continuamente a STG-INT tan pronto como estén listos y validados con pruebas unitarias. Esto se realiza a menudo usando la opción "Promote and Deploy" directamente desde la US.

En resumen, el flujo implica desarrollar en US, confirmar los metadatos y tests, preparar las US para ser promocionadas, agruparlas en Promociones, validarlas rigurosamente en entornos de prueba (STR) y, finalmente, coordinar con la oficina técnica para el despliegue a producción.