Existen muchos artículos sobre los comandos que podemos lanzar con la linea de comandos de Salesforce, la llamada Salesforce CLI.
Pero en muchas ocasiones, me pregunto si al mostrar todos esos comandos, conseguimos realmente transmitir las capacidades y los beneficios que la CLI puede aportar a todos, sin excepción.
Por este motivo, este artículo tiene un enfoque completamente distinto.
Vimos en la entrada anterior las alternativas para almacenar información confidencial en Salesforce y vimos que el mecanismo preferido inicialmente, era la creación y despliegue de un Protected Custom Metadata Type.
En este artículo veremos paso a paso y en detalle:
Durante estas fechas (Navidades), es fundamental saber guardar ciertos secretos 😉 .
Saber qué secretos ocultar, a quién y a quién no ocultarlos, y cuanto esfuerzo nos a va suponer ocultarlo. Aparecen varias opciones y así no romper la magia de los más pequeños demasiado pronto.
Sucede de igual manera en Salesforce cuando deseamos almacenar secretos o información confidencial.
Desde hace ya mucho, para los lenguajes de programación más comunes, disponemos de analizadores de código estático.
Existen varias herramientas en el mercado, para el análisis de código Apex (Checkmarx utilizada por Salesforce, Sonarqube, Cosechan, Codacy, etc.) pero desde abril de 2016, Robert Sösemann portó Apex a PMD, una de las herramientas más conocidas de análisis de código y con licencia Open Source (Hiper-Kudos para Robert), con años de experiencia como una de las soluciones líderes en Java.
PMD para Apex y Visualforce (aún incipiente) no requiere de ninguna infraestructura adicional, solo descargar los binarios y ejecutarlos, en nuestro ordenador, en el servidor, con la JDK instalada etc.
Las capacidades de PMD, su licenciamiento, versatilidad, extensibilidad, integración con los IDEs y con herramientas de CI habituales (Maven, Ant, Gradle, etc.), y comunidad facilita enormemente su adopción.
Por ello, si no lo conoces, creo que puede ser muy útil, y es una herramienta muy a tener en cuenta para utilizar en nuestros proyectos. Te animo a leer el artículo por si te puede ayudar.
Partimos inicialmente con el deseo y con la convicción de que la Integración Contínua en Salesforce es completamente necesaria, y esa convicción, a pesar de los retos y condicionantes observados, sigue intacta.
Lo que ha cambiado completamente, es la simplificación con la que se habla y se predica la adopción de este proceso en modo DIY (Do it Yourself).
Hemos visto en las entradas previas, varias necesidades para implementar el proceso de integración contínua automatizado en Salesforce.
Veamos cual es el proceso para desplegar en una ORG.
El proceso de despliegue en Salesforce, a diferencia de, por ejemplo, en el mundo Java, no se realiza desplegando un fichero .ear/.war que contiene todos los componentes y sustituye de forma completa al anterior , sinó que se realiza mediante el despliegue de los componentes añadidos/modificados y listando aquellos que queremos eliminar, lo que se suele llamar incremental, por diferencias (en adelante usaré este último término).
