L'Intégration Continue, aussi connue sous le terme l'IC, est l'un des piliers du développement logiciel moderne. En fait, elle est un véritable tournant — quand l'Intégration Continue est mise en place dans une organisation, elle change radicalement la manière dont les équipes pensent le processus de développement. Elle est capable de permettre et d'induire toute une série d'améliorations et de transformations, depuis le build régulier automatisé jusqu'à la livraison continue en production. Une bonne infrastructure IC peut fluidifier le processus de développement jusqu'au déploiement, aide à détecter et corriger les bogues plus rapidement, fournit un écran de contrôle très utile aux développeurs mais aussi aux non-développeurs, et poussée à l'extrême, elle permet aux équipes de fournir plus de valeur métier aux utilisateurs finaux. Toute équipe de développement professionnelle, quelque soit sa taille, devrait mettre en œuvre l'IC.

A l'époque des projets en V et des diagrammes de Gantt, avant l'introduction des pratiques de l'IC, une équipe de développement dépensait son temps et son énergie sans compter durant la phase amenant à la livraison, appelée Phase d'Intégration. Durant cette phase, toutes les modifications apportées au code par les développeurs ou de petites équipes étaient rassemblées puis agrégées et fusionnées en un produit fonctionnel. Ce travail était dur, intégrant ainsi des mois de modifications qui entraient en conflit. Il était très difficile d'anticiper les problèmes qui allaient surgir, et encore plus de les corriger car cela impliquait de reprendre du code qui avait été écrit des semaines, voire des mois auparavant. Ce douloureux processus, plein de risques et de dangers, amenait souvent des retards significatifs de livraison, des coûts supplémentaires et, au final, des clients mécontents. L'Intégration Continue est née comme une réponse à ces problèmes.

L'Intégration Continue, dans sa forme la plus simple, se compose d'un outil qui surveille les modifications de code dans votre gestionnaire de configuration. Dès qu'un changement est détecté, cet outil va automatiquement compiler et tester votre application. Si la moindre erreur arrive alors l'outil va immédiatement avertir les développeurs afin qu'ils puissent tout de suite corriger le problème.

Mais l'Intégration Continue est bien plus que cela. L'Intégration Continue peut aussi suivre la santé de votre projet en surveillant la qualité du code et les métriques de couverture et ainsi aider à maintenir la dette technique à un niveau bas et à abaisser les coûts de maintenance. Rendre visible publiquement les métriques de qualité de code encourage les développeurs à être fiers de la qualité de leur code et à essayer de toujours l'améliorer. Combinée à une suite de tests d'acceptance automatisés, l'IC peut aussi se transformer en outil de communication en affichant une image claire de l'état des développements en cours. Et elle peut simplifier et accélerer la livraison en vous aidant à automatiser le processus de déploiement, vous permettant de déployer la dernière version de votre application soit automatiquement soit d'un simple clic.

Dans le fond, l'Intégration Continue c'est réduire les risques en fournissant des retours rapides. En premier lieu, de par sa conception, elle permet d'identifier et de corriger les problèmes d'intégration et les regressions plus rapidement ce qui permet de livrer plus facilement et avec moins de bogues. En donnant une meilleure visibilité sur l'état du projet à tous les membres de l'équipe, techniques comme non-techniques, l'Intégration Continue facilite la communication au sein de l'équipe et encourage la collaboration pour résoudre les problèmes ainsi que l'amélioration du processus. Et, en automatisant le processus de déploiement, l'Intégration Continue vous permet de mettre votre logiciel dans les mains des testeurs et des utilisateurs finaux plus rapidement, avec plus de fiabilité et avec moins d'efforts.

Ce concept de déploiement automatisé est important. En effet, si vous poussez ce concept de déploiement automatisé à sa conclusion logique, vous pourriez mettre en production tout build qui passerait sans encombre les tests automatisés nécessaires. Cette pratique de déployer en production tous les builds ayant réussi est appelée communément Déploiement Continu.

