Un política es un conjunto de puertas de calidad con nombre y versión. Las políticas son las que se asocian a los proyectos; las puertas son las que realmente se ejecutan.
Para entender los conceptos: bloqueantes frente a informativos, y dónde se ubican las puertas en una ejecución, lee Puertas de calidad primero. Esta página trata sobre cómo gestionarlas.
Gestiona las políticas en Control de Calidad. Su panel muestra la configuración predeterminada de la organización y todas las del proyecto. Selecciona una para ver cómo se filtra 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 aplica al activarlo. 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 informa.
La mayoría de las organizaciones necesitan dos o tres políticas, no una por proyecto:
- una estricta política para los servicios de producción
- una estándar política para todo lo habitual
- y ocasionalmente una ligera política para herramientas internas y prototipos
Si hay más, nadie recordará cuál política corresponde a cada proyecto.
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 se modifique alguno de sus interruptores. Esa modificación le otorga 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 esta, y nada cambia para el proyecto hasta que se publique esa copia.
Configura la predeterminada como tu estándar comprobaciones, las que la mayoría de los proyectos deben ejecutar, no las más estrictas: estas últimas deben seleccionarse deliberadamente, proyecto por proyecto.
Solicitudes de extracción
Las solicitudes de extracción que abren personas y otras herramientas 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, tanto para la configuración predeterminada de la organización como para cada proyecto:
- Control de Calidad de Coroid ejecuta las comprobaciones anteriores en cada pull request y reporta el resultado como la comprobación de Control de Calidad de Coroid en GitHub.
- Revisión de Coroid hace que el revisor de Coroid lea cada pull request y comente las líneas que cuestione. Lee las solicitudes de extracción que el Control de Calidad de Coroid comprueba.
Configuración de la Revisión de Coroid:
- Qué publica. El modo informativo, el predeterminado, comenta pero nunca falla su comprobación. Al activar el modo bloqueante, la comprobación falla cuando encuentra un problema. Haz que la Revisión de Coroid 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, ya que el revisor de Coroid ya las revisó 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; por defecto, cinco minutos. Un envío más reciente reemplaza una revisión que aún no haya comenzado. Al volver a ejecutar en GitHub, se 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 reglas de tu repositorio en la carpeta
review-rules . 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 todos los proyectos. Cada interruptor ejecuta una automatización, listada en Fábrica bajo Automatizaciones; el agente lee el código y abre una tarea, y esta sigue el mismo proceso de 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 | Determina la causa y, si está en el código, abre una tarea para corregirla |
| 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 registre qué se revirtió, por qué y qué debe cambiar antes de volver a lanzarla |
Al desactivar una automatización se pausa su ejecución; al volver a activarla se reanuda. Cada cambio permite deshacerlo. La página de la automatización en la Fábrica indica que está gestionada por el Control de Calidad. Pausarla allí equivale a desactivarla; al modificar sus instrucciones y confirmarlo, pasará a ser propia y el interruptor ya no la activará ni desactivará.
Estos eran plantillas en Nuevo trabajo. Una automatización creada a partir de alguna de ellas sigue ejecutándose. Si nunca la modificaste, al activar el interruptor correspondiente la tomará el control en lugar de iniciar una segunda instancia. Si sí la modificaste, seguirá siendo tuya: el interruptor la nombra y puedes adoptarla para que él la gestione.
Despliegue seguro
El problema de las compuertas no es que sean demasiado débiles, sino que una compuerta bloqueante bien intencionada detiene todas las tareas de la organización a la vez.
Una secuencia segura:
- Añade la compuerta como recomendada.
- Déjala ejecutarse en trabajos reales durante una o dos semanas y revisa lo que detecte.
- Ajusta sus parámetros según lo aprendido.
- Promociona a bloqueante en un proyecto.
- Despliégala más ampliamente 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 controlada. Cada interruptor publica una nueva versión y su confirmación permite deshacer el cambio volviendo a la versión 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 cambios. 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 bloqueante puede ser sobreescrita por alguien con autoridad. La sobreescritura queda registrada: quién, cuándo y contra qué.
Controla tu tasa de sobrescrituras. Si una compuerta se sobreescribe cada vez que se activa, no está imponiendo ninguna regla: solo genera fricción y un rastro documental. Corrige la compuerta o elimínala.