Empiece a realizar un seguimiento de su progreso
Inicio de Trailhead
Inicio de Trailhead

Comprender en qué consiste la gestión del ciclo de vida de aplicaciones

Objetivos de aprendizaje

Después de completar esta unidad, podrá:
  • Identificar las personalizaciones que se pueden realizar con seguridad directamente en la organización de producción.
  • Definir la gestión del ciclo de vida de las aplicaciones.
  • Explicar por qué la utilización del proceso de gestión del ciclo de vida de aplicaciones ayuda a los equipos a desarrollar aplicaciones con mayor rapidez.

Introducción

Salesforce ofrece varias herramientas de desarrollo y procesos que permiten satisfacer las necesidades de los clientes. Este módulo presenta el proceso de gestión del ciclo de vida de las aplicaciones (ALM) y los tres modelos de desarrollo existentes.
  • Desarrollo de conjuntos de cambios
  • Desarrollo de organización
  • Desarrollo de paquetes

En líneas generales, los tres modelos de desarrollo siguen el mismo proceso de ALM. Sin embargo, los modelos se distinguen por la manera en que permiten gestionar los cambios en su organización. El control de cambios es un factor muy importante en el desarrollo de software y puede elegir el modelo de desarrollo que mejor se ajuste a su situación si puede comprender las opciones que tiene disponibles.

A continuación, vamos a acompañar a un profesional de Salesforce y a la compañía en la que trabaja para ver cómo afrontan los cambios de desarrollo que se producen con el tiempo. Durante el recorrido, podrá ver cómo cada modelo de desarrollo puede satisfacer las necesidades de diferentes situaciones. Encontrará detalles sobre cómo utilizar los distintos modelos de desarrollo en otros módulos.

Nota

Nota

En circunstancias similares, usted y su equipo pueden tomar decisiones distintas de las que tomará la compañía ficticia que se analizará en este módulo. Lo más importante es saber cuáles son sus opciones en todo momento.

Presentación de Calvin, el administrador de Salesforce de Zephyrus Relocation Services, Inc.

Calvin Green desempeña numerosas funciones técnicas para Zephyrus Relocation Services, una firma de movilidad de talentos de Fairfax, Virginia (EE.UU.). Una de las funciones de Calvin consiste en personalizar Salesforce para el equipo de ventas de la compañía: un equipo pequeño, pero que está creciendo. Al utilizar la interfaz de configuración en la organización de producción, se toma con una variedad de nuevos tableros y reportes.

Calvin desarrolló sus habilidades como administrador de Salesforce mediante Vetforce, el programa de capacitación de Salesforce y aceleración profesional para militares, veteranos y cónyuges.

Calvin en su escritorio en Zephyrus, con una taza de café de Vetforce.

¿Qué se puede cambiar en producción de forma segura?

En las organizaciones de producción, hay determinados tipos de funciones que pueden desarrollarse de manera segura. Las personalizaciones que no afectan a los datos se pueden crear de forma segura en una organización de producción, como, por ejemplo, el desarrollo de nuevos tableros, reportes y plantillas de email. No obstante, existen determinadas personalizaciones que, de realizarse directamente en organizaciones de producción pueden generar caos al eliminar datos o incluso cosas peores.

¿Qué puede ocurrir si no prueba los cambios antes de ponerlos a disposición de producción?

  • Una regla de flujo de trabajo puede crear un bucle de procesamiento infinito.
  • Un cambio de tipo de campo puede modificar los datos sin que se puedan deshacer estos cambios.
  • Se genera un error de lógica en una regla de validación que no permite guardar el registro.
  • Los cambios de formato de página confunden a los usuarios en lugar de mejorar su experiencia.

La forma más segura de personalizar su organización consiste en realizar y probar los cambios utilizando un entorno exclusivo para el desarrollo. De hecho, algunos cambios se deben realizar en un entorno de desarrollo. Por ejemplo, no puede escribir código Apex directamente en una organización de producción.

Pasar a los conjuntos de cambios para incrementar la seguridad de las personalizaciones

A medida que Zephyrus va creciendo, la demanda de personalizaciones de Salesforce también aumenta. Por ello, la compañía agrega otro miembro a la plantilla para ayudar en las tareas. El creciente volumen de solicitudes de personalización incluye nuevas reglas de flujo de trabajo y nuevos formatos de página y Calvin se niega a hacer estos cambios directamente en la organización de producción.

Con el fin de satisfacer las cambiantes necesidades del negocio, Zephyrus decide actualizar a la versión Professional Edition. Con la versión Professional Edition, Zephyrus puede crear y probar todo lo que necesita utilizando herramientas de desarrollo declarativas (con función de apuntar y hacer clic) en un entorno de desarrollo separado.

En el modelo de desarrollo de conjuntos de cambios, Calvin y su colega Ella pueden gestionar su aplicación mediante herramientas declarativas. De este modo, no necesitan utilizar ninguna interfaz de línea de comandos ni ningún sistema de control de versiones para responder ante las crecientes necesidades de personalización del equipo de ventas al que asisten.

Con las herramientas declarativas, Calvin y Ella pueden crear numerosas funciones inteligentes capaces de incrementar la productividad del equipo de ventas. Por ejemplo, Calvin utiliza el generador de aplicaciones para crear un filtro que muestre un componente de texto enriquecido en una página de oportunidades cuando la cantidad asciende al menos a 1 millón de dólares.

