Gérer les environnements de développement dans l’infrastructure sans serveur AWS

Une plate-forme sans serveur offre la possibilité de donner à chaque développeur son propre environnement de pile complète distinct sur un compte AWS qu’il peut exploiter pour les activités de développement et de test.

Cela est possible sans que des coûts importants n’augmentent et n’aient d’impact sur qui que ce soit d’autre. Ou sans risque que la configuration du développeur soit modifiée accidentellement.

L’architecture sans serveur donne une vision différente des anciens problèmes et est positivement rafraîchissante à bien des égards. Le principal avantage est que vous n’avez plus besoin d’administrateurs dans l’équipe pour ne faire aucun sacrifice dans l’exécution de processus à grande échelle. L’autre avantage – désormais orienté vers l’équipe de développement interne plutôt que vers l’entreprise, est qu’il peut servir l’équipe de développement avec des conditions illimitées pour leur travail de développement.

Nous allons expliquer ici ce que cela signifie exactement, à savoir :

• Comment créer une configuration d’environnement de développement illimitée dans une plate-forme sans serveur.
• Quels sont les avantages d’une telle configuration pour l’équipe ?
• Les domaines les plus cruciaux à surveiller dans une telle configuration afin qu’elle ne se brise pas avec le temps.
• Exemple de démonstration d’une telle configuration.

Une route vers une pile d’environnements autonomes pour chaque développeur

Vous pouvez considérer les infrastructures de développement comme un processus évolutif dans le temps.

Au commencement, il y avait une lumière…

La manière la plus courante de gérer les environnements de compte de développement consiste à créer un ou plusieurs environnements de développement distincts. Dans le meilleur des cas, ils contiennent tous les composants de l’environnement de production. Même ce n’est pas du tout standard. Souvent, l’environnement de développement se limitera à certains des services les plus importants et manquera le reste.

Naturellement, dans un tel environnement, il est plus difficile de développer une solution fiable. L’impact sur les composants du système qui ne se présentent pas est tout simplement absent. L’équipe de direction dira que cela peut être compris plus tard dans des environnements de test lors des tests du système. Cependant, cela ne gagnera jamais un trophée d’accomplissement d’empathie aux yeux des développeurs.

Les activités de développement seront moins précises. Les développeurs passeront plus de temps à retravailler et à résoudre les problèmes, et dans l’ensemble, leur motivation à créer un morceau de code parfait diminuera. De plus, avec une telle configuration, vous créez déjà un environnement incohérent et instable dès le début.

Selon la taille de l’équipe, plusieurs environnements de développement peuvent être nécessaires pour atténuer les conflits de travail parallèles les plus critiques entre les équipes. Comme ils partageront les environnements de développement, un développeur aura un impact sur l’autre d’une manière ou d’une autre. Une communication approfondie entre les membres de l’équipe est indispensable.

Plus d’environnements de développement signifient moins de conflits, mais le facteur de partage est toujours là. Cela pourrait être réalisable, mais ce ne sera jamais une configuration parfaite. Le plus souvent, les développeurs finiront par créer quelque chose (qui est déjà en conflit) localement directement sur les ordinateurs portables. Cela pourrait créer des problèmes supplémentaires ultérieurement lors de la fusion du code. Le comportement sur la machine portable peut être différent de celui sur le cloud. Cela peut créer des problèmes après avoir fusionné le code avec les développements déjà faits par les autres.

Mais ensuite, quelqu’un a créé le monde…

La question évidente est maintenant – qu’est-ce que c’est alors? Quelle configuration supprimerait le facteur de partage et ne motiverait pas l’équipe à faire des activités ailleurs que sur le compte cloud ?

Imaginez que chaque membre de l’équipe reçoive une pile d’environnement distincte qu’il peut utiliser pour ses propres activités. Il serait constitué des mêmes éléments que le système de production. Sans le chargement complet des données car c’est quelque chose que vous ne voulez même pas vraiment pour les activités de développement.

Ou montons d’un niveau – qu’en est-il de la création d’une telle pile pour chaque tâche sur laquelle le développeur travaille ?

Cher – vous pourriez penser.

Pas vraiment – je dirais.

Si les développeurs utilisent activement les environnements et leurs ressources, la comparaison de la charge entre tout faire dans un environnement partagé en parallèle et les diviser en plusieurs environnements est très susceptible d’être égale en termes de coûts. Parce que vous avez une architecture sans serveur et que vous ne payez que pour l’utilisation réelle.

