Pour moi, Powershell est le chemin à parcourir. Voici mes raisons pour lesquelles:
- Script Indépendance:
Vous obtenez l'indépendance de script en utilisant cette approche. Exemple: J'ai un certain nombre de scripts exécutés après la construction (la compilation) processus est terminé:
- Instantiate Database
- Déployer le code de base de données
- déployer des applications Web
- contrôler le déploiement
- Exécuter des tests d'acceptation
Tout ce qui précède peut être lancé, débogué et testé indépendamment sans devoir faire la queue nouvelle construction.
- Powershell est facile de travailler avec:
ensembles personnalisés ont tendance à ajouter beaucoup de complexité et squames à la solution. Exemple: La mise à niveau de TFS 2010 à TFS 2012 a été très douloureuse, car tous les modèles de construction ont été cassés. Nous avons dû recompiler tous nos assemblages personnalisés, et seul un développeur de l'équipe savait comment TFS Build était configuré pour exécuter nos activités personnalisées. J'ai récemment supprimé tous les assemblys personnalisés de nos modèles de construction et j'utilise Powershell exclusivement.
J'ai personnalisé mes modèles de processus pour appeler un script PowerShell défini par l'utilisateur une fois la compilation TFS terminée. Je fais ceci en utilisant un argument de chemins dans la définition de construction. Cet argument est simplement un tableau de chaînes pointant vers les scripts. Je suis d'accord avec Ewald, ci-dessus, que TFS ne passe pas les arguments de construction aux scripts.Pour résoudre ce problème, dans mon modèle de flux de travail, j'analyse chaque script dans le tableau de chaînes et remplace les jetons bien connus par les arguments de génération - par ex. @ (BuildNumber), @ (SourcesDirectory) etc. Je trouve que c'est une solution très facile et solide.
Donc, essentiellement, un script powershell est un substitut pour les activités personnalisées et il semble que les deux servent le même but. Puis-je mélanger et associer PS et les activités? Puis-je invoquer un script PS à partir d'une activité personnalisée? – DotnetDude
Dans l'activité personnalisée, vous avez accès à tous les arguments et variables de la construction. Ce n'est donc pas un substitut. Vous pouvez l'utiliser mélangé. –
Pour appeler le script PS, le plus simple est d'ouvrir le modèle de processus de génération et d'ajouter un nouvel argument au modèle de processus de construction pour transmettre le script souhaité. Ajoutez une activité convertWorkspace pour convertir le chemin d'un chemin contrôlé par version vers le chemin local. Ajoutez ensuite une nouvelle activité InvokeProcess qui exécute Powershell avec l'argument "@". –