J'utilise AWS depuis un certain temps maintenant, mais je me demande comment développer avec Lambda. Je suis un grand fan d'avoir des fonctions sans serveur et de laisser Amazon gérer la maintenance et je l'utilise depuis un certain temps. Ma question: existe-t-il un flux de travail recommandé pour le contrôle et le développement de versions?
Je comprends qu'il est possible de publier une nouvelle version dans Lambda. Et que vous pouvez pointer vers des versions spécifiques dans un service qui l'appelle, comme API Gateway. Je vois que API Gateway a également de belles capacités pour partitionner qui appelle quelle version. c'est-à-dire avoir une API de test et également des mises à jour progressives pour dire 10% des appels d'API de production et évoluer lentement.
Cependant, cela semble un peu maladroit pour un système de contrôle de version réel. Peut-être que les fonctions sont codées localement et téléchargées à l'aide de l'AWS CLI, puis tout est géré via un système de contrôle de version tiers (Github, Bitbucket, etc.)? Puis-je déployer sur des versions nouvelles ou existantes de la fonction de cette façon? De cette façon, je peux maintenir une séparation des fonctions de test et de production.
Le développement n'est pas non plus aussi agréable avec l'éditeur de Lambda. Sans parler de l'utilisation de packages personnalisés, il faut de toute façon télécharger. Il semble que le développement local soit la meilleure solution. Essayer de comprendre les flux de travail des autres pour que je puisse améliorer le mien.
Comment avez-vous abordé ce problème dans votre expérience?
4 Réponses :
Vous pouvez avoir un contrôle de version sur votre lambda en utilisant aws CodeCommit (beaucoup plus simple que d'utiliser un système de référentiel git externe, bien que vous puissiez faire l'un ou l'autre). Voici un didacticiel pour configurer un CodePipeline pour les étapes de validation / construction / déploiement: https://docs.aws.amazon.com/codepipeline/latest/userguide/tutorials-simple-codecommit.html
Cet exemple déploie une instance EC2, donc pour la partie de déploiement d'un lambda, voir ici
Si vous configurez un pipeline, vous pouvez avoir une étape de validation initiale, puis une étape de construction qui exécute vos tests unitaires et conditionne le code, puis une étape de déploiement (et potentiellement plus d'étapes si nécessaire). C'est une manière très organisée de déployer les changements lambda.
Je ne pense pas qu'il y ait d'étalon-or. D'après mes recherches, il existe différentes approches et cadres. J'ai décidé que je ne voulais pas dépendre de tout type de frameworks comme Serverless ou Apex parce que je ne voulais pas apprendre à utiliser ces choses en plus d'apprendre sur Lambda. Au lieu de cela, j'ai construit des améliorations de manière organique en fonction de mes besoins pendant que je développais une fonction.
Pour répondre à votre question, voici mon flux de travail.
Maintenant qu'un certain temps s'est écoulé, avez-vous mis à jour votre flux de travail?
Je vous suggère de jeter un œil à SAM. SAM est un outil de ligne de commande et un framework pour vous aider à développer votre application sans serveur. À l'aide de SAM, vous pouvez tester vos applications localement avant de les télécharger sur le cloud. Il prend également en charge le déploiement bleu / vert et les flux de travail CI / CD, à partir automatiquement de github.
Je pense que Serverless Framework + le flux de travail Git standard est votre meilleur pari ici. Chaque branche Git est liée à un environnement (ou une étape) complètement séparé. Ils peuvent également être dans différents comptes AWS également .
Votre équipe travaille dans des branches de fonctionnalités ou utilise un flux de travail basé sur les relations publiques et vos déploiements sont associés à des commits Git. Cela vous évite d'avoir à gérer la gestion des versions Lambda.
Vous pouvez donc déployer localement sur un certain ensemble de branches. Alors que pour vos environnements de préparation et de production, vous voudrez peut-être les connecter via votre processus CI.
Nous avons décrit en détail l'aspect du flux de travail Git ici - https://seed.run/blog/git-workflow-for-serverless-apps