L'Intégration Continue n'est pas une histoire de tout ou rien. En fait, mettre en place l'IC au sein d'une organisation suit un chemin qui vous fera passer par différentes phases. A chacune de ces phases se rattachent des améliorations de l'infrastructure technique, mais aussi, et c'est peut-être le plus important, des améliorations des pratiques et de la culture de l'équipe de développement elle-même. Dans les paragraphes qui vont suivre j'ai essayé d'esquisser chacune de ces phases.

Au tout début, l'équipe n'a pas de serveur central de build quel qu'il soit. Le logiciel est construit manuellement sur la machine du développeur, même si cela peut être réalisé par un script Ant ou équivalent. Le code source peut être enregistré dans un gestionnaire de configuration centralisé, mais les développeurs n'ont pas l'habitude de commiter leurs modifications régulièrement. Peu de temps avant la prochaine livraison prévue, un développeur intègre manuellement les modifications, une opération qui produit beaucoup de peine et de souffrance.

Dans cette phase, l'équipe possède un serveur de build et des builds automatisés sont exécutés régulièrement (généralement la nuit). Ce build compile tout simplement le code car il n'existe pas de tests unitaires pertinents et répétables. En effet, les tests automatisés, même s'ils sont écrits, ne font pas partie du processus de build, et peuvent ne pas s'exécuter correctement du tout. Cependant, maintenant les développeurs commitent leurs modifications régulièrement au moins à la fin de la journée. Si un développeur commite des modifications de code qui entrent en conflit avec le travail d'un autre développeur, le serveur de build avertit l'équipe par mail le lendemain matin. Toutefois, l'équipe ne se sert du serveur de build qu'à titre informatif — ils ne se sentent pas obligés de réparer un build en échec immédiatement, et le build peut rester en échec pendant plusieurs jours sur le serveur de build.

L'équipe commence à prendre l'Intégration Continue et les tests au sérieux. Le serveur de build est configuré pour lancer un build dès qu'un nouveau code est commité dans l'outil de gestion de configuration et les membres de l'équipe peuvent facilement voir quelles sont les modifications du code qui correspondent à chaque build et de quel problème elles traitent. A cela s'ajoute le fait que le script de build compile l'application et lance une série de tests unitaires ou d'intégration automatisés. En plus des emails, le serveur de build avertit aussi les membres de l'équipe des problèmes d'intégration en utilisant des canaux plus proactifs tel que la messagerie instantanée. Les builds en echec sont maintenant réparés rapidement.

