Anup Jadhav sobre control de versiones, CI y otros temas para desarrolladores de Salesforce

En este artículo, conoce la experiencia de Anup Jadhav, MVP de desarrollo de Salesforce, y sus opiniones sobre el desarrollo en Salesforce, el control de versiones, la entrega continua y los recientes anuncios de Dreamforce.

Estas son nuestras 5 conclusiones clave:

1. Force.com es una plataforma potente que permite desarrollar aplicaciones de forma ágil y rápida con un mínimo de código.

2. El control de versiones es fundamental para dar seguimiento a los cambios e incorporar un proceso de revisión de código a tu flujo de trabajo.

3. La integración continua y la entrega continua presentan desafíos para los equipos de desarrollo de Salesforce debido a las limitaciones de la API de metadatos.

4. Salesforce DX ofrece más control y opciones para automatizar el proceso de despliegue, lo que aumenta la productividad de los desarrolladores.

5. La nueva CLI y las organizaciones temporales de Salesforce DX serán útiles para las pruebas de desarrollo y de datos.

Anup tuvo la amabilidad de compartir sus opiniones sobre el desarrollo en Salesforce, la entrega continua, el control de versiones, Einstein y otros temas relacionados con Force.com.

Anup Jadhav es Salesforce Developer MVP y reside en el Reino Unido. Es desarrollador de software, arquitecto técnico y gerente de ingeniería, con más de 12 años de experiencia desarrollando aplicaciones web y de Salesforce para empresas de primer nivel. Anup ha trabajado principalmente en los sectores de servicios financieros y medios de comunicación, con más de 7 años de experiencia profesional en la plataforma Salesforce.

También es fundador y coorganizador del London Developer User Group. Lee más de Anup en su blog: www.anup.io y síguelo en Twitter @Anup.

¿Cómo empezaste a trabajar con la plataforma Force.com?

Al principio era desarrollador de Java y C#. Llevo entre doce y trece años desarrollando software. Trabajé con Java y C# durante cinco o seis años y después entré a una empresa local en Redding que usaba Salesforce. Fue por la época en que se lanzaron Apex y Visualforce.

Como Apex es muy similar a Java, lo aprendí rápidamente y estudié Salesforce por mi cuenta. Cuando comprendí lo potente que era esta plataforma y todo lo que se podía hacer con ella, me convertí en desarrollador de Salesforce a tiempo completo. Después trabajé en un par de consultoras, donde me dediqué al desarrollo en Salesforce, la implementación, el análisis de negocio y la arquitectura técnica.

¿Qué hace que Force.com sea una plataforma tan potente?

Lo que más me gustó de la plataforma fue la agilidad y la rapidez con las que puedes crear aplicaciones. Como venía de Java, estaba acostumbrado a realizar mucha configuración inicial. Aunque cuentas con frameworks y bibliotecas que te ayudan a crear aplicaciones, todavía debes preocuparte por la seguridad, la escalabilidad y el mantenimiento del software y el hardware.

Uso control de versiones en casi todos mis proyectos. Digo «casi» porque, a veces, cuando trabajas como consultor, no puedes imponerlo, pero siempre que puedo intento usarlo. Me gusta Git porque tiene una interfaz de línea de comandos muy buena.

En cambio, con la plataforma de aplicaciones de Salesforce, casi todo ya está configurado y puedes concentrarte en crear aplicaciones increíbles. La mayor parte de lo que necesitas se puede hacer con herramientas de apuntar y hacer clic, con poco o nada de código. Y para lo que no puedes hacer de esa forma, puedes usar el framework Lightning, Apex y Visualforce para crear una aplicación en días o semanas.

¿Tuviste algún desafío al empezar con Salesforce?

Empezar no me resultó tan difícil gracias a mi experiencia con Java. Antes había trabajado con JSP, lo que me preparó para el modelo de Apex y Visualforce. Sorprendentemente, lo más difícil para mí fue el modelo de seguridad. Creo que me llevó meses entenderlo en su totalidad.

Sorprendentemente, aprender algunos aspectos de la administración de Salesforce me llevó más tiempo que aprender los de desarrollo.

¿Pasas más tiempo en una herramienta como el IDE de Force.com o desarrollando desde la interfaz de usuario?

