Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Utilizar el control de versiones y lanzamiento para los constructos
Control de versiones para AWS CDK
AWS CDK Varios equipos pueden crear estructuras comunes y compartirlas en una organización para su consumo. Por lo general, los desarrolladores lanzan nuevas funciones o corrigen errores en sus AWS CDK construcciones comunes. Estas construcciones las utilizan las AWS CDK aplicaciones o cualquier otra AWS CDK construcción existente como parte de una dependencia. Por este motivo, es fundamental que los desarrolladores actualicen y publiquen su constructo con las versiones semánticas adecuadas de forma independiente. AWS CDK Las aplicaciones posteriores u otras AWS CDK construcciones pueden actualizar su dependencia para usar la versión de construcción publicada recientemente. AWS CDK
El control de versiones semántico (Semver) es un conjunto de reglas, o un método, para proporcionar números de software únicos al software del equipo. Las versiones se definen de la siguiente manera:
-
Una versión IMPORTANTE consiste en cambios de API incompatibles o cambios importantes.
-
Una versión MENOR consiste en una funcionalidad que se agrega de forma compatible con versiones anteriores.
-
Una versión REVISIÓN consiste en correcciones de errores compatibles con versiones anteriores.
Para obtener más información sobre el control de versiones semántico, consulte la Especificación del control de versiones semántico (SemVer) en la documentación sobre el control de versiones
AWS CDK Repositorio y empaquetado para construcciones
Como AWS CDK las construcciones las desarrollan equipos distintos y son utilizadas por varias AWS CDK aplicaciones, puede utilizar un repositorio independiente para cada AWS CDK construcción. Esto también puede ayudarlo a aplicar el control de acceso. Cada repositorio puede contener todo el código fuente relacionado con la misma AWS CDK construcción junto con todas sus dependencias. Al mantener una sola aplicación (es decir, una AWS CDK construcción) en un único repositorio, se puede reducir el alcance del impacto de los cambios durante la implementación.
AWS CDK No solo genera CloudFormation plantillas para implementar la infraestructura, sino que también agrupa activos en tiempo de ejecución, como funciones Lambda e imágenes de Docker, y los implementa junto con su infraestructura. No solo es posible combinar el código que define la infraestructura y el código que implementa la lógica de tiempo de ejecución en una sola construcción, sino que es una práctica recomendada. No es necesario que estos dos tipos de código se encuentren en repositorios separados o incluso en paquetes separados.
Para consumir paquetes más allá de los límites del repositorio, debes tener un repositorio de paquetes privado, similar a npm o Maven Central PyPi, pero interno en tu organización. También debe tener un proceso de publicación que compile, pruebe y publique el paquete en el repositorio de paquetes privado. Puede crear repositorios privados, como un PyPi servidor, mediante una máquina virtual (VM) local o Amazon S3. Al diseñar o crear un registro de paquetes privado, es fundamental tener en cuenta el riesgo de interrupción del servicio debido a la alta disponibilidad y escalabilidad. Un servicio gestionado sin servidor alojado en la nube para almacenar paquetes puede reducir considerablemente la sobrecarga de mantenimiento. Por ejemplo, se puede utilizar AWS CodeArtifactpara alojar paquetes para los lenguajes de programación más populares. También se puede utilizar CodeArtifact para establecer conexiones de repositorios externos y replicarlas en ellas CodeArtifact.
El administrador de paquetes de tu idioma (por ejemplo, npm for TypeScript o JavaScript applications) gestiona las dependencias de los paquetes del repositorio de paquetes. El administrador de paquetes se asegura de que las compilaciones sean repetibles al registrar las versiones específicas de cada paquete del que depende su aplicación y, a continuación, le permite actualizar esas dependencias de forma controlada, como se muestra en el siguiente diagrama.
Construya una versión para AWS CDK
Le recomendamos que cree su propia canalización automatizada para crear y lanzar nuevas versiones de AWS CDK construcción. Si implementa un proceso de aprobación de solicitudes de extracción adecuado, una vez que confirme e inserte su código fuente en la rama principal del repositorio, la canalización podrá compilar y crear una versión candidata a ser lanzada. Puedes actualizar esa versión CodeArtifact y probarla antes de lanzar la versión lista para producción. Si lo desea, puede probar la nueva versión de AWS CDK construcción localmente antes de fusionar el código con la rama principal. Esto hace que la canalización publique la versión lista para la producción. Tenga en cuenta que los constructos y los paquetes compartidos deben probarse por separado de la aplicación que los utilice, como si se estuvieran lanzando al público.
En el siguiente diagrama se muestra un ejemplo del proceso de publicación de una AWS CDK versión.
Puede utilizar los siguientes comandos de ejemplo para crear, probar y publicar paquetes npm. En primer lugar, inicie sesión en el repositorio de artefactos al ejecutar el siguiente comando.
aws codeartifact login --tool npm --domain <Domain Name> --domain-owner $(aws sts get-caller-identity --output text --query 'Account') \ --repository <Repository Name> --region <AWS Region Name>
A continuación, complete los pasos siguientes:
-
Instale los paquetes necesarios en función del archivo
package.json:npm install -
Cree la versión candidata a ser lanzada:
npm version prerelease --preid rc -
Cree el paquete npm:
npm run build -
Pruebe el paquete npm:
npm run test -
Publique el paquete npm:
npm publish
