Si algo hemos aprendido desde que lanzamos Blue Canvas y hablamos con miles de equipos de Salesforce, es que adoptar DevOps para Salesforce es un proceso. No existe un interruptor mágico que puedas activar.

Además, DevOps para Salesforce significa cosas distintas para cada persona.

Dado que hemos trabajado con cientos de equipos de Salesforce a lo largo de los años, pensamos que sería interesante compartir lo que hemos aprendido. Los equipos quizá quieran entender en qué punto de su recorrido de DevOps se encuentran y cuáles son los siguientes pasos lógicos.

Por eso creamos El Evaluación de Salesforce DevOps. Puedes completarla aquí.

La evaluación de DevOps para Salesforce

Con los años, hemos observado que los equipos de Salesforce se dividen, en líneas generales, en cuatro categorías principales. Hay diferencias dentro de cada una, pero también características comunes importantes y reconocibles. Para avanzar de un nivel al siguiente, es necesario comprender e implementar conceptos similares en una secuencia bastante lógica.

Creamos la evaluación de DevOps más como una herramienta educativa que como una forma de clasificar equipos. Su objetivo es ayudar a los equipos a comprender el recorrido de DevOps para Salesforce y cómo dar el siguiente paso.

En la evaluación identificamos cinco categorías principales en las que evaluamos a los equipos:

1. Estrategia de sandbox
2. El control de versiones
3. Despliegue
4. Calidad y pruebas
5. Gestión de lanzamientos

Por supuesto, existen otras clasificaciones, pero estas son las que nos resultaron más coherentes.

Estrategia de sandbox

Una estrategia sólida de sandbox es la base de cualquier implementación de DevOps en Salesforce. Te guste o no (y recibimos algunas críticas en HackerNews por esto) Salesforce es una plataforma de desarrollo. La gran ventaja de Salesforce es que ofrece entornos de sandbox que se encargan de algunos aspectos repetitivos del desarrollo de aplicaciones, como la seguridad, la autenticación, el escalado, la administración de bases de datos y las migraciones de esquemas, la ejecución de código, el alojamiento en la nube, etc.

Te sorprendería saber cuántos equipos aún hacen cambios en producción o tienen un solo sandbox que usan antes de pasar a producción.

Más arriba en la escala, hay equipos que usan varias etapas, como desarrollo, integración, pruebas de aceptación del usuario, preproducción y capacitación, antes de que los cambios lleguen a su entorno de producción.

Y en el extremo más avanzado están los equipos con estrategias de sandbox muy complejas y sofisticadas, con calendarios de actualización, organizaciones temporales como ramas de funcionalidades y otros flujos más complejos.

Control de versiones

Aunque este movimiento ha crecido en los últimos 5 años, muchos equipos aún no cuentan con un verdadero control de versiones para sus entornos de Salesforce. Si lo tienen, puede ser muy limitado, como ejecutar un script de Ant cada noche para hacer una «copia de seguridad» de los metadatos. A menudo, los equipos tienen Apex en un repositorio de Git, pero no cuentan con una buena manera de ayudar a los administradores a registrar metadatos de configuración, como flujos de trabajo, generadores de procesos o XML de objetos personalizados, en el control de versiones.

El control de versiones es importante porque permite revertir cambios problemáticos, restaurar desde copias de seguridad, evitar que se sobrescriba código y auditar los cambios en el sistema.

‍

Con la llegada de Salesforce DX, desarrollo basado en el código fuente se ha convertido en un tema central entre los desarrolladores de Salesforce. Contar con un flujo de desarrollo basado en código fuente es la base de cualquier estrategia de DevOps. Es casi como el aire que respiramos o el agua en la que nada un pez. Un equipo de DevOps que trabaje, por ejemplo, en Java o .Net probablemente ni siquiera podría imaginar una plataforma de desarrollo sin control de versiones y hasta daría por sentado que forma parte del flujo de DevOps.