Depende del proyecto. Si incluye muchos requisitos de negocio complejos que no se pueden implementar con herramientas de apuntar y hacer clic, paso mucho tiempo en mi IDE. Antes usaba el complemento Force.com IDE para Eclipse. Pero desde que salió MavensMate para Sublime Text, uso MavensMate.

Paso aproximadamente el 60% de mi tiempo en el IDE y el 40% en la interfaz de usuario.

¿Cuáles son algunas de tus herramientas favoritas?

En primer lugar, uso control de versiones en casi todos mis proyectos. Digo «casi» porque, a veces, cuando trabajas como consultor, no puedes imponerlo, pero siempre que puedo intento usarlo. Me gusta Git porque tiene una interfaz de línea de comandos muy buena.

El control de versiones es importante para llevar un registro de tus cambios. No te das cuenta de lo útil que es hasta que necesitas saber quién cambió qué. Y eso ocurre con bastante frecuencia.

Me encanta la terminal. Por eso uso el kit de herramientas de migración de Force.com para desplegar. Intento usarlo en lugar de conjuntos de cambios y utilizo el control de código fuente para rastrear todos mis cambios.

A veces uso Jenkins para la integración continua. Depende del proyecto. Si es grande y complejo, configuramos un servidor de integración continua y vinculamos una rama con la organización de Salesforce y con Jenkins. Así, cada vez que confirmas cambios o despliegas, se ejecutan pruebas automáticamente y luego se despliegan todas las clases y los artefactos nuevos.

¿Por qué es importante el control de versiones?

El control de versiones es importante porque permite rastrear los cambios en el código a lo largo del tiempo. No te das cuenta de lo útil que es hasta que necesitas saber quién cambió qué. Y eso ocurre con bastante frecuencia. Durante el desarrollo, cuando aparece un error, muchas veces necesitas saber cómo evolucionó una clase en particular. Quieres saber quién cambió qué, no necesariamente para buscar culpables, sino para entender la evolución de la lógica de los procesos de negocio implementados.

Con Git, puedes incorporar un proceso de revisión de código a tu flujo de trabajo, lo que tiene un enorme impacto en la calidad del código que produces.

Obviamente, también funciona como respaldo porque, por distintas razones, un desarrollador puede sobrescribir los cambios de otro, especialmente cuando varios trabajan en un mismo sandbox. En ese caso, es útil contar con control de código fuente para llevar un registro de esos cambios y poder volver con seguridad a una versión anterior.

¿Cuánto tiempo llevas usando Git?

Creo que ya llevo 4+ años. Antes usaba SVN. ¿Hay algo que haga que Git sea ideal para un desarrollador de Salesforce? Git funciona muy bien con el flujo de trabajo de Salesforce y su modelo distribuido se adapta bien a la estrategia de organizaciones de Salesforce. En lugar de confirmar cambios directamente en el repositorio principal, puedes enviar un parche para que alguien de tu equipo lo revise. Es fácil comprobar si los cambios cumplen con los estándares de código o si existe algún riesgo de introducir un error. Con Git, puedes incorporar un proceso de revisión de código a tu flujo de trabajo, lo que tiene un enorme impacto en la calidad del código que produces. Sin embargo, esto requiere disciplina y una cultura de equipo que haga cumplir las mejores prácticas de control de versiones.

¿Cuáles son hoy los mayores obstáculos para que los equipos de desarrollo de Salesforce avancen hacia la integración continua y la entrega continua?

Cuando digo integración continua (CI), no lo digo en el sentido tradicional. Si hablas de entrega continua e integración continua en el contexto de Java y C#, te refieres a un flujo de trabajo que te permite enviar cambios a tu repositorio de Git o al sistema de control de versiones que uses. Esto inicia automáticamente un proceso que ejecuta todas las pruebas de integración, las pruebas unitarias y las pruebas de interfaz de usuario con Selenium. Después, quizá despliegue en otros entornos, como qa, uat e incluso prod. Ese es el modelo tradicional de integración continua.

El principal beneficio de la integración continua es que detecta cualquier problema de calidad del código desde el principio. Detectar a tiempo algo que rompe el código te hace prestar más atención a los cambios que confirmas y también a tus pruebas.

