Comment CI peut-il être utilisé pour les langages interprétés?

Je n'ai jamais utilisé de système d'intégration continue (CI) auparavant. Je code principalement en MATLAB, Python ou PHP. Aucun de ceux-ci n'a une étape de construction et je ne vois pas comment un CI pourrait être utilisé pour mon travail. Un ami sur un grand projet dans une grande entreprise m'a dit que la langue n'a pas d'importance.

Je ne vois pas en quoi CI me serait utile si je n'avais pas d'étape de construction. Je peux penser à CI comme un environnement de test qui exécuterait des tests unitaires. Suis-je en train de manquer quelque chose?

L'intégration continue en tant que terme fait référence à deux idées distinctes.

Le premier est un flux de travail: au lieu que tout le monde dans une équipe travaille sur sa propre branche, puis après quelques semaines de programmation, essayez de fusionner leurs modifications dans la ligne principale, que les modifications sont intégrées (presque) en continu. Cela permet aux problèmes de faire surface tôt et évite les changements incompatibles. Cependant, cela nécessite que nous puissions facilement vérifier si un changement «fonctionne».

C'est là qu'intervient la deuxième idée, qui s'est avérée beaucoup plus populaire. Un serveur CI est un environnement propre où les modifications sont testées le plus rapidement possible. L'environnement propre est nécessaire pour que la construction soit reproductible. Si cela fonctionne une fois, cela devrait toujours fonctionner. Cela évite les problèmes «mais cela a fonctionné sur ma machine». En particulier, un serveur CI est précieux lorsque votre logiciel s'exécute sur différents systèmes ou dans différentes configurations et vous devez vous assurer que tout fonctionne.

L'absence d'une étape de construction n'est pas pertinente. Cependant, CI n'a de sens que si vous avez une suite de tests. Cette suite de tests doit être automatique et ne doit présenter aucun échec. Si les tests échouent, le développeur approprié devrait recevoir une notification afin qu'ils puissent résoudre le problème qu'ils ont introduit («casser la build», même quand il n'y a pas de build en tant que compilation).

Il s'avère qu'un tel serveur est utile pour bien plus que des tests. En fait, la plupart des logiciels CI sont vraiment nulles pour exécuter des tests dans diverses configurations, mais sont bons pour gérer toutes sortes de travaux. Par exemple, en plus des tests unitaires «continus», il pourrait y avoir un test complet comme construction nocturne. Le logiciel peut être testé avec plusieurs versions de Python, différentes versions de bibliothèque. Un site Web pourrait être testé pour les liens morts. Nous pouvons exécuter une analyse statique, des vérificateurs de style, des outils de couverture de test, etc. sur le code. La documentation peut être générée. Une fois toutes les suites de tests réussies, le processus de mise en package peut être lancé afin que vous soyez prêt à publier votre logiciel. Ceci est utile dans un environnement agile où vous voulez un produit déployable (et démontrable) à tout moment. Avec l'essor des applications web, il y a aussi l'idée d' un déploiement continu: Si tous les tests réussissent, nous pouvons automatiquement pousser les modifications à la production. Bien sûr, cela nécessite que vous ayez vraiment confiance en votre suite de tests (sinon, vous avez de plus gros problèmes).

Certes, vous n'avez pas particulièrement besoin d'un système CI pour effectuer des builds et vérifier que ces builds sont corrects, mais ce n'est qu'une partie de la raison d'être de CI.

Le but de CI est de détecter les erreurs le plus tôt possible, car en règle générale, plus une erreur est détectée tôt, moins elle est coûteuse à réparer. À cette fin, dans le cas où une étape de construction n'est pas nécessaire, un système CI peut toujours automatiser l'utilisation des outils d'analyse de code, le déploiement dans un environnement de test, les tests unitaires / d'intégration / de régression / autres que vous pouvez automatiser et toutes les autres étapes vous pouvez effectuer automatiquement afin de vérifier les erreurs.

L'intégration continue effectue plus qu'une compilation du code. Si c'est tout ce qu'il a fait, alors nous n'aurions pas besoin de presque autant d'outils pour cela!

Quelques autres tâches auxquelles je peux penser spontanément qu'un pipeline d'intégration continue effectue souvent:

• Exécution de tests automatiques. (Python possède une multitude de bibliothèques de tests automatisés, et PHP en a au moins certaines. Je ne peux pas parler à MATLAB.)
• Regroupement du logiciel pour distribution. En automatisant ce processus, vous vous assurez qu'il est effectué de manière exacte, cohérente et répétable à chaque fois. Aucune étape ne sera oubliée; générer un tel package de distribution prend au plus un clic. (Regrouper votre application Python en tant que roue est une excellente idée!)
• Le balisage du jalon est validé. Chaque fois que vous créez un package pour la production, vous voudrez probablement le marquer.
• Numéros de version à incrémentation automatique. Habituellement, ce serait simplement le numéro de "build" et non les parties les plus significatives, mais il peut être agréable d'identifier de manière unique une build particulière, afin que vous sachiez ce qui est déployé où.

En allant un peu plus loin à la frontière de l '«intégration continue» au sens strict, vous pourriez aussi faire ceci:

• Avoir un processus automatisé pour configurer un système d'exploitation et installer vos dépendances.
• Déploiement automatique de copies du logiciel (principalement utile pour les applications Web ou les logiciels distribués par un gestionnaire de packages). Certaines équipes l'utilisent en fait pour déployer en production (livraison continue), mais même si vous ne le faites pas, vous pouvez toujours en tirer parti pour déployer des copies supplémentaires, hors production, du code. Pour certains projets où je travaille, nous avons une copie pour que les développeurs testent leur code avant de le mettre à la disposition de QA, une copie pour QA à tester et une copie plus "stable" à des fins de démonstration.

Le point est simplement le suivant: il y a des tâches que vous devez effectuer périodiquement dans le processus de développement de logiciels en plus de simplement écrire le code. En automatisant ces tâches et en les exécutant sur un serveur, vous obtenez

• Processus cohérent (Stan et Sally ne feront pas les choses différemment.)
• Connaissance des processus enregistrés dans le code (Quiconque peut lire les scripts peut apprendre les étapes impliquées dans le déploiement, au lieu que Sally soit la seule à le faire ou sache comment.)
• Duplication plus simple des processus (Simple pour déployer plusieurs copies du site web: vous venez de fournir une nouvelle configuration!)
• Des tests plus approfondis (Bob n'a testé que sa page, mais ses modifications ont cassé la page de Sally. Sally a oublié de valider un fichier. Stan a ajouté une nouvelle dépendance qui doit être installée à côté de l'application mais ne s'en est pas rendu compte car elle est installée automatiquement par l'IDE . J'ai vu tout cela sous une forme ou une autre.)

Et probablement d'autres avantages qui ne viennent même pas à l'esprit.

Vous n'aurez peut-être pas besoin de compiler les solutions, mais CI peut toujours vous aider en modifiant les fichiers de configuration / les chemins de dossier, etc.

Supposons que vous déployiez votre code Python sur 5 serveurs QA différents et que vous en ayez besoin pointant vers différentes bases de données QA, puis une fois le test automatisé exécuté (déclenché par CI), promouvant la génération en production et le déployant là-bas avec les modifications de configuration appropriées pour chaque serveur de production .