Ir al contenido principal

Proceso de liberación de Celo Oracles

Detalles del proceso de actualización de los Oráculos Celo para el Protocolo de Estabilidad Mento.

Versionamiento

Las liberaciones se efectúan en función de las necesidades. Las versiones se numeran según el versionado semántico, tal como se describe en semver.org.

Las compilaciones de desarrollo deben identificarse con un sufijo -dev, y sólo debe existir un commit con una versión liberada x.y.z para cualquier (x, y, z). Las versiones candidatas deben identificarse con un sufijo -rCX, donde X es la versión de la versión candidata.

Documentación​

La documentación se mantiene en el repositorio celo-org/docs y está alojada en docs.celo.org.

Identificando lanzamientos​

Ramas de Git​

El código para el cliente se almacena en el repositorio Celo Oracles GitHub. El desarrollo se realiza en la rama main, que corresponde a la siguiente versión mayor o menor.

Etiquetas de Git​

Cada versión debe crearse en Github y etiquetarse con el número de versión, por ejemplo X.Y.Z. Cada versión debe incluir un resumen de su contenido, con enlaces a pull requests e incidencias y una descripción detallada de los cambios más destacados. Las etiquetas deben ser etiquetas anotadas.

Las etiquetas deben estar firmadas y pueden verificarse con el siguiente comando.

git verify-tag vX.Y.Z

En Github, cada etiqueta de lanzamiento debe tener firmas adjuntas que se pueden utilizar para verificar las imágenes Docker.

Etiquetas Docker​

Las imágenes Docker se almacenan en el repositorio us-west1-docker.pkg.dev/celo-testnet-production/celo-oracle, almacenado en Google Cloud Platform Artifact Registry. Los commits se etiquetan con celo-oracle-X.Y.Z y celo-oracle-<commithash>. Al igual que una etiqueta Git apunta inmutablemente a un hash de commit, la etiqueta Docker debería apuntar inmutablemente a un hash de imagen.

Probando​

Además de las pruebas automatizadas de CI, se espera que todas las versiones se sometan a pruebas manuales según sea necesario para verificar las propiedades de seguridad, la exactitud de la documentación y la compatibilidad con la configuración de producción actual de los operadores de nodos.

Proceso de promoción​

Los cambios de rama seleccionados se añadirán a una rama protegida releases. Al fusionar código a esta rama, el número de versión debe actualizarse en consecuencia.

Control de las fuentes​

Distribución​

FechaAcción
T-1w
  1. Despliegue de la versión candidata en la red de pruebas de Alfajores
  2. Supervisar las métricas y el comportamiento
T
  1. Etiquetar la versión y publicar la imagen Docker como se describe en este documento
  2. Informar a la comunidad de la nueva versión a través de Discord y el Foro Celo
T+1w en adelante
  1. Confirme que los servicios de Mainnet se han actualizado sin problemas
  2. Seguir supervisando los cuadros de mando para detectar problemas de los usuarios

Parches de emergencia​

Las correcciones de seguridad o hotfixes pueden no llevar asociado un commit público en caso de que sea necesario parchear la vulnerabilidad antes de divulgarla al público en general para evitar que un atacante explote una vulnerabilidad antes de que los operadores parcheen sus servicios. Los parches de emergencia se distribuirán utilizando el mismo método descrito en Etiquetas Git

Revelación de vulnerabilidades​

Las vulnerabilidades en los Oráculos Celo deben ser reveladas de acuerdo con la política de seguridad.