optimiser compiletime dans l'intégration continue

Question

Peut-être que c'est juste le rêve d'un homme fou, mais

Dans mon entreprise, nous avons un gros projet C# .NET, avec ~25 solutions (très anciennes) et ~3,5 millions de localisations. Le problème auquel je suis confronté est le suivant : les temps de construction sont trop lents. Actuellement, il faut 7 minutes avec un SSD (machines de développement), 15 minutes et plus dans une VM avec des disques durs normaux (ce serait le système de construction TeamCity que j'aimerais déployer). Je sais, le système de construction devrait être le plus rapide, mais ce n'est rien que je puisse changer à court terme.

Je veux raccourcir la boucle de rétroaction commit-build-unittest pour les développeurs (de préférence sur la machine Teamcity en ce moment) en compilant juste le(s) projet(s) qui ont été touchés par le dernier commit, en prenant tous les autres assemblages à partir par exemple d'un serveur nuget local (le serveur Teamcity lui-même avec la version 7.0).

Maintenant, ça serait immensément de réduire la boucle de rétroaction (de 15 minutes à moins d'une minute, étant donné réel tests unitaires) pour les petits commits.

Je sais que le problème d'une telle compilation partielle est la possibilité d'ignorer des erreurs de compilation (des interfaces non concordantes pourraient passer inaperçues), mais cela serait atténué en faisant tourner une deuxième instance de serveur de compilation (Teamcity ?) qui exécute toute l'enchilada, en parallèle. Mais obtenir un premier retour immédiat est très important pour moi.

Ma question est la suivante : existe-t-il un système de construction ou d'intégration continue capable de gérer cette tâche ? Ou bien devrais-je écrire mon propre service d'arrière-plan qui tienne compte des engagements ? Ce qui serait un peu désagréable, car nous utilisons FinalBuilder scripts, et ce format ne semble pas être lisible par une quelconque API (mais je n'ai pas creusé assez profondément dans ce domaine).

P.S. : J'aimerais également n'exécuter les tests unitaires que pour les projets qui ont été modifiés par le dernier commit, ou au moins les classer par ordre de priorité. Mais c'est une réflexion après coup.

Answer 1

La plupart des moteurs à CI disponibles adoptent un chaîne de déploiement qui est spécialement conçu pour réduire le temps de réaction dans la boucle de développement. Il fonctionne comme suit, avec un statut FAIL immédiatement si l'une des étapes a mal tourné.

Il est suggéré ( par ce livre ) pour que les 4 premières étapes durent moins de 2-5 minutes, même pour les projets les plus compliqués. Si cela dépasse ce délai, il y a un problème avec votre configuration et la façon dont vous utilisez le processus de CI.

Code commit
 triggers --->

 Step 1. Automatic checkout on CI side
 Step 2. Compile code, ideally 1-2 mins  
 Step 3. Save binaries to the artifact repository
 Step 4. Unit test, ideally 1-2 mins
 Step 5. Deploy to staging
 Step 6. Automated integration testing
 Step 7. Automated acceptance testing
 ------------------------------------
 Manual testing
 Manual deploy to production

Spécifiquement à l'étape 2, vous pouvez :

a. Diviser la grande solution en plusieurs niveaux. Chaque niveau aura sa propre solution Visual Studio et seulement les projets pertinents pour ce niveau, dans un sens vous effectuez la décentralisation de la solution initiale volumineuse. À l'étape 5, vous saurez comment assembler les niveaux en une application utilisable.

b. Dans la configuration de TeamCity, vous pouvez spécifier s'il faut effectuer un checkout propre ou utiliser la source déjà disponible (peut faire gagner du temps sur l'étape 1). Vérifiez que la cible de MSBuild est définie sur Construir qui récupérera uniquement les fichiers sources qui ont été modifiés depuis la dernière compilation (gain de temps à l'étape 2).

D'après mon expérience personnelle, l'option a) est la meilleure, mais si nécessaire, vous pouvez également utiliser à la fois a) et b), ce qui peut toutefois entraîner des bugs latents avec d'anciens fichiers conservés plus longtemps que nécessaire. Teamcity prend également en charge plusieurs agents (jusqu'à 3 dans l'édition gratuite) qui vous permettront d'exécuter des tâches en parallèle.

Answer 2

Utilisez un système de constructions dépendantes. Si vous utilisez SVN et que chaque projet se trouve dans son propre dossier, vous pouvez configurer un projet CI pour chacun de vos projets c# qui ne construit que ce projet et vous informe très rapidement de sa réussite ou de son échec.

Configurez un second projet CI avec un déclencheur de construction pour que le second projet CI se construise si le premier réussit et que le second projet exécute vos cas de test. J'ai fait cela en utilisant Jenkins avec un bon succès.

Pour une construction complète, vous pouvez avoir un autre projet CI qui surveille le dossier racine pour toute modification et lance une construction de la solution complète.

En procédant de la sorte, vous pouvez faire en sorte que chaque projet soit construit et renvoie des résultats rapidement lorsque le code est enregistré et un retour plus lent pour les tests du projet.

Answer 3

MSBuild fait la différence entre "build" et "rebuild" pour les cibles build script - le build normal ne construit que les projets qu'il voit comme étant modifiés depuis les builds précédents.

Cela dit, il devrait suffire de ne pas nettoyer le répertoire de construction de l'agent TeamCity lors de l'obtention de la source à partir du contrôle de la source (la possibilité de le faire peut dépendre du SCM - cela semble fonctionner correctement avec Mercurial) et de déclencher une construction, pas une reconstruction.

En ce qui concerne les tests unitaires, TeamCIty peut exécuter ceux qui ont échoué en premier, mais déterminer quels tests s'adressent à quelles parties du code source me semble être une tâche difficile, qui n'est pas prise en charge par TeamCity AFAIK.