Des métriques de qualité et de couverture de code automatisées sont maintenant mesurées pour aider à évaluer la qualité du code et (jusqu'à un certain point) la pertinence et l'efficacité des tests. Le build mesurant la qualité de code produit aussi automatiquement la documentation de l'API de l'application. Tout ceci permet à l'équipe de maintenir un code de très bonne qualité, alertant les membres de l'équipe en cas de dérive des bonnes pratiques de tests. L'équipe a aussi monté un “build radiator”, un tableau de bord qui présente l'état du projet sur un écran visible de l'ensemble des membres de l'équipe.

Les bénéfices de l'Intégration Continue sont étroitement liés à de solides pratiques de test. De nos jours, des techniques comme le développement piloté par les tests sont très utilisées ce qui améliore la confiance que l'on peut avoir dans le résultat d'un build automatisé. L'application n'est plus simplement compilée et testée, mais si les tests passent, elle est automatiquement déployée sur un serveur d'application pour des tests plus complets de bout en bout et des tests de performance.

Le développment piloté par les tests d'acceptance est utilisé, guidant les efforts de développement et fournissant des rapports de haut niveau sur l'état du projet. Ces tests automatisés profitent des outils issus du monde du Développement piloté par le comportement (BDD) et du Développement piloté par les tests d'acceptance non seulement comme outils de tests mais aussi comme outils de communication et de documentation, en produisant des rapports de tests utilisant les termes métier qu'un non-développeur peut comprendre. Puisque ces tests de haut-niveau sont automatisés dès le début du processus de développement, ils permettent de savoir très simplement quelles sont les fonctionnalités qui sont réalisées et celles qu'il reste à faire. L'application est automatiquement déployée sur un environnement de test pour l'équipe qualité (QA) soit à chaque modification soit tous les soirs ; une version peut être déployée (ou “promue”) pour des tests de conformité utilisateurs et il est possible de la déployer dans des environnements de production au moyen d'un build lancé manuellement quand les testeurs la considère prête. L'équipe peut aussi utiliser le serveur de build pour revenir en arrière d'une version en cas de catastrophe.

La confiance dans les tests unitaires, d'intégration et d'acceptance automatisés est telle que les équipes peuvent utiliser les techniques de déploiement continu développées dans les phases précédentes pour pousser les modifications directement en production.

La progression entre les niveaux décrite ici est approximative et peut ne pas correspondre exactement à des situations dans le monde réel. Par exemple, vous pouvez tout à fait introduire des tests de l'interface web avant de mettre en places les métriques de qualité de code et les rapports sur la couverture de code. Cependant, cela devrait vous donner une idée globale de la stratégie d'Intégration Continue à mettre en oeuvre dans une organisation du monde réel.

Jenkins est un outil logiciel d’intégration continu. Il s’agit d’un logiciel open source, développé à l’aide du langage de programmation Java. Il permet de tester et de rapporter les changements effectués sur une large base de code en temps réel. En utilisant ce logiciel, les développeurs peuvent détecter et résoudre les problèmes dans une base de code et rapidement. Ainsi les tests de nouveaux builds peuvent être automatisés, ce qui permet d’intégrer plus facilement des changements à un projet, de façon continue. L’objectif de Jenkin est en effet d’accélérer le développement de logiciels par le biais de l’automatisation. Jenkins permet l’intégration de toutes les étapes du cycle de développement.

L’intégration continue est assurée par le biais de plugins. Ces plugins permettent l’intégration de diverses étapes de Various DevOps. Pour intégrer un outil particulier, il est nécessaire d’installer les plugins correspondant à cet outil : Git, Maven 2 project, Amazon EC2, HTML Publisher…

Jenkins présente plusieurs avantages. Il s’agit d’un outil open source fédérant une vaste communauté proposant sans cesse de nouvelles améliorations et autres perfectionnements. Le logiciel est facile à installer, et plus de 1000 plugins sont disponibles. Si un plugin correspondant à vos besoins n’existe pas, vous pouvez le créer vous-même et le partager avec la communauté. Autre avantage : Jenkins est également gratuit. Enfin, en tant qu’outil développé avec Java, il peut être porté sur toutes les principales plateformes logicielles.

Par ailleurs, Jenkins se distingue de la plupart des autres outils d’intégration continue par plusieurs points. Tout d’abord, Jenkins est adopté de manière bien plus large que ses concurrents. Au total, on dénombre 147 000 installations actives et plus d’un million d’utilisateurs autour du monde. L’autre force de Jenkins est son interconnexion avec plus de 1000 plugins permettant de l’intégrer à la plupart des outils de développement, de test et de déploiement.

Voici comment se déroule généralement le fonctionnement de Jenkins. Un développeur insère son morceau de code dans le répertoire du code source. Jenkins, de son côté, vérifie régulièrement le répertoire pour détecter d’éventuels changements. Lorsqu’un changement est détecté, Jenkins prépare un nouveau build. Si le build rencontre une erreur, l’équipe concernée est notifiée. Dans le cas contraire, le build est déployé sur le serveur test. Une fois le test effectué, Jenkins génère un feedback et notifie les développeurs au sujet du build et des résultats du test.

java-1.8.0-openjdk

Installation de java 8

# yum install java-1.8.0-openjdk

Jenkins stable repository.

# wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat-stable/jenkins.repo

Import the repo key.

# rpm --import https://jenkins-ci.org/redhat/jenkins-ci.org.key

Install package.

# yum install jenkins

Redémarrage du service

# service jenkins restart

Installation de java 8.

root@jenkins:~# apt-get install default-jre

Jenkins stable repository.

root@jenkins:~# wget -q -O - http://pkg.jenkins-ci.org/debian-stable/jenkins-ci.org.key | apt-key add -
root@jenkins:~# echo "deb http://pkg.jenkins-ci.org/debian-stable binary/" | tee -a /etc/apt/sources.list

Mise à jour du cache et installation des packages.

root@jenkins:~# apt-get update
root@jenkins:~# apt-get install jenkins -y

Redémarrage du service

root@jenkins:~# systemctl status jenkins
● jenkins.service - LSB: Start Jenkins at boot time
   Loaded: loaded (/etc/init.d/jenkins; generated; vendor preset: enabled)
   Active: active (exited) since Wed 2019-07-24 20:56:34 CEST; 14s ago
     Docs: man:systemd-sysv-generator(8)

juil. 24 20:56:33 jenkins systemd[1]: Starting LSB: Start Jenkins at boot time...
juil. 24 20:56:33 jenkins jenkins[5862]: Correct java version found
juil. 24 20:56:33 jenkins su[5892]: Successful su for jenkins by root
juil. 24 20:56:33 jenkins su[5892]: + ??? root:jenkins
juil. 24 20:56:33 jenkins su[5892]: pam_unix(su:session): session opened for user jenkins by (uid=0)
juil. 24 20:56:34 jenkins jenkins[5862]: Starting Jenkins Automation Server: jenkins.
juil. 24 20:56:34 jenkins systemd[1]: Started LSB: Start Jenkins at boot time.

Une fois Jenkins installé, il ne vous reste plus qu'à accéder, via votre navigateur web, à son interface.

Par défaut, Jenkins écoute sur le port 8080 ; donc, en fonction de l'adresse de votre serveur d'intégration, vous utiliserez une URL de ce type pour y accéder :

http://192.168.0.10:8080/

Ou, si vous avez défini une entrée DNS ou un alias dans votre fichier hosts, vous utiliserez quelque chose de ce type :

http://jenkins:8080/

Suivez les instruction de configuration de démarrage de Jenkins. Jenkins veut juste s’assurer qu’il s’agit bien d’un administrateur de la plateforme. Suivez les instructions. Copiez et collez le mot de passe comme indiqué.

Jenkins vous propose d’installer les plugins par défaut ou de sélectionner vous mêmes les plugins que vous souhaitez installer. Vous pouvez effectuer le choix par défaut. Tout en sachant qu’il sera toujours possible d’ajouter des plugins une fois l’installation terminée.

Une fois le choix réalisé, l'installation s’opère.

Créer le premier utilisateur lors de la configuration de démarrage.

Jenkins vous propose de configurer une instance pour terminer l’installation. Ici vous êtes libre de modifier le port et mettre un port à votre convenance.

Notre plateforme est prête.

Voici l'interface par défaut de Jenkins.

Les serveurs d'intégration continue utilisent beaucoup de mémoire. Les 'builds' consomment de la mémoire, et plusieurs 'builds' exécutées en parallèle consomment encore plus de mémoire.

Vous devez donc vous assurer que votre serveur de build dispose de suffisamment de RAM pour gérer le nombre de builds que vous souhaitez exécuter simultanément.

Jenkins a naturellement besoin de RAM pour fonctionner, mais si vous devez prendre en charge un grand nombre de processus de 'builds', il ne suffit pas de lui donner beaucoup de mémoire.

En fait, Jenkins créer un nouveau processus Java chaque fois qu'il lance un build. Ainsi, lors d'un 'build' volumine, le processus de construction a besoin de mémoire, pas de Jenkins.

Vous pouvez définir des options de mémoire spécifiques à chaque 'build' pour vos 'jobs' Jenkins.

Pour allouer une quantité de mémoire à notre serveur jenkins, nous allons éditer notre fichier de configuration et décommenter la paramètre “-Xmx”.

Pour les distributions Debian et dérivée :

# nano /etc/default/jenkins
...
JAVA_ARGS="-Xmx512m"
...

Pour les distributions Redhat et dérivée :

# nano /etc/sysconfig/jenkins
...
JENKINS_JAVA_OPTIONS="-Xmx512m"
...

Nginx est un serveur Web puissant et un excellent proxy inverse. Dans notre cas, nous souhaitons l’utiliser devant notre application Jenkins:

• Pour gérer toutes les configurations de sécurité telles que les certificats SSL et la sécurité des demandes entrantes.
• Pour autoriser toutes les demandes entrantes à atteindre les ports http traditionnels 80/443 et à laisser le serveur Jenkins CI s'exécuter en interne sur le port 8080.

Pour les distributions Debian et dérivée.

root@jenkins:~# apt-get install nginx

Pour les distributions RedHat et dérivée.

root@jenkins:~# yum install nginx

On vérifier l'état du service “nginx”.

root@jenkins:~# systemctl status nginx
● nginx.service - A high performance web server and a reverse proxy server
   Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2019-07-24 21:49:46 CEST; 1min 22s ago
     Docs: man:nginx(8)
  Process: 7108 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
  Process: 7107 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
 Main PID: 7111 (nginx)
    Tasks: 2 (limit: 4915)
   CGroup: /system.slice/nginx.service
           ├─7111 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
           └─7112 nginx: worker process

on crée le vhosts jenkins qui va proxifier les flux du nom de domaine “jenkins.oowy.lan” vers la “localhost” sur le port “8080”.

root@jenkins:~# nano /etc/nginx/sites-available/jenkins
upstream jenkins{
    server 127.0.0.1:8080;
}
 
server{
    listen      80;
    server_name jenkins.domain.lan;
 
    access_log  /var/log/nginx/jenkins.access.log;
    error_log   /var/log/nginx/jenkins.error.log;
    ignore_invalid_headers off;
 
    location / {
 
        proxy_set_header    Host            $host:$server_port;
        proxy_set_header    X-Real-IP       $remote_addr;
        proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header    X-Forwarded-Proto $scheme;
 
        # Required for new HTTP-based CLI
        proxy_http_version 1.1;
        proxy_request_buffering    off; # Required for HTTP CLI commands in Jenkins > 2.54
        proxy_buffering            off; # Required for HTTP CLI commands in Jenkins > 2.54
 
        proxy_pass          http://jenkins;
        proxy_read_timeout  90;
 
        proxy_redirect      http://127.0.0.1:8080 http://jenkins.domain.lan;
 
        # workaround for https://issues.jenkins-ci.org/browse/JENKINS-45651
        add_header 'X-SSH-Endpoint' 'jenkins.domain.lan:50022' always;
 
    }
}

Sous la distribution “debian”, on crée le liens symbolique.

root@jenkins:~# cd /etc/nginx/sites-enabled/
root@jenkins:/etc/nginx/sites-enabled# ln -s /etc/nginx/sites-available/jenkins

On vérifie la configuration de nginx avant de le redémarrer

root@jenkins:/etc/nginx/sites-enabled# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

On redémarre le serveur web nginx.

root@jenkins:/etc/nginx/sites-enabled# systemctl restart nginx

Toujours depuis la connexion via l'adresse IP, il suffira de mettre à jour le paramètre : URL de Jenkins

Administrer Jenkins > Configurer le système remplacer l'ip par l'url et Enregistrer

Si l'on se rend à l'url : “jenkins.oowy.lan”

Maintenant, notre serveur Jenkins CI écoute sur le port 8080 et que nous avons Nginx qui envoie toutes les demandes entrantes du port 80 au port 8080. La dernière étape consiste à fermer l’accès direct au Jenkins par le biais du port 8080, de sorte que toutes les demandes transitent par le port http standard 80.

Pour cela, nous allons modifier la configuration de Jenkins.

Editer le fichier “/etc/default/jenkins” et ajouter le paramètre "--httpListenAddress=127.0.0.1" à la fin du fichier de configuration dans la variable “JENKINS_ARGS”. L'ajout de cette entrée va forcer Jenkins à n'écouter que les requêtes local donc provenant de notre serveur nginx qui fait office de reverse-proxy.

Pour les distributions debian et dérivée :

# nano /etc/default/jenkins

Pour les distributions Redhat et dérivée :

# nano /etc/sysconfig/jenkins

Et on ajoute comme indiqué le paramètre “–httpListenAddress=127.0.0.1”

...
JENKINS_ARGS="--webroot=/var/cache/$NAME/war --httpPort=$HTTP_PORT --httpListenAddress=127.0.0.1"

Maintenant que nous venons de modifier la configuration de Jenkins, nous redémarrons celui-ci.

root@jenkins: systemctl restart jenkins

Dans la plupart des environnements d'entreprise, votre serveur Jenkins sera situé derrière un pare-feu, et n'aura pas un accès direct à Internet. Jenkins a besoin d'un accès Internet pour télécharger les plugins et les mises à jour, et aussi pour installer les outils tels que le JDK, Ant et Maven depuis des sites distants. Si vous avez besoin de passer par un serveur proxy HTTP pour accéder à Internet, vous pouvez configurer les détails de connexion (le serveur et le port, et si nécessaire le nom utilisateur et le mot de passe) dans l'onglet Avancé de l'écran Gestionnaire de plugins.

Si votre proxy utilise le système d'authentification Microsoft NTLM, vous devrez alors fournir un nom de domaine en plus d'un nom d'utilisateur. Vous pouvez placer les deux dans le champ Nom d'utilisateur : entrez simplement le nom de domaine, suivi par anti-slash (\), puis par le nom utilisateur, comme par exemple “MonDomain\Joe Bloggs”.

Jenkins > Manage Jenkins > Manage Plugins > Advanced

Jenkins vous permet d'identifier et de gérer les utilisateurs de plusieurs façons, depuis une simple base de données intégrée pour les petites équipes jusqu'à l'intégration avec des annuaires d'entreprise, avec de nombreuses autres options entre les deux.

Le moyen le plus simple pour gérer des comptes utilisateurs dans Jenkins est d'utiliser la base de données interne de Jenkins. C'est une bonne option si vous voulez garder les choses simples, car peu de configuration est nécessaire. Les utilisateurs qui ont besoin de se connecter au serveur Jenkins peuvent s'enregistrer, et, en fonction du modèle de sécurité choisi, un administrateur peut ensuite décider ce que ces utilisateurs sont autorisés à faire.

Vous pouvez visualiser les utilisateurs que Jenkins connaît actuellement, et aussi voir le dernier projet dans lequel ils ont committé. Notez que cette liste contient la liste de tous les utilisateurs à avoir jamais committé dans les projets que Jenkins surveille — ils pourraient ne pas être (et en général ne sont pas) tous des utilisateurs actifs de Jenkins capables de se connecter sur le serveur Jenkins.

Aller dans : Manage Jenkins > Manage Users

Un utilisateur apparaissant sur cette liste (Ch. Afficher les utilisateurs) ne peut pas nécessairement se connecter à Jenkins. Pour pouvoir se connecter, l'utilisateur doit avoir un mot de passe configuré.

Pour créer un utilisateur, il nous suffira de nous rendre dans la partie management de jenkins.

Aller dans : Manage Jenkins > Manage Users et cliquer sur Create User

Remplir les champs indiqué et cliquer sur “Create User” :

A cette étape, notre utilisateur est créer. Il faudra par la suite passer par votre plugin préféré pour gérer les droits des utilisateurs.

Manage Jenkins > Manage Plugins > Available : Dans la barre de recherche taper le plugin que vous souhaitez.

Nous allons ajouter des fonctionnalités à notre plateforme.

• Locale : Permet de changer la langue de la plateforme.
• Green Balls : Permet de changer Jenkins pour utiliser des balles vertes au lieu de balles bleu pour les Builds réussies.
• Role-based Authorization Strategy : Mise en place de role pour la gestions des droits des utilisateurs.
• Simple Theme : Ce plugin permet de personnaliser l'apparence de Jenkin avec du CSS et JavaScript personnalisés. Cela permet également de remplacer le Favicon.

La désinstallation d'un plugin supprime le fichier binaire du plugin (* .jpi ou * .hpi) du disque. Le plug-in continue de fonctionner normalement jusqu'à ce que vous redémarriez Jenkins, mais une fois que vous redémarrez, Jenkins se comportera comme si vous n'aviez pas le plug-in. Ils n'apparaîtront nulle part dans l'interface utilisateur, toutes les extensions auxquelles ils ont contribué disparaîtront.

S'il y a des “jobs”/“slaves”/“views”/“builds”, etc… existants qui utilisaient des extensions du plug-in, Jenkins signalera, au démarrage, qu'il y a des fragments dans ces configurations qu'il n'a pas compris, et fait comme si cela ne s'était pas passé.

Étant donné que la configuration est toujours intacte jusqu'à ce que vous remplaciez ces fichiers, si vous réinstallez le plug-in désinstallé et redémarrez Jenkins, la configuration est rétablie.

Si vous voulez récupérer la configuration laissée par les plugins désinstallés, allez dans “Manage Jenkins” et cliquez sur “Manage Old Data”.

Désactiver un plugin est un moyen plus doux de retirer un plugin. Jenkins continuera à reconnaître que le plug-in est installé, mais il ne le démarrera pas et aucune extension apportée par ce plug-in ne sera visible.

Les fragments apportés par un plugin désactivé aux fichiers de configuration suivraient le même sort que dans le cas de plugins désinstallés.

Les plugins peuvent être désactivés à partir de l'interface utilisateur (ou en touchant le fichier $ JENKINS_HOME/plugins/$PLUGIN_NAME.jpi.disabled (ou $JENKINS_HOME/plugins/$PLUGIN_NAME.hpi.disabled).

Les plugins désactivés peuvent être réactivés à partir de l'interface utilisateur (ou en supprimant le fichier *.jpi.disabled (ou *.hpi.disabled) du disque.)

Si vous voulez que tous ceux qui accèdent à votre serveur Jenkins ai accès à une interface plus design, il suffira de déployer un thème.

Installation du plugin “Simple Theme” Manage Jenkins > Manage Plugins

Cliquer sur l'onglet : Disponibles (Available) et dans la barre de recherche taper : Simple Theme

Sélectionner le plugin et cliquer sur : Télécharger maintenant et installer après redémarrage

Une fois l'installation effectué, cliquer sur : Redémarrer Jenkins quand l'installation est terminée et qu’aucun jobs n'est en cours.

La plateforme redémarre.

Manage Jenkins > Configure system et chercher la section thème.

Ajouter l'url suivante : http://jenkins-contrib-themes.github.io/jenkins-neo-theme/dist/neo-light.css

Cliquer sur Enregistrer et voilà notre nouveau thème !

Jenkins possède une interface de ligne de commande intégrée qui permet aux utilisateurs et aux administrateurs d'accéder à Jenkins à partir d'un script ou d'un environnement shell. Cela peut être pratique pour la création de scripts de tâches de routine, les mises à jour groupées, le dépannage, etc.

L’interface de ligne de commande est accessible via SSH ou avec le client Jenkins CLI, un fichier “.jar” distribué avec Jenkins.

Step for cli

- Création d'un token pour le user admin, celui-ci sera utilisé pour les appels API. - Test avec l'adresse : http://jenkins.oowy.lan/

# java -jar ./jenkins-cli.jar -s http://jenkins.oowy.lan/ -auth admin:11bec6c5fca27298298ac99624131a9624 help
  add-job-to-view
    Adds jobs to view.
  build
    Builds a job, and optionally waits until its completion.
  cancel-quiet-down
    Cancel the effect of the "quiet-down" command.
  clear-queue
    Clears the build queue.
 
  ...

# echo 'jenkins.model.Jenkins.instance.securityRealm.createAccount("User1", "hwCQY2NnT")' | java -jar jenkins-cli.jar -auth admin:11bec6c5fca27298298ac99624131a9624 -s http://jenkins.oowy.lan/ groovy = –

# java -jar jenkins-cli.jar -s http://jenkins.oowy.lan/ -auth admin:11bec6c5fca27298298ac99624131a9624 -noKeyAuth list-plugins

Installer le plugin “Active directory” via Manage Jenkins > Manage Plugins

Une fois le plugin installé, il nous suffira de nous rendre dans “Manage Jenkins” > “Configure Global Security” > “Security Realm” de sélectionner “Active Directory” et de renseigner les paramètres de connexion à notre Active Directory.

Pour réaliser une authentification basé sur le service FreeIPA, aucun besoin de plugin additionnel. Il nous suffira de configurer directement une authentification de type “LDAP”.

Il nous suffira de nous rendre dans “Manage Jenkins” > “Configure Global Security” > “Security Realm” : de sélectionner “LDAP” et de renseigner les paramètres de la plateforme FreeIPA.

Site web officiel :

https://jenkins.io

https://plugins.jenkins.io

http://updates.jenkins-ci.org/download/plugins/

Site web + Plugins :

https://jenkins-le-guide-complet.github.io/html/book.html

https://jenkins-le-guide-complet.github.io/html/sect-master-slave-strategies.html

http://objis.com/installation-agent-jenkins/

https://aws-labs.com/jenkins-cli-add-user/

https://sharadchhetri.com/2018/12/02/managing-jenkins-plugins/

https://blog.soat.fr/2011/07/integration-continue-en-environnement-distribue-avec-jenkins/

https://riptutorial.com/fr/jenkins/example/29046/comment-obtenir-des-informations-sur-l-instance-de-jenkins

Jenkins cli

https://jenkins.io/doc/book/managing/cli/

http://devrajndrg.blogspot.com/2016/12/jenkins-cli-examples.html

https://sharadchhetri.com/2018/12/02/managing-jenkins-plugins/

Role base access

https://computingforgeeks.com/how-to-configure-jenkins-freeipa-ldap-authentication/

https://medium.com/modern-stack/implementing-active-directory-based-security-in-jenkins-f78dbac929de

https://sqlnotesfromtheunderground.wordpress.com/2017/01/27/connecting-jenkins-to-active-directory-and-how-to-reset-access-to-jenkins/

https://www.youtube.com/watch?v=JG7T4F3w7qY

https://medium.com/@anusha.sharma3010/creating-managing-multiple-users-in-jenkins-b68ba7dc0810

https://github.com/jenkinsci/role-strategy-plugin/blob/master/README.md

Backup :

https://www.javatpoint.com/jenkins-backup-plugins

Reverse-proxy https

upstream jenkins{
    server 127.0.0.1:8080;
}

server {
    listen 80;

    server_name jenkins.oowy.lan;

    return 301 https://jenkins.oowy.lan$request_uri;
}

server{
    listen      443;
    server_name jenkins.oowy.lan;

    ssl on;
    ssl_certificate /etc/nginx/cert/bundle.crt;
    ssl_certificate_key /etc/nginx/cert/oowy.lan.key;

    access_log  /var/log/nginx/jenkins.access.log;
    error_log   /var/log/nginx/jenkins.error.log;

    ignore_invalid_headers off;

    location / {

        proxy_set_header    Host            $host:$server_port;
        proxy_set_header    X-Real-IP       $remote_addr;
        proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header    X-Forwarded-Proto $scheme;

        # Required for new HTTP-based CLI
        proxy_http_version 1.1;
        proxy_request_buffering    off; # Required for HTTP CLI commands in Jenkins > 2.54
        proxy_buffering            off; # Required for HTTP CLI commands in Jenkins > 2.54

        proxy_pass          http://jenkins;
        proxy_read_timeout  90;

        proxy_redirect      http://127.0.0.1:8080 http://jenkins.oowy.lan;

        # workaround for https://issues.jenkins-ci.org/browse/JENKINS-45651
        add_header 'X-SSH-Endpoint' 'jenkins.oowy.lan:50022' always;

    }
}