blockchain-client
title: Proceso de lanzamiento de Celo Blockchain Client description: Detalles del proceso de lanzamiento para actualizar el cliente blockchain en la plataforma Celo.
Proceso de Lanzamiento de Cliente Blockchain
Detalles del proceso de lanzamiento para actualizar el cliente blockchain en la plataforma Celo.
Versionamiento
Las versiones de celo-blockchain se numeran según la versión semántica, como se describe en semver.org.
Se pueden esperar nuevas versiones de celo-blockchain de la siguiente manera:
- Versiones mayores: aproximadamente una vez al año
- Versiones menores: aproximadamente 4 veces al año
- Versiones de parche: según sea necesario
Todas las compilaciones se identifican como inestable (una compilación de desarrollo) o estable (una compilación publicada con un número de versión concreto). Sólo debe existir una confirmación con una versión x.y.z-estable para cualquier (x, y, z).
Firmas
Los artefactos producidos por este proceso de compilación (por ejemplo, etiquetas, binarios, imágenes Docker) serán firmados. Las firmas se producen utilizando cualquiera de las claves de desarrollador principales que se indican a continuación.
Las claves públicas para los desarrolladores del núcleo están alojadas en celo.org y pueden importarse a gpg con el siguiente comando:
gpg --auto-key-locate wkd --locate-keys $EMAIL
Las claves de desarrollo del núcleo actualmente alojadas incluyen:
Documentación
La documentación de las características del cliente, como APIs y comandos, se mantienen en el directorio docs dentro del repositorio celo-blockchain. La documentación sobre las características del protocolo, como el protocolo proof-of-stake, se encuentra en docs.celo.org.
Identificando lanzamientos:
Ramas de Git
Cada versión menor de celo-blockchain tiene su propia "rama de lanzamiento", por ejemplo release/1.0.
El desarrollo se realiza en la rama master, que corresponde a la siguiente versión mayor o menor. Los cambios que se incluyan en una versión de parche de una versión menor existente se incorporan a esa rama de la versión existente.
Etiquetas de Git
Todas las versiones deben etiquetarse con el número de versión, por ejemplo vX.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 estar firmadas y pueden verificarse con el siguiente comando.
git verify-tag vX.Y.Z
En Github, cada etiqueta de lanzamiento debería tener adjuntos los binarios de Geth para las plataformas soportadas, junto con las firmas que se pueden utilizar para verificar el binario y las imágenes Docker.
Etiquetas Docker
Cada imagen Docker publicada debe ser etiquetada con su número de versión de tal manera que para la versión x.y.z, la imagen debe tener las etiquetas x, x.y, y x.y.z, con las dos primeras etiquetas potencialmente movidas de una imagen anterior. Al igual que una etiqueta Git x.y.z apunta inmutablemente a un hash de commit, la etiqueta Docker, x.y.z debería apuntar inmutablemente a un hash de imagen.
Proceso de construcción
Binarios
Los binarios para plataformas comunes se construyen automáticamente con Google Cloud Build después de empujar al maestro y todas las ramas de lanzamiento.
Debe producirse una firma sobre el binario construido automáticamente en el hash de confirmación correspondiente e incluirse en la publicación de Github.
Las firmas binarias de liberación pueden verificarse con el siguiente comando:
gpg --verify celo-blockchain-vX.Y.Z-stable.tar.gz.asc celo-blockchain-vX.Y.Z-stable.tar.gz
Imágenes de Docker
Las imágenes Docker se crean automáticamente con Google Cloud Build cuando se envían a master y a todas las ramas de publicación. Las compilaciones automatizadas se etiquetarán en Google Container Registry con el hash de confirmación correspondiente.
Debe producirse una firma sobre la imagen construida automáticamente en el hash de confirmación correspondiente e incluirse con la publicación en Github.
Las firmas de las imágenes de lanzamiento pueden verificarse con el siguiente comando:
docker save $(docker image inspect us.gcr.io/celo-org/geth:X.Y.Z -f '{{ .Id }}') | gpg --verify celo-blockchain-vX.Y.Z.docker.asc -
Probando
Todas las compilaciones de celo-blockchain se prueban automáticamente en CI para comprobar el rendimiento y la compatibilidad con versiones anteriores. Cualquier regresión en estas pruebas debe considerarse un bloqueo para una versión.
Se espera que las versiones menores y mayores pasen por rondas adicionales de pruebas manuales según sea necesario para verificar el comportamiento en condiciones de estrés, como una red con nodos defectuosos y una conectividad de red deficiente.
Proceso de promoción
Control de las fuentes
Las versiones de parche deben construirse seleccionando todos los commits incluidos de master a la rama release/x.y. El primer commit de este proceso debería cambiar el número de versión codificado en el código fuente de x.y.z-stable a x. .z+1-inestable y el commit final debería cambiar el número de versión a x.y.z+1-stable.
Las versiones mayores y menores deben construirse enviando un commit a la rama master para cambiar el número de versión codificado de x.y.z-unstable a x.y.z-stable. Se debe crear una rama release/x.y a partir de este commit. El siguiente commit debe cambiar el número de versión de x.y.z-stable a x.y+1. -unstable, o x+1.0.0-inestable si la próxima versión prevista es una versión mayor.
Sólo un commit debería tener la etiqueta "estable" en cualquier número de versión. Cuando se cree ese commit, se añadirá una etiqueta junto con las notas de la versión. Una vez publicada la etiqueta, no debe reutilizarse para ninguna otra publicación o modificación.
Distribución
La distribución de una imagen debe producirse según el siguiente calendario:
| Fecha | Acción |
| T |
|
| T+1w |
|
| T+2w |
|
| T+3w |
|
Parches de emergencia
Los fallos que afectan a la seguridad, la estabilidad o la funcionalidad básica de la red pueden tener que publicarse fuera del ciclo de publicación estándar. En este caso, debe crearse una versión de parche de emergencia sobre todas las versiones menores compatibles que contenga el cambio mínimo y la prueba correspondiente para la corrección.
If the issue is not exploitable, release notes should describe the issue in detail and the image should be distributed publicly.
Si el problema es explotable y no se dispone de medidas de mitigación, debe prepararse un parche de forma privada y deben distribuirse binarios firmados a partir de commits privados. Establecer la confianza es clave para sacar adelante el arreglo. Se puede contratar una auditoría de un tercero acreditado para verificar la liberación y ayudar a ganarse esa confianza. Once a majority of validators updated, patch details can be made public.
Empujar una actualización con este proceso será perjudicial para cualquier nodo que no se actualice rápidamente. Debe utilizarse sólo cuando las circunstancias lo requieran.
Revelación de vulnerabilidades
Las vulnerabilidades en las versiones de celo-blockchain deben revelarse de acuerdo con la política de seguridad.
Dependencias
Ninguna
Dependientes
Ninguno