Jenkins Best-practice

Cette pratique recommandée concerne l’authentification des utilisateurs et l’application du contrôle d’accès sur une instance Jenkins.

Dans la configuration par défaut, Jenkins n'effectue aucune vérification de sécurité. Cela signifie que toute personne accédant au site Web peut exécuter du code arbitraire sur le maître Jenkins et sur tous les agents connectés, y compris l'extraction de tous vos mots de passe, certificats et autres données privées, en plus de simplement configurer Jenkins et les travaux, et effectuer des générations. Cette configuration est uniquement acceptable pour une utilisation dans des intranets (très petits) et des configurations de test.

Si votre configuration de sécurité est plus complexe et permet à certains utilisateurs de ne configurer que des tâches, mais pas d’administrer Jenkins, vous devez les empêcher d’exécuter des versions sur le nœud maître. Dans le cas contraire, ils ont un accès illimité au répertoire JENKINS_HOME. Pour ce faire, définissez le nombre d'exécuteurs à zéro. Au lieu de cela, assurez-vous que tous les travaux sont exécutés sur des agents.

Cela garantit que le maître jenkins peut évoluer pour prendre en charge de nombreux autres travaux, et protège également les versions de la modification accidentelle / malveillante de données potentiellement sensibles sur $ JENKINS_HOME. Si vous avez besoin que certains travaux soient exécutés sur le maître (par exemple, des sauvegardes de Jenkins lui-même), utilisez le plug-in Job Restrictions Plugin pour limiter les travaux pouvant y être exécutés.

Entre les versions archivées, les journaux de construction vous permettant de déterminer exactement ce qui s'est passé et les informations d'historique SCM qui vous indiquent exactement ce qui a été construit, Jenkins contient de nombreuses informations que vous ne voulez pas perdre.

Jenkins utilise des noms de projet pour les dossiers liés au projet. De nombreux outils mal écrits ne peuvent pas gérer les espaces, les signes dollar ou des caractères similaires dans les chemins de fichiers. Il est donc plus facile de vous limiter, par exemple, à [a-zA-Z0-9 _-] + dans les noms de projet et utilisez la fonction Nom complet pour les rendre plus jolis. Vous pouvez définir un modèle pour les noms de projets autorisés dans Configure Jenkins afin d'appliquer cette restriction à tous vos utilisateurs.

Lorsque vous avez des projets interdépendants sur Jenkins, il devient souvent difficile de savoir quelle version de celle-ci est utilisée par quelle version de celle-ci. Jenkins supporte les “empreintes de fichiers” pour simplifier les choses, alors utilisez-les au mieux.

Pour garantir la possibilité de reproduire une version, celle-ci doit être une version complète, entièrement construite à partir du contrôle de code source. Cette pratique implique également que tout le code, y compris les fichiers JAR tiers, les scripts de construction, les notes de publication, etc., soit archivé dans le contrôle de code source.

L'intégration permet de suivre les modifications au fur et à mesure qu'elles sont apportées, notamment le statut de la construction, ce qui a été réalisé pour cette exigence ou ces défauts, ainsi que le lien avec les résultats et les artefacts de la construction.

La navigation dans les référentiels fournit une mise à jour rapide sur ce qui se passe dans un référentiel Subversion. Il fournit également un diff graphique sur les modifications apportées par rapport à la version précédente.

Trends aide les chefs de projet et les développeurs à visualiser rapidement l’état d’avancement actuel du projet. De plus, les tests unitaires ne suffisent souvent pas pour garantir que le logiciel fourni est conforme à la qualité souhaitée. Plus vous testez le logiciel, plus le logiciel fourni est conforme à la qualité souhaitée.

Jenkins a besoin d’espace disque pour réaliser des builds et conserver des archives. Tous les paramètres, les journaux de construction, les archives d'artefacts sont stockés dans le répertoire JENKINS_HOME. Archivez simplement ce répertoire pour faire une sauvegarde. De même, la restauration des données ne fait que remplacer le contenu du répertoire JENKINS_HOME à partir d'une sauvegarde.

Tous les travaux inutilisés doivent être archivés pour pouvoir être ressuscités en cas de besoin. Voir Administration de Jenkins pour savoir comment procéder.

L'un des avantages de l'utilisation des outils de CI est la détection des problèmes au début du cycle de développement. Configurer un travail / projet différent pour chaque branche que vous créez contribuera à maximiser les avantages de la détection précoce des problèmes dans le cadre des efforts de développement parallèles et de la réduction des risques.

L'exécution simultanée de plusieurs tâches provoque souvent des conflits si elles configurent un type de service ou si elles nécessitent un accès exclusif. Si vos versions impliquent l'utilisation de bases de données ou d'autres services en réseau, vous devez vous assurer qu'elles n'interfèrent pas les unes avec les autres. Allouez un port différent pour les générations de projet parallèles afin d'éviter les conflits de génération. Si cela n’est pas possible (par exemple, dans le cas d’une ressource persistante qui doit être verrouillée), vous pouvez empêcher les versions qui l’utilisent de s’exécuter en même temps en utilisant, par exemple. Plugin de construction simultanée de papillon.

Essayez d'éviter de programmer tous les travaux pour qu'ils démarrent en même temps. Si vous utilisez des déclencheurs de minuterie ou interrogez périodiquement le GDS, utilisez la syntaxe H dans l'expression cron ou des jetons prédéfinis tels que @hourly pour répartir les heures de début des travaux de manière uniforme.

Configurez chaque personne de la liste des personnes avec leur adresse e-mail correcte et le rôle qu’elles jouent actuellement.

Par exemple, exécutez une suite limitée de tests de fumée avant d'exécuter des suites de tests consommatrices de temps.