Comment faire pour échouer construire TFS basé sur l'avertissement FXCop

Question

Nous utilisons actuellement TFS 2008 pour le contrôle de la source et l'intégration continue. Nous utilisons FXCop pour vérifier les performances et les avertissements de sécurité. Nous utilisons FXCop pour vérifier les performances et les avertissements de sécurité. L'architecte ou le développeur senior exécute FX Cop à la fin d'un sprint ou avant une livraison.

Nous aimerions que cela se fasse dans le cadre de l'IC et échoue la construction s'il y a un avertissement, quelle est la meilleure façon de le faire?

Answer 1

J'ai travaillé sur quelque chose de similaire. Même si cette question est un peu ancienne, j'espère que cela vous aidera.

J'ai commencé comme la plupart - en faisant un événement de post-construction qui appelle FxCopCmd.

Dans mon cas, je voulais juste un petit sous-ensemble du code, certaines des règles intégrées, ainsi que des règles personnalisées (dans un .dll)

J'ai utilisé un fichier de projet .fxcop pour cette - en configurant tout ce que je voulais via l'interface graphique, puis en pointant FxCopCmd sur le fichier projet dans l'événement post-build. Pour la plupart, cela a très bien fonctionné, mais les violations de règles ne sont apparues que comme des avertissements. L'option "Traiter les avertissements en tant qu'erreurs" ne semble pas s'appliquer à cela, j'ai donc dû trouver une solution différente. Ce qui a finalement fonctionné le mieux pour moi était basé sur un article de blog que je suis tombé sur. J'ai modifié le fichier de projet pour ajouter deux nouveaux événements.

J'ai quelques paramètres supplémentaires et des trucs pour FxCop, mais l'essentiel de celui-ci est:

1: <PropertyGroup> 
    2: <FxCopResults>$(ProjectDir)obj\$(Configuration)\FxCopResults.xml</FxCopResults> 
    3: <PostBuildEvent>"%25ProgramFiles%25\Microsoft FxCop 10.0\FxCopCmd.exe" /file:"$(TargetPath)" /console /out:"$(ProjectDir)obj\$(ConfigurationName)\FxCopResults.xml"</PostBuildEvent> 
    4: </PropertyGroup> 
    5: <Target Name="BeforeBuild"> 
    6: <Delete Files="$(FxCopResults)" ContinueOnError="true" /> 
    7: </Target> 
    8: <Target Name="AfterBuild"> 
    9: <Error Text="One or more FxCop warnings occurred." Condition="Exists('$(FxCopResults)')" /> 
    10: </Target> 

Le flux général est comme ceci:

1. (CONSTRUIRE PROCESSUS EST ENFONCÉ)
2. Avant le début d'une génération, les résultats FxCop précédents (s'ils existent) sont effacés.
3. événement pré-construction est déclenché
4. (BUILD COMMENCE)
5. événement post-construction est déclenché (qui court FxCopCmd)
6. Après la post-construction se termine, s'il y a des résultats FxCop, une erreur est élevé.
7. (BUILD EST PAS TERMINÉE)

Maintenant, si l'analyse FxCop généré - par exemple - 4 violations des règles, votre construction générerait 4 avertissements et 1 erreur.

J'espère que cela aide.

Answer 2

Vous pouvez jeter un oeil à la code analysis features within Visual Studio, qui est pris en charge pour une utilisation dans un environnement d'intégration continue.

Answer 3

En supposant que vous développiez MSBuild et des projets/solutions standard, vous pouvez configurer FXCop pour s'exécuter dans le cadre de chaque génération (client et serveur). Dans le dialogue des propriétés de votre projet, consultez l'onglet "Analyse de code". Notez que ceci peut être paramétré séparément pour les versions de débogage et de version, donc vous pouvez simplement les définir comme des erreurs pour les versions Release si cela facilite la vie de vos développeurs.

Ces paramètres FXCop vous permettent de définir que les violations apparaissent comme des erreurs au lieu des avertissements dans la version. Vous pouvez également activer la stratégie TFS qui nécessite que l'analyse de code ait été exécutée avec un ensemble défini de règles avant que l'archivage ne soit valide. Cela vous évitera des constructions rouges en forçant les développeurs à corriger les violations avant de les archiver.

Je recommande d'activer toutes ces choses - si vous visez ce niveau de qualité (ce qui n'est pas une mauvaise idée), il est bon de faire autant que vous pouvez pré-vérifier.