Si les développeurs ne sont pas actifs et qu’ils ont quand même créé cette pile complète (ou plusieurs d’entre eux en même temps), le coût est nul car vous avez une architecture sans serveur. Les services non utilisés ne génèrent aucun coût.

Parlons des avantages de plus près.

Des avantages que seule l’équipe de développement peut apprécier

Tout d’abord, une chose est très claire. Tous les avantages de cette configuration ne peuvent être appréciés que par l’équipe de développement elle-même. Aucune direction ou utilisateur commercial n’y verra jamais de valeur. Je veux dire, ils pourraient comprendre où est la valeur. Mais très probablement, ils n’admettront jamais qu’ils en ont absolument besoin. Ils ne l’utilisent pas et ils ne le voient pas dans leur travail quotidien.

Mais à quel point est-il vraiment difficile de comprendre que les meilleurs résultats de développement ne peuvent se produire que dans les meilleurs environnements de travail ?

Voici donc les avantages :

1. Le développeur a la certitude que personne d’autre ne modifiera l’environnement sur lequel il travaille actuellement. Tous les composants sont nouvellement créés uniquement pour cette tâche et cette activité de développement.
2. L’environnement de développement est une copie exacte de l’environnement de production. Cela signifie qu’une simulation précise du comportement des changements de code est possible
3. L’équipe développera toujours directement à l’intérieur du compte cloud, car il ne sert plus à rien de le faire localement.
4. En supposant que vous ayez créé des pipelines DevOps pour la création et la mise à jour de l’environnement, vous pouvez les intégrer aux outils Jira ou ADO pour la gestion des histoires et des tickets et créer ou terminer l’environnement de développement avec la progression et la fermeture des histoires. Cela vous donnera un environnement de développement distinct pour chaque histoire. Ou même une tâche à l’intérieur de l’histoire, d’ailleurs, ce qui est vraiment génial pour revenir en arrière.
5. Chaque fois que le développeur valide une modification du référentiel de code, le pipeline met à jour l’environnement avec le dernier code du référentiel. Cela signifie une automatisation du déploiement lors de la création de nouveau code et des processus de test unitaire plus rapides.
6. Aucune maintenance régulière des environnements de développement n’est vraiment nécessaire. Chaque environnement n’existe que pour une courte durée spécifique. Il est toujours créé à partir du dernier état du code du référentiel et du dernier instantané de données. Le problème de maintenance se résout d’elle-même dans ce cas.

Quels sont les inconvénients ?

Oui, il y a quelques mises en garde à prendre en compte. Je ne les appellerais pas explicitement des inconvénients. Cependant, si vous ne prêtez pas une attention raisonnable aux éléments ci-dessous, il est très probable qu’au fil du temps, ils pourraient devenir vos raisons pour les actions de refactorisation de l’infrastructure.

#1. Attention aux limites AWS

Voici la chose. Si vous allez créer une pile d’environnement distincte pour chaque personne et activité, vous allez créer un grand nombre d’objets AWS.

Pensez aux buckets S3, aux stratégies, aux rôles, aux utilisateurs, aux bases de données, aux VPC, etc.

C’est un must pour vous de surveiller et de surveiller. Si les environnements viennent d’être créés et que les développeurs en ajoutent de plus en plus sans supprimer correctement les anciens ou ceux liés aux histoires déjà terminées, tôt ou tard, vous rencontrerez des problèmes pour atteindre diverses limites AWS.

Certains d’entre eux sont faciles à augmenter. D’autres que vous pouvez demander à augmenter via le support AWS. Et puis il y a des limites strictes auxquelles vous ne pouvez rien faire une fois atteintes.

Ce sera un jeu sur le contrôle du nombre total d’objets AWS utilisés pour chaque type d’objet. Il s’agira de s’assurer que vous ne dansez pas constamment sur le bord. Vous ne voulez pas être la plupart du temps dans la zone supérieure des limites. Cela signifierait effectivement qu’avant chaque nouvelle création d’environnement, vous devez d’abord vous occuper de certains processus de nettoyage, manuels ou automatiques.

Quoi qu’il en soit, cela n’aura pour effet que de ralentir globalement les activités de développement. L’équipe de développement sera constamment dans un processus de résolution des environnements existants avant d’en créer un autre.

