#2 Fichiers de projet
Une introduction aux meilleures pratiques de gestion de projet à l'ère de l'IA.
À présent, nous avons compris la vue d'ensemble de l'IA. Cependant, pour commencer le développement, nous avons d'abord besoin d'un environnement. Configurons un environnement de développement basé sur l'utilisation de l'IA. Tout d'abord, nous devons décider comment gérer les fichiers de projet. Le simple partage de fichiers comporte le risque de devoir réécrire le code à partir de zéro en cas d'erreur. Cela reste vrai même lors de l'utilisation de l'IA, de sorte que le contrôle de version et la gestion de projet sont indissociables dans le développement moderne.
Par le passé, le développement commençait par un simple partage de fichiers (NFS ou NetBIOS), qui a ensuite évolué vers le CVS (à partir de ~1990) → VSS (à partir de ~1995) → Subversion (à partir de ~2000) → Git (à partir de ~2010) (ces repères temporels sont approximatifs). J'ai préparé et configuré des environnements pour chacune de ces étapes. Historiquement, la configuration des environnements de dépôt (unités de stockage et de gestion des fichiers de projet ainsi que des historiques de mise à jour) nécessitait une installation ou des achats manuels, ainsi que l'établissement d'environnements de sauvegarde, ce qui représentait une tâche majeure. Aujourd'hui, GitHub est le choix incontestable. (Puisque c'est gratuit, lol)
【À propos de GitHub】
Auparavant, GitHub limitait les comptes gratuits à un seul dépôt privé, mais il est désormais illimité. De plus, GitHub Actions offre jusqu'à 2 000 minutes gratuites par mois, et le stockage est gratuit jusqu'à 500 Mo.
C'est merveilleux. Nous vivons dans une époque formidable. Bien sûr, vous pouvez également lancer un conteneur Gitea via Docker pour créer un environnement Git local. Pour les grands projets où je n'utilise pas le CI/CD, je les gère sur mon serveur local.
<Qu'est-ce que le CI/CD ?>
C'est une philosophie importante dans le développement piloté par l'IA et sans code. Auparavant, les analystes système (SA) analysaient les opérations commerciales et compilaient les exigences, les ingénieurs système (SE) créaient les spécifications et les exigences de test, et les programmeurs (PG) écrivaient le code (connu sous le nom de modèle en cascade). En comparaison, aujourd'hui semble être un monde différent. Reflétant les coûts élevés du retour aux phases précédentes, les méthodes modernes privilégient une construction progressive et évolutive. Définissons brièvement ces termes :
- CI : Intégration continue (Continuous Integration)
Le processus par lequel les développeurs fusionnent fréquemment leurs modifications de code dans un dépôt partagé, déclenchent des builds automatisés et exécutent des tests.
- CD : Livraison et déploiement continus (Continuous Delivery & Deployment)
Une pratique consistant à automatiser le code testé en CI afin qu'il soit prêt à être publié manuellement en production à tout moment, ou à automatiser le déploiement réel en production.
En termes simples, c'est une méthode pour terminer un projet étape par étape tout en vérifiant l'interface utilisateur et les fonctionnalités. Auparavant, ces méthodes étaient appelées développement agile ou DevOps (développement + opérations), mais l'approche actuelle semble encore plus rapide. C'est une combinaison parfaite pour l'IA.
À l'ère de l'IA, il existe un autre concept clé à connaître : GitOps.
<Qu'est-ce que GitOps ?>
Il s'agit d'une méthodologie de développement centrée sur un dépôt Git. C'est le concept de gestion de toutes les définitions d'infrastructure, des configurations d'applications et des déploiements de code sur les serveurs afin qu'ils soient entièrement versionnés, permettant des retours en arrière et des historiques d'audit complets. Centrer toutes les informations de projet autour de cette source de vérité améliore considérablement l'efficacité du développement, la tolérance aux pannes et les délais de récupération rapide.
Un avertissement concernant GitHub à l'ère de l'IA : comme expliqué précédemment, les outils d'IA personnels utilisent les historiques de conversation pour l'apprentissage. Les informations sensibles (mots de passe, jetons d'accès, etc.) doivent être sécurisées à l'aide de GitHub Secrets. De plus, pour les opérations GitHub, il est préférable de se connecter au préalable à l'aide de GitHub CLI avant de déléguer des tâches à l'IA.
Mauvais exemple :
$ git clone https://{username}:{Token}@github.com/{UserID}/{repository_name}.git
Bien que GitHub autorise ce format, il expose complètement votre jeton. Vous devriez toujours exécuter `gh auth login` au préalable afin de ne pas avoir à transmettre vos identifiants directement aux commandes Git. En faisant cela, le jeton est enregistré dans l'URL distante, le rendant visible par n'importe qui, alors ne supposez pas que c'est sûr simplement parce qu'un humain a exécuté la commande initialement.
Comme de nombreux sites Web expliquent comment créer des comptes GitHub et exécuter des commandes de clonage, je passerai sur ces détails ici. Tout d'abord, votre dépôt (un ensemble de fichiers de projet) a été créé avec succès.