Ejecución de inspecciones de IntelliJ desde la integración continua
Ejecución de inspecciones de IntelliJ desde la integración continua
IntelliJ IDEA ofrece funcionalidad para ayudar a mejorar nuestra codificación, dentro del IDE al escribir código como Intenciones. Las Intenciones pueden ser usadas en lote para inspeccionar el código en busca de patrones a lo largo de la fuente e incluso extenderse al análisis de la Línea de Comandos o añadirse a la Integración Continua. Este post cubre la funcionalidad fuera de la caja de IntelliJ y la expansión con Intenciones personalizadas creadas en Sensei.
Inspecciones de IntelliJ
La función de Inspecciones de IntelliJ impulsa la visualización de muchos de los errores que se informan dinámicamente en el IDE cuando se codifica, por ejemplo
- detectar las clases abstractas que pueden convertirse en interfaces,
- identificar los campos de clase redundantes que pueden ser locales,
- advertencia sobre el uso de métodos obsoletos,
- etc.
Estas inspecciones resaltan el código que coincide en el IDE como Acciones de Intención que a menudo tienen un QuickFix asociado.
El resaltado del IDE en tiempo real cuando el código coincide con una Inspección puede ayudarnos a mejorar nuestra codificación de forma dinámica. Después de identificar el problema en el código, el uso de IntelliJ Intention Actions para QuickFix el código puede reforzar mejores patrones.
Perfil de las inspecciones
Las inspecciones pueden ejecutarse por lotes desde el IDE, y desde la línea de comandos o en un proceso de integración continua.
La clave para trabajar con las inspecciones de IntelliJ como un lote es mediante el uso de un Perfil de Inspección.
IntelliJ tiene dos perfiles de inspección por defecto: uno almacenado en el proyecto, y otro almacenado en el IDE.
Se pueden crear nuevos perfiles de inspección para configurar plugins o casos de uso específicos, por ejemplo
- Ejecutar sólo el escaneo en tiempo real de Checkstyle
- Ejecutar un conjunto específico de reglas de Sensei
- Ejecutar las comprobaciones de HTML
Las inspecciones de un perfil pueden activarse o desactivarse desde las Preferencias de IntelliJ. El cuadro de diálogo de Preferencias es también una forma sencilla de conocer la gama de Inspecciones disponibles.
El icono de la "herramienta" le permite duplicar un perfil y crear un nuevo perfil para recoger un conjunto específico de reglas.
Ejecución de un perfil de inspección en el IDE
Los Perfiles de Inspección pueden ser ejecutados desde el IDE usando el menú `Analizar | Inspeccionar Código...`.
La función de análisis le permite controlar el ámbito en el que se ejecutará la inspección, por ejemplo, todo el proyecto, incluyendo o excluyendo los orígenes de las pruebas, o un conjunto específico de archivos.
También puede gestionar los perfiles de inspección desde aquí para crear o configurar un perfil concreto.
Al hacer clic en [Aceptar] en el cuadro de diálogo "Especificar ámbito de inspección", IntelliJ ejecutará todas las inspecciones seleccionadas en el perfil en el ámbito definido.
IntelliJ informará de los resultados de la ejecución de las inspecciones en la pestaña `Resultados de la inspección`.
El plugin Sensei de Secure Code Warrior le permite crear recetas personalizadas de coincidencia de código. Sensei se integra estrechamente con IntelliJ para hacer que estas recetas personalizadas sean tan naturales de usar como las Acciones de Intención de IntelliJ. Esto significa que se cargan en IntelliJ como inspecciones y pueden agruparse, activarse y desactivarse utilizando perfiles de inspección. La creación de un perfil de inspección personalizado y el uso de la función de análisis del código de inspección es la forma recomendada de ejecutar las recetas de Sensei de forma masiva en un proyecto.
Ejecución de un perfil de inspección desde la línea de comandos
IntelliJ tiene la capacidad de ejecutar inspecciones desde la línea de comandos, tal y como documenta JetBrains:
- https://www.jetbrains.com/help/idea/working-with-the-ide-features-from-command-line.html
Yo uso principalmente macOS, y puedo ejecutar una sola instancia de IntelliJ desde la línea de comandos con:
open -na "IntelliJ IDEA CE.app"
Para facilitar la ejecución, añado esto a un script de comandos del shell.
vi /usr/local/bin/idea
El contenido del script proviene de la documentación oficial proporcionada por IntelliJ.
#!/bin/sh
open -na "IntelliJ IDEA CE.app" --args "$@"
Luego hice este ejecutable para permitirme simplificar el proceso de inspección de la línea de comandos.
chmod 755 /usr/local/bin/idea
La documentación oficial de intellij describe la forma general del comando de inspección como
idea inspect <project> <inspection-profile> <output></output></inspection-profile></project>
[<options>]</options>
En la práctica, califico completamente las rutas y no necesito ninguna opción:
idea inspect /Users/user/GitHub/sensei-blog-examples /Users/user/GitHub/sensei-blog-examples/.idea/inspectionProfiles/senseiprofile.xml /Users/user/GitHub/sensei-blog-examples/scan-results
Esto ejecuta todas las inspecciones que agregué al `senseiprofile` y reporta los resultados en la carpeta `scan-results`.
Visualización de los resultados de la inspección
Podemos informar de estos resultados desde la integración continua, como veremos más adelante.
También podemos verlos dentro del propio IntelliJ utilizando la función `Analyse \ View Offline Inspection Results...`.
Esto cargará los resultados en la pestaña "Resultados de la inspección".
Esto está oficialmente documentado en el sitio de JetBrains:
- https://www.jetbrains.com/help/idea/command-line-code-inspector.html#inspection-results
Esto podría utilizarse durante un proceso de revisión de código si la ejecución de la línea de comandos se incorporara a un proceso de Integración Continua y los revisores quisieran comprobar el contexto de origen completo de cualquiera de las entradas de resultados de la Inspección.
Perfiles de inspección en la integración continua
Al añadir la inspección de la línea de comandos en la integración continua, lo ideal es que queramos que se genere un informe de forma automática y hay varias opciones abiertas para nosotros.
TeamCity ofrece soporte inmediato para los perfiles de inspección en la integración continua.
- https://www.jetbrains.com/help/teamcity/inspections.html
El plugin Jenkins Warnings NG soporta la salida de línea de comandos de IntelliJ Inspections como uno de los formatos de informe.
- https://github.com/jenkinsci/warnings-ng-plugin
- https://github.com/jenkinsci/warnings-ng-plugin/blob/master/SUPPORTED-FORMATS.md
Existen proyectos comunitarios como `idea CLI Inspector` para apoyar el uso de los Perfiles de Inspección en otras herramientas de CI, por ejemplo
- https://github.com/bentolor/idea-cli-inspector
El futuro de los Perfiles de Inspección en un proceso de CI parece aún más brillante con la introducción del proyecto JetBrains Qodana. El proyecto Qodana es una versión sin cabeza de IntelliJ con acciones oficiales de Github e imágenes Docker.
- https://github.com/JetBrains/Qodana
Qodana se encuentra actualmente en fase beta, pero el equipo de Sensei lo está supervisando para que se convierta en una plataforma soportada oficialmente para ejecutar las reglas de Sensei como parte de la Integración Continua.
Resumen
Las Acciones de Intención nos permiten reforzar los patrones de codificación y corregirlos rápidamente en el IDE cuando cometemos errores durante la codificación.
Los Perfiles de Inspección nos permiten reunirlos en perfiles que pueden ejecutarse por lotes como una acción de Análisis e Inspección de Código. Esto puede ser útil si encontramos un patrón y queremos volver a comprobar si lo hemos pasado por alto en alguna otra parte de nuestro código.
Los Perfiles de Inspección pueden ejecutarse desde la línea de comandos e incluso incorporarse a los procesos de Integración Continua apoyando un modelo de "confiar, pero verificar" y detectar cualquier desviación accidental.
Todo lo anterior está incorporado en la funcionalidad de IntelliJ y JetBrains está mejorando su proceso de Integración Continua con la introducción de Qodana.
Sensei recetas se cargan en IntelliJ para actuar como Acciones de Intención nativas y ser recogidas en Perfiles de Inspección para soportar la comprobación por lotes a través de Inspect Code y el soporte de Integración Continua proporcionado por la funcionalidad oficial de ejecución de Línea de Comandos de JetBrains.
---
Puede instalar Sensei desde IntelliJ usando "Preferences \ Plugins" (Mac) o "Settings \ Plugins" (Windows) y luego sólo busque "sensei secure code".
Si quieres probar a ejecutar un proyecto en IntelliJ desde la línea de comandos, el proyecto utilizado en este post se puede encontrar en el repositorio `sensei-blog-examples` en la cuenta de GitHub de Secure Code Warrior . Un ejercicio para el lector es crear un perfil que ejecute sólo las reglas de Sensei . Pruébalo:
https://github.com/securecodewarrior/sensei-blog-examples
Aprenda a ejecutar Sensei y las Acciones de Intención de IntelliJ en modo de lote como Inspecciones dentro del IDE, desde la Línea de Comandos, y en Integración Continua.
Alan Richardson cuenta con más de veinte años de experiencia profesional en TI, trabajando como desarrollador y en todos los niveles de la jerarquía de pruebas, desde probador hasta jefe de pruebas. Jefe de Relaciones con los Desarrolladores en Secure Code Warrior, trabaja directamente con los equipos, para mejorar el desarrollo de un código seguro de calidad. Alan es autor de cuatro libros, entre ellos "Dear Evil Tester" y "Java For Testers". Alan también ha creado una formación en línea courses para ayudar a la gente a aprender las pruebas técnicas de la web y Selenium WebDriver con Java. Alan publica sus escritos y vídeos de formación en SeleniumSimplified.com, EvilTester.com, JavaForTesters.com, y CompendiumDev.co.uk.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostración
Alan Richardson cuenta con más de veinte años de experiencia profesional en TI, trabajando como desarrollador y en todos los niveles de la jerarquía de pruebas, desde probador hasta jefe de pruebas. Jefe de Relaciones con los Desarrolladores en Secure Code Warrior, trabaja directamente con los equipos, para mejorar el desarrollo de un código seguro de calidad. Alan es autor de cuatro libros, entre ellos "Dear Evil Tester" y "Java For Testers". Alan también ha creado una formación en línea courses para ayudar a la gente a aprender las pruebas técnicas de la web y Selenium WebDriver con Java. Alan publica sus escritos y vídeos de formación en SeleniumSimplified.com, EvilTester.com, JavaForTesters.com, y CompendiumDev.co.uk.
Ejecución de inspecciones de IntelliJ desde la integración continua
IntelliJ IDEA ofrece funcionalidad para ayudar a mejorar nuestra codificación, dentro del IDE al escribir código como Intenciones. Las Intenciones pueden ser usadas en lote para inspeccionar el código en busca de patrones a lo largo de la fuente e incluso extenderse al análisis de la Línea de Comandos o añadirse a la Integración Continua. Este post cubre la funcionalidad fuera de la caja de IntelliJ y la expansión con Intenciones personalizadas creadas en Sensei.
Inspecciones de IntelliJ
La función de Inspecciones de IntelliJ impulsa la visualización de muchos de los errores que se informan dinámicamente en el IDE cuando se codifica, por ejemplo
- detectar las clases abstractas que pueden convertirse en interfaces,
- identificar los campos de clase redundantes que pueden ser locales,
- advertencia sobre el uso de métodos obsoletos,
- etc.
Estas inspecciones resaltan el código que coincide en el IDE como Acciones de Intención que a menudo tienen un QuickFix asociado.
El resaltado del IDE en tiempo real cuando el código coincide con una Inspección puede ayudarnos a mejorar nuestra codificación de forma dinámica. Después de identificar el problema en el código, el uso de IntelliJ Intention Actions para QuickFix el código puede reforzar mejores patrones.
Perfil de las inspecciones
Las inspecciones pueden ejecutarse por lotes desde el IDE, y desde la línea de comandos o en un proceso de integración continua.
La clave para trabajar con las inspecciones de IntelliJ como un lote es mediante el uso de un Perfil de Inspección.
IntelliJ tiene dos perfiles de inspección por defecto: uno almacenado en el proyecto, y otro almacenado en el IDE.
Se pueden crear nuevos perfiles de inspección para configurar plugins o casos de uso específicos, por ejemplo
- Ejecutar sólo el escaneo en tiempo real de Checkstyle
- Ejecutar un conjunto específico de reglas de Sensei
- Ejecutar las comprobaciones de HTML
Las inspecciones de un perfil pueden activarse o desactivarse desde las Preferencias de IntelliJ. El cuadro de diálogo de Preferencias es también una forma sencilla de conocer la gama de Inspecciones disponibles.
El icono de la "herramienta" le permite duplicar un perfil y crear un nuevo perfil para recoger un conjunto específico de reglas.
Ejecución de un perfil de inspección en el IDE
Los Perfiles de Inspección pueden ser ejecutados desde el IDE usando el menú `Analizar | Inspeccionar Código...`.
La función de análisis le permite controlar el ámbito en el que se ejecutará la inspección, por ejemplo, todo el proyecto, incluyendo o excluyendo los orígenes de las pruebas, o un conjunto específico de archivos.
También puede gestionar los perfiles de inspección desde aquí para crear o configurar un perfil concreto.
Al hacer clic en [Aceptar] en el cuadro de diálogo "Especificar ámbito de inspección", IntelliJ ejecutará todas las inspecciones seleccionadas en el perfil en el ámbito definido.
IntelliJ informará de los resultados de la ejecución de las inspecciones en la pestaña `Resultados de la inspección`.
El plugin Sensei de Secure Code Warrior le permite crear recetas personalizadas de coincidencia de código. Sensei se integra estrechamente con IntelliJ para hacer que estas recetas personalizadas sean tan naturales de usar como las Acciones de Intención de IntelliJ. Esto significa que se cargan en IntelliJ como inspecciones y pueden agruparse, activarse y desactivarse utilizando perfiles de inspección. La creación de un perfil de inspección personalizado y el uso de la función de análisis del código de inspección es la forma recomendada de ejecutar las recetas de Sensei de forma masiva en un proyecto.
Ejecución de un perfil de inspección desde la línea de comandos
IntelliJ tiene la capacidad de ejecutar inspecciones desde la línea de comandos, tal y como documenta JetBrains:
- https://www.jetbrains.com/help/idea/working-with-the-ide-features-from-command-line.html
Yo uso principalmente macOS, y puedo ejecutar una sola instancia de IntelliJ desde la línea de comandos con:
open -na "IntelliJ IDEA CE.app"
Para facilitar la ejecución, añado esto a un script de comandos del shell.
vi /usr/local/bin/idea
El contenido del script proviene de la documentación oficial proporcionada por IntelliJ.
#!/bin/sh
open -na "IntelliJ IDEA CE.app" --args "$@"
Luego hice este ejecutable para permitirme simplificar el proceso de inspección de la línea de comandos.
chmod 755 /usr/local/bin/idea
La documentación oficial de intellij describe la forma general del comando de inspección como
idea inspect <project> <inspection-profile> <output></output></inspection-profile></project>
[<options>]</options>
En la práctica, califico completamente las rutas y no necesito ninguna opción:
idea inspect /Users/user/GitHub/sensei-blog-examples /Users/user/GitHub/sensei-blog-examples/.idea/inspectionProfiles/senseiprofile.xml /Users/user/GitHub/sensei-blog-examples/scan-results
Esto ejecuta todas las inspecciones que agregué al `senseiprofile` y reporta los resultados en la carpeta `scan-results`.
Visualización de los resultados de la inspección
Podemos informar de estos resultados desde la integración continua, como veremos más adelante.
También podemos verlos dentro del propio IntelliJ utilizando la función `Analyse \ View Offline Inspection Results...`.
Esto cargará los resultados en la pestaña "Resultados de la inspección".
Esto está oficialmente documentado en el sitio de JetBrains:
- https://www.jetbrains.com/help/idea/command-line-code-inspector.html#inspection-results
Esto podría utilizarse durante un proceso de revisión de código si la ejecución de la línea de comandos se incorporara a un proceso de Integración Continua y los revisores quisieran comprobar el contexto de origen completo de cualquiera de las entradas de resultados de la Inspección.
Perfiles de inspección en la integración continua
Al añadir la inspección de la línea de comandos en la integración continua, lo ideal es que queramos que se genere un informe de forma automática y hay varias opciones abiertas para nosotros.
TeamCity ofrece soporte inmediato para los perfiles de inspección en la integración continua.
- https://www.jetbrains.com/help/teamcity/inspections.html
El plugin Jenkins Warnings NG soporta la salida de línea de comandos de IntelliJ Inspections como uno de los formatos de informe.
- https://github.com/jenkinsci/warnings-ng-plugin
- https://github.com/jenkinsci/warnings-ng-plugin/blob/master/SUPPORTED-FORMATS.md
Existen proyectos comunitarios como `idea CLI Inspector` para apoyar el uso de los Perfiles de Inspección en otras herramientas de CI, por ejemplo
- https://github.com/bentolor/idea-cli-inspector
El futuro de los Perfiles de Inspección en un proceso de CI parece aún más brillante con la introducción del proyecto JetBrains Qodana. El proyecto Qodana es una versión sin cabeza de IntelliJ con acciones oficiales de Github e imágenes Docker.
- https://github.com/JetBrains/Qodana
Qodana se encuentra actualmente en fase beta, pero el equipo de Sensei lo está supervisando para que se convierta en una plataforma soportada oficialmente para ejecutar las reglas de Sensei como parte de la Integración Continua.
Resumen
Las Acciones de Intención nos permiten reforzar los patrones de codificación y corregirlos rápidamente en el IDE cuando cometemos errores durante la codificación.
Los Perfiles de Inspección nos permiten reunirlos en perfiles que pueden ejecutarse por lotes como una acción de Análisis e Inspección de Código. Esto puede ser útil si encontramos un patrón y queremos volver a comprobar si lo hemos pasado por alto en alguna otra parte de nuestro código.
Los Perfiles de Inspección pueden ejecutarse desde la línea de comandos e incluso incorporarse a los procesos de Integración Continua apoyando un modelo de "confiar, pero verificar" y detectar cualquier desviación accidental.
Todo lo anterior está incorporado en la funcionalidad de IntelliJ y JetBrains está mejorando su proceso de Integración Continua con la introducción de Qodana.
Sensei recetas se cargan en IntelliJ para actuar como Acciones de Intención nativas y ser recogidas en Perfiles de Inspección para soportar la comprobación por lotes a través de Inspect Code y el soporte de Integración Continua proporcionado por la funcionalidad oficial de ejecución de Línea de Comandos de JetBrains.
---
Puede instalar Sensei desde IntelliJ usando "Preferences \ Plugins" (Mac) o "Settings \ Plugins" (Windows) y luego sólo busque "sensei secure code".
Si quieres probar a ejecutar un proyecto en IntelliJ desde la línea de comandos, el proyecto utilizado en este post se puede encontrar en el repositorio `sensei-blog-examples` en la cuenta de GitHub de Secure Code Warrior . Un ejercicio para el lector es crear un perfil que ejecute sólo las reglas de Sensei . Pruébalo:
https://github.com/securecodewarrior/sensei-blog-examples
Ejecución de inspecciones de IntelliJ desde la integración continua
IntelliJ IDEA ofrece funcionalidad para ayudar a mejorar nuestra codificación, dentro del IDE al escribir código como Intenciones. Las Intenciones pueden ser usadas en lote para inspeccionar el código en busca de patrones a lo largo de la fuente e incluso extenderse al análisis de la Línea de Comandos o añadirse a la Integración Continua. Este post cubre la funcionalidad fuera de la caja de IntelliJ y la expansión con Intenciones personalizadas creadas en Sensei.
Inspecciones de IntelliJ
La función de Inspecciones de IntelliJ impulsa la visualización de muchos de los errores que se informan dinámicamente en el IDE cuando se codifica, por ejemplo
- detectar las clases abstractas que pueden convertirse en interfaces,
- identificar los campos de clase redundantes que pueden ser locales,
- advertencia sobre el uso de métodos obsoletos,
- etc.
Estas inspecciones resaltan el código que coincide en el IDE como Acciones de Intención que a menudo tienen un QuickFix asociado.
El resaltado del IDE en tiempo real cuando el código coincide con una Inspección puede ayudarnos a mejorar nuestra codificación de forma dinámica. Después de identificar el problema en el código, el uso de IntelliJ Intention Actions para QuickFix el código puede reforzar mejores patrones.
Perfil de las inspecciones
Las inspecciones pueden ejecutarse por lotes desde el IDE, y desde la línea de comandos o en un proceso de integración continua.
La clave para trabajar con las inspecciones de IntelliJ como un lote es mediante el uso de un Perfil de Inspección.
IntelliJ tiene dos perfiles de inspección por defecto: uno almacenado en el proyecto, y otro almacenado en el IDE.
Se pueden crear nuevos perfiles de inspección para configurar plugins o casos de uso específicos, por ejemplo
- Ejecutar sólo el escaneo en tiempo real de Checkstyle
- Ejecutar un conjunto específico de reglas de Sensei
- Ejecutar las comprobaciones de HTML
Las inspecciones de un perfil pueden activarse o desactivarse desde las Preferencias de IntelliJ. El cuadro de diálogo de Preferencias es también una forma sencilla de conocer la gama de Inspecciones disponibles.
El icono de la "herramienta" le permite duplicar un perfil y crear un nuevo perfil para recoger un conjunto específico de reglas.
Ejecución de un perfil de inspección en el IDE
Los Perfiles de Inspección pueden ser ejecutados desde el IDE usando el menú `Analizar | Inspeccionar Código...`.
La función de análisis le permite controlar el ámbito en el que se ejecutará la inspección, por ejemplo, todo el proyecto, incluyendo o excluyendo los orígenes de las pruebas, o un conjunto específico de archivos.
También puede gestionar los perfiles de inspección desde aquí para crear o configurar un perfil concreto.
Al hacer clic en [Aceptar] en el cuadro de diálogo "Especificar ámbito de inspección", IntelliJ ejecutará todas las inspecciones seleccionadas en el perfil en el ámbito definido.
IntelliJ informará de los resultados de la ejecución de las inspecciones en la pestaña `Resultados de la inspección`.
El plugin Sensei de Secure Code Warrior le permite crear recetas personalizadas de coincidencia de código. Sensei se integra estrechamente con IntelliJ para hacer que estas recetas personalizadas sean tan naturales de usar como las Acciones de Intención de IntelliJ. Esto significa que se cargan en IntelliJ como inspecciones y pueden agruparse, activarse y desactivarse utilizando perfiles de inspección. La creación de un perfil de inspección personalizado y el uso de la función de análisis del código de inspección es la forma recomendada de ejecutar las recetas de Sensei de forma masiva en un proyecto.
Ejecución de un perfil de inspección desde la línea de comandos
IntelliJ tiene la capacidad de ejecutar inspecciones desde la línea de comandos, tal y como documenta JetBrains:
- https://www.jetbrains.com/help/idea/working-with-the-ide-features-from-command-line.html
Yo uso principalmente macOS, y puedo ejecutar una sola instancia de IntelliJ desde la línea de comandos con:
open -na "IntelliJ IDEA CE.app"
Para facilitar la ejecución, añado esto a un script de comandos del shell.
vi /usr/local/bin/idea
El contenido del script proviene de la documentación oficial proporcionada por IntelliJ.
#!/bin/sh
open -na "IntelliJ IDEA CE.app" --args "$@"
Luego hice este ejecutable para permitirme simplificar el proceso de inspección de la línea de comandos.
chmod 755 /usr/local/bin/idea
La documentación oficial de intellij describe la forma general del comando de inspección como
idea inspect <project> <inspection-profile> <output></output></inspection-profile></project>
[<options>]</options>
En la práctica, califico completamente las rutas y no necesito ninguna opción:
idea inspect /Users/user/GitHub/sensei-blog-examples /Users/user/GitHub/sensei-blog-examples/.idea/inspectionProfiles/senseiprofile.xml /Users/user/GitHub/sensei-blog-examples/scan-results
Esto ejecuta todas las inspecciones que agregué al `senseiprofile` y reporta los resultados en la carpeta `scan-results`.
Visualización de los resultados de la inspección
Podemos informar de estos resultados desde la integración continua, como veremos más adelante.
También podemos verlos dentro del propio IntelliJ utilizando la función `Analyse \ View Offline Inspection Results...`.
Esto cargará los resultados en la pestaña "Resultados de la inspección".
Esto está oficialmente documentado en el sitio de JetBrains:
- https://www.jetbrains.com/help/idea/command-line-code-inspector.html#inspection-results
Esto podría utilizarse durante un proceso de revisión de código si la ejecución de la línea de comandos se incorporara a un proceso de Integración Continua y los revisores quisieran comprobar el contexto de origen completo de cualquiera de las entradas de resultados de la Inspección.
Perfiles de inspección en la integración continua
Al añadir la inspección de la línea de comandos en la integración continua, lo ideal es que queramos que se genere un informe de forma automática y hay varias opciones abiertas para nosotros.
TeamCity ofrece soporte inmediato para los perfiles de inspección en la integración continua.
- https://www.jetbrains.com/help/teamcity/inspections.html
El plugin Jenkins Warnings NG soporta la salida de línea de comandos de IntelliJ Inspections como uno de los formatos de informe.
- https://github.com/jenkinsci/warnings-ng-plugin
- https://github.com/jenkinsci/warnings-ng-plugin/blob/master/SUPPORTED-FORMATS.md
Existen proyectos comunitarios como `idea CLI Inspector` para apoyar el uso de los Perfiles de Inspección en otras herramientas de CI, por ejemplo
- https://github.com/bentolor/idea-cli-inspector
El futuro de los Perfiles de Inspección en un proceso de CI parece aún más brillante con la introducción del proyecto JetBrains Qodana. El proyecto Qodana es una versión sin cabeza de IntelliJ con acciones oficiales de Github e imágenes Docker.
- https://github.com/JetBrains/Qodana
Qodana se encuentra actualmente en fase beta, pero el equipo de Sensei lo está supervisando para que se convierta en una plataforma soportada oficialmente para ejecutar las reglas de Sensei como parte de la Integración Continua.
Resumen
Las Acciones de Intención nos permiten reforzar los patrones de codificación y corregirlos rápidamente en el IDE cuando cometemos errores durante la codificación.
Los Perfiles de Inspección nos permiten reunirlos en perfiles que pueden ejecutarse por lotes como una acción de Análisis e Inspección de Código. Esto puede ser útil si encontramos un patrón y queremos volver a comprobar si lo hemos pasado por alto en alguna otra parte de nuestro código.
Los Perfiles de Inspección pueden ejecutarse desde la línea de comandos e incluso incorporarse a los procesos de Integración Continua apoyando un modelo de "confiar, pero verificar" y detectar cualquier desviación accidental.
Todo lo anterior está incorporado en la funcionalidad de IntelliJ y JetBrains está mejorando su proceso de Integración Continua con la introducción de Qodana.
Sensei recetas se cargan en IntelliJ para actuar como Acciones de Intención nativas y ser recogidas en Perfiles de Inspección para soportar la comprobación por lotes a través de Inspect Code y el soporte de Integración Continua proporcionado por la funcionalidad oficial de ejecución de Línea de Comandos de JetBrains.
---
Puede instalar Sensei desde IntelliJ usando "Preferences \ Plugins" (Mac) o "Settings \ Plugins" (Windows) y luego sólo busque "sensei secure code".
Si quieres probar a ejecutar un proyecto en IntelliJ desde la línea de comandos, el proyecto utilizado en este post se puede encontrar en el repositorio `sensei-blog-examples` en la cuenta de GitHub de Secure Code Warrior . Un ejercicio para el lector es crear un perfil que ejecute sólo las reglas de Sensei . Pruébalo:
https://github.com/securecodewarrior/sensei-blog-examples
Haga clic en el siguiente enlace y descargue el PDF de este recurso.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Ver el informeReservar una demostración
Alan Richardson cuenta con más de veinte años de experiencia profesional en TI, trabajando como desarrollador y en todos los niveles de la jerarquía de pruebas, desde probador hasta jefe de pruebas. Jefe de Relaciones con los Desarrolladores en Secure Code Warrior, trabaja directamente con los equipos, para mejorar el desarrollo de un código seguro de calidad. Alan es autor de cuatro libros, entre ellos "Dear Evil Tester" y "Java For Testers". Alan también ha creado una formación en línea courses para ayudar a la gente a aprender las pruebas técnicas de la web y Selenium WebDriver con Java. Alan publica sus escritos y vídeos de formación en SeleniumSimplified.com, EvilTester.com, JavaForTesters.com, y CompendiumDev.co.uk.
Ejecución de inspecciones de IntelliJ desde la integración continua
IntelliJ IDEA ofrece funcionalidad para ayudar a mejorar nuestra codificación, dentro del IDE al escribir código como Intenciones. Las Intenciones pueden ser usadas en lote para inspeccionar el código en busca de patrones a lo largo de la fuente e incluso extenderse al análisis de la Línea de Comandos o añadirse a la Integración Continua. Este post cubre la funcionalidad fuera de la caja de IntelliJ y la expansión con Intenciones personalizadas creadas en Sensei.
Inspecciones de IntelliJ
La función de Inspecciones de IntelliJ impulsa la visualización de muchos de los errores que se informan dinámicamente en el IDE cuando se codifica, por ejemplo
- detectar las clases abstractas que pueden convertirse en interfaces,
- identificar los campos de clase redundantes que pueden ser locales,
- advertencia sobre el uso de métodos obsoletos,
- etc.
Estas inspecciones resaltan el código que coincide en el IDE como Acciones de Intención que a menudo tienen un QuickFix asociado.
El resaltado del IDE en tiempo real cuando el código coincide con una Inspección puede ayudarnos a mejorar nuestra codificación de forma dinámica. Después de identificar el problema en el código, el uso de IntelliJ Intention Actions para QuickFix el código puede reforzar mejores patrones.
Perfil de las inspecciones
Las inspecciones pueden ejecutarse por lotes desde el IDE, y desde la línea de comandos o en un proceso de integración continua.
La clave para trabajar con las inspecciones de IntelliJ como un lote es mediante el uso de un Perfil de Inspección.
IntelliJ tiene dos perfiles de inspección por defecto: uno almacenado en el proyecto, y otro almacenado en el IDE.
Se pueden crear nuevos perfiles de inspección para configurar plugins o casos de uso específicos, por ejemplo
- Ejecutar sólo el escaneo en tiempo real de Checkstyle
- Ejecutar un conjunto específico de reglas de Sensei
- Ejecutar las comprobaciones de HTML
Las inspecciones de un perfil pueden activarse o desactivarse desde las Preferencias de IntelliJ. El cuadro de diálogo de Preferencias es también una forma sencilla de conocer la gama de Inspecciones disponibles.
El icono de la "herramienta" le permite duplicar un perfil y crear un nuevo perfil para recoger un conjunto específico de reglas.
Ejecución de un perfil de inspección en el IDE
Los Perfiles de Inspección pueden ser ejecutados desde el IDE usando el menú `Analizar | Inspeccionar Código...`.
La función de análisis le permite controlar el ámbito en el que se ejecutará la inspección, por ejemplo, todo el proyecto, incluyendo o excluyendo los orígenes de las pruebas, o un conjunto específico de archivos.
También puede gestionar los perfiles de inspección desde aquí para crear o configurar un perfil concreto.
Al hacer clic en [Aceptar] en el cuadro de diálogo "Especificar ámbito de inspección", IntelliJ ejecutará todas las inspecciones seleccionadas en el perfil en el ámbito definido.
IntelliJ informará de los resultados de la ejecución de las inspecciones en la pestaña `Resultados de la inspección`.
El plugin Sensei de Secure Code Warrior le permite crear recetas personalizadas de coincidencia de código. Sensei se integra estrechamente con IntelliJ para hacer que estas recetas personalizadas sean tan naturales de usar como las Acciones de Intención de IntelliJ. Esto significa que se cargan en IntelliJ como inspecciones y pueden agruparse, activarse y desactivarse utilizando perfiles de inspección. La creación de un perfil de inspección personalizado y el uso de la función de análisis del código de inspección es la forma recomendada de ejecutar las recetas de Sensei de forma masiva en un proyecto.
Ejecución de un perfil de inspección desde la línea de comandos
IntelliJ tiene la capacidad de ejecutar inspecciones desde la línea de comandos, tal y como documenta JetBrains:
- https://www.jetbrains.com/help/idea/working-with-the-ide-features-from-command-line.html
Yo uso principalmente macOS, y puedo ejecutar una sola instancia de IntelliJ desde la línea de comandos con:
open -na "IntelliJ IDEA CE.app"
Para facilitar la ejecución, añado esto a un script de comandos del shell.
vi /usr/local/bin/idea
El contenido del script proviene de la documentación oficial proporcionada por IntelliJ.
#!/bin/sh
open -na "IntelliJ IDEA CE.app" --args "$@"
Luego hice este ejecutable para permitirme simplificar el proceso de inspección de la línea de comandos.
chmod 755 /usr/local/bin/idea
La documentación oficial de intellij describe la forma general del comando de inspección como
idea inspect <project> <inspection-profile> <output></output></inspection-profile></project>
[<options>]</options>
En la práctica, califico completamente las rutas y no necesito ninguna opción:
idea inspect /Users/user/GitHub/sensei-blog-examples /Users/user/GitHub/sensei-blog-examples/.idea/inspectionProfiles/senseiprofile.xml /Users/user/GitHub/sensei-blog-examples/scan-results
Esto ejecuta todas las inspecciones que agregué al `senseiprofile` y reporta los resultados en la carpeta `scan-results`.
Visualización de los resultados de la inspección
Podemos informar de estos resultados desde la integración continua, como veremos más adelante.
También podemos verlos dentro del propio IntelliJ utilizando la función `Analyse \ View Offline Inspection Results...`.
Esto cargará los resultados en la pestaña "Resultados de la inspección".
Esto está oficialmente documentado en el sitio de JetBrains:
- https://www.jetbrains.com/help/idea/command-line-code-inspector.html#inspection-results
Esto podría utilizarse durante un proceso de revisión de código si la ejecución de la línea de comandos se incorporara a un proceso de Integración Continua y los revisores quisieran comprobar el contexto de origen completo de cualquiera de las entradas de resultados de la Inspección.
Perfiles de inspección en la integración continua
Al añadir la inspección de la línea de comandos en la integración continua, lo ideal es que queramos que se genere un informe de forma automática y hay varias opciones abiertas para nosotros.
TeamCity ofrece soporte inmediato para los perfiles de inspección en la integración continua.
- https://www.jetbrains.com/help/teamcity/inspections.html
El plugin Jenkins Warnings NG soporta la salida de línea de comandos de IntelliJ Inspections como uno de los formatos de informe.
- https://github.com/jenkinsci/warnings-ng-plugin
- https://github.com/jenkinsci/warnings-ng-plugin/blob/master/SUPPORTED-FORMATS.md
Existen proyectos comunitarios como `idea CLI Inspector` para apoyar el uso de los Perfiles de Inspección en otras herramientas de CI, por ejemplo
- https://github.com/bentolor/idea-cli-inspector
El futuro de los Perfiles de Inspección en un proceso de CI parece aún más brillante con la introducción del proyecto JetBrains Qodana. El proyecto Qodana es una versión sin cabeza de IntelliJ con acciones oficiales de Github e imágenes Docker.
- https://github.com/JetBrains/Qodana
Qodana se encuentra actualmente en fase beta, pero el equipo de Sensei lo está supervisando para que se convierta en una plataforma soportada oficialmente para ejecutar las reglas de Sensei como parte de la Integración Continua.
Resumen
Las Acciones de Intención nos permiten reforzar los patrones de codificación y corregirlos rápidamente en el IDE cuando cometemos errores durante la codificación.
Los Perfiles de Inspección nos permiten reunirlos en perfiles que pueden ejecutarse por lotes como una acción de Análisis e Inspección de Código. Esto puede ser útil si encontramos un patrón y queremos volver a comprobar si lo hemos pasado por alto en alguna otra parte de nuestro código.
Los Perfiles de Inspección pueden ejecutarse desde la línea de comandos e incluso incorporarse a los procesos de Integración Continua apoyando un modelo de "confiar, pero verificar" y detectar cualquier desviación accidental.
Todo lo anterior está incorporado en la funcionalidad de IntelliJ y JetBrains está mejorando su proceso de Integración Continua con la introducción de Qodana.
Sensei recetas se cargan en IntelliJ para actuar como Acciones de Intención nativas y ser recogidas en Perfiles de Inspección para soportar la comprobación por lotes a través de Inspect Code y el soporte de Integración Continua proporcionado por la funcionalidad oficial de ejecución de Línea de Comandos de JetBrains.
---
Puede instalar Sensei desde IntelliJ usando "Preferences \ Plugins" (Mac) o "Settings \ Plugins" (Windows) y luego sólo busque "sensei secure code".
Si quieres probar a ejecutar un proyecto en IntelliJ desde la línea de comandos, el proyecto utilizado en este post se puede encontrar en el repositorio `sensei-blog-examples` en la cuenta de GitHub de Secure Code Warrior . Un ejercicio para el lector es crear un perfil que ejecute sólo las reglas de Sensei . Pruébalo:
https://github.com/securecodewarrior/sensei-blog-examples
Índice
Alan Richardson cuenta con más de veinte años de experiencia profesional en TI, trabajando como desarrollador y en todos los niveles de la jerarquía de pruebas, desde probador hasta jefe de pruebas. Jefe de Relaciones con los Desarrolladores en Secure Code Warrior, trabaja directamente con los equipos, para mejorar el desarrollo de un código seguro de calidad. Alan es autor de cuatro libros, entre ellos "Dear Evil Tester" y "Java For Testers". Alan también ha creado una formación en línea courses para ayudar a la gente a aprender las pruebas técnicas de la web y Selenium WebDriver con Java. Alan publica sus escritos y vídeos de formación en SeleniumSimplified.com, EvilTester.com, JavaForTesters.com, y CompendiumDev.co.uk.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostraciónDescargarRecursos para empezar
Evaluación comparativa de las competencias en materia de seguridad: optimización del diseño seguro en la empresa
El movimiento Secure-by-Design es el futuro del desarrollo de software seguro. Conozca los elementos clave que las empresas deben tener en cuenta cuando piensan en una iniciativa Secure-by-Design.
DigitalOcean reduce su deuda de seguridad con Secure Code Warrior
El uso por parte de DigitalOcean de la formación Secure Code Warrior ha reducido significativamente la deuda de seguridad, permitiendo a los equipos centrarse más en la innovación y la productividad. La mejora de la seguridad ha reforzado la calidad de sus productos y su ventaja competitiva. De cara al futuro, SCW Trust Score les ayudará a seguir mejorando las prácticas de seguridad y a continuar impulsando la innovación.
Recursos para empezar
La puntuación de confianza revela el valor de las iniciativas de mejora de la seguridad mediante el diseño
Nuestra investigación ha demostrado que la formación en código seguro funciona. Trust Score, que utiliza un algoritmo basado en más de 20 millones de puntos de datos de aprendizaje procedentes del trabajo de más de 250 000 alumnos en más de 600 organizaciones, revela su eficacia a la hora de reducir las vulnerabilidades y cómo hacer que la iniciativa sea aún más eficaz.
.png)
Seguridad reactiva frente a seguridad preventiva: Prevenir es mejor que curar
La idea de introducir la seguridad preventiva en el código y los sistemas heredados al mismo tiempo que en las aplicaciones más recientes puede parecer desalentadora, pero un planteamiento basado en el diseño seguro, aplicado mediante la mejora de las competencias de los desarrolladores, puede aplicar las mejores prácticas de seguridad a esos sistemas. Es la mejor oportunidad que tienen muchas organizaciones de mejorar su seguridad.
Ventajas de la evaluación comparativa de las competencias de seguridad de los desarrolladores
La creciente atención que se presta al código seguro y a los principios del diseño seguro exige que los desarrolladores reciban formación en ciberseguridad desde el principio del proceso de desarrollo de software, con herramientas como Secure Code Warrior's Trust Score, que ayudan a medir y mejorar sus progresos.
Impulsando iniciativas de seguridad por diseño para empresas con éxito significativo
Nuestro último documento de investigación, Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise, es el resultado de un análisis profundo de iniciativas reales de Secure-by-Design a nivel empresarial y de la derivación de enfoques de mejores prácticas basados en hallazgos basados en datos.
Codificación orientada al desarrollador.
Con seguridad.
Póngase en contacto con nosotros hoy mismo y haga de la seguridad del software una parte intrínseca de su proceso de desarrollo.