Au lieu de cela, ce qui est vraiment crucial est de garder toutes les limites sous contrôle de manière proactive en faisant un ménage de fond constant. Idéalement, de manière automatisée afin que la prochaine fois qu’un développeur a besoin d’un nouvel environnement, il le crée immédiatement sans plus tarder.

#2. Réduisez le temps d’exécution du pipeline DevOps

Cela sonne bien de dire que chaque nouvel environnement de développement sera créé automatiquement une fois que vous commencerez à travailler sur une histoire.

Cela semble terrible si, en réalité, cela signifie que le développeur attendra un tel environnement quelques heures. Et puis pas seulement pour la création mais pour chaque mise à jour conséquente de l’environnement (juste après chaque commit du référentiel).

Mettez-le dans une formule récapitulative et voyez combien de temps d’inactivité générerait une telle situation. Il n’est pas vraiment possible pour un développeur de passer à «autre chose» chaque fois qu’il doit attendre que l’environnement soit prêt.

Ce serait comme s’attendre à ce que vous alliez faire du shopping en attendant chez le médecin pour vos examens planifiés. Cela n’arrivera tout simplement pas. Vous vous asseyez là et attendez parce que cela pourrait arriver toutes les minutes.

#3. Mettre à jour régulièrement le jeu de données principal

Chaque nouvelle création d’environnement doit avoir un jeu de données source de référence. Cela sert à copier les données dans la pile d’environnement qui vient d’être créée. L’ensemble de données doit être régulièrement mis à jour (essentiellement après chaque sortie de production). Cela garantira que l’environnement est créé avec la dernière structure de jeu de données.

Il n’est pas nécessaire qu’il contienne un instantané complet de la base de données de production, bien que ce soit généralement la manière la plus simple de le faire. Cependant, le modèle de données doit toujours être à jour afin que chaque nouvelle activité de développement commence à partir du bon point de départ.

#4. Apprenez à votre équipe à être «responsable de l’environnement»

Être respectueux de l’environnement est désormais un sujet important et une attente de toutes les grandes entreprises. Des attentes similaires s’appliqueront également à l’équipe de développement.

Si un développeur a besoin de plus d’environnements en parallèle parce que cela augmentera considérablement l’efficacité, qu’il en soit ainsi. Mais si, d’un autre côté, le développeur garde ouverts plusieurs environnements en parallèle simplement parce qu’il est paresseux pour les fermer, alors c’est quelque chose à guérir le plus rapidement possible.

Avoir le privilège de travailler sur un bac à sable privé doit s’accompagner d’un niveau de responsabilité adéquat. Nous n’attendrons rien de moins qu’une utilisation responsable et solidaire de ces avantages.

Exemple de configuration

Maintenant, en mettant tout cela ensemble, voici à quoi s’attendre d’une telle configuration multi-environnements sans serveur.

• Vous pouvez utiliser le pipeline DevOps pour automatiser la création, la mise à jour et la résiliation d’un nouvel environnement.
• Ensuite, le développeur travaillera et mettra à jour l’environnement de développement au fur et à mesure de sa progression dans le développement.
• Une fois que le développeur a terminé les modifications de code et les tests unitaires, terminez l’activité sur cet environnement en fusionnant le code avec la branche du référentiel maître.
• Étant donné que de nombreux développeurs peuvent le faire simultanément, des activités de fusion de code sont nécessaires pour assurer le transfert de toutes les modifications des environnements de développement vers le lieu unique de vrai – la branche principale.
• Mettez à jour l’environnement de test central avec cet état de référentiel de branche principal afin que les activités de test du système puissent être effectuées sur le code fusionné de tous les développeurs.
• Utilisez un environnement de correction de bogues dédié pour résoudre tous les problèmes en cours. Cet environnement peut être créé en utilisant les mêmes pipelines DevOps déjà en place (considérez-le simplement comme un autre environnement de développement temporaire).
• Enfin, passez aux tests d’assurance qualité et à la mise en production.

Comme vous pouvez le constater, en réutilisant le même pipeline DevOps à différentes étapes de l’architecture, vous pouvez rapidement créer une plate-forme sans serveur flexible avec autant d’environnements de développement ou de test autonomes que nécessaire. Mieux encore, tous les avantages n’auront pas de coût.

Vous pouvez également être intéressé par ces plates-formes informatiques sans serveur pour exécuter votre code.