No es que los equipos tengan malas intenciones: Salesforce dificulta bastante la incorporación de metadatos al control de versiones. Por suerte, existen nuevas formas de incorporar tus metadatos declarativos y Apex al control de versiones.

Despliegue

Históricamente, Salesforce ofrece dos formas de desplegar cambios entre entornos: los conjuntos de cambios y la herramienta de migración de Force.com (también conocida como scripts de Ant). Ninguna de las dos opciones goza de gran popularidad.

Después de ser señalada dos veces como la plataforma de desarrollo «más temida»Salesforce respondió con una nueva forma de desplegar basada en tecnologías modernas: Salesforce DX. Su objetivo era ofrecer a los equipos de Salesforce otro conjunto de herramientas para crear flujos de DevOps. Es una herramienta bastante avanzada y la utilizan principalmente proyectos que empiezan desde cero y la verdadera élite de los equipos de desarrollo de Salesforce.

A medida que los equipos de Salesforce empiezan a trabajar y organizarse más como los equipos de desarrollo de software de otras plataformas, más equipos experimentan con servidores de integración continua como Jenkins, Travis y Bitbucket Pipelines. Una de sus grandes ventajas es que estas herramientas son muy personalizables. Puedes usarlas para activar acciones antes y después del despliegue, como iniciar una validación de Salesforce y ejecutar pruebas unitarias de Apex antes de una revisión de código. Los equipos más avanzados pueden ejecutar pruebas funcionales automatizadas adicionales y análisis estáticos de código.

Calidad y pruebas

Incluir controles de calidad y pruebas funcionales automatizadas en tu flujo de despliegue de Salesforce dice mucho sobre tu nivel de avance en DevOps. Aunque no todos los equipos los incluyen en cada entrega, cada vez más adoptan estas prácticas, y la tecnología facilita su implementación.

Análisis estático de código.

El análisis estático de código puede darte un informe sobre el estado de tu código de Salesforce. Hay herramientas de código abierto como SonarApex que puede asignar una puntuación al estado de tu código Apex según los errores, las vulnerabilidades de seguridad y los indicios de problemas en el código.

El análisis estático de código es un excelente primer paso hacia las revisiones de código, porque te da una base para debatir y se puede automatizar, lo que elimina el factor humano que impide que muchos equipos actúen.

El análisis estático de código también ayuda a fomentar y mantener la calidad de una aplicación de Salesforce que lleva mucho tiempo en uso. La mayoría de las aplicaciones de Salesforce ya son sistemas heredados o llegarán a serlo, y se espera que funcionen durante años. Dada la presencia habitual de consultores y la competencia por el talento de desarrollo de Salesforce, quienes trabajen en tu código dentro de 12 a 24 meses podrían no ser quienes lo escribieron inicialmente. El análisis estático de código puede ayudarte a evitar que acumules grandes cantidades de deuda técnica y puedas seguir ampliando tu implementación de Salesforce durante los próximos años.

Los equipos avanzados incluso configuran controles de calidad para impedir despliegues que no cumplan con ciertos estándares.

Pruebas funcionales automatizadas.

Las pruebas funcionales automatizadas son una parte importante de la mayoría de los procesos de despliegue ágiles. Aceleran tu ciclo de QA y reducen la probabilidad de errores manuales. Selenium se ha consolidado como la herramienta líder para automatizar pruebas de aplicaciones web, y los equipos de Salesforce la usan cada vez más para probar componentes de Lightning y otros elementos de la interfaz.

Con los servidores modernos de CI/CD, ahora es más fácil configurar pruebas funcionales automatizadas para que se ejecuten según un calendario o en puntos específicos de tu flujo de entrega.

Gestión de lanzamientos

¿Usas hojas de cálculo para llevar un registro de tus cambios en Salesforce? ¿Documentos de Word? Muchos equipos lo hacen. Los equipos están empezando a invertir en herramientas de ALM (gestión del ciclo de vida de las aplicaciones) como JIRA para dar seguimiento al trabajo. Contar con una solución de ALM adecuada te permite saber quién está haciendo qué y cuándo estará terminado.