Utilización del Generador de aplicaciones Lightning para crear un filtro.

Aplicar un poco de orden al caos

Ahora que ya es posible crear personalizaciones en distintos entornos y con distintas personas, Calvin se plantea cómo puede gestionar el impacto hasta de los cambios de menor envergadura.

Por ejemplo, el objeto de contacto estándar no incluye ningún campo para especificar el tipo de contacto. Ahora, Calvin puede agregar fácilmente un campo personalizado y lanzar el nuevo campo de tipo de contacto de inmediato a todos los usuarios. Pero... ¿es esto algo que Calvin debe hacer?

  • ¿No entrará el nuevo campo de tipo de contacto en conflicto con las personalizaciones que realizaron otros usuarios?
  • ¿Sabe el equipo de ventas cómo utilizar el nuevo campo o necesita capacitación?
  • Si el campo es obligatorio, ¿hay integraciones o procesos de importación que requieran actualización?
  • ¿Dónde aparecerá el campo? ¿En todos los formatos de página? ¿En qué vistas de lista? ¿Muestra algún reporte o tablero?
  • ¿Debe incluirse el campo también en el objeto Prospecto? De ser así, ¿supone algún cambio para el proceso de conversión de prospectos?
  • ¿Será el campo obligatorio para las integraciones con otros sistemas? De ser así, pueden ser necesarios cambios en el middleware, las asignaciones de campos, los extremos, etc.

en Salesforce Trailblazer Community, otros miembros recomiendan a Calvin consultar los pasos de gestión del ciclo de vida de las aplicaciones que recomienda Salesforce para el desarrollo de nuevas aplicaciones y aplicaciones personalizadas.

En el sitio web para desarrolladores de Salesforce, Calvin averigua que ALM define el proceso de gestión del desarrollo de aplicaciones desde el diseño hasta el lanzamiento final. ALM también establece un marco de trabajo para la aplicación de correcciones de errores en aplicaciones y de futuras mejoras.

Espere... ¿la adición de procesos no ralentizará el desarrollo?

En una reunión con Ernesto Rondán, el director del departamento de TI, Calvin plantea la posibilidad de cambiar a la gestión del ciclo de vida de las aplicaciones. La gestión del ciclo de vida de las aplicaciones (ALM) ofrece procesos y políticas que ayuda a crear aplicaciones sin complicaciones y, por lo tanto, con mayor rapidez y sin contratiempos. Las aplicaciones y las herramientas pueden variar, pero los pasos del ciclo de ALM se pueden aplicar a cualquier proyecto de desarrollo de Salesforce.

El ciclo de ALM: Planificar la versión, desarrollar, probar, crear la versión, probar la versión, publicar la versión

Paso 1: Planificación de la versión
El proyecto de desarrollo o personalización debe comenzar con un plan. Recopile los requisitos y analícelos. Pida a su gestor de productos (o equivalente) que cree las especificaciones del diseño y las comparta con el equipo de desarrollo para su implementación. Determine los entornos de desarrollo y de pruebas que el equipo necesitará a medida que el proyecto vaya progresando durante el ciclo de ALM.
Paso 2: Desarrollo
Realice el trabajo según las especificaciones de diseño. Trabaje en un entorno que incluya una copia de los metadatos de la organización de producción, pero sin datos de producción. Complete el desarrollo en Lightning Platform utilizando una combinación adecuada de herramientas declarativas (Generador de procesos, asistente para objetos personalizados y otras herramientas de la interfaz de usuario) y herramientas programáticas (Developer Console, editor de código fuente o Visual Studio Code).
Paso 3: Prueba
Realice pruebas de los cambios que va a hacer para asegurarse de que funcionan correctamente antes de integrarlos en el trabajo de otras personas. Haga las pruebas en el mismo tipo de entorno que el que utilizó en el paso de desarrollo, pero mantenga el entorno de desarrollo separado del entorno de pruebas integrado. En este punto, céntrese en probar los cambios en sí mismos, no en comprender cómo afectarán a otras partes de la versión o de la aplicación en conjunto.
Paso 4: Compilación de la versión
Agregue todos los recursos que creó o modificó durante la etapa de desarrollo en un único artefacto de la versión: un paquete lógico de personalizaciones para implementar en el entorno de producción. Desde este punto en adelante, céntrese en lo que va a lanzar, no en las aportaciones de cada individuo.
Paso 5: Prueba de la versión
Pruebe lo que va a implementar, pero hágalo de manera segura en un entorno de pruebas tan similar al entorno de producción como sea posible. Utilice una cantidad de datos de producción realista. Conecte los entornos de prueba a todos los sistemas externos necesarios para imitar los puntos de integración de su sistema de producción. Ejecute una regresión completa y realice pruebas de desempeño finales durante este paso. Pruebe la versión con un pequeño conjunto de personas con experiencia para recopilar comentarios (técnica que se conoce como prueba de aceptación de los usuarios).
Paso 6: Lanzamiento de la versión
Tras completar las pruebas y verificar que se cumplen los requisitos de calidad, puede implementar la personalización en el entorno de producción. Capacite a sus empleados y socios para que comprendan los cambios. Si una versión tiene un impacto significativo para los usuarios, cree un entorno separado con datos realistas para la capacitación de los usuarios.