Bonjour,
Azure DevOps est un outil très puissant fourni par Microsoft, pour automatiser une grande partie du travail DevOps : Gestion de la PIC, mise en production etc.
Avant de s’appeler ainsi, la plateforme de Microsoft a eu plusieurs noms : Team Fondation Server, Visual Studio Online ou encore Visual Studio Team Services. Pratique pour garder nos CVs bien à jour !
La plateforme contient plusieurs outils bien pratiques auquel il pourrait être utile de revenir plus tard plus en détails :
Azure Board : Un système de ticketing pour gérer les projets
Azure Pipeline : Une partie servant à réaliser des tâches automatisées
Azure Repos : Un espace de dépôt Git illimité avec un système de pull requests
Azure Test Plan : Un kit de ressources pour les tests
Azure Artifacts : Pour gérer et partagez des packages comme NuGet
Le modèle économique de ce service est basé sur la vente de temps de calcul. Pour profiter ‘gratuitement’ de cet outil, il faut utiliser son propre matériel pour faire les calculs : avoir son usine de build en local.
Pour cela Il suffit de déclarer à Azure que les builds ne se feront pas sur leurs serveurs mais sur une machine locale (des Macs pour build des projets Xamarins). Faire ce changement de cible requiert quelques actions :
Pour que vous puissiez faire des compilations sur votre machine personnelle il faut qu’elle possède une autorisation et soit reconnue par Azure comme vous appartenant. Pour cela une clé d’accès est nécessaire : Le Personal Access Token PAT.
Cette clef doit provenir d’un admin du projet Azure sinon vous aurez un « access denied » (cf. le chapitre Configuration de l’usine).
Si vous voulez plus d’information sur les PAT rendez-vous sur le site de Microsoft :
Pour la création du PAT via Azure, il vous faut aller dans votre compte haut à droite, puis l’onglet sécurité.
Une fois sur la page l’onglet Personal Acces Tokens :
Sélectionnez : New token
Puis dans les options sélectionnez tous les droits, ainsi que la date de validité souhaitée. Date où le token ne sera plus valable et il vous faudra déclarer à nouveau l’agent à l'aide une autre clef, veillez donc à prendre une date plutôt large.
Cliquez le bouton sauvegarder et le PAT vous sera affiché sous forme d'une chaine de caractères.
Enregistrez bien le PAT, car IL EST IMPOSSIBLE de le récupérer via leur site. Il faudra en créer un autre le cas échéant.
Téléchargement de l’agent à partir d’azure
Dans votre projet sur Azure vous retrouvez cette interface. Cliquer sur la partie « Projet settings » (en bas à gauche) :
Puis dans la nouvelle page sélectionnée l’onglet Pipelines/Agents pools :
Puis cliquer sur le bouton "New Agent" :
Une fois le tar.gz sur votre disque ouvrez un terminal nous allons créer le fichier qui contiendra l’agent.
mkdir NomAgent && cd NomAgent
On continue avec le dé-zippage de l’agent dans le dossier :
tar zxvf ~/Downloads/vsts-agent-osx-x64-2.149.2.tar.gz
L’agent est maintenant décompressé sur votre disque :
Configuration de l’agent (listener)
Maintenant que les fichiers sont sur votre machine il s’agit de les configurer pour qu’Azure soit capable de les reconnaitre comme usine locale. C’est maintenant que nous allons utiliser la clef PAT créée précédemment sur Azure. Il faut lancer le script de configuration pour cela dans le terminal :
./config.sh
On accepte la "licence agreement" puis on entre l'URL de notre projet :
https://dev.azure.com/LENOMDEVOTREPROJET
Le type d’authentification est ensuite demandé, on choisit celui par défaut qui est le PAT. Collez ensuite votre Personnal Access Token récupéré plus haut.
Le nom de l’agent pool est demandé (à ne pas confondre avec le nom de l’agent). L’agent pool permet d'organiser les ordinateurs de l'entreprise qui réaliseront les tâches DevOps soit par site, soit par groupe de machines, soit par puissance, etc…
Le nom de l'Agent pool sélectionné dans Azure par défaut est "default". Taper Entrer pour le sélectionner. (Pour en créer un nouveau Il faut aller sur le site Azure).
Taper ensuite le nom de votre agent, qui identifiera votre machine parmi les autres de votre parc. Faites attention à ne choisir deux fois le même nom lorsque vous en avez plusieurs. Cela coupe l’accès de la première machine qui portait ce nom…
Avant de continuer je tiens à préciser un cas qui peut arriver lorsque plusieurs personnes travaillent sur un projet avec des droits différents.
Lors de la configuration un « Access denied » peut apparaitre après avoir rentré votre PAT, car vous n’avez pas les droits requis au sein du projet.
Demandez donc à l’admin Azure du projet de vous donner un PAT ou plus de droits.
Informations additionnelles
Pour notre projet nous avons utilisé des options supplémentaires.
1. Modification du run.sh
_________________________________
#!/bin/bash
# Validate not sudo
user_id=`id -u`
if [ $user_id -eq 0 ]; then
echo "Must not run interactively with sudo"
say erreur de lancement de NOM_AGENT
exit 1
fi
export JAVA_HOME=$(/usr/libexec/java_home)
export ANDROID_HOME=/Users/$(whoami)/Library/Developer/Xamarin/android-sdk-macosx
export PATH=/Library/Frameworks/Python.framework/Versions/3.7/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:
/sbin: /usr/local /share/dotnet:~/.dotnet/tools:/Library/Frameworks/Mono.framework/Versions/Current /Commands:/Applications/Xamarin Workbooks.app/Contents/SharedSupport/path-bin
# Change directory to the script root directory
# https://stackoverflow.com/questions/59895/getting-the-source-directory-of-a-bash-script-from-within
SOURCE="${BASH_SOURCE[0]}"
while [ -h "$SOURCE" ]; do # resolve $SOURCE until the file is no longer a symlink
DIR="$( cd -P "$( dirname "$SOURCE" )" && pwd )"
SOURCE="$(readlink "$SOURCE")"
[[ $SOURCE != /* ]] && SOURCE="$DIR/$SOURCE" # if $SOURCE was a relative symlink, we need to resolve it relative to the path where the symlink file was located
done
DIR="$( cd -P "$( dirname "$SOURCE" )" && pwd )"
# Do not "cd $DIR". For localRun, the current directory is expected to be the repo location on disk.
say demarrage NOM_AGENT
# Run
shopt -s nocasematch
if [[ "$1" == "localRun" ]]; then
$DIR/bin/Agent.Listener $*
else
$DIR/bin/Agent.Listener run $*
fi
say arret de NOM_AGENT
_________________________________
Les ajouts de type "say" permettent à l'usine de build sous macOS d'annoncer le démarrage de ses agents. Le logiciel "Automator" permet lui, de lancer les agents au démarrage de la machine.
Les exports eux, correspondent à des problématiques de publications que nous verrons plus tard. Pas de spoil ici donc.
NOM_AGENT est à remplacer par un autre nom si vous voulez un message personnalisé pour l’appareil.
2. Script additionnel utilisable via alias
Si votre usine de build requiert des scripts personnalisés cette étape vous permet de les rendre accessibles facilement via d’autres scripts bash.
Pour notre exemple "updateAssemblies" est un script que nous utilisons spécialement pour mettre à jour les numéros de version. Cet alias nous évite ainsi d'écrire le chemin complet dans tous les scripts. Pour configurer les alias nous modifierons le fichier de configuration bash nommé : .bash_profile.
Pour le créer au bon endroit, allez dans votre répertoire home et créez un fichier .bash_profile et collez le contenu suivant :
_________________________________
export PS1="\[\033[36m\]\u\[\033[m\]@\[\033[32m\]\h:\[\033[33;1m\]\w\[\033[m\]\$"
export CLICOLOR=1
export LSCOLORS=ExFxBxDxCxegedabagacad
alias ls='ls -GFh'
alias nuget='mono /usr/local/bin/nuget.exe'
alias apksigner='/Users/$(whoami)/Library/Developer/Xamarin/android-sdk-macosx/build-tools/28.0.0/apksigner'
alias lsa='ls -la'
alias updateAssemblies='/Users/$(whoami)/Scripts/UpdateVersionAssemblies.sh'
alias alertMac='afplay /Users/$(whoami)/Scripts/red_alert.mp3'
# Setting PATH for Python 3.7
# The original version is saved in .bash_profile.pysave
PATH="/Library/Frameworks/Python.framework/Versions/3.7/bin:${PATH}"
export PATH
_________________________________
Le fichier contient des raccourcis intéressants pour l'utilisation du terminal tel que de la coloration ou l'ajout du "lsa" qui est un exemple d'utilisation d'alias.
