Un política es un conjunto con nombre y versión de filtros de calidad. Las políticas son las que se asocian a los proyectos; los filtros son los que realmente se ejecutan.
Para conocer los conceptos — bloqueantes frente a consultivos, y dónde se ubican los filtros en una ejecución — lee Filtros de calidad primero. Esta página trata sobre cómo gestionarlos.
Gestiona ellos en Control de Calidad. Su panel muestra la configuración predeterminada de la organización y todas las del proyecto. Elige una para ver cómo se evalúa el trabajo nuevo, qué se comprueba en cada cambio, su nivel de control de calidad y dónde se ejecutan las comprobaciones; cada una tiene un interruptor que se activa al instante. La confirmación permite deshacer el cambio, y los ajustes de una fila modifican el funcionamiento de esa comprobación.
- Configuración predeterminada de la organización3 proyectos lo siguen2 de 5
- Tienda onlineConfiguración personalizada4 de 5
- Sitio de documentaciónSigue la configuración predeterminada2 de 5
- Facturación APISigue la configuración predeterminada2 de 5
- Aplicación móvilSigue la configuración predeterminada2 de 5
- Anti-slopDevuelve un cambio al equipo cuando debilita las pruebas, oculta errores, incluye marcadores de posición o genera deuda técnica.
- Pruebas unitariasLocaliza y ejecuta las pruebas unitarias del repositorio en cada modificación.
- Pruebas en navegador2 de 3difiere de la configuración predeterminadaEjecuta sus flujos de navegador contra la modificación realizada.
- Traduccionesdifiere de la configuración predeterminadaVerifica que las cadenas de texto modificadas estén traducidas y que sus marcadores de posición y formas plurales coincidan correctamente.
- Comprobaciones del repositorioEjecuta sus propios comandos, como formatado, comprobación de tamaño de archivos, migraciones, pruebas de integración y análisis de seguridad.
- Control de calidad exhaustivoThoroughEl control de calidad recopila pruebas y capturas de pantalla en tiempo real conforme a la Especificación. Si está desactivado, el proceso pasa a QA estándar.
Control de calidad: las políticas vigentes y la última ejecución de la compuerta. Datos ilustrativos.
Crear una política
Una política es un conjunto de comprobaciones más, para cada una, si el fallo bloquea o solo advierte.
La mayoría de las organizaciones necesitan dos o tres políticas, no una por proyecto:
- una estricta política para servicios de producción
- una estándar política para todo lo habitual
- ocasionalmente una ligera política para herramientas internas y prototipos
Más de eso y nadie recordará cuál proyecto usa cuál política.
La configuración predeterminada de la organización y la propia del proyecto
Un proyecto sigue la configuración predeterminada de la organización hasta que cambies alguno de sus interruptores. Ese cambio le otorga al proyecto su propia configuración, copiada de la predeterminada, y los cambios posteriores en la predeterminada ya no le afectarán. Una fila puede copiar una comprobación desde la predeterminada, y el menú del proyecto puede restablecer todo el proyecto a la configuración predeterminada de la organización. La política completa detrás de los interruptores, con expectativas, dependencias entre comprobaciones, presupuestos de reparación y versiones, se abre desde el mismo menú que el editor avanzado. Para un proyecto que sigue la predeterminada, el editor parte de una copia de ella, y nada cambia para el proyecto hasta que publiques esa copia.
Configura la predeterminada como tu estándar comprobaciones, las que la mayoría de los proyectos deben ejecutar, no la más estricta: esta última debe seleccionarse deliberadamente, proyecto por proyecto.
Solicitudes de extracción
Las solicitudes de extracción que personas y otras herramientas abren llegan a Coroid a través de la aplicación Coroid GitHub. El grupo Solicitudes de extracción en Control de Calidad decide qué hacer con ellas, para la configuración predeterminada de la organización y para cada proyecto:
- Coroid Control de Calidad ejecuta las comprobaciones anteriores en cada pull request y reporta el resultado como la comprobación de Coroid Control de Calidad en GitHub.
- Coroid Revisión hace que el revisor de Coroid lea cada pull request y comente las líneas que cuestione. Lee las solicitudes de extracción que Coroid Control de Calidad comprueba.
Configuraciones de Coroid Revisión:
- Lo que publica. La opción consultiva, la predeterminada, comenta y nunca falla su comprobación, con una excepción: un problema crítico o grave confirmado hace que falle cuando Seguridad exige revisión de seguridad (ver Análisis de código y revisión de seguridad). La opción de solicitudes bloqueantes cambia al detectar un problema y su comprobación falla. Haz que Coroid Revisión sea una comprobación obligatoria en GitHub si una revisión bloqueante debe impedir la fusión.
- Qué solicitudes de extracción. Por defecto espera a que un borrador se marque como listo, y omite las solicitudes de extracción abiertas por Coroid, porque el revisor de Coroid ya las evaluó dentro de la tarea. También puede omitir las solicitudes de extracción de bots.
- Cuándo realiza la revisión. Espera un período de inactividad después del último envío; cinco minutos por defecto. Un envío más reciente reemplaza una revisión que no haya comenzado. La opción Re-ejecutar en GitHub inicia una de inmediato.
- Profundidad de la revisión. Cuánto puede leer y escribir el revisor en una sola revisión.
Sigue las reglas de revisión de Coroid y las del archivo
review-rules de tu repositorio. Un proyecto que sigue la configuración predeterminada de la organización obtiene los ajustes de esta, al igual que cualquier otro control.
Cuando algo falla
Tres interruptores bajo la configuración predeterminada de la organización convierten los fallos en tareas de seguimiento para cada proyecto. Cada interruptor ejecuta una automatización, listada en Fábrica bajo Automatizaciones; el agente lee el código y abre una tarea, y esta pasa por la misma especificación, compilación, verificación y revisión que cualquier otra.
| Interruptor | Cuándo | Qué hace el agente |
|---|---|---|
| Cuando una tarea falla, abrir una tarea de corrección | Una tarea falla | Descubre la causa y, si está en el código, abre una tarea que la corrija |
| Cuando una implementación falla, investigar | Una implementación falla | Lee qué cambió en esa versión y abre una tarea que indique qué salió mal y qué modificar |
| Cuando se revierte una versión, planificar la corrección | Se revierte una versión | Abre una tarea que registra lo que se ha revertido, el motivo y qué debe cambiarse antes de volver a lanzarlo. |
Desactivar uno pausa su automatización; volver a activarlo la reanuda. Cualquier cambio permite deshacerlo. La página de la automatización en la Fábrica indica que está gestionada por Control de Calidad. Pausarla allí es lo mismo que desactivarla; modificar sus instrucciones la convierte en propia tras confirmarlo, y el interruptor ya no la activará ni desactivará.
Estas eran plantillas en Nuevo trabajo. Una automatización creada a partir de una de ellas sigue ejecutándose. Si nunca la modificaste, al activar el interruptor correspondiente la tomará el control en lugar de iniciar una segunda. Si la modificaste, seguirá siendo tuya: la fila del interruptor la nombra, y puedes adoptarla para que el interruptor la gestione.
Lanzamiento seguro
El problema de las compuertas no es que sean demasiado débiles, sino que una compuerta bloqueadora bien intencionada detiene todas las tareas de la organización a la vez.
Una secuencia segura:
- Añade la compuerta como recomendación.
- Déjala ejecutarse en trabajos reales durante una o dos semanas. Lee lo que detecte.
- Ajusta sus parámetros según lo aprendido.
- Promociona a bloqueadora en un proyecto.
- Despliega en más ámbitos una vez que funcione correctamente.
- 1Añadir la puertaAviso
- 2Supervisarla durante una o dos semanasAviso
- 3Ajustarla según lo que detecteAviso
- 4Bloquear en un proyectoBloqueanteUn proyecto
- 5Implementarla de forma más ampliaBloqueanteMás proyectos
Control de versiones y reversión
Las políticas tienen versión. Cada interruptor publica una nueva versión, y su confirmación permite deshacerla volviendo a la anterior; las versiones anteriores se pueden restaurar desde el historial de versiones del editor avanzado.
La reversión es la razón por la que puedes permitirte ser decidido al publicar. Si una nueva compuerta resulta estar mal configurada, revertirla es una acción sencilla en lugar de un proceso complejo de recuperación.
Sobrescrituras
Una compuerta bloqueadora puede ser sobreescrita por alguien con autoridad. La sobrescritura queda registrada: quién, cuándo y contra qué.
Controla tu tasa de sobrescrituras. Una compuerta que se sobrescribe la mayoría de las veces que se activa no está imponiendo nada; solo genera fricción y un rastro documental. O arregla la compuerta o elimínala.