Configurez ALI dans Agile Manager afin d'utiliser les serveurs de builds et les serveurs SCM dans votre environnement local. Pour plus d'informations, reportez-vous à la section Supported environments and frameworks.
Pour configurer ALI ou afficher la configuration actuelle, sélectionnez Configuration > Récapitulatif ALI. Utilisez l'assistant pour vous guider lors de chaque étape de configuration de ALI ou pour configurer ALI manuellement.
Tip:
L'assistant de configuration de ALI est disponible sur toutes les pages de configuration ALI.
Configurez une ou plusieurs tâches de build ou branches de code source si nécessaire. Vous pouvez configurer plusieurs tâches de build (toutes du même type ou chacune d'un type différent, par exemple des tâches du serveur Jenkins et des tâches du serveur TFS). Vous pouvez en outre configurer plusieurs branches de code source, soit pour diverses branches GIT, soit pour GIT, SVN, TFS, etc.
La configuration ALI comprend les étapes suivantes :
Intégration | Gestion des builds | Gestion du code source |
---|---|---|
|
Ajoutez les informations concernant le serveur de builds et les configurations du serveur de builds. Utilisez l'assistant pour ajouter un nouveau serveur de builds ou une nouvelle configuration, ou mettre à jour un serveur existant. Cliquez sur Ajouter un serveur de builds pour le faire manuellement. Configurez les paramètres supplémentaires sur la page Builds. Pour plus d'informations, reportez-vous aux sections suivantes : |
|
La configuration ALI est automatiquement validée en arrière-plan et les utilisateurs sont informés des erreurs détectées.
Configuration ALI |
Validée sur une base horaire. Cela vous permet de détecter les problèmes de synchronisation, notamment les mots de passe ayant expiré ou les connexions impossible à établir. |
Connectivité et synchronisation Dev Bridge |
Validées régulièrement lorsque les utilisateurs parcourent les pages ALI. Cela vous permet de vérifier que la passerelle est connectée à Agile Manager, et que les données les plus récemment synchronisées sont à jour. |
Les administrateurs de site peuvent désormais activer les artefacts ALI (serveurs de builds et référentiels SCM) en vue de les utiliser sur plusieurs espaces de travail. En d'autres termes, les administrateurs de divers espaces de travail peuvent utiliser les mêmes serveurs de builds et référentiels SCM lorsqu'ils configurent ALI pour les releases de leurs espaces de travail.
Une fois un artefact partagé, la plupart de ses paramètres de configuration sont disponibles uniquement en lecture seule, à l'exception des informations d'identification des artefacts, que l'administrateur de l'espace de travail doit saisir avant d'utiliser l'artefact partagé dans l'espace de travail.
Pour le serveur de builds, les informations d'identification correspondent toujours au nom d'utilisateur et au mot de passe du serveur de builds. Pour les référentiels SCM, les informations d'identification comprennent les noms d'utilisateur, les mots de passe, les certificats clients et les phrases secrètes.
Partagez des artefacts dans les pages d'informations sur le serveur de builds et le référentiel SCM. Pour plus d'informations, reportez-vous aux sections suivantes :
Note: pour supprimer le partage d'un artefact (ou supprimer l'artefact proprement dit), vous devez tout d'abord vérifier que l'artefact n'est pas utilisé dans une configuration ALI dans l'un des espaces de travail du site.
Si votre serveur de builds ou SCM nécessite l'utilisation du protocole HTTPS pour s'y connecter, le certificat du serveur (certificat de serveur SSL) doit être approuvé par les clients (en l'occurrence, ALI Dev Bridge). Si votre serveur utilise un certificat autosigné ou un certificat signé par votre autorité de certification personnelle, vous devez ajouter votre certificat racine ou autosigné au magasin d'approbations utilisé par ALI Dev Bridge.
Vous pouvez utiliser l'outil de clé Java pour ajouter votre certificat au magasin d'approbations :
keytool -importcert -alias my_custom_authority -trustcacerts –file cert_authority.crt
Cette commande ajoute le certificat cert_authority.cer au magasin d'approbations de votre JRE/JDK. Si votre navigateur Web utilise un autre magasin d'approbations, vous devez le spécifier sur la ligne de commande (-file).
Procédez comme suit :
Vérifiez que l'agent de build ALI a été installé sur le serveur de builds, et que ALI est activé pour votre tâche de build (action post build ALI). Si ALI n'est pas activé pour la tâche de build, la configuration de build (tâche) ne s'affiche pas dans la liste des tâches de build qu'il est possible de sélectionner sur le serveur de builds.
Le chargement initial du code source peut prendre plusieurs heures. Cela dépend des facteurs suivants :
Si votre serveur Jenkins/Hudson utilise un mécanisme d'authentification modifié, il est possible que vous deviez activer l'authentification préemptive. Procédez comme suit :
Vérifiez que l'utilisateur est autorisé à obtenir toutes les informations de build ALI. Pour cela, connectez-vous à Jenkins et vérifiez les liens ALI :
Lien Intégration ALI de premier niveau
Lien Intégration ALI au niveau de la tâche
Liens Intégration ALI , Couverture de code, Résultats du test et Modifications de code au niveau du build
Vérifiez le statut de ALI Dev Bridge affiché sur la page Récapitulatif ALI, sous Intégration.
Note: Internet Explorer 9 et Firefox 23 ou les versions ultérieures ne permettent pas aux utilisateurs d'afficher les pages comportant à la fois du contenu sécurisé et non sécurisé (contenu provenant de connexions HTTP et HTTPS).
Ces versions :
Pour plus d'informations, consultez les pages http://blogs.msdn.com/b/ie/archive/2011/06/23/internet-explorer-9-security-part-4-protecting-consumers-from-malicious-mixed-content.aspx (Internet Explorer 9) et https://blog.mozilla.org/security/2013/05/16/mixed-content-blocking-in-firefox-aurora/ (Firefox 23 ou versions ultérieures).