Por ahora no podemos implementar la integración continua tradicional con Salesforce porque no podemos automatizar el despliegue de todos los artefactos. Uno de los desafíos es que la Metadata API, que usa el kit de herramientas de migración de Force.com, no admite todos los artefactos. Por eso no puedes desplegar elementos como servicios de correo electrónico, plantillas de cotización, site.com, etc. Debes desplegarlos desde la interfaz de usuario, mediante conjuntos de cambios o pasos manuales. Esto impide automatizar el despliegue. Dados esos desafíos, puedes configurar una integración continua limitada conectando un servidor de integración continua a una organización de Salesforce. Configuras una regla para que, si confirmas cambios en una rama de desarrollo o de integración continua, se obtenga todo el código de esa rama, se despliegue en la organización de Salesforce, se ejecuten todas las pruebas y se envíe por correo al equipo el resultado de éxito o fallo.

¿Cuál es el principal beneficio de configurar la integración continua, incluso con estas limitaciones?

El principal beneficio es que detecta cualquier problema de calidad del código desde el principio. Detectar a tiempo algo que rompe el código te hace prestar más atención a los cambios que confirmas y también a tus pruebas. Así escribirás mejores pruebas y más efectivas.

Sí mejora la calidad del código que produces, así que vale la pena configurarla. Puede llevarte uno o dos días, pero una vez que está lista, no tienes que hacer nada más.

Desde tu perspectiva, ¿cuál fue el anuncio más interesante de Dreamforce?

Hubo dos anuncios que me interesaron. Einstein, obviamente, pero como desarrollador, el que más me entusiasmó fue Salesforce DX. Una de las cosas que extrañé al comenzar a desarrollar en Force.com fue el flujo de trabajo fluido de desarrollo, compilación y despliegue que usaba cuando trabajaba con Java/C#. El flujo comenzaba con el control de versiones y ya en ese entonces se podía automatizar casi todo. La integración continua y la entrega continua no eran tan difíciles.

Dados los desafíos que mencioné antes, como no poder escribir scripts para desplegarlo todo, Salesforce DX nos da más control como desarrolladores y más opciones para automatizar el proceso de despliegue. Con DX, en lugar de empezar con una organización y luego agregar elementos al repositorio, empezamos con el control de código fuente y después desplegamos en la organización. Así, tu repositorio de control de versiones se convierte en la fuente de verdad. Esto invierte el proceso, que es lo que buscamos si queremos adoptar un flujo de trabajo compatible con el control de versiones y la integración continua.

Creo que hará que los desarrolladores sean mucho más productivos. La nueva CLI, junto con las organizaciones temporales, será muy útil para realizar pruebas de desarrollo y de datos con rapidez.

¿Qué opinas de DX?

La nueva CLI mejorada abre la posibilidad de implementar la entrega continua en Salesforce. También nos permitirá automatizar más cosas de las que podemos automatizar hoy con las herramientas disponibles. La automatización y la entrega continua significan código de buena calidad y mayor velocidad de desarrollo. Podremos empezar a crear aplicaciones aún más rápido en Force.com.

El otro anuncio que mencionaste fue Einstein. ¿Qué opinas de Einstein?

Tenemos la suerte de vivir en una época de revolución de la IA (inteligencia artificial). Aunque no sea verdadera IA ni conciencia artificial, es fascinante ver cómo empresas como Google, Facebook y Microsoft invierten sus recursos para crear algoritmos de aprendizaje automático más inteligentes que tendrán un impacto en todos los aspectos de nuestra vida.

Fue interesante que Salesforce centrara su atención en la IA. Tiene sentido al ver el panorama general. Con Salesforce Einstein están llevando la IA a las empresas. Las demostraciones que he visto muestran un gran potencial. En definitiva, no puedo opinar con fundamento sin probar y experimentar con Einstein. Pero veo enormes posibilidades en sus capacidades de predicción. Por ejemplo, predecir si un prospecto se convertirá en una venta o anticipar el flujo de oportunidades. Podría ahorrarles mucho trabajo manual a los usuarios empresariales. Será interesante ver cómo se integra Einstein en los productos existentes de Salesforce.

