Utiliser le contrôle des éditions et des versions pour les constructions

Contrôle de version pour le AWS CDK

AWS CDK des concepts communs peuvent être créés par plusieurs équipes et partagés au sein d'une organisation à des fins de consommation. Généralement, les développeurs publient de nouvelles fonctionnalités ou corrigent des bogues dans leurs AWS CDK constructions communes. Ces constructions sont utilisées par les AWS CDK applications ou par toute autre AWS CDK construction existante dans le cadre d'une dépendance. Pour cette raison, il est crucial que les développeurs mettent à jour et publient indépendamment leur construction avec des versions sémantiques appropriées. AWS CDK Les applications en aval ou d'autres AWS CDK constructions peuvent mettre à jour leur dépendance pour utiliser la version de AWS CDK construction récemment publiée.

La gestion des versions sémantique (Semver) est un ensemble de règles, ou de méthodes, permettant de fournir des numéros de logiciel uniques au logiciel informatique. Les versions sont définies comme suit :

• Une MAJOR version se compose de API modifications incompatibles ou d'une modification radicale.

• Une MINOR version comprend des fonctionnalités ajoutées de manière rétrocompatible.

• Une PATCH version consiste en des corrections de bogues rétrocompatibles.

Pour plus d'informations sur le versionnement sémantique, consultez la section Spécification de version sémantique (SemVer) dans la documentation sur le versionnage sémantique.

Référentiel et empaquetage pour les AWS CDK constructions

Comme AWS CDK les constructions sont développées par différentes équipes et utilisées par plusieurs AWS CDK applications, vous pouvez utiliser un référentiel distinct pour chaque AWS CDK construction. Cela peut également vous aider à appliquer le contrôle d'accès. Chaque dépôt peut contenir tout le code source lié à la même AWS CDK construction ainsi que toutes ses dépendances. En conservant une seule application (c'est-à-dire une AWS CDK construction) dans un référentiel unique, vous pouvez réduire l'impact des modifications lors du déploiement.

AWS CDK Non seulement il génère des CloudFormation modèles pour le déploiement de l'infrastructure, mais il regroupe également les actifs d'exécution tels que les fonctions Lambda et les images Docker et les déploie parallèlement à votre infrastructure. Il est non seulement possible de combiner le code qui définit votre infrastructure et le code qui implémente votre logique d'exécution en une seule construction, mais c'est également une bonne pratique. Ces deux types de code n'ont pas besoin de se trouver dans des référentiels séparés ni même dans des packages distincts.

Pour consommer des packages au-delà des limites du référentiel, vous devez disposer d'un référentiel de packages privé, similaire à npm ou à Maven Central PyPi, mais interne à votre organisation. Vous devez également disposer d'un processus de publication qui génère, teste et publie le package dans le référentiel de packages privé. Vous pouvez créer des référentiels privés, tels que des PyPi serveurs, à l'aide d'une machine virtuelle (VM) locale ou d'Amazon S3. Lorsque vous concevez ou créez un registre de packages privé, il est essentiel de prendre en compte le risque d'interruption de service en raison de la haute disponibilité et de la capacité de mise à l'échelle. Un service géré sans serveur hébergé dans le cloud pour stocker les packages peut considérablement réduire les frais de maintenance. Par exemple, vous pouvez l'utiliser AWS CodeArtifactpour héberger des packages pour les langages de programmation les plus courants. Vous pouvez également l'utiliser CodeArtifact pour définir des connexions au référentiel externe et les répliquer au sein CodeArtifact de celui-ci.

Les dépendances des packages du référentiel de packages sont gérées par le gestionnaire de packages de votre langue (par exemple, npm for TypeScript ou JavaScript applications). Votre gestionnaire de packages s'assure que les générations sont reproductibles en enregistrant les versions spécifiques de chaque package dont dépend votre application, puis vous permet de mettre à niveau ces dépendances de manière contrôlée, comme le montre le schéma suivant.

Constructez la publication pour le AWS CDK

Nous vous recommandons de créer votre propre pipeline automatisé pour créer et publier de nouvelles versions de AWS CDK construction. Si vous mettez en place un processus d'approbation des demandes d'extraction approprié, une fois que vous avez validé et transféré votre code source dans la branche principale du référentiel, le pipeline peut générer et créer une version possible. Cette version peut être transférée CodeArtifact et testée avant de publier la version prête pour la production. Vous pouvez éventuellement tester votre nouvelle version de AWS CDK construction localement avant de fusionner le code avec la branche principale. Ainsi, le pipeline va publier la version prête pour la production. Tenez compte du fait que les constructions et les packages partagés doivent être testés indépendamment de l'application utilisatrice, comme s'ils étaient mis à la disposition du public.

Le schéma suivant montre un exemple de pipeline de publication de AWS CDK versions.

Vous pouvez utiliser les exemples de commandes suivants pour générer, tester et publier des packages npm. Tout d'abord, connectez-vous au référentiel d'artefacts en exécutant la commande suivante.

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>

Ensuite, procédez comme suit :

1. Installez les packages requis sur la base du fichier package.json : npm install

2. Créez la version possible pour la publication : npm version prerelease --preid rc

3. Générez le package npm : npm run build

4. Testez le package npm : npm run test

5. Publiez le package npm : npm publish