À quel moment un serveur d'intégration continue est-il intéressant?

J'ai lu un peu sur les serveurs CI comme Jenkins et je me demande: à quel moment est-ce utile?

Parce que sûrement pour un petit projet où vous n'auriez que 5 classes et 10 tests unitaires, il n'y a pas vraiment besoin.

Ici, nous avons environ 1500 tests unitaires et ils passent (sur les anciennes stations de travail Core 2 Duo) en environ 90 secondes (car ils testent vraiment des "unités" et sont donc très rapides). La règle que nous avons est que nous ne pouvons pas valider le code lorsqu'un test échoue.

Ainsi, chaque développeur lance tous ses tests pour éviter la régression.

Évidemment, parce que tous les développeurs lancent toujours tout le test, nous détectons des erreurs dues à des changements conflictuels dès qu'un développeur tire le changement d'un autre (le cas échéant).

Ce n'est toujours pas très clair pour moi: dois-je configurer un serveur CI comme Jenkins? Qu'apporterait-il?

Est-ce juste utile pour le gain de vitesse? (pas un problème dans notre cas)

Est-ce utile parce que les anciennes versions peuvent être recréées? (mais nous pouvons le faire avec Mercurial, en vérifiant les anciens tours)

Fondamentalement, je comprends que cela peut être utile, mais je ne vois pas exactement pourquoi.

Toute explication tenant compte des points que j'ai soulevés ci-dessus serait la bienvenue.

Est-ce juste utile pour le gain de vitesse? (pas un problème dans notre cas)

Le temps que vous passez à parcourir votre processus est le temps que vous auriez pu passer à vous lancer dans le développement.

Vous gagnerez également du temps aux étapes importantes, car vous construisez idéalement des morceaux entièrement emballés et prêts à être expédiés qui peuvent être gravés directement sur CD, téléchargés sur le Web, etc.

Est-ce utile parce que les anciennes versions peuvent être recréées? (mais nous pouvons le faire avec Mercurial, en vérifiant les anciens tours)

Non, vous ne recréez pas de builds. Vous utilisez la génération qu'il a créée et la conservez jusqu'à ce que vos paramètres de rétention la jettent.

Vous le construisez sur le serveur de build, par opposition à sur la boîte de certains Dev.

Ici, nous avons environ 1500 tests unitaires et ils passent (sur les anciennes stations de travail Core 2 Duo) en environ 90 secondes (car ils testent vraiment des "unités" et sont donc très rapides). La règle que nous avons est que nous ne pouvons pas valider le code lorsqu'un test échoue.

De plus, n'aimeriez-vous pas pouvoir exécuter des tests d'intégration ou de bout en bout automatisés sur votre code et détecter les problèmes que les tests unitaires ne détecteront pas?

Vous ne voudriez pas les exécuter sur des boîtes de développement, car ce serait pénible de configurer et de maintenir cet environnement. Les tests d'intégration ont également tendance à être très lents à exécuter.

à quel moment est-ce utile?

C'est un investissement comme un autre.

Utilisez-le une fois et vous risquez de ressortir ou de ne faire qu'atteindre le seuil de rentabilité. Utilisez-le sur plusieurs projets et vous en sortirez probablement en tête.

Cela dépend également du type d'applications que vous faites.

Si vous créez des applications Web qui doivent être déployées sur un serveur d'applications Java ou IIS, CI devient une évidence. Même chose si vous avez une base de données dans le cadre de votre projet. Le déploiement est pénible à exécuter manuellement, et votre équipe AQ ​​(si vous en avez un) en aura besoin aussi souvent que quotidiennement à un moment donné.

En outre, vous voudrez peut-être voir comment vos besoins et vos problèmes s'alignent sur les 12 étapes vers un meilleur code de Joel Spolsky . Particulièrement 2, 3 et 10 (bien qu'ils soient tous intéressants et importants).

À quel moment est-ce utile?

• Votre cycle de build + test prend plus de quelques minutes. Avec un test de 5 minutes, vous ne voudrez plus exécuter tous les tests vous-même, en particulier pour les petits changements.
• Vous commencez à créer plusieurs variantes. Si vous avez quelques clients avec des personnalisations différentes, vous devez exécuter les tests pour chaque variante, afin que la quantité de travail commence à augmenter assez rapidement. Ensuite, vous exécutez la suite de tests pour une variante sur la machine du développeur et laissez le soin à CI de l'exécuter sur les autres.
• Vous écrivez des tests d'intégration automatisés qui nécessitent une configuration d'environnement de test non triviale. Que vous souhaitez tester contre un environnement de test canonique, car les développeurs peuvent avoir leur environnement modifié de diverses manières en raison des changements de développement. Le CI est l'endroit le plus approprié pour l'environnement canonique.
• Les testeurs peuvent simplement extraire la dernière version de CI. Ainsi, ils n'ont pas besoin d'avoir, d'apprendre et d'utiliser les outils de développement et aucun développeur n'a à leur envoyer leur build manuellement.
• Lorsque vous préparez la sortie:
  • Les tests deviennent plus importants, donc avoir un seul endroit avec des builds préparés pour le test est encore plus utile.
  • Vous êtes certain que toutes les versions sont construites avec le même environnement de génération, vous évitez donc les problèmes qui peuvent être introduits par des différences subtiles entre les installations des développeurs.
  • Vous êtes certain de construire exactement ce qui est vérifié dans le système de contrôle de version. Pendant le développement, si quelqu'un oublie de vérifier quelque chose, vous le trouverez assez rapidement, car cela échouera pour le prochain développeur. Mais si une telle version glissait vers le contrôle qualité ou la production et signalait un bogue, il serait très difficile à retracer.

Vous n'avez probablement pas encore besoin de CI, mais je pense que cela deviendra utile lorsque vous arriverez à la phase de test. Jenkins est installé en quelques heures et cela simplifiera vos tests et vous aidera à éviter les erreurs stupides (cela se produit surtout lorsque vous dépêchez une solution rapide pour la production).

Pour moi, un CI devient intéressant si votre équipe compte plus d'un membre.

Vous devez cesser de penser à CI comme "un autre PC exécutant les tests pour moi". CI pour avoir un processus de construction et une gestion des versions définis et automatisés .

CI est la seule entité faisant autorité qui crée votre version de logiciel. S'il ne s'appuie pas sur le CI, cela ne s'est tout simplement pas produit.

Avec un CI, vous avez des restrictions pour automatiser tout ce qui vous montrera tous les ajustements, hacks et raccourcis manuels que vous avez en place et ne fonctionne tout simplement pas avec un CI et devrait être évité en premier lieu.

Problèmes évités:

• Qui est responsable de la création de la version
• Cette personne est-elle disponible 24h / 24 et 7j / 7
• Mais il s'appuie sur mon syndrome de la machine
• Supprime toute ambiguïté sur la version que nous avons publiée

Avantages (trop nombreux pour tous les mentionner):

• Numérotation automatique des versions
• Intégration du suivi des problèmes
• Génération de métriques automatisée
• Analyse de code statique
• Déploiement automatisé
• Configurations en plusieurs étapes

Il y a un problème fondamental à propos de l'intégration continue (CI) qui se reflète parfaitement dans votre question: les pratiques de CI sont difficiles à mettre en œuvre et à défendre car le logiciel de serveur CI n'est pas trivial à configurer, ni à mettre en place et à exécuter vos projets via un CI serveur. Avec cela, il devient difficile de voir réellement où est le gain à adopter le CI du tout.

Tout d'abord, CI est synonyme de perspicacité et de qualité. Un bon CI vous rapproche de votre projet, vous fournit des commentaires appropriés sur les mesures de qualité, la documentation, la conformité aux normes de codage, etc. associez un ensemble de modifications à un instantané spécifique de toutes ces mesures de projet.

Il ne s'agit pas seulement d'exécuter des tests unitaires. Pas du tout! Ce qui m'amène à la qualité. CI accepte les erreurs, il ne les évite pas et ne les jette pas. Ce qu'il fait, c'est tout simplement de vous fournir un outil pour sortir tôt, plutôt que plus tard. Donc, vous ne validez pas vraiment le code précédemment testé sur un serveur CI. Bien que vous devriez vous efforcer de valider du code propre et non cassé, vous utilisez en fait le serveur CI pour exécuter automatiquement un générateur d'intégration automatiquement via votre code et le faire évaluer si tout s'est bien passé. Si c'est le cas, c'est parfait! Si ce n'est pas le cas, pas de problème - les bonnes pratiques de CI indiquent que votre prochaine priorité devrait être simplement de réparer tout ce qui est cassé. Qui, dans un bon serveur CI, devrait être facilement indiqué pour vous.

À mesure que la taille d'une équipe augmente, l'intégration du code de chacun devient naturellement plus difficile. Ce devrait être la tâche d'un serveur CI centralisé de tester toutes les pièces intégrées et d'alléger ce fardeau des membres de l'équipe. Donc, vous devez obliger tout le monde à s'engager tôt (et aussi proprement que possible), puis à surveiller l'état des builds (il y a généralement des notifications envisagées). Et encore une fois, si quelque chose se casse à cause de l'engagement d'un développeur, il devient immédiatement de sa responsabilité de résoudre ce problème et de remettre ces versions automatisées à l'état OK immédiatement.

Donc, vous voyez, à mon avis, chaque projet bénéficie d'une intégration continue. Le fait est que, jusqu'à présent et en raison de la complexité époustouflante de chaque serveur CI que je connais, les gens ont vraiment repoussé les pratiques CI sur des projets plus petits / plus simples. Parce que, allez, les gens ont mieux à faire que de passer des jours à configurer un logiciel laid, trop complexe, sous-performant et gonflé.

J'ai eu exactement le même problème, et c'est ce qui m'a fait développer Cintient pendant mon temps libre depuis environ un an maintenant. Ma prémisse était de le rendre simple à installer, à configurer et à utiliser, et à lui faire livrer des mesures de qualité que tout le monde échoue ou sous-distribue. Donc, après cette longue réponse, vient ma fiche éhontée de souligner le lien GitHub pour le projet (qui est gratuit et open-source, natch). Il a également de belles captures d'écran, apparemment. :-) https://github.com/matamouros/cintient

J'espère que je vous ai aidé.

(REMARQUE: édité après le commentaire de Bryan Oakley, sur le fait que j'aurais dû prendre plus de temps pour élaborer une meilleure réponse. Je pense également qu'il avait raison.)