Como desarrollador, me entusiasma pensar en el tipo de aplicaciones que ahora podemos crear en la plataforma con Einstein. Una de las cosas que mostraron fue la Vision API, creo que así se llama. Podía aplicar su algoritmo a rostros y luego, si le mostrabas ese rostro en distintos lugares, reconocía a la persona. Eso abre oportunidades para crear aplicaciones innovadoras en la plataforma.

¿Cuándo veremos muchas aplicaciones de Einstein en el mercado?

Como no trabajo en Salesforce ni conozco los planes de desarrollo de Einstein, es difícil decirlo, pero si tuviera que aventurar una respuesta, diría que todavía está en desarrollo. Aunque mostraron muchas demostraciones en Dreamforce, parecían estar en un entorno controlado. Probablemente tengamos que esperar entre seis y ocho meses para probar algo más concreto. Pero, de nuevo, estoy especulando. Ya sabes: advertencias al comprador, declaraciones a futuro y todo eso.

¿De qué estaremos hablando en el próximo Dreamforce, dentro de 1 año?

Bueno, Salesforce ha abordado casi todo. Abordaron IoT (Internet de las cosas), están trabajando con IA, así que sin duda veremos más de Einstein el próximo año, y funciona en toda su suite de productos. Si tuviera que adivinar, una de las tecnologías que veremos es la que está detrás de Bitcoin: blockchain. Blockchain, o el registro distribuido, está transformando el sector de servicios financieros. Así que predigo que veremos algo relacionado con blockchain y la plataforma Salesforce.

¿Qué opinas de la próxima versión Winter ‘17?

Winter ‘17 es un gran avance para Lightning Experience. Han lanzado muchas funciones de LEX para Sales Cloud, Service Cloud, Community Cloud y otras nubes. Esta versión probablemente nos acerca un 65-70% a la transición de Classic a Lightning. Como desarrollador, me entusiasma usar los componentes base de Lightning junto con las acciones personalizadas, que ofrecerán una solución elegante para las acciones de botones JavaScript personalizados de Classic. Locker Service es una incorporación bienvenida desde el punto de vista de la seguridad. Esta versión sin duda animará a desarrolladores, administradores y usuarios a pasar de Classic a LEX.

¿Qué mejoras de Lightning te entusiasman más?

Lo que más me entusiasma es cómo los componentes de Lightning pueden integrarse en la interfaz estándar. Creo que hay mucho potencial si lo hacen bien. Podrías personalizar cada aspecto de tu experiencia con Lightning. Si logran ese objetivo, todas las dificultades de la transición valdrán la pena, porque abrirá muchísimas posibilidades para configurar Salesforce o crear componentes y aplicaciones en la plataforma.

¿Hay algo que no te haya preguntado y que te gustaría que nuestros lectores supieran o tuvieran en cuenta?

Lightning, e incluso Salesforce, todavía están en sus primeras etapas, especialmente desde el punto de vista del desarrollo. Lo que aún no tiene suficiente madurez son las prácticas de desarrollo, sobre todo para equipos pequeños y medianos. Los equipos más grandes suelen tener algún tipo de proceso. Pero con el lanzamiento de Salesforce DX, me gustaría ver que la comunidad adopte mejores prácticas comunes. Creo que debemos unirnos como comunidad, identificar qué funciona bien en proyectos pequeños, medianos e incluso grandes, y crear un marco de desarrollo que nos haga a todos más productivos y mejores desarrolladores.

¿Algún consejo para nuestros lectores interesados en empezar a desarrollar en Salesforce?

Mantén una mente abierta. Especialmente si vienes de Ruby, Java o C#, el paradigma de desarrollo puede parecerte poco familiar y, en algunos casos, restrictivo, pero al final vale la pena. Sobre todo si creas aplicaciones empresariales grandes. Salesforce y Heroku te ahorrarán muchas complicaciones. Solo tienes que comprender las mejores prácticas y el paradigma de trabajo del ecosistema de Salesforce. Aspectos como los límites de ejecución pueden parecer restrictivos al principio, pero en realidad te ayudan a ser un mejor desarrollador y a crear aplicaciones más eficientes.

‍