Ce tutoriel explique comment utiliser TeamCity pour exécuter les scripts de ligne de commande qui sont à la base de vos pipelines de build.
Nous avons créé un dépôt GitHub dans le cadre de la démonstration :
github.com/marcobehlerjetbrains/buildpipelines. N'hésitez pas à l'utiliser et suivre les instructions.
Le dépôt comporte 2 microservices : Authorization-Service et Calculator-Service. Vous pouvez copier l'URL, aller dans vos services TeamCity et créer un nouveau projet depuis l'URL du dépôt. Dans la mesure où il s'agit d'un dépôt public, vous n'avez pas à entrer de mot de passe ou de jeton d'accès.
Au cours de l'étape suivante, TeamCity se connecte au dépôt et l'utilise pour créer un projet. Cela vous révèle également la branche par défaut, qui est la branche principale qui va être extraite toutes les 60 secondes pour identifier les changements et déclencher des builds.
Vous pouvez également spécifier les autres branches à surveiller en utilisant des caractères génériques.
Une configuration de build dans TeamCity est une tâche. Lorsque vous configurez un projet, TeamCity analyse les fichiers de votre dépôt et détecte automatiquement les étapes de build pour vous.
Dans ce tutoriel, nous n'allons pas poursuivre les étapes de build autodétectées, car nous disposons de notre propre script de ligne de commande à exécuter. Cependant, il est important de noter que TeamCity peut analyser le dépôt du système de contrôle de version source d'un projet et détecter automatiquement les étapes de build à suivre dans Node.js, Kotlin, Python, Ant, NAnt, Gradle, Maven, MSBuild, les fichiers de solution Visual Studio, PowerShell, les fichiers de projet Xcode, Rake et les projets IntelliJ IDEA.
Pour poursuivre la configuration de l'étape manuelle de build, cliquez sur ce lien :
Dans la mesure où nous souhaitons exécuter un script de ligne de commande, nous allons choisir Command Line dans le menu déroulant.
Au cours de l'étape suivante, nous allons choisir l'option Run Custom Script dans le menu déroulant et coller notre script de build dans le champ approprié. Nous allons exécuter la commande mvn clean package
. Comme de nombreux autres outils, ce paquet est installé par défaut sur tous nos agents de build.
mvn clean package
compile les sources Java, exécute des tests et crée un fichier .jar
.
Au cours de l'étape de déploiement, nous exécutons l'outil de ligne de commande AWS, puis copions le fichier .jar
qui vient d'être créé dans un compartiment S3 privé. Ensuite, il ne nous reste plus qu'à appuyer sur Save.
Avant d'appuyer sur le bouton Run, nous devons spécifier les informations d'authentification pour notre compartiment S3 AWS, à savoir l'identifiant et le secret de la clé d'accès. L'une des façons de procéder consiste à utiliser Parameters dans TeamCity.
Pour ajouter des paramètres, cliquez sur Parameters | Add New Parameter. Pour l'instant, nous allons n'utiliser qu'une seule variable d'environnement. Entrez le nom, qui est AWS_ACCESS_KEY_ID
. Vous aurez aussi besoin de sélectionner le type du nouveau paramètre (Environment variable (env.) dans notre cas) et de coller l'identifiant de clé d'accès.
Remarque importante : la clé d'accès que nous utilisons sert uniquement pour la démonstration, vous ne pouvez pas réutiliser cette clé.
Nous voulons également modifier le paramètre et définir le type sur Password. Cela signifie que TeamCity va masquer la valeur du paramètre non seulement dans l'interface utilisateur, mais également dans les messages de journaux et partout ailleurs.
Vous verrez alors que l'identifiant de clé d'accès est déjà masqué.
De même, nous pouvons ajouter une nouvelle variable d'environnement : la clé d'accès secrète. Ensuite, nous devrions pouvoir exécuter le build.
Pour ce faire, cliquez sur le bouton Run qui vous redirige vers la page de vue d'ensemble. Pendant que TeamCity exécute le build, il affiche les journaux correspondants pour donner le détail des opérations.
Dès que le build a fini de s'exécuter, TeamCity affiche le statut du build et ses données, comme par exemple l'heure de déclenchement et par qui, la durée d'exécution et l'agent de build utilisé.
Parce que nous exécutons des scripts de ligne de commande, la seule véritable sortie dont nous disposons est le journal de build. Si nous avions utilisé un exécuteur TeamCity à la place (p. ex. l'exécuteur Maven), nous aurions aussi directement obtenu un rapport de test et un autre de couverture, ainsi que de nombreuses autres fonctionnalités, telles que des tests parallèles.
Pour accéder au journal de build, cliquez sur l'onglet Build Log dans la page de résultats de votre build. TeamCity simplifie considérablement la lecture des journaux ! Au lieu de vous forcer à télécharger l'intégralité du journal de build sur votre machine (ce que vous pouvez toujours faire), puis de l'ouvrir avec Notepad++, TeamCity réduit le journal de build et permet de faire facilement des recherches avec le raccourci Ctrl+F.
C'est tout pour le moment ! Regardez les autres tutoriels pour apprendre comment utiliser les fonctionnalités propres à TeamCity, telles que des rapports de test ou de couverture du code.
Joyeux builds !
Pour en savoir plus, consultez la documentation sur la ligne de commande de TeamCity (en anglais).
Découvrez comment intégrer une étape de build SSH Exec dans vos configurations de build et comment charger une clé SSH dans TeamCity pour la transférer aux agents de build.
TeamCity réunit un grand nombre de fonctionnalités qui permettent de booster vos builds. En este tutorial, exploraremos cómo utilizar ejecutores específicos y por qué querrá utilizarlos.
En TeamCity, puede obtener fácilmente datos de sus compilaciones con la ayuda de artefactos. Ce tutoriel montre plus en détail comment travailler avec les artefacts dans TeamCity.