¿Con qué frecuencia despliegas? La integración continua abre la posibilidad de implementar la entrega continua, que te permitiría ofrecer nuevas funcionalidades a tus usuarios en cuanto estén listas. Esto es especialmente útil para corregir errores. Contar con un flujo que permita llevar un cambio a producción de inmediato, sin interrumpir otros trabajos, es una gran ventaja para la mayoría de los equipos de Salesforce.

¿Haces revisiones de código? Al igual que el análisis estático de código, las revisiones son especialmente importantes en el ecosistema de Salesforce porque a menudo tienes:

1. Distintos niveles de experiencia
2. Sistemas heredados que funcionan indefinidamente
   

Por supuesto, las revisiones de código ayudan a detectar errores y fallos, pero lo más importante es que te permiten mantener un nivel uniforme de calidad y coherencia en toda tu aplicación. También facilitan el intercambio de conocimientos dentro del equipo.

Resultados de la evaluación de DevOps

Ya completaste la evaluación. Aquí puedes ver dónde estás y cuáles pueden ser tus próximos pasos.

70-100: La élite de DevOps

Acerca de ti:  

Tienes una estrategia de sandboxes bien definida. Cada desarrollador y administrador tiene su propio sandbox y registra cambios regularmente en los entornos posteriores de integración, preproducción y pruebas de aceptación del usuario (UAT). Probablemente no usas organizaciones temporales, pero las evaluaste y decidiste que era mejor esperar a que Sandboxes de Lightning Developer Pro estuvieran disponibles de forma general.

El control de versiones te resulta muy sencillo. Todos tus desarrolladores y administradores registran cambios con frecuencia en el sistema de control de versiones. Todo en tus organizaciones está debidamente registrado en él. Los despliegues parten del control de versiones y, si surgiera algún problema en producción, podrías revertir los cambios de forma rápida y sencilla, sin complicaciones.

Tus despliegues están completamente automatizados. Las solicitudes de incorporación de cambios inician compilaciones con un servidor de CI y ejecutan validaciones de Salesforce y pruebas unitarias de Apex. Según tu nivel de avance, puede que incluso ejecutes pruebas funcionales automatizadas como pasos posteriores al despliegue. No has usado un conjunto de cambios en meses. Y cada desarrollador puede desplegar en entornos de etapas posteriores (dentro de lo razonable) sin tener que recurrir al “experto en Ant”.

Los despliegues están sujetos a permisos que determinan quién puede desplegar y en qué entornos.

Estás haciendo al menos una o dos de estas tres cosas:

1. Revisiones periódicas de código
2. Pruebas funcionales automatizadas de la interfaz
3. Controles de calidad y análisis estático de código
   

Tu calendario de despliegues depende de las necesidades de tu negocio, pero, si quisieras, podrías desplegar fácilmente una corrección urgente en minutos sin interrumpir otros trabajos.

Dónde puedes mejorar:

Estás en la etapa de perfeccionamiento de tu recorrido de DevOps. Tu proceso funciona bastante bien y ahora solo quieres pulirlo e incorporar más mejoras. Muy pocos equipos aplican controles de calidad adecuados, así que quizás quieras invertir en eso. Tal vez quieras aumentar tu cobertura de pruebas del 75% de Salesforce a un nivel superior, como 80 o 90%.

55-69: Pioneros de DevOps

Acerca de ti:

Tienes al menos 3 etapas de desarrollo: desarrollo, preproducción y producción. Tal vez preproducción incluya incluso un paso de integración. No necesariamente todos los desarrolladores tienen su propio sandbox: las cosas se organizan más sobre la marcha. Los administradores trabajan un poco por su cuenta.

Tienes control de versiones con Bitbucket o GitHub, pero aún no funciona a la perfección. No todos lo usan a diario como parte de su flujo de trabajo. Tal vez tienes un script automatizado que “respalda” todo cada noche. Pero es una solución bastante general.

