Exemple de pipeline Java
Description de l'illustration cicd-process-pipeline.png
L'orchestrateur de pipeline pilote le processus de pipeline dans cet exemple de pipeline Java illustré à l'aide de certains outils couramment utilisés. Les étapes du processus sont les suivantes :
- Code modification
Effectue des vérifications Git de base pour les informations d'identification à l'aide du test SAST (Static Application Security Testing) et lance le pipeline. Utilise l'approche Gitflow pour gérer le référentiel de code en fonction de la façon dont le code est structuré à l'aide d'outils tels que GitLab ou GithHub. Le code peut être structuré de manière à disposer d'un branchement, d'une fusion et d'une libération de version pour contrôler les modifications de source. Le code est mis en correspondance avec des environnements tels que le développement, le test, la pré-production et la production. Les validations dans les différentes parties du référentiel déclenchent des actions Sast.
- Par exemple, GitHub intègre une analyse de sécurité statique pour rechercher les modèles qui reconnaîtront les mots de passe et les jetons dans le code et les fichiers de configuration.
- Code de compilation
Génère un fichier JAR/WAR/EAR et extrait les dépendances requises. Vous pouvez utiliser des outils tels que Java Apache Maven pour compiler et créer le fichier JAR (ou les fichiers d'archive déployables associés) et signer l'artefact.
- Gérer les dépendances tierces : gère les dépendances de code et les bibliothèques tierces à l'aide d'outils tels que Snyk. Synk vérifie et s'assure que les dépendances sont correctes, à partir d'une source acceptée, et recherche du contenu malveillant. Il extrait, inspecte, approuve et stocke les artefacts de dépendance externes. La gestion des dépendances tierces vous permet de stocker localement nos dépendances à l'aide d'outils comme Archiva, Nexus OSS, etc. Vous pouvez également contrôler les dépendances afin qu'elles aient des origines sécurisées. Cela peut garantir que la dépendance n'a pas été compromise avec du contenu malveillant à l'aide d'outils tels que Snyk, Nexus ou scanOS.
- Vérifier la qualité et la conformité
Recherchez les 10 principaux problèmes liés à OWASP et vérifiez la conformité aux normes de codage à l'aide d'outils tels que Sonarcube ou Lint.
- Effectuer un test d'unité
Effectuer des tests unitaires et capturer les données de couverture du code à l'aide de JACOCO et de JUnit. JACOCO fournit la collection de couverture, par exemple pour rechercher les lignes de code qui ont été exécutées et la proportion du code qui a été testée de manière statistique. JUnit exécute les tests d'unité. Vous pouvez développer la description si cela vous semble utile.
- Effectuer des tests d'API
Teste les API avec des données de simulation et teste les clients à l'aide d'outils tels que Dredd, Apiary ou Swagger Hub.
- Composants de test et expérience utilisateur
Tester les composants d'une boîte noire et tous les éléments d'interface utilisateur. Mesure les performances pour s'assurer qu'il n'y a pas de problèmes de base. Collecte les mesures de couverture des tests à l'aide d'outils tels que Selenium et JMeter. JMeter effectue des tests d'expérience utilisateur et de performances, et teste les workflows utilisateur. Selenium pilote l'exercice des éléments de l'interface utilisateur.
- Tester la sécurité
Tester le code pour détecter les vulnérabilités, telles que la manière dont il gère les appels API illégaux, les charges utiles excédentaires, les attaques par injection, etc. en utilisant Zap. Effectuez des tests de sécurité en recherchant le code redondant et les instructions SQL préparées.
- Package pour déploiement
Packagez la solution en tant que conteneur, validez l'emballage et vérifiez les problèmes de conteneur et les meilleures pratiques à l'aide d'outils tels que Docker Snyk.
- Générer de la documentation
Générez une documentation utile et rendez-la disponible pour consommation. Signez des artefacts à l'aide d'outils comme Pandoc ou Doxygen. Pandoc propage le projet à l'étape suivante et l'ajoute à l'espace de stockage sécurisé tel qu'un registre à utiliser dans la phase suivante.
Si l'une de ces étapes échoue ou si le processus identifie un trop grand nombre d'avertissements, la compilation échoue. Les builds peuvent échouer à tout moment du processus et empêcher la poursuite des étapes suivantes. L'échec d'un build empêche toute promotion de code automatisée configurée. Vous pouvez utiliser certains des outils recommandés pour les builds comportant plusieurs phases afin de prendre en charge l'exécution des tests à chaque phase. Par exemple, les tests au niveau système peuvent utiliser des outils de test d'API pour interagir avec le système en tant que service externe plutôt que de simuler les actions d'un autre composant au sein de la solution d'entreprise.