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.)