Aumenta tu velocidad con el despliegue continuo para Salesforce
El Premio Kremer se creó en 1959 para otorgar 50,000 libras esterlinas al equipo que pudiera crear la primera máquina voladora de propulsión humana. Hoy, el desarrollo continuo (CD) se aplica al desarrollo de software, incluido Salesforce, para crear y entregar software de alta calidad con rapidez.
Por Randalyn Hill-Coffer·Revisado por el equipo de Blue Canvas··7 min de lecturaEn este artículo, conoce la historia del Premio Kremer y descubre cómo el enfoque del Dr. Paul MacCready para construir una máquina voladora de propulsión humana puede aplicarse al desarrollo de software mediante el desarrollo continuo. El artículo también ofrece consejos para que los desarrolladores de Salesforce implementen el desarrollo continuo, incluido el uso del control de versiones, las pruebas automatizadas y un servidor de CI.
Estas son nuestras 5 conclusiones clave:
1. El enfoque del Dr. Paul MacCready para construir una máquina voladora de propulsión humana puede aplicarse al desarrollo de software mediante el desarrollo continuo.
2. El desarrollo continuo requiere que cada desarrollador registre sus cambios en un repositorio de código central y compartido varias veces al día, y que se automatice el proceso de compilación y despliegue.
3. Los desarrolladores de Salesforce pueden implementar el desarrollo continuo usando el control de versiones, ejecutando pruebas automáticamente y utilizando un servidor de CI.
4. Las pruebas automatizadas son un componente clave de cualquier flujo de desarrollo continuo, incluidas las pruebas unitarias y funcionales.
5. Blue Canvas es una herramienta de control de versiones y despliegue mediante push para aplicaciones de Salesforce que puede simplificar el proceso de desarrollo continuo.
Henry Kremer fue un destacado industrial en la Gran Bretaña de la década de 1950. Como correspondía a un industrial destacado, era un hombre bastante excéntrico. Su obsesión era el vuelo de propulsión humana. Así que en 1959 creó el Premio Kremer que otorgaría 50,000 libras esterlinas al equipo que pudiera crear la primera máquina voladora de propulsión humana.
El recorrido era sencillo: trazar un ocho alrededor de 2 marcadores separados por media milla, manteniendo una altura de al menos 10 pies. A pesar de más de 50 intentos oficiales y 17 años, nadie había logrado ganar el premio de 50,000 libras (equivalente a aproximadamente $1.4M hoy).
Optimización para ganar velocidad
Entonces, en 1977, el Dr. Paul MacCready aceptó el desafío. De inmediato se dio cuenta de que el problema no era «cómo construir la primera máquina voladora de propulsión humana», sino cómo construir un avión que pudiera ensamblarse en cuestión de horas en lugar de meses.
La mayoría de los equipos tenía largas fases de diseño. Pasaban meses diseñando sus aviones. Luego dedicaban otros meses a construirlos según especificaciones precisas. Después de meses de trabajo, realizaban una prueba e inevitablemente estrellaban el avión. Entonces volvían a empezar ese ciclo de meses. ¿Te suena familiar?
MacCready, en cambio, construyó un avión con mylar y cinta adhesiva Scotch. El avión podía reconstruirse en cuestión de horas, lo que le permitía probar el diseño a diario. Mientras que la mayoría de los equipos realizaban uno o dos vuelos al año, el equipo de MacCready realizó 222 en 6 meses. En el vuelo 223 ganó el premio.
El problema no era construir el primer avión, sino uno que pudiera ensamblarse en cuestión de horas en lugar de meses.
Integración continua (o desarrollo continuo)
Muchos están aplicando la lección de MacCready al desarrollo de software con la llegada de la integración continua (CI), el despliegue continuo y la entrega continua (CD). Preferimos el término «desarrollo continuo» para reflejar que una implementación eficaz de CD debe abarcar cada etapa de programación, compilación, pruebas y lanzamiento de software.
El desarrollo continuo requiere que cada desarrollador registre sus cambios en un repositorio de código central y compartido varias veces al día. Un sistema de compilación automática prueba y verifica cada conjunto de cambios, lo que permite a los equipos detectar problemas de forma temprana. Si todas las pruebas pasan, la aplicación actualizada puede empaquetarse y desplegarse de inmediato, en lugar de esperar un largo período de diseño e integración de software.
Para poner en práctica el desarrollo continuo, los equipos deben trabajar con un único flujo de compilación optimizado. Este flujo incorpora varios principios y componentes importantes:
- Mantén un único repositorio para tu código fuente
- Programa clonando el repositorio en tu entorno personal
- Automatiza el proceso de compilación y despliegue
- El código debe probarse a sí mismo
- Todos pueden ver los cambios y comparar entornos
- Debe ser posible desplegar cambios y revertirlos de forma rápida y transparente
Esto se logra configurando distintas herramientas, como las de control de código fuente, automatización de pruebas y compilaciones, y despliegue.
¿Por qué es importante la integración continua para Salesforce?
Para muchas organizaciones, la entrega continua se ha convertido en la forma estándar de crear y entregar software de alta calidad. Como la integración y las pruebas son automáticas y se realizan con tanta frecuencia, la probabilidad de descubrir errores en una etapa tardía del proceso de lanzamiento se reduce drásticamente. Acortar el tiempo entre la introducción de un error y su detección hace que encontrar y solucionar un problema sea mucho más sencillo. Los desarrolladores no solo pueden concentrarse en crear, sino que también se elimina el tiempo perdido en pruebas manuales o en esperar a que terminen los despliegues.
Los desarrolladores pueden concentrarse en crear y eliminar el tiempo perdido en pruebas manuales y en esperar los despliegues.
Incluso nuestros amigos de Gartner creen que el cambio cultural y de gestión en las organizaciones hacia un enfoque DevOps (que incluye entrega continua, mejora continua, infraestructura y configuración como código, entre otros) ofrece grandes oportunidades de crecimiento para los proveedores de herramientas DevOps, así como los equipos que los adoptan.
Lo que la integración continua puede cambiar para los desarrolladores de Salesforce
Esto es especialmente cierto para los desarrolladores de Force.com. La plataforma Force.com es extraordinaria y potente. Herramientas como Lightning, Apex y Visualforce están diseñadas para crear rápidamente aplicaciones personalizadas de Salesforce con todas las funciones necesarias.
Pero si no puedes desplegar tu código tan rápido como lo escribes, estás dejando pasar oportunidades:
- Tus usuarios dependen de tu software para hacer su trabajo. Las aplicaciones de Force.com permiten que cientos de miles de personas en todo el mundo logren grandes cosas. Cuanto más tardes en entregarles nuevas funciones, menos eficaces serán.
- Los errores en aplicaciones creadas con Apex, Visualforce y Lightning son medibles y extremadamente costosos. Si tu equipo de ventas recibe millones de dólares en remuneración y un error le impide trabajar, el tiempo de inactividad le sale muy caro a tu empresa.
- Estás creando funciones increíbles y código elegante. ¿Por qué dejarlo guardado o dar la impresión de una burocracia interminable? ¡Ponlo en manos de tus usuarios!
Implementa despliegues continuos para Salesforce
Con todos los beneficios que aporta la entrega continua (CD), implementarla puede resultar sorprendentemente difícil para los desarrolladores de Salesforce. Como Apex y Lightning se alojan en la nube, configurar y mantener una cadena de herramientas funcional, eficiente y confiable es un desafío. Se requiere capacitación y experiencia para elegir las herramientas adecuadas y combinarlas en un proceso que funcione. Estos son algunos consejos para empezar:
Usa el control de versiones
El control de versiones o de código fuente es absolutamente esencial si buscas implementar el despliegue continuo. Herramientas como Git, Team Foundation Server o Perforce cumplen esta función. Hay varios servicios alojados, como GitHub, Bitbucket o GitLab que te ahorran la configuración manual. El control de código fuente te permite hacer seguimiento de los cambios y colaborar con mucha más eficacia.
Algo especialmente importante para la comunidad de Force.com es el control de versiones del código que reside en tus organizaciones de Salesforce.
¿Qué pasa si varios desarrolladores trabajan en el mismo proyecto, uno actualiza una clase y, poco después, otro guarda cambios en esa misma clase? ¿Cómo se gestiona la fusión del código? Lamentablemente, hoy no hay una buena respuesta. Los cambios se sobrescribirían y se perderían de forma irreversible. (Una pista: ¡aquí es donde Blue Canvas busca ayudarte!)
¿Qué pasa si varios desarrolladores trabajan en la misma organización? ¿Cómo se fusionan los cambios en una misma clase?
Ejecuta pruebas automáticamente
Las pruebas automatizadas son un componente clave de cualquier pipeline de entrega continua. Suelen adoptar dos formas: pruebas unitarias y pruebas funcionales. Las aplicaciones de Salesforce necesitan ambas.
Tus pruebas unitarias son pruebas pequeñas, rápidas y atómicas que te permiten probar componentes individuales de una aplicación. Salesforce exige una cobertura de código de al menos el 75% del código Apex, de lo contrario, no se puede desplegar en producción. Las pruebas suelen escribirse en clases de prueba Apex, pero Salesforce solo las ejecuta durante un despliegue o si se activan manualmente. Para activarlas automáticamente como parte de tu cadena de herramientas de entrega continua, necesitas herramientas adicionales. La herramienta Force.com CLI es una herramienta creada por el excelente equipo de Heroku y nuestra opción preferida para esta tarea.
El segundo componente son las pruebas funcionales. A veces también se llaman pruebas de integración y te permiten comprobar cómo funciona todo el sistema de extremo a extremo, desde la base de datos hasta la interfaz de usuario. Herramientas como Selenium son excelentes para esto, y servicios de terceros como Sauce Labs facilitan los primeros pasos. Si buscas una solución integral, explora Cinnamon, un framework de pruebas creado y mantenido por Salesforce, que se integra con Sauce Labs de forma nativa.
Usa un servidor de CI
Ahora, para conectar todo, necesitarás un servidor de integración continua (CI) como motor de compilación. El servidor de CI es el director de la orquesta. Consulta tu repositorio de código fuente en busca de cambios y, cuando encuentra nuevos commits, ejecuta los pasos que hayas definido como importantes para tu pipeline de entrega.
Hay muchas herramientas para elegir, pero estas son algunas buenas opciones que puedes explorar:
- Travis CI – un popular servicio alojado con configuración de compilación basada en YAML
- Jenkins – la clásica herramienta de CI de código abierto que ha recibido actualizaciones recientemente
- Bamboo o Bitbucket Pipelines – las herramientas profesionales de CI/CD de Atlassian, con una excelente integración con toda su suite de productos
Queremos que dediques tu tiempo a programar
Configurar la entrega continua para Salesforce es difícil. Es un proceso complejo y engorroso que te obliga a conectar diferentes herramientas y sistemas solo para que funcione lo mínimo indispensable. Muchas organizaciones dedican años a diseñar y perfeccionar su pipeline de entrega. Y después dedican meses a repararlo y mantenerlo.
Creemos que la mejor forma de aprovechar tu tiempo es crear aplicaciones increíbles. Haz cambios audaces. Piensa en grande. Trabaja en equipo. Déjanos el trabajo pesado y las esperas.
Blue Canvas ofrece control de código fuente y despliegue mediante push para aplicaciones de Salesforce. Creemos que debería ser así de sencillo:
$ git push salesforce master
Counting objects: 6, done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (6/6), 486 bytes, done.
Total 6 (delta 0), reused 0 (delta 0)
remote: Starting deployment to 'na30.salesforce.com'.
remote: Updating branch 'master'.
remote: Preparing deployment for commit id '369a79c929'.
remote: Preparing files for deployment.
remote: Deployment successful.
To https://git.bluecanvas.io/o/00D90060000aaPg.git
* [new branch] master -> master
¿Qué opinas? Queremos conocer tu visión de cómo debería ser tu pipeline de entrega continua. Imagina lo increíble que sería que los cambios de código que hiciste por la mañana ya estuvieran en producción y los usuarios reales los estuvieran usando cuando te prepares tu café de las 11am. Imagina la sonrisa de tu equipo cuando puedas lanzar un parche para corregir un error en 15 minutos.
Una vez que conoces la visión, el resto son solo detalles.
Contáctanos: team@bluecanvas.io