Todavía usas conjuntos de cambios a veces, pero también tienes cierta automatización con Ant. Tal vez haya un “experto en Ant” en el equipo que esté empezando a convertirse en un cuello de botella y sea ya la única persona capaz de desplegar. Quizás tengas una herramienta comercial de gestión de entregas de generación 1.0 que parece mejor que nada y aporta cierto valor, pero no has incorporado mejoras en meses.

Has leído sobre pruebas funcionales y controles de calidad. Sabes qué son, pero todavía no has podido implementarlos en todo el equipo. Las revisiones de código se hacen de forma ocasional o entre uno o dos de los integrantes con mayor perfil técnico.

Dónde puedes mejorar:

Por suerte, las herramientas disponibles han mejorado enormemente en los últimos tres años, así que ahora tienes nuevas opciones. Algunas ideas para lograr mejoras rápidas:

• Da el paso y crea un sandbox para cada integrante del equipo. Te lo agradecerán después.
• Explora herramientas de Git con interfaz gráfica como Source Tree, la interfaz gráfica de GitHub o Blue Canvas.
• Invierte en una herramienta de CI para gestionar tus despliegues: hay opciones de código abierto como Jenkins o Bitbucket y opciones comerciales como Travis CI y Circle CI. Blue Canvas ofrece una herramienta de CI dedicada, diseñada específicamente para Salesforce.
• Invierte en QA y pruebas automatizadas para agilizar el trabajo de tu equipo.
• Invierte en SonarApex para evaluar el estado de tu código de Salesforce y usa los resultados para establecer revisiones de código periódicas y comprobar si mejoras con el tiempo.

20-54: Interesados en DevOps

Acerca de ti:

Estás aquí porque sabes que DevOps y CI/CD son objetivos que quieres alcanzar en tu organización, pero aún no has dado los primeros pasos.

Usas principalmente conjuntos de cambios para realizar despliegues. Quizás encontraste una forma de respaldar algunos de tus metadatos de Salesforce en un repositorio de Git, pero no todos saben cómo funciona. O tal vez todavía no tienes control de versiones, pero sabes que lo necesitas.

Has leído sobre controles de calidad y pruebas automatizadas, o quizás los estés conociendo por primera vez en esta evaluación.

Reconoces el valor de DevOps y solo necesitas una forma de implementarlo.

Dónde puedes mejorar:

¡Buenas noticias! Tienes a tu alcance la mayor cantidad de oportunidades de mejora rápida, así que hay mucho que puedes hacer. La primera gran barrera para usar DevOps en Salesforce es reconocer que lo necesitas. Si estás en este grupo, ya superaste ese obstáculo y puedes empezar a avanzar rápidamente.

• Infórmate sobre estrategias de sandboxes y agrega etapas de desarrollo, pruebas y producción a tu flujo de trabajo.
• Invierte en control de versiones: hay soluciones económicas y fáciles de implementar diseñadas para Salesforce, como Blue Canvas, o soluciones más personalizables, como GitHub y Bitbucket
• Deja de usar conjuntos de cambios y explora la herramienta de migración Ant o una solución comercial
• Infórmate sobre la automatización de pruebas y prepárate para invertir en ella cuando tengas un mejor control de versiones y flujo de despliegue.

0-19: Primeros pasos

Acerca de ti: Para ser sinceros, ¡nos sorprende que estés aquí! Este es el comienzo de tu camino. Si estás en este grupo y estás respondiendo este cuestionario, tienes las ganas y el interés.

Puede que tu organización aún no sea lo suficientemente grande como para haber invertido en esto, o quizá tú seas el único administrador. Aun así, puedes beneficiarte de DevOps y del control de versiones, aunque no tengas un flujo completo de CI/CD.

Dónde puedes mejorar:

1. Lee sobre Buenas prácticas de desarrollo en Salesforce
2. Usa sandboxes y conjuntos de cambios para pasar los cambios a producción en lugar de trabajar directamente en ella
3. Configura el control de versiones o las copias de seguridad de metadatos