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.
(Actualizado Mayo 2020)
Desde hace ya mucho, para los lenguajes de programación más comunes, disponemos de analizadores de código estático. Son herramientas, que aplican reglas de validación al código que escribimos.
Salesforce no proporciona una herramienta nativa dedicada al análisis de código estático APEX. Afortunadamente existen diferentes opciones en el mercado: CodeScan, Checkmarx, PMD, etc. Salesforce ofrece scans ad-hoc mediante Force.com Code Scanner Portal en asociación con Checkmarx, que es la herramienta utilizada internamente en Salesforce.
Una de estas herramientas muy empleada en otro lenguajes de programación es PMD. PMD es una librería Open Source para la ejecución de reglas de validación sobre un lenguaje de programación.
En Abril de 2016, Robert Sösemann anunció que había portado muchas reglas de validadción sobre el lenguaje Apex a PMD. Desde entonces PMD se ha convertido en una herramienta crucial en muchos proyectos de Salesforce, dada su facilidad de uso y la calidad de las reglas utilizadas.
PMD no requiere de ninguna infraestructura adicional, solo descargar los binarios y ejecutarlos, en nuestro ordenador, o en un servidor, con unda 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.
Esta entrada pertenece a una serie:
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).
Esta entrada pertenece a una serie:
Hemos visto en las entradas previas, varias necesidades para implementar el proceso de integración contínua automatizado en Salesforce.
Esta entrada pertenece a una serie:
En esta segunda entrada, conoceremos las nociones básicas de la Metadata API.
Esta entrada inicia una serie en la que muestro el proceso de mi adopción de Integración continua en Salesforce. Para la mayoría, no aporta ningún conocimiento nuevo, pero sirve para sentar las bases comunes.
Las entradas de la serie son:
Vincent Driessen en su blog GitFlow- A successfull Branching Model, describe el casi proceso de facto que aplican muchos equipos de desarrollo para la gestión de ramas (aunque prefiero la explicación y gráficos de AtlassiangitFlow Workflow.)-.
En esta entrada, intento explicar por qué, al menos en mi caso, no es directa su aplicación en un proyecto de Salesforce y las consideraciones adicionales y conclusiones a las que he llegado.
