Nouvelle commande git-diff-pairs(1)

Les diffs sont au cœur de chaque revue de code et affichent toutes les modifications apportées entre deux révisions. Dans GitLab, ils apparaissent à plusieurs endroits, généralement dans l'onglet « Modifications » d'une merge request. En arrière-plan, la génération de diff est optimisée par git-diff(1).

Par exemple :

$ git diff HEAD~1 HEAD

Cette commande renvoie le diff complet de tous les fichiers modifiés. Son utilisation peut poser un problème d'évolutivité, car le nombre de fichiers modifiés entre différentes versions du code peut être très important, et le backend GitLab risque de dépasser une délai d'attente maximal qu'il s'impose pour exécuter cette commande. Pour les grands ensembles de modifications, il est préférable de pouvoir diviser le calcul des diffs en blocs plus petits et plus faciles à assimiler.

Pour ce faire, vous pouvez utiliser git-diff-tree(1) pour récupérer des informations sur tous les fichiers modifiés :

$ git diff-tree -r -M --abbrev HEAD~ HEAD
:100644 100644 c9adfed339 99acf81487 M Documentation/RelNotes/2.50.0.adoc
:100755 100755 1047b8d11d 208e91a17f M GIT-VERSION-GEN

Git appelle ce résultat le format « brut ». En bref, chaque ligne de sortie répertorie les paires de fichiers et les métadonnées associées en lien avec les modifications apportées entre les révisions de début et de fin. En comparaison avec la génération de la sortie de « correctif » pour les modifications importantes, ce processus est relativement rapide et fournit un résumé de tous les éléments qui ont été modifiés. Cette commande peut éventuellement effectuer détection de changement de nom en ajoutant -M pour vérifier si les modifications identifiées étaient dues à un changement de nom de fichier.

Avec ces informations, nous pourrions utiliser git-diff(1) pour calculer chacun des diffs de paire de fichiers individuellement.
Par exemple, nous pouvons fournir directement des ID de blob :

$ git diff 1047b8d11de767d290170979a9a20de1f5692e26 208e91a17f04558ca66bc19d73457ca64d5385f

Nous pouvons répéter ce processus pour chacune des paires de fichiers, mais lancer un processus Git distinct pour chaque diff de fichier n'est pas une approche efficace. De plus, lorsque vous utilisez des ID de blob, le diff perd certaines informations contextuelles telles que le statut de modification et les modes de fichier qui sont stockés dans l'objet arbre parent. En réalité, nous avons besoin d'un mécanisme permettant d'alimenter des informations « brutes » sur les paires de fichiers et de générer la sortie de correctifs correspondants.

Avec la version 2.50.0, Git dispose d’une nouvelle commande intégrée git-diff-pairs(1), qui prend en charge les informations de paires de fichiers au format « brut » en tant qu'entrée sur stdin pour déterminer avec précision les correctifs à générer.

L'exemple suivant montre comment cette commande peut être utilisée :

$ git diff-tree -r -z -M HEAD~ HEAD | git diff-pairs -z

De cette façon, la sortie générée est identique à celle obtenue avec git-diff(1). En utilisant une commande distincte pour générer la sortie de correctif, la sortie « brute » de git-diff-tree(1) peut être divisée en lots plus petits de paires de fichiers et envoyée vers des processus git-diff-pairs(1) distincts. Cette approche résout le problème d'évolutivité mentionné précédemment, car le calcul des diffs ne s'effectue plus en une seule fois. Les futures versions de GitLab pourraient s'appuyer sur ce mécanisme pour améliorer les performances de génération de diff, en particulier lorsque de grands ensembles de modifications sont concernés.

Pour plus d'informations sur ce changement, consultez ce fil de discussion.
Ce projet a été mené par Justin Tobler.

Mises à jour des références par lots

Git fournit la commande git-update-ref(1) pour effectuer des mises à jour de références. Lorsqu'elle est associée à --stdin, il est possible de regrouper plusieurs mises à jour de références en une seule transaction en indiquant des instructions pour chaque mise à jour à effectuer sur stdin. La mise à jour des références par lot offre également un comportement atomique : si une seule mise à jour échoue, la transaction est annulée et aucune référence n'est mise à jour.

Voici un exemple illustrant ce comportement :

# Create repository with three empty commits and branch named "foo"
$ git init
$ git commit --allow-empty -m 1
$ git commit --allow-empty -m 2
$ git commit --allow-empty -m 3
$ git branch foo
# Print out the commit IDs
$ git rev-list HEAD
cf469bdf5436ea1ded57670b5f5a0797f72f1afc
5a74cd330f04b96ce0666af89682d4d7580c354c
5a6b339a8ebffde8c0590553045403dbda831518
# Attempt to create a new reference and update existing reference in transaction.
# Update is expected to fail because the specified old object ID doesn’t match.
$ git update-ref --stdin <<EOF
> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc
> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c
> EOF
fatal: cannot lock ref 'refs/heads/foo': is at cf469bdf5436ea1ded57670b5f5a0797f72f1afc but expected 5a74cd330f04b96ce0666af89682d4d7580c354c
# The "bar" reference was not created.
$ git switch bar
fatal: invalid reference: bar

En comparaison avec la mise à jour de nombreuses références une par une, la mise à jour par lot est également beaucoup plus efficace. Toutefois, dans certaines circonstances, il peut être acceptable qu'un sous-ensemble des mises à jour de références demandées échoue. Cela ne remet pas en cause les gains de productivité obtenus grâce aux mises à jour par lot.

Avec cette version, git-update-ref(1) met à disposition la nouvelle option --batch-updates, qui permet aux mises à jour de se poursuivre même lorsqu'une ou plusieurs mises à jour de références échouent.

Dans ce mode, les échecs individuels sont signalés dans le format suivant :

rejected SP (<old-oid> | <old-target>) SP (<new-oid> | <new-target>) SP <rejection-reason> LF

Cela permet de poursuivre les mises à jour de références réussies, tout en fournissant un contexte indiquant celles qui ont été rejetées et pour quelle raison.

Voici ce que nous obtenons en utilisant le même exemple de dépôt que dans l'exemple précédent :

# Attempt to create a new reference and update existing reference in transaction.
$ git update-ref --stdin --batch-updates <<EOF
> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc
> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c
> EOF
rejected refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c incorrect old value provided
# The "bar" reference was created even though the update to "foo" was rejected.
$ git switch bar
Switched to branch 'bar'

Cette fois, avec l'option --batch-updates, la création de la référence a réussi même si la mise à jour n'a pas fonctionné. Cette série de correctifs est un aperçu des futures améliorations des performances de git-fetch(1) et git-receive-pack(1) lors de la mise à jour de références par lot.

Pour plus d'informations, consultez ce fil de discussion.

Ce projet a été mené par Karthik Nayak.

Nouvelle option de filtre pour git-cat-file(1)

Avec git-cat-file(1), il est possible d’afficher des informations pour tous les objets contenus dans le dépôt via l'option --batch–all-objects.

En voici un exemple :

# Setup simple repository.
$ git init
$ echo foo >foo
$ git add foo
$ git commit -m init
# Create an unreachable object.
$ git commit --amend --no-edit
# Use git-cat-file(1) to print info about all objects including unreachable objects.
$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)'
commit 0b07e71d14897f218f23d9a6e39605b466454ece
tree 205f6b799e7d5c2524468ca006a0131aa57ecce7
blob 257cc5642cb1a054f08cc83f2d943e56fd3ebe99
commit c999f781fd7214b3caab82f560ffd079ddad0115

Dans certains cas, un utilisateur peut effectuer une recherche dans tous les objets du dépôt, mais n'afficher qu'un sous-ensemble basé sur un attribut spécifique.

Par exemple, si nous voulons voir uniquement les objets qui correspondent à des commits, nous pouvons utiliser grep(1) :

$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' | grep ^commit
commit 0b07e71d14897f218f23d9a6e39605b466454ece
commit c999f781fd7214b3caab82f560ffd079ddad0115

Bien que cela fonctionne, un des inconvénients du filtrage de la sortie est que git-cat-file(1) doit toujours parcourir tous les objets du dépôt, même ceux qui n'intéressent pas l'utilisateur. Cette approche peut se révéler assez inefficace.

Avec la version 2.50.0, git-cat-file(1) dispose désormais de l'option --filter, qui n'affiche que les objets correspondant aux critères spécifiés. Celle-ci est similaire à l'option du même nom pour git-rev-list(1), mais seul un sous-ensemble des filtres est pris en charge : blob:none, blob:limit=, ainsi que object:type=.

Comme dans l'exemple précédent, il est possible de filtrer les objets par type avec Git directement :

$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' --filter='object:type=commit'
commit 0b07e71d14897f218f23d9a6e39605b466454ece
commit c999f781fd7214b3caab82f560ffd079ddad0115

Cette approche facilite le traitement par Git, mais également la recherche dans les grands dépôts contenant de nombreux objets. Si un dépôt dispose d'index bitmap, Git peut rechercher efficacement des objets d'un type spécifique, sans scanner le fichier d'empaquetage («packfile»), ce qui accélère de manière considérable le processus.

Les benchmarks effectués sur le dépôt Chromium montrent des améliorations significatives :

Benchmark 1: git cat-file --batch-check --batch-all-objects --unordered --buffer --no-filter
Time (mean ± σ): 82.806 s ± 6.363 s [User: 30.956 s, System: 8.264 s]
Range (min … max): 73.936 s … 89.690 s 10 runs
Benchmark 2: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tag
Time (mean ± σ): 20.8 ms ± 1.3 ms [User: 6.1 ms, System: 14.5 ms]
Range (min … max): 18.2 ms … 23.6 ms 127 runs
Benchmark 3: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=commit
Time (mean ± σ): 1.551 s ± 0.008 s [User: 1.401 s, System: 0.147 s]
Range (min … max): 1.541 s … 1.566 s 10 runs
Benchmark 4: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tree
Time (mean ± σ): 11.169 s ± 0.046 s [User: 10.076 s, System: 1.063 s]
Range (min … max): 11.114 s … 11.245 s 10 runs
Benchmark 5: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=blob
Time (mean ± σ): 67.342 s ± 3.368 s [User: 20.318 s, System: 7.787 s]
Range (min … max): 62.836 s … 73.618 s 10 runs
Benchmark 6: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=blob:none
Time (mean ± σ): 13.032 s ± 0.072 s [User: 11.638 s, System: 1.368 s]
Range (min … max): 12.960 s … 13.199 s 10 runs
Summary
git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tag
74.75 ± 4.61 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=commit
538.17 ± 33.17 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tree
627.98 ± 38.77 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=blob:none
3244.93 ± 257.23 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=blob
3990.07 ± 392.72 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --no-filter

Il est intéressant de noter que ces résultats indiquent que le temps de calcul est maintenant proportionnel au nombre d'objets pour un type donné plutôt qu'au nombre total d'objets dans le fichier d'empaquetage. Pour plus d'informations, consultez ce fil de discussion.

Ce projet a été mené par Patrick Steinhardt.

Amélioration des performances lors de la génération de paquets

Avec Git, vous pouvez générer une archive d'un dépôt qui contient un ensemble spécifié de références et d'objets accessibles qui l'accompagnent via la commande git-bundle(1). Cette opération est utilisée par GitLab pour générer des sauvegardes de dépôt et dans le cadre du mécanisme bundle-URI.

Pour les grands dépôts contenant des millions de références, cette opération peut prendre plusieurs heures, voire même plusieurs jours. Par exemple, avec le dépôt principal de GitLab (gitlab-org/gitlab), les temps de sauvegarde étaient d'environ 48 heures. Des recherches ont révélé la présence d'un goulot d'étranglement des performances en raison de la façon dont Git effectuait une vérification pour éviter que des références dupliquées ne soient incluses dans le paquet. L'implémentation a utilisé une boucle for imbriquée pour itérer et comparer toutes les références répertoriées, ce qui a entraîné une complexité temporelle O(N^2). Cette façon de procéder n'est pas adaptée en cas d'augmentation du nombre de références dans un dépôt.

Dans la version 2.50.0, ce problème a été résolu en remplaçant les boucles imbriquées par une structure de données de mappage, ce qui a permis d'accélérer considérablement le processus. Le benchmark suivant montre l'amélioration des performances lors de la création d'un paquet avec un dépôt contenant 100 000 références :

Benchmark 1: bundle (refcount = 100000, revision = master)
Time (mean ± σ): 14.653 s ± 0.203 s [User: 13.940 s, System: 0.762 s]
Range (min … max): 14.237 s … 14.920 s 10 runs
Benchmark 2: bundle (refcount = 100000, revision = HEAD)
Time (mean ± σ): 2.394 s ± 0.023 s [User: 1.684 s, System: 0.798 s]
Range (min … max): 2.364 s … 2.425 s 10 runs
Summary
bundle (refcount = 100000, revision = HEAD) ran
6.12 ± 0.10 times faster than bundle (refcount = 100000, revision = master)

Pour en savoir plus, découvrez notre article de blog qui explique comment nous avons réduit les temps de sauvegarde du dépôt GitLab de 48 heures à 41 minutes et consultez ce fil de discussion.

Ce projet a été mené par Karthik Nayak.

Meilleur dégroupage des URI de paquets

À l'aide du mécanisme bundle-uri dans Git, il est possible de fournir aux clients les emplacements pour récupérer les paquets dans le but d'accélérer les clones et les récupérations. Lorsqu'un client télécharge un paquet, les références sous refs/heads/* et les objets qui les accompagnent sont copiés du paquet dans le dépôt. Un paquet peut contenir des références supplémentaires en dehors de refs/heads/* telles que refs/tags/*, qui sont simplement ignorées lors de l'utilisation de l'URI du paquet sur le clone.

Dans Git 2.50.0, cette restriction est levée. Par conséquent, toutes les références correspondant à refs/* contenues dans le paquet téléchargé sont copiées.

Scott Chacon, qui a contribué à cette fonctionnalité, montre la différence lors du clonage de gitlab-org/gitlab-foss :

$ git-v2.49 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.49
Cloning into 'gl2.49'...
remote: Enumerating objects: 1092703, done.
remote: Counting objects: 100% (973405/973405), done.
remote: Compressing objects: 100% (385827/385827), done.
remote: Total 959773 (delta 710976), reused 766809 (delta 554276), pack-reused 0 (from 0)
Receiving objects: 100% (959773/959773), 366.94 MiB | 20.87 MiB/s, done.
Resolving deltas: 100% (710976/710976), completed with 9081 local objects.
Checking objects: 100% (4194304/4194304), done.
Checking connectivity: 959668, done.
Updating files: 100% (59972/59972), done.
$ git-v2.50 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.50
Cloning into 'gl-2.50'...
remote: Enumerating objects: 65538, done.
remote: Counting objects: 100% (56054/56054), done.
remote: Compressing objects: 100% (28950/28950), done.
remote: Total 43877 (delta 27401), reused 25170 (delta 13546), pack-reused 0 (from 0)
Receiving objects: 100% (43877/43877), 40.42 MiB | 22.27 MiB/s, done.
Resolving deltas: 100% (27401/27401), completed with 8564 local objects.
Updating files: 100% (59972/59972), done.

En comparant ces résultats, nous constatons que Git 2.50.0 récupère 43 887 objets (40,42 MiB) après l'extraction du paquet, tandis que Git 2.49.0 récupère un total de 959 773 objets (366,94 MiB). Git 2.50.0 récupère environ 95 % d'objets en moins et 90 % de données en moins, ce qui est avantageux aussi bien pour le client que le serveur. Le serveur doit traiter beaucoup moins de données à destination du client, et ce dernier doit télécharger et extraire moins de données. Dans l'exemple fourni par Scott, cela a conduit à une accélération de 25 %.

Pour en savoir plus, consultez ce fil de discussion.

Cette série de correctifs a été fournie par Scott Chacon.

En savoir plus

Cet article n'a mis en évidence que quelques-unes des contributions apportées par GitLab et la communauté Git pour cette nouvelle version. Vous pouvez approfondir ce sujet en lisant l'annonce officielle du projet Git et en consultant ces ressources.

Avec GitLab Duo combiné à Amazon Q, ce scénario appartient maintenant au passé. Notre nouvel outil d'IA agentique dédié aux clients AWS intervient à chaque étape du cycle de développement logiciel pour effectuer une revue complète de votre code en une fraction du temps qu'il vous faudrait, à vous et vos collègues. En tirant parti des capacités avancées de l'IA agentique, GitLab Duo combiné à Amazon Q rationalise l'ensemble de votre workflow de revue de code et maintient la qualité et la rigueur dont votre équipe a besoin. Vous disposez ainsi d'un relecteur expérimenté et disponible à tout moment, capable d'analyser instantanément votre code, de détecter les problèmes et de fournir des recommandations pertinentes et exploitables.

Lancement d'une revue de code

Comment fonctionne GitLab Duo combiné à Amazon Q ? Imaginons que vous venez de finaliser la mise à jour d'une fonctionnalité via une merge request répertoriant toutes les modifications que vous avez apportées au code. Au lieu de contacter vos collègues et d'attendre qu'ils soient disponibles pour relire votre travail, il vous suffit de saisir une commande rapide directement dans les commentaires : « /q review ». Cette commande suffit pour que l’IA entre en action.

L'agent Amazon Q s'active immédiatement et analyse vos modifications. Un message de confirmation vous indique que la revue de code est en cours et, en quelques instants, l'IA examine votre travail ligne par ligne, à la recherche d'erreurs, de bogues et d'anomalies potentiels.

Une fois la revue de code terminée, vous recevez des commentaires détaillés qui couvrent tous les points critiques, conformément aux standards de votre équipe en matière de codage : détection de bogues, amélioration de la lisibilité, erreurs de syntaxe. Chaque retour de l'agent d'IA est contextualisé, avec des suggestions précises pour résoudre ces problèmes. Il vous aide à comprendre facilement ce qui nécessite votre attention et pourquoi.

L'intérêt de cette approche basée sur l'IA agentique est qu'elle gère tous les aspects fastidieux de la revue de code afin que vous puissiez vous concentrer sur ce qui compte le plus : créer des logiciels performants. Vous bénéficiez des avantages d'une revue de code approfondie (détection des bogues améliorée, cohérence du code et code de meilleure qualité) sans perdre de temps. Vos délais de déploiement s'en trouvent considérablement réduits, car vous n'avez plus à patienter pour votre revue de code. Toute votre équipe gagne ainsi en productivité.

Pourquoi utiliser GitLab Duo combiné à Amazon Q ?

GitLab Duo combiné à Amazon Q transforme votre workflow de développement en profondeur :

• Des revues de code ultra-rapides, sans compromis sur la qualité
• Une application cohérente des normes sur l'ensemble de votre code source
• Des commentaires instantanés pour résoudre les problèmes avant qu'ils n'atteignent l'environnement de production
• Des délais de déploiement réduits pour livrer de nouvelles fonctionnalités, plus rapidement
• Plus de temps pour se concentrer sur la résolution créative des problèmes plutôt que sur des revues de code répétitives

Regardez cette vidéo et découvrez comment GitLab Duo combiné à Amazon Q peut optimiser votre processus de revue de code :

<!-- blank line --> <figure class="video_container"> <iframe src="https://www.youtube.com/embed/4gFIgyFc02Q?si=GXVz--AIrWiwzf-I" frameborder="0" allowfullscreen="true"> </iframe> </figure> <!-- blank line -->

Pour en savoir plus sur GitLab Duo combiné à Amazon Q, contactez votre représentant GitLab.

L'approche CI/CD repose sur la mise en place d'un pipeline fluide et automatisé qui permet de transférer le code de l'environnement de développement vers l'environnement de production, tout en intégrant les retours et suggestions de modification en temps réel. L'intégration continue (CI) aide les équipes à détecter rapidement les problèmes avant qu'ils ne deviennent coûteux. Les modifications de code sont fréquemment fusionnées dans un dépôt partagé, puis testées automatiquement et validées. La livraison continue (CD) vient compléter cette démarche. Elle vise à automatiser le processus de déploiement, rendant les sorties de nouvelles versions prévisibles et harmonieuses.

Grâce à un pipeline CI/CD robuste, les équipes peuvent compiler, tester et déployer leurs logiciels sans dépendre de processus manuels ou de chaînes d’outils complexes. L'intégration de l'IA aide à optimiser encore davantage ce processus, en générant automatiquement des pipelines CI/CD qui garantissent la cohérence des contrôles de qualité, de conformité et de sécurité.

Découvrez dans ce guide tout ce que vous devez sur les pipelines CI/CD modernes, des principes de base aux bonnes pratiques, en passant par les stratégies avancées. Apprenez également comment les grandes entreprises leaders dans leur domaine tirent parti de l'approche CI/CD pour atteindre des résultats impressionnants. À l’issue de cette lecture, vous saurez comment faire évoluer votre environnement DevSecOps afin de développer et de livrer des logiciels de manière agile, automatisée et efficace.

Qu'est-ce que l'intégration continue ?

L'intégration continue (CI) est une pratique qui consiste à intégrer régulièrement les modifications de code dans la branche principale d'un dépôt de code source partagé. Cette intégration s'effectue dès que possible, et fréquemment. Après chaque validation ou merge, les modifications sont automatiquement testées, puis une compilation est déclenchée sans intervention manuelle. Grâce à l'intégration continue, les équipes peuvent identifier et corriger les erreurs, ainsi que les failles de sécurité, plus facilement et beaucoup plus tôt dans le processus de développement.

Qu'est-ce que la livraison continue ?

La livraison continue (CD), également appelée déploiement continu, automatise le processus de mise en production des applications. Les équipes de développement ont ainsi plus de temps à consacrer au suivi des déploiements en cours pour en garantir la réussite. Avec la livraison continue, les équipes DevSecOps définissent à l'avance les critères de mise à disposition du code. Une fois ces critères remplis et validés, le code est automatiquement déployé dans l'environnement de production. Cette automatisation permet aux entreprises de gagner en flexibilité et de mettre plus rapidement de nouvelles fonctionnalités à disposition des utilisateurs.

Quel est le lien entre la gestion du code source et l'approche CI/CD ?

La gestion du code source (SCM) et l'approche CI/CD constituent la base des pratiques modernes de développement logiciel. Les systèmes SCM, comme Git, offrent une solution centralisée pour suivre les modifications, gérer les versions de code et faciliter la collaboration entre les membres de l'équipe. Lorsqu’un développeur travaille sur une nouvelle fonctionnalité ou une correction de bogues, il crée une branche à partir du code source et apporte ses modifications avant de les fusionner à l'aide des merge requests. Cette stratégie de gestion de branches permet à plusieurs développeurs de travailler simultanément sans interférer avec le code de leurs collègues, tout en maintenant une branche principale stable qui contient un code prêt à être déployé dans l'environnement de production.

L'approche CI/CD automatise les étapes de compilation, de test et de validation du code géré par le système SCM à chaque push de modifications. Lorsqu'un développeur soumet ses modifications de code, le système CI/CD récupère automatiquement le code le plus récent, le combine avec le code source existant, puis exécute une série de vérifications automatisées. Celles-ci comprennent généralement la compilation du code, l'exécution de tests unitaires, l'analyse statique du code et la vérification de la couverture de code. En cas d’échec d’une de ces étapes, l'équipe en est immédiatement informée, ce qui lui permet de résoudre les problèmes avant qu'ils n'affectent d'autres développeurs ou qu'ils n’apparaissent dans l'environnement de production. Cette intégration étroite entre le contrôle de version et l'intégration continue crée une boucle de rétroaction constante qui garantit la qualité du code et prévient l'accumulation de problèmes d'intégration.

Quels sont les avantages de l'approche CI/CD ?

L'approche CI/CD apporte de nombreux avantages qui transforment le développement logiciel moderne et réduisent considérablement les délais ainsi que les risques associés à la livraison de nouvelles fonctionnalités et corrections de bogues. Grâce à une boucle de rétroaction continue, les équipes DevSecOps peuvent garantir que leurs modifications sont automatiquement validées sur l'ensemble du code source.

Résultat : des logiciels de meilleure qualité, des cycles de livraison plus courts et des sorties de nouvelles versions plus fréquentes pour répondre rapidement aux besoins des utilisateurs et aux demandes du marché.

Au-delà des aspects techniques, l'approche CI/CD favorise une culture de collaboration et de transparence au sein des équipes de développement logiciel. Grâce à une visibilité en temps réel du statut des compilations, des tests et des déploiements, il est plus facile d'identifier et de résoudre les goulots d'étranglement dans le processus de livraison. L'automatisation offerte par l'approche CI/CD réduit également la charge cognitive des équipes de développement qui peuvent ainsi se concentrer sur l'écriture de code plutôt que sur la gestion de processus de déploiement manuels. La satisfaction et la productivité des équipes s’améliorent, tandis que les risques généralement associés aux étapes critiques du processus de publication de logiciel diminuent. Les équipes peuvent expérimenter de nouvelles idées sans craindre de compromettre le projet, sachant que des mécanismes de contrôle robustes, comme les revues de code rapides, sont intégrés au processus. Elles peuvent rapidement annuler les modifications si nécessaire. L'approche CI/CD encourage donc une culture d'innovation et d'amélioration continue.

Quelles sont les principales différences entre l'approche CI/CD et le développement traditionnel ?

L'approche CI/CD diffère du développement logiciel traditionnel à bien des égards, notamment en ce qui concerne les points suivants :

Validations fréquentes du code

Dans le développement traditionnel, les équipes de développement travaillent souvent de manière isolée et intègrent rarement leurs modifications dans le code source. Cette situation entraîne des conflits de merge et d'autres problèmes chronophages. Avec l'approche CI/CD, les équipes effectuent régulièrement des push de validation, parfois plusieurs fois par jour. De cette manière, les conflits de merge sont détectés rapidement et le code source est maintenu à jour.

Réduction des risques

Les méthodes de développement logiciel traditionnelles reposent sur des cycles de test à rallonge et une planification rigoureuse avant la sortie de chaque nouvelle version. Bien que ce type de développement ait pour objectif de réduire au maximum les risques, il entrave souvent la capacité à identifier et à résoudre les problèmes. À l’inverse, l'approche CI/CD permet de gérer les risques en appliquant de petites modifications incrémentielles. Ces changements, surveillés de près, peuvent être facilement annulés en cas de problème.

Tests automatisés et continus

Dans le cadre du développement logiciel traditionnel, les tests sont généralement exécutés à la fin du processus de développement, ce qui peut entraîner des retards de livraison et des corrections de bogues coûteuses. L'approche CI/CD, en revanche, intègre des tests automatisés qui sont exécutés en continu tout au long du processus de développement logiciel et déclenchés à chaque validation de code. Cette approche permet aux équipes de développement de recevoir des retours immédiats et d’implémenter rapidement les correctifs nécessaires.

Déploiements automatisés, reproductibles et fréquents

L’automatisation des déploiements dans l’approche CI/CD réduit le stress et les efforts habituellement associés aux déploiements massifs de logiciels. Ce processus automatisé est reproductible dans tous les environnements et garantit ainsi un gain de temps, une réduction des risques d’erreurs ainsi qu'une cohérence accrue dans chaque déploiement.

Quels sont les principes fondamentaux de l'approche CI/CD ?

L'approche CI/CD constitue un framework essentiel pour la mise en place de processus de livraison de logiciels évolutifs et régulièrement mis à jour. Pour les équipes DevSecOps, une maîtrise parfaite de ses concepts fondamentaux est indispensable. Une solide compréhension des principes CI/CD permet aux équipes d'adapter leurs stratégies et leurs pratiques aux évolutions technologiques, en s’affranchissant des limitations des méthodes traditionnelles.

Qu'est-ce qu'un pipeline CI/CD ?

Un pipeline CI/CD est une série d'étapes (compilation, test et déploiement) qui automatise et rationalise le processus de livraison de logiciels. Chaque étape agit comme un mur qualité et permet de s'assurer que seul le code validé passe à l'étape suivante. Les premières étapes gèrent les vérifications de base, telles que la compilation et les tests unitaires. Les étapes ultérieures, quant à elles, peuvent inclure des tests d'intégration, de performance et de conformité, ainsi que des déploiements échelonnés dans divers environnements.

Le pipeline peut être configuré de manière à nécessiter des approbations manuelles aux points critiques, par exemple avant le déploiement en production, tout en automatisant les tâches routinières. Les équipes de développement obtiennent ainsi un retour rapide sur l'état de leurs modifications. Cette approche structurée assure la cohérence, réduit les erreurs humaines et fournit une piste d'audit claire du transfert des modifications de code de l'environnement de développement vers l'environnement de production. Les pipelines modernes sont souvent implémentés sous forme de code et peuvent ainsi être contrôlés, testés et tenus à jour, de la même manière que le code applicatif.

Voici d'autres termes associés à l'approche CI/CD qu'il est important de connaître :

• Validation : une modification apportée au code
• Job : une série d'instructions qu'un runner doit exécuter
• Runner : un agent ou serveur qui exécute chaque job individuellement et qui peut se mettre à l'échelle selon les besoins
• Étapes : un mot-clé qui définit certaines phases spécifiques d'un job, comme la phase de « compilation » et de « déploiement ». Les jobs d'une même étape s’exécutent en parallèle. Les pipelines sont configurés à l'aide d'un fichier YAML nommé .gitlab-ci.yml, soumis au contrôle de version et situé à la racine du projet.

Bonnes pratiques pour réussir votre approche CI/CD

Votre maîtrise de l'approche CI/CD dépend grandement des bonnes pratiques que vous mettez en œuvre.

Les bonnes pratiques en matière d'intégration continue

• Validez tôt et souvent.
• Optimisez les étapes du pipeline.
• Simplifiez et accélérez les compilations.
• Utilisez les échecs pour améliorer les processus.
• Assurez-vous que l'environnement de test reflète l'environnement de production.

Les bonnes pratiques en matière de livraison continue

• Lancez-vous avec les outils et infrastructures disponibles, puis itérez pour améliorer vos processus.
• Utilisez le moins d'outils possibles pour optimiser la livraison continue.
• Surveillez l’avancée des projets en continu afin d’éviter l’accumulation de tickets ou de merge requests.
• Simplifiez les tests d'acceptation par l'utilisateur et le déploiement vers l'environnement de préproduction grâce à l'automatisation.
• Automatisez la gestion du pipeline de sortie des nouvelles versions.
• Mettez en œuvre la surveillance du pipeline pour gagner en visibilité et en productivité.

Pour en savoir plus sur l'approche CI/CD, consultez notre webinaire « Intro to CI/CD ».

<!-- blank line -->

<figure class="video_container"> <iframe src="https://www.youtube.com/embed/sQ7Nw3o0izc?si=3HpNqIClrc2ncr7Y" title="Intro to CI/CD webinar" frameborder="0" allowfullscreen="true"> </iframe> </figure> <!-- blank line -->

Premiers pas avec l'approche CI/CD

Pour commencer à utiliser l'approche CI/CD, identifiez un projet simple mais représentatif qui servira de projet pilote. Sélectionnez une application simple avec des exigences de test basiques. Vous pourrez ainsi vous concentrer sur l'apprentissage du fonctionnement des pipelines plutôt que sur des scénarios de déploiement complexes. Assurez-vous que votre code est soumis au contrôle de version et qu'il comporte des tests automatisés basiques. Même quelques tests unitaires suffisent pour débuter. L'objectif est de créer un pipeline basique que vous pourrez améliorer progressivement à mesure que vos compétences progressent.

Dans le cas de GitLab, le processus commence par la création d'un fichier .gitlab-ci.yml dans le répertoire racine de votre projet. Ce fichier YAML définit les étapes de base (comme la compilation, les tests et le déploiement) et les jobs de votre pipeline. Voici un exemple de pipeline simple : l'étape de « Compilation » compile votre code et crée des artefacts, l'étape de « Test » exécute les tests unitaires et l'étape de « Déploiement » effectue le push de votre application vers un environnement de préproduction. GitLab détecte automatiquement ce fichier et commence à exécuter votre pipeline chaque fois que des modifications sont transmises via un push vers votre dépôt. La plateforme fournit des runners intégrés pour exécuter les jobs de votre pipeline, mais vous pouvez également configurer vos propres runners si vous souhaitez davantage de contrôle.

À mesure que vous maîtrisez les éléments de base, enrichissez votre pipeline progressivement avec des fonctionnalités plus avancées. Par exemple, ajoutez des contrôles de qualité du code, le scanning de sécurité ou le déploiement automatisé du nouveau code en production. La plateforme DevSecOps de GitLab inclut des fonctionnalités telles que la gestion de la conformité, les variables de déploiement et les portes d'approbation manuelle que vous pouvez intégrer à mesure que votre pipeline évolue. Soyez attentif à la durée d'exécution du pipeline et exécutez dans la mesure du possible des jobs en parallèle. Pensez à ajouter des notifications et un traitement approprié des erreurs afin que les membres de l'équipe soient rapidement informés en cas d’échec de pipeline. Commencez à documenter les problèmes que vous rencontrez le plus souvent et les solutions adoptées. Ces données seront très utiles quand votre équipe s'agrandira.

Vous souhaitez en savoir plus sur l'approche CI/CD ? Inscrivez-vous à notre cours GitLab University gratuit sur l'approche CI/CD.

Sécurité, conformité et approche CI/CD

L'un des plus grands avantages de l'approche CI/CD est la possibilité d'intégrer des contrôles de sécurité et de conformité réguliers, et ce dès les premières étapes du cycle de développement logiciel. Dans GitLab, les équipes peuvent utiliser la configuration .gitlab-ci.yml pour déclencher automatiquement des scans de sécurité à plusieurs étapes, de la validation initiale du code à son déploiement en production. Les fonctionnalités d'analyse des conteneurs, d'analyse des dépendances et de scanning de sécurité (Test dynamique de sécurité des applications et Analyseur Advanced SAST de GitLab) de la plateforme peuvent être configurées pour s'exécuter automatiquement à chaque modification de code afin de rechercher les vulnérabilités, les violations des exigences de conformité et les erreurs de configuration de sécurité. L'API de la plateforme permet l'intégration avec des outils de sécurité externes, tandis que les fonctionnalités de couverture des tests garantissent que les tests de sécurité répondent aux seuils requis.

Les rapports de test de sécurité de GitLab fournissent des informations détaillées sur les découvertes de vulnérabilités afin de remédier rapidement aux problèmes de sécurité avant qu'ils n'atteignent l'environnement de production. Le tableau de bord relatif à la sécurité fournit une vue centralisée des vulnérabilités détectées dans les différents projets, tandis que des stratégies de sécurité peuvent être appliquées via les approbations de merge request et les portes dans les pipelines. GitLab offre plusieurs niveaux de gestion des secrets pour protéger les données sensibles tout au long du processus CI/CD, y compris des journaux d'audit permettant de suivre l'accès à ces secrets. De plus, un contrôle d'accès basé sur les rôles (RBAC) garantit que seuls les utilisateurs autorisés peuvent consulter ou modifier les données de configuration sensibles.

GitLab prend également en charge la génération de nomenclatures logicielles (SBOM), qui fournissent un inventaire complet de l'ensemble des composants logiciels, dépendances et licences dans une application. Elles permettent aux équipes d'identifier et de corriger rapidement les vulnérabilités, ainsi que de se conformer aux exigences réglementaires.

Approche CI/CD et cloud

La plateforme CI/CD de GitLab offre une intégration robuste avec les principaux fournisseurs de services cloud, notamment Amazon Web Services, Google Cloud Platform et Microsoft Azure. Les équipes de développement logiciel peuvent ainsi automatiser leurs déploiements cloud directement à partir de leurs pipelines. Grâce aux intégrations cloud de GitLab, elles peuvent également gérer les ressources cloud, déployer des applications et surveiller les services cloud directement depuis l'interface de GitLab. Les templates de déploiement cloud intégrés et les fonctionnalités Auto DevOps de la plateforme réduisent considérablement la complexité des déploiements cloud. Les membres de l'équipe peuvent ainsi se concentrer sur le développement d'applications plutôt que sur la gestion de l'infrastructure. Pour les entreprises qui souhaitent automatiser leur infrastructure informatique à l'aide de GitOps, GitLab propose l'intégration Flux CD.

Les fonctionnalités cloud de GitLab vont au-delà de la simple automatisation des déploiements. L'intégration Kubernetes à la plateforme GitLab permet aux équipes de gérer l'orchestration des conteneurs entre plusieurs fournisseurs de services cloud. De plus, les options d'installation cloud-native de GitLab permettent à la plateforme elle-même de fonctionner dans des environnements cloud. Grâce à ces fonctionnalités cloud-native, les équipes peuvent mettre en œuvre des runners à mise à l'échelle automatique qui provisionnent dynamiquement les ressources cloud pour l'exécution de pipelines afin d'optimiser les coûts et les performances. Enfin, l'intégration de la plateforme avec les services de sécurité des fournisseurs de services cloud garantit le respect des exigences de sécurité et de conformité tout au long du processus de déploiement.

Pour les environnements multicloud, GitLab fournit des workflows et des outils cohérents, quel que soit le fournisseur de services cloud sous-jacent. Les équipes de développement peuvent utiliser les fonctionnalités de gestion de l'environnement de GitLab pour gérer différentes configurations cloud dans les environnements de développement, de préproduction et de production. La prise en charge de l'Infrastructure as Code (IaC) de la plateforme GitLab, en particulier son intégration native avec Terraform, permet aux équipes de développement de contrôler les versions et d'automatiser le provisionnement de leur infrastructure cloud. Les fonctionnalités de surveillance et d'observabilité de GitLab s'intègrent aux indicateurs des fournisseurs de services cloud, offrant une visibilité complète de l'intégrité des applications et de l'infrastructure dans les différents environnements cloud.

Pipeline CI/CD avancé

L'approche CI/CD a connu une évolution significative qui va bien au-delà de la simple construction et du déploiement de pipelines. Dans les mises en œuvre avancées, elle implique une orchestration sophistiquée des tests automatisés, du scanning de sécurité, du provisionnement de l'infrastructure, de l'IA et de bien d'autres aspects. Voici quelques stratégies CI/CD avancées pour aider les équipes d'ingénierie à améliorer leurs pipelines et à résoudre les problèmes qui surviennent, même lorsque la complexité de l'architecture augmente.

Réutilisation et automatisation des pipelines CI/CD

GitLab révolutionne les pratiques des équipes de développement logiciel et de gestion des pipelines CI/CD en introduisant deux innovations majeures : le catalogue CI/CD et CI/CD Steps. Ce dernier est un nouveau langage de programmation expérimental dédié à l'automatisation DevSecOps. Le catalogue CI/CD est une plateforme centralisée où les équipes peuvent découvrir, réutiliser et optimiser les différents composants CI/CD. Ces derniers fonctionnent comme des blocs de construction réutilisables et à usage unique qui simplifient la configuration des pipelines au sein des workflows CI/CD. Parallèlement, CI/CD Steps offre la possibilité de gérer des workflows complexes en permettant aux équipes de configurer les entrées et sorties pour chaque job CI/CD. Avec le catalogue CI/CD et CI/CD Steps, les équipes DevSecOps peuvent facilement standardiser l'approche CI/CD et ses composants, et ainsi simplifier le processus de développement et de maintenance des pipelines CI/CD.

Pour en savoir plus, consultez notre FAQ sur le catalogue CI/CD et notre documentation sur CI/CD Steps.

Dépannage des pipelines avec l'IA

Bien qu'une défaillance des pipelines CI/CD soit possible, le dépannage rapide du problème peut considérablement réduire son impact. L'analyse des causes profondes de GitLab Duo, l'une des fonctionnalités alimentées par l'IA, élimine les hypothèses en déterminant la cause profonde de l'échec d'un pipeline CI/CD. Lorsqu'un pipeline échoue, GitLab fournit des job logs détaillés, des messages d'erreur et des traces d'exécution qui indiquent exactement où et pourquoi l'échec s'est produit. L'analyse des causes profondes utilise ensuite l'IA pour suggérer une solution.

Découvrez la fonctionnalité d'analyse des causes profondes de GitLab Duo en action :

<!-- blank line -->

<figure class="video_container"> <iframe src="https://www.youtube.com/embed/sTpSLwX5DIs?si=J6-0Bf6PtYjrHX1K" frameborder="0" allowfullscreen="true"> </iframe> </figure> <!-- blank line -->

Comment migrer son code vers un pipeline GitLab CI/CD ?

La migration vers la plateforme DevSecOps de GitLab et son pipeline CI/CD intégré implique l'analyse systématique de vos configurations de pipeline, dépendances et processus de déploiement existants pour les mapper aux fonctionnalités et à la syntaxe équivalentes de GitLab.

Consultez nos ressources pour faciliter votre migration vers GitLab CI/CD :

• Migration de Bamboo vers GitLab CI/CD
• De Jenkins à GitLab : le guide complet pour moderniser votre environnement CI/CD
• Migrer de GitHub Advanced Security vers GitLab Ultimate : notre guide complet

Témoignages d'entreprises leaders dans leur domaine

Ces entreprises de premier plan ont migré vers GitLab et profitent des innombrables avantages de l'approche CI/CD. Découvrez leurs témoignages.

• Lockheed Martin
• Indeed
• CARFAX
• HackerOne
• Betstudios
• Thales et Carrefour

Tutoriels CI/CD

Devenez un expert des pipelines CI/CD à l'aide de ces tutoriels :

• Intégration continue : créez votre premier pipeline CI avec GitLab
• Configuration de votre premier composant GitLab CI/CD
• GitLab CI/CD : comment créer facilement un pipeline pour un monorepo
• Déployer en continu dans de multiples environnements avec les pipelines enfants
• Refactorisation d'un template CI/CD en composant CI/CD

Commencez un essai de GitLab Ultimate et essayez gratuitement GitLab CI/CD pendant 60 jours.

Les défis actuels du développement sur mainframe

Les entreprises qui utilisent les systèmes IBM Z pour leurs charges de travail critiques sont confrontées à des défis que les outils DevSecOps classiques ne sont pas en mesure de relever. Tandis que les équipes cloud-native bénéficient de pipelines CI/CD modernes, d'un développement collaboratif fluide et de tests automatisés, les équipes mainframe restent souvent confinées à des outils obsolètes, source d'inefficacités coûteuses et de silos opérationnels.

Elles ont souvent recours à des solutions de contournement, telles que les connexions SSH et les transferts manuels de fichiers, qui fragilisent la sécurité et complexifient les audits. Or, dans un contexte de conformité de plus en plus exigeant, ces pratiques improvisées s’exposent à des risques inacceptables. Par ailleurs, les entreprises maintiennent des chaînes d'outils parallèles coûteuses, reposant sur des outils de développement mainframe hérités aux coûts de licence élevés et aux fonctionnalités limitées par rapport aux alternatives modernes.

Cette fragmentation crée deux problèmes : des cycles de livraison de logiciels plus lents et une difficulté à attirer des développeurs, qui recherchent des environnements de travail modernes.

« GitLab Ultimate pour IBM Z représente une avancée décisive pour résoudre une problématique à laquelle le secteur doit faire face depuis longtemps. D'après les recherches menées par IDC, les équipes de développement mainframe s'appuient encore largement sur des outils hérités qui contribuent à freiner les livraisons et compliquent l'acquisition de nouveaux talents. Avec cette offre conjointe, les fonctionnalités DevSecOps modernes et les workflows unifiés sont intégrés directement au mainframe. Résultat : une collaboration plus fluide et plus efficace pour les équipes de développement, et une accélération de l'innovation pour les entreprises, qui peuvent ainsi totalement intégrer le développement mainframe à leurs stratégies globales de transformation digitale. » - Katie Norton, Research Manager, DevSecOps and Software Supply Chain Security chez IDC

Vers des environnements de développement unifiés

Une véritable modernisation du développement mainframe nécessite de concevoir une plateforme unifiée où les équipes mainframe, cloud-native, web et mobile collaborent en harmonie.

GitLab Ultimate pour IBM Z permet aux équipes de développement d'utiliser des workflows cohérents, qu'ils déploient sur z/OS, dans le cloud ou sur une infrastructure locale. Les connaissances sont ainsi transférées entre les équipes au lieu de rester cloisonnées. Les entreprises peuvent ainsi moderniser leurs pratiques progressivement, à leur propre rythme, sans interrompre leurs activités, car les systèmes hérités continuent de fonctionner.

À l'heure où les architectures hybrides mêlant mainframe et développement cloud-native deviennent la norme, GitLab fournit une base robuste pour développer des applications entre ces différents environnements.

Qu'est-ce que GitLab Ultimate pour IBM Z ?

GitLab Ultimate pour IBM Z offre une prise en charge native des runners sur z/OS et permet ainsi une exécution fluide et sécurisée de vos pipelines CI/CD directement sur votre infrastructure mainframe. Cette solution certifiée par GitLab supprime le besoin de solutions de contournement complexes tout en maintenant la sécurité et la fiabilité que vos applications exigent.

En combinant la plateforme DevSecOps complète de GitLab avec l'expertise approfondie d'IBM en matière de mainframe, cette offre unique et certifiée connecte les systèmes hérités aux pratiques d'innovation cloud-native.

Quelles fonctionnalités offre GitLab Ultimate pour IBM Z ?

GitLab Ultimate pour IBM Z fournit aux équipes de développement les outils dont elles ont besoin pour moderniser le développement mainframe tout en préservant la continuité des systèmes métier critiques.

Voici les principales fonctionnalités de cette solution intégrée :

La prise en charge native des runners sur z/OS : les pipelines CI/CD s'exécutent directement sur votre mainframe. Cette approche réduit les risques de sécurité et les goulots d'étranglement d'évolutivité associés aux connexions distantes, tout en accélérant les déploiements et les livraisons.

La gestion unifiée du code source : votre chaîne d'outils est modernisée en remplaçant les outils de gestion de bibliothèques hérités coûteux par le système de dépôt consultable et le contrôle de version de GitLab. Ainsi, vos coûts de licence et frais de maintenance sont réduits.

L'intégration fluide avec IBM Developer for z/OS Enterprise Edition (IDzEE) : les cycles de livraison sont accélérés grâce à des compilations basées sur les dépendances, à une analyse automatique du code et à des outils de débogage complets, directement accessibles dans les environnements de développement habituels. Le tout améliore à la fois la qualité du code et la sécurité des applications, sans perturber les habitudes des équipes.

La visibilité complète sur les environnements mainframe et distribués : une gestion complète des projets, de la planification à la production, permet d'automatiser les workflows DevOps et améliore l'expérience développeur grâce à des outils de développement modernes de nouvelle génération.

Modernisez votre environnement de développement mainframe dès aujourd'hui

GitLab Ultimate pour IBM Z est désormais disponible pour les entreprises prêtes à transformer leur expérience de développement mainframe. Pour en savoir plus, consultez la page dédiée au partenariat entre GitLab et IBM.

<center><i>Degré de complexité de l'intégration de plusieurs outils dans un processus DevSecOps</i></center>

<br></br>

Bonne nouvelle, une solution existe : une plateforme DevSecOps complète offrant une approche unifiée du développement logiciel.

Cette plateforme est conçue pour les entreprises opérant dans des environnements cloud et DevSecOps : tous les aspects du développement logiciel (gestion du code, processus CI/CD, gestion des tâches, sécurité, automatisation pilotée par l'IA) s'effectuent depuis une seule interface. Ainsi, tous les workflows sont centralisés, offrant aux équipes de développement et des opérations une collaboration optimisée, une communication rationalisée et une réduction significative des complexités et des perturbations opérationnelles.

En outre, l'expérience développeur s'améliore considérablement : les équipes d’ingénierie sont beaucoup plus heureuses de travailler avec un produit conçu spécifiquement pour les besoins du développement moderne.

Découvrez comment GitLab simplifie la gestion de projet, renforce la sécurité et la conformité, et intègre l’IA pour transformer le développement logiciel et aider les équipes à surmonter les défis courants.

Gestion de projet Agile intégrée

GitLab fournit une solution holistique qui rassemble toutes les fonctionnalités nécessaires pour la gestion des projets et des tâches. Cette intégration couvre toutes les étapes du développement logiciel, y compris les pipelines CI/CD. Les équipes peuvent ainsi suivre en temps réel la progression du projet. Les tickets et les epics sont directement liés aux processus d'automatisation. De la planification au déploiement en production, toutes les étapes s'effectuent sans accroc. La transparence entre les équipes est ainsi renforcée, les retards sont réduits et toutes les parties prenantes ont une vision claire de l'état du développement en temps réel.

Sécurité intégrée

La sécurité est au cœur de GitLab avec l'intégration de fonctionnalités de sécurité complètes. La plateforme intègre un large éventail de scanners de sécurité automatisés, notamment :

• L'analyse des dépendances
• Les tests statiques de sécurité des applications (SAST)
• Les tests dynamiques de sécurité des applications (DAST)
• La détection des secrets
• L'analyse des conteneurs

<center><i>Fonctionnalités de scanning de sécurité intégrées dans le processus CI/CD à différentes étapes du développement</i></center>

<br></br>

Ces contrôles de sécurité sont intégrés à chaque étape du cycle de développement logiciel, y compris dans les pipelines CI/CD, et offrent aux équipes de développement des retours immédiats sur les failles de sécurité potentielles, et ce dès le début du cycle de développement.

Conformité et exigences réglementaires

Au-delà de la productivité et de l'expérience utilisateur, de nombreuses entreprises, en particulier celles opérant dans les secteurs réglementés tels que les institutions financières ou les grands groupes, doivent s'assurer que leurs processus respectent des normes de sécurité et de conformité strictes. Elles doivent pouvoir appliquer des stratégies pour différents projets, par exemple en rendant obligatoire l'utilisation d'un scanner de sécurité chaque fois qu'un pipeline CI/CD s'exécute sur des branches de code spécifiques (par exemple, les branches principales ou protégées) ou en exigeant des approbations spécifiques avant de fusionner le code dans la branche principale.

Tout devient plus facile avec les frameworks de conformité de GitLab : cette fonctionnalité permet aux entreprises de définir et d'appliquer des stratégies structurées aux projets sélectionnés. Cette approche garantit la conformité en appliquant sans intervention manuelle des exigences réglementaires et de sécurité, tout en maintenant un workflow de développement fluide et efficace.

Développement alimenté par l'IA

GitLab Duo offre une assistance pilotée par l'IA à chaque étape du développement logiciel. Par conséquent, aucun outil externe n'est nécessaire. Chaque requête alimentée par l'IA est traitée dans le contexte complet du projet et du code base, ce qui permet de travailler de façon plus intelligente et plus efficace.

L'IA peut effectuer de nombreuses tâches, notamment :

• Générer automatiquement des descriptions de tâches
• Synthétiser les discussions des tickets pour gagner un temps précieux
• Enrichir la revue de code
• Suggérer des améliorations pour optimiser le code
• Automatiser la génération de tests
• Détecter et corriger les failles de sécurité
• Réaliser une analyse des causes profondes en cas d'échec des pipelines CI
• Garantir le respect de la confidentialité et la sécurité des données

Grâce à sa compréhension des besoins des entreprises opérant dans les secteurs fortement réglementés, en particulier dans le secteur public et le secteur financier, GitLab offre une plateforme unique qui permet d'exécuter des modèles d'IA dans un environnement sécurisé.

GitLab Duo Self-Hosted permet de garder un contrôle total sur la confidentialité des données, la sécurité et le déploiement de grands modèles de langage (LLM) dans leur propre infrastructure et garantit ainsi :

• La protection de la confidentialité des données
• La conformité aux exigences réglementaires
• Une sécurité maximale
• Tous les avantages de l’IA, sans dépendre d’un réseau externe ni exposer vos systèmes à des risques

GitLab, une plateforme moderne et complète

Les entreprises ont besoin d'une plateforme DevSecOps complète pour rationaliser leurs processus, renforcer la sécurité et accélérer l'innovation. C'est précisément ce qu'offre GitLab : une application unique, qui regroupe tous les outils essentiels aux équipes de développement, de sécurité et des opérations, avec une sécurité intégrée et une automatisation alimentée par l'IA.

Pour en savoir plus sur GitLab, découvrez nos démonstrations interactives :

• GitLab Premium et Ultimate avec GitLab Duo : l'assistance au développement alimentée par l'IA
• La sécurité dans les pipelines CI/CD : l'analyse de sécurité intégrée qui protège vos logiciels
• Frameworks de conformité : des stratégies appliquées à l'ensemble des projets pour une meilleure gouvernance

Participez à notre événement virtuel à l'occasion du lancement de GitLab 18 et découvrez ce que vous réserve notre plateforme DevSecOps, notamment le rôle de l'IA agentique. Inscrivez-vous dès aujourd'hui !

« GitLab est la solution tout-en-un la plus complète. Elle s'adresse aux entreprises qui cherchent à standardiser leurs processus avec un seul achat. » - Rapport The Forrester Wave™ dédié aux plateformes DevOps, T2 2025

Cette reconnaissance vient renforcer notre conviction : les équipes de développement logiciel doivent livrer des logiciels sécurisés, plus rapidement, sans sacrifier ni la rapidité, ni la sécurité, ni la simplicité, alors que d'autres plateformes imposent ce compromis. GitLab unifie les enjeux de rapidité, de fiabilité et de gouvernance. Avec la version 18.0 de GitLab sortie en mai, nous franchissons une nouvelle étape en intégrant les fonctionnalités basées sur l'IA native de GitLab Duo, sans frais supplémentaires. Avec GitLab Duo, nos clients bénéficient de fonctionnalités avancées, telles que la génération de tests, les suggestions de code et la refactorisation du code, directement dans GitLab Premium et GitLab Ultimate.

Consultez le rapport Forrester dès aujourd'hui !

Une IA de pointe, sans compromis sur la sécurité

Les principes de l'approche DevSecOps évoluent rapidement, et l'IA est au cœur de cette transformation. Malheureusement, de nombreux outils alimentés par l'IA imposent de choisir entre des fonctionnalités de pointe et la sécurité à l'échelle de l'entreprise.

Forrester a attribué à GitLab la note maximale de 5 pour 2 critères clés : l'injection d'IA et l'atténuation des risques liés à l'IA. Nous sommes fiers que notre engagement à créer des fonctionnalités d'IA innovantes qui renforcent la sécurité soit remarqué non seulement par nos clients, mais également par d'autres parties prenantes.

Ces deux critères se reflètent dans nos offres d'IA GitLab Duo, notamment :

• Duo Workflow (bêta privée) : des agents d'IA autonomes capables de gérer des tâches DevSecOps complexes, avec l'implémentation de garde-fous adaptés au secteur d'activité concerné et de pistes d'audit.
• Agentic Chat : une IA contextuelle et conversationnelle adaptée à toutes les étapes du cycle de développement, des explications de code à la création de tests, avec une protection de la propriété intellectuelle et des contrôles de confidentialité intégrés.
• Suggestions de code : génération prédictive de blocs de code, définition d'une logique fonctionnelle, génération de tests et suggestion d'un code commun comme des motifs regex.
• Résolution de vulnérabilités intégrant l'IA native : détection, explication et correction automatiques des vulnérabilités, avec des merge requests générées automatiquement, qui simplifient le processus de développement.

En finir avec la multiplication des outils

Les équipes DevSecOps ne veulent plus jongler entre plusieurs outils disparates et des intégrations qui les aident seulement pour une partie de leur cycle de développement logiciel. Elles ont besoin d'une expérience de développement fluide, intégrée et cohérente de bout en bout.

Les scores de GitLab dans les critères suivants valident notre stratégie centrée sur le client :

• Expérience zero-day : Forrester a cité notre « forte expérience zero-day », en notant que « la plateforme est opérationnelle immédiatement », grâce notamment aux nombreux outils de migration et tutoriels complets mis à disposition.
• Outils de développement : Forrester a cité GitLab Duo combiné à Amazon Q, notre offre d'IA agentique destinée aux clients AWS, ainsi que notre environnement de développement cloud, notre plateforme de développement intégrée et nos wikis de documentation.
• Planification et alignement des projets : Forrester a noté la « robustesse de notre centre de conformité » et le fait que nous disposons d'outils pour favoriser une approche à la fois descendante et ascendante.
• Sécurité des pipelines : Forrester nous a attribué la note maximale pour ce critère.
• Automatisation des compilations et intégration continue (CI) : Forrester a cité notre automatisation des compilations et nos fonctionnalités d'intégration continue avec des pipelines de compilation en plusieurs étapes et une solide prise en charge des modèles auto-hébergés.

Téléchargez notre rapport

Le fait que GitLab soit nommée Leader dans le rapport The Forrester Wave™: DevOps Platforms (T2 2025) témoigne de l'étendue et de la profondeur des fonctionnalités de notre plateforme, qui fournit une source unique de vérité pour l'ensemble du cycle de développement logiciel. Plus besoin de jongler avec plusieurs outils et multiples intégrations : GitLab offre une expérience fluide et intégrée qui augmente la productivité et réduit les points de friction. Cette distinction reflète le travail assidu de nos équipes, les nombreuses contributions de notre communauté open source, les précieux retours de nos clients et notre engagement constant à façonner l'avenir du développement logiciel.

Téléchargez le rapport dès aujourd'hui !

Forrester ne cautionne aucune entreprise, aucun produit, aucune marque ou aucun service inclus dans ses publications de recherche et ne conseille à quiconque de sélectionner les produits ou services d'une entreprise ou d'une marque en fonction des notes attribuées. Les informations se fondent sur les meilleures ressources disponibles. Les opinions reflètent notre jugement du moment et peuvent évoluer. Pour en savoir plus, découvrez les critères d'objectivité de Forrester.

Mais imaginez un assistant qui ne se limite plus au code : capable de comprendre tous les artefacts de votre processus de développement, de gérer vos tickets, de documenter vos projets, et d’accéder à vos pipelines CI/CD et vos merge requests pour vous aider à mener à bien vos tâches de développement.

Découvrez GitLab Duo Agentic Chat, l'assistant d'IA nouvelle génération, qui succède à GitLab Duo Chat. Dernier-né de la plateforme GitLab, GitLab Duo Agentic Chat marque une avancée majeure dans l'assistance au développement basée sur l'IA native. Disponible dès aujourd'hui en version expérimentale, il est accessible à tous les utilisateurs de GitLab.com via l'extension GitLab Workflow pour VS Code.

Contrairement aux assistants de chat traditionnels basés sur une IA conversationnelle, Agentic Chat effectue des actions en votre nom. Il décompose les problèmes complexes en tâches distinctes qu'il peut accomplir. Au lieu de répondre simplement aux questions en se basant sur le contexte que vous fournissez, il offre les capacités suivantes :

• Il détermine de manière autonome les informations dont il a besoin pour répondre à vos questions.
• Il exécute une séquence d'opérations afin de collecter ces informations à partir de plusieurs sources.
• Il formule des réponses complètes en combinant les données provenant de l'ensemble de votre projet.
• Il crée et modifie des fichiers pour vous aider à mettre en œuvre des solutions.

Mais bien évidemment, en tant que développeur, vous avez toujours votre mot à dire.

Agentic Chat repose sur l'architecture GitLab Duo Workflow, actuellement disponible en version bêta privée qui intègre des agents et des outils dédiés pour des tâches spécifiques : recherche contextuelle, modification de fichiers, et bien plus encore.

Cas d'utilisation de GitLab Duo Agentic Chat

Avec Agentic Chat, vous pouvez :

• Prendre en main les nouveaux projets plus rapidement en demandant à l'IA de vous guider à travers le nouveau code base.

• Commencer à effectuer immédiatement les tâches qui vous sont attribuées, même lorsque les descriptions des tickets ne sont pas claires : Agentic Chat vous aide à faire le lien entre les exigences et les implémentations.

• Gérer l’implémentation : lorsqu'il est temps d'apporter des modifications, Agentic Chat peut gérer le travail d'implémentation en créant et en modifiant plusieurs fichiers dans votre projet.

• Vérifier votre solution : au moment de la mise en production, Agentic Chat peut vous aider à vérifier que votre solution répond réellement aux exigences initiales en analysant vos merge requests et en les comparant au ticket ou à la tâche d'origine.

<center><i>Agentic Chat apporte des modifications au code</i></center>

De l'apprentissage à la livraison : un workflow en quatre étapes

Pour mieux saisir l'impact d'Agentic Chat, explorons un scénario réel vécu par notre équipe d’ingénierie. Prenons l'exemple suivant : vous intégrez une nouvelle équipe, un ticket vous est attribué, mais vous ne maîtrisez pas encore le code base.

Pour mieux visualiser ce scénario, n'hésitez pas à regarder la vidéo de démonstration ci-dessous :

<!-- blank line --> <figure class="video_container"> <iframe src="https://www.youtube.com/embed/uG9-QLAJrrg?si=kaOhYylMIaWkIuG8j" frameborder="0" allowfullscreen="true"> </iframe> </figure> <!-- blank line -->

Étape 1 : comprendre le projet

Au lieu d'explorer manuellement les fichiers et la documentation, vous pouvez soumettre le prompt suivant à Agentic Chat :

I am new to this project. Could you read the project structure and explain it to me?

Agentic Chat fournit une vue d'ensemble complète du projet en :

• explorant la structure des répertoires
• lisant les fichiers README et la documentation
• identifiant les composants et les applications clés

Étape 2 : comprendre la tâche qui vous a été attribuée

Ensuite, vous devez comprendre la tâche à effectuer. Vous pouvez donc saisir le prompt suivant :

I have been assigned Issue 1119. Could you help me understand this task, specifically where do I need to apply the refactoring?

Agentic Chat explique la tâche et propose une approche de refactorisation :

• en récupérant et en analysant les détails du ticket à partir du serveur GitLab distant
• en examinant les fichiers associés au projet
• en identifiant les emplacements spécifiques nécessitant des modifications

Étape 3 : mettre en œuvre la solution

Plutôt que d'effectuer le travail manuellement, vous pouvez saisir le prompt suivant :

Could you make the edits for me? Please start with steps one, two, three.

Agentic Chat :

• crée des répertoires et fichiers si nécessaire
• extrait et refactorise le code à plusieurs emplacements
• assure la cohérence de tous les fichiers modifiés
• fournit un résumé de toutes les modifications apportées

Étape 4 : vérifier que le travail effectué est correct

Enfin, après avoir créé votre merge request, vous pouvez vérifier votre travail avec le prompt suivant :

Does my MR fully address Issue 1119?  

Agentic Chat confirme alors si toutes les exigences ont été prises en compte en analysant à la fois votre merge request et le ticket d'origine.

Essayez Agentic Chat dès aujourd'hui !

GitLab Duo Agentic Chat est actuellement disponible en tant que fonctionnalité expérimentale dans VS Code pour les utilisateurs de GitLab Duo Pro et GitLab Duo Enterprise. Découvrez les prérequis et les étapes de configuration dans notre documentation officielle.

Cette version expérimentale d'Agentic Chat présente encore quelques limitations connues que nous nous efforçons de résoudre, y compris des temps de réponse parfois lents en raison de multiples appels API, une recherche basée sur des mots-clés plutôt que sur une recherche sémantique, ainsi qu'une prise en charge limitée des nouveaux dossiers locaux ou des projets autres que GitLab. Vos retours sont précieux pour nous aider à hiérarchiser les prochaines améliorations et à proposer Agentic Chat en disponibilité générale. C'est pourquoi nous vous invitons à partager votre expérience dans ce ticket.

Quelles perspectives pour Agentic Chat ?

Nous concentrons tous nos efforts sur l'amélioration d'Agentic Chat en vue de sa future disponibilité générale. À court terme, notre objectif est de réduire les temps de réponse et d'y intégrer les capacités dont GitLab Duo Chat dispose actuellement, telles que la compatibilité avec les modèles de GitLab Duo Self-Hosted, ainsi que la prise en charge des environnements JetBrains et Visual Studio, en plus de VS Code. Une fois cette nouvelle architecture pleinement implémentée dans GitLab Duo Chat, nous prévoyons également d'intégrer Agentic Chat directement au chat intégré à l'application web de GitLab. D'autres améliorations sont déjà en cours de développement, notamment : la modification directe des artefacts GitLab, la prise en charge du contexte à partir de serveurs personnalisés via MCP (Model Context Protocol) et la possibilité d'exécuter des commandes directement dans le terminal.

Vous souhaitez découvrir l'assistance au développement autonome, mais vous n'utilisez pas encore GitLab ? Profitez dès aujourd'hui d'un essai gratuit de 60 jours de GitLab Ultimate avec Duo Enterprise pour tester Agentic Chat et contribuez à façonner l'avenir du développement alimenté par l'IA. Pour commencer, suivez simplement ces étapes de configuration pour VS Code.

Avertissement : cet article de blog contient des informations relatives aux produits, fonctionnalités et caractéristiques à venir. Il est important de noter qu'elles ne sont fournies qu'à titre informatif. Veuillez ne pas vous fier à ces informations à des fins d'achat ou de planification. Comme pour tout projet, les éléments mentionnés dans cet article sont susceptibles de changer ou d’être retardés. Le développement, la sortie et le calendrier de tout produit ou fonctionnalité restent à la seule discrétion de GitLab.

En savoir plus

• GitLab Duo Workflow : une IA agentique offrant visibilité et contrôle à l'échelle de l'entreprise
• Qu'est-ce que l'IA agentique ?
• Agentic Chat : guides et ressources

Dans cet article, découvrez comment fonctionnent les grands modèles de langage, leurs applications concrètes et les principaux enjeux à surmonter pour exploiter pleinement leur potentiel.

Sommaire

• Qu’est-ce qu’un LLM ?
• Comment fonctionnent les grands modèles de langage ?
• Applications des grands modèles de langage dans une approche DevSecOps
• Quels sont les avantages des grands modèles de langage ?
• Quels sont les défis liés à l’utilisation des LLM ?
• Comment GitLab utilise les LLM pour ses fonctionnalités GitLab Duo ?

Qu’est-ce qu’un LLM ?

Les grands modèles de langage (LLM) sont des systèmes d’intelligence artificielle capables de traiter et de générer du texte de manière autonome. Leur apprentissage repose sur l’analyse de vastes ensembles de données issues de sources variées, afin qu’ils puissent maîtriser les structures linguistiques, les relations contextuelles et les nuances du langage.

Les LLM représentent une avancée majeure dans le domaine de l’IA. Leur capacité à traiter, générer et interpréter du texte repose sur des techniques sophistiquées d’apprentissage automatique et de traitement automatique du langage naturel (NLP). Ces systèmes ne se contentent pas de traiter des mots isolés : ils analysent des séquences complexes pour saisir le sens global, les contextes subtils et les nuances linguistiques.

Comment fonctionnent les grands modèles de langage ?

Pour mieux comprendre leur fonctionnement, explorons certaines des caractéristiques clés des grands modèles de langages.

Apprentissage supervisé et non supervisé

Les grands modèles de langage sont entraînés selon deux approches complémentaires : l’apprentissage supervisé et l’apprentissage non supervisé. Ces deux approches du machine learning permettent de maximiser leurs capacités à analyser et à générer du texte.

• L’apprentissage supervisé repose sur des données étiquetées, où chaque entrée est associée à un résultat attendu. Le modèle apprend à associer ces entrées aux sorties correctes en ajustant ses paramètres internes pour réduire les erreurs de prédiction. Grâce à cette approche, le modèle acquiert des connaissances précises sur des tâches spécifiques, telles que la classification de textes ou la reconnaissance d’entités nommées.

• L’apprentissage non supervisé (ou apprentissage automatique), quant à lui, ne nécessite pas de données étiquetées. Le modèle explore de vastes volumes de texte pour découvrir des structures cachées et identifier des relations sémantiques. Ainsi, le modèle est en capacité d‘apprendre des schémas récurrents, des règles grammaticales implicites dans le texte ou encore de contextualisation des phrases et des concepts. Cette méthode permet d’entraîner les LLM sur de vastes corpus de données, accélérant considérablement leur progression sans intervention humaine directe.

En combinant ces deux approches, les grands modèles de langage bénéficient autant d'un apprentissage précis guidé par des humains que d’une exploration autonome illimitée. Cette complémentarité leur permet de se développer rapidement, tout en améliorant continuellement leur capacité à comprendre et à générer du texte de manière cohérente et contextuelle.

Apprentissage reposant sur un large volume de données

Les grands modèles de langage sont entraînés à partir de milliards de phrases issues de sources variées, telles que des articles de presse, des forums en ligne, des documentations techniques, des études scientifiques et bien plus encore. Cette variété de sources leur permet d’acquérir une compréhension étendue et nuancée du langage naturel, allant des expressions courantes aux terminologies spécialisées.

La richesse des données utilisées est un facteur clé de la performance des LLM. Chaque source apporte des styles d’écriture, des contextes culturels et des niveaux de technicité différents.

Par exemple :

• Des articles de presse : pour maîtriser un langage informatif et factuel.
• Des forums en ligne : pour comprendre les conversations informelles et les langages techniques des communautés spécialisées.
• Des documentations techniques et études scientifiques : pour assimiler des concepts complexes et des terminologies spécifiques, notamment dans des domaines comme le DevOps et le DevSecOps.

Cette diversité de contenu permet aux LLM de reconnaître des structures linguistiques complexes, d’interpréter des phrases dans différents contextes et de s’adapter à des domaines très techniques. Dans le DevSecOps, cela signifie comprendre des commandes, des configurations, des protocoles de sécurité et même des concepts liés au développement et à la maintenance de systèmes informatiques.

Grâce à cette formation à grande échelle, les grands modèles de langage peuvent répondre avec précision à des questions complexes, rédiger des documentations techniques ou identifier des vulnérabilités dans des systèmes informatiques.

Architecture de réseaux neuronaux et « deep learning »

Les grands modèles de langage reposent sur des architectures de réseaux neuronaux avancées. Ces réseaux sont spécialement conçus pour traiter de grandes séquences de texte tout en maintenant une compréhension précise du contexte. Cet apprentissage en « deep learning » constitue un atout majeur dans le domaine du traitement automatique du langage naturel (NLP).

La plus connue de ces structures est l’architecture des modèles séquence à séquence (transformers). Cette architecture a révolutionné le NLP grâce à sa capacité à analyser simultanément toutes les parties d’un texte, contrairement aux approches séquentielles qui traitent les mots un par un.

Les modèles séquence à séquence excellent dans le traitement des textes longs. Par exemple, dans une conversation ou un document technique détaillé, ils sont capables de relier des informations distantes dans le texte pour produire des réponses précises et bien argumentées. Cette gestion du contexte est essentielle dans une approche DevSecOps, où les instructions peuvent être complexes et réparties sur plusieurs lignes de code ou étapes de configuration.

Génération de texte prédictive

Lorsque l'utilisateur soumet un texte, une requête ou une question, un grand modèle de langage utilise sa capacité de prédiction pour générer la suite la plus probable, fondée sur le contexte fourni.

Le modèle analyse chaque mot, étudie les relations grammaticales et sémantiques, puis sélectionne les termes les plus adaptés pour produire un texte cohérent et informatif. Cette approche permet de générer des réponses précises, détaillées et adaptées au ton attendu.

Dans les environnements DevSecOps, cette capacité devient particulièrement utile pour :

• l’assistance au codage : génération de blocs de code ou de scripts adaptés à des configurations spécifiques.
• la résolution de problèmes techniques : propositions de solutions basées sur des descriptions de bogues ou d’erreurs.
• la rédaction de documentations techniques : création automatique de guides, de manuels ou d'instructions.

La génération de texte prédictive permet ainsi d’automatiser de nombreuses tâches répétitives et d’accélérer le travail des équipes techniques.

Applications des grands modèles de langage dans une approche DevSecOps

Avec la montée en puissance de l’automatisation, les grands modèles de langage sont devenus des alliés incontournables pour les équipes techniques. Leur capacité à comprendre et à générer du texte de manière contextuelle leur permet d’intervenir efficacement dans des environnements complexes tels que le DevSecOps.

Grâce à leur puissance d’analyse et leur capacité à s’adapter aux besoins spécifiques, ces modèles offrent des solutions sur mesure pour rationaliser les processus et alléger la charge de travail des équipes techniques.

Génération de code automatisée

Les équipes de développement peuvent exploiter les grands modèles de langage pour transformer des spécifications fonctionnelles en code source de manière automatisée.

Grâce à cette capacité, elles peuvent :

• générer des scripts d'automatisation complexes,
• créer des pipelines CI/CD adaptés aux processus spécifiques de l'entreprise,
• produire des correctifs de sécurité sur mesure.
• générer des explications de code et créer une documentation,
• refactoriser le code en améliorant sa structure et sa lisibilité sans modifier les fonctionnalités,
• générer des tests.

En s'appuyant sur les LLM, les équipes parviennent à accélérer le développement de leurs logiciels tout en réduisant les risques d'erreurs humaines.

Documentation et partage des connaissances améliorés

Ces puissants outils facilitent la création de manuels d'utilisation, de descriptions d'API et de tutoriels sur mesure, parfaitement adaptés au niveau d'expertise de chaque utilisateur. En s’appuyant sur des bases de connaissances existantes, les grands modèles de langages créent des réponses contextuelles aux questions fréquentes. Cela améliore la transmission des savoirs au sein des équipes, accélère l'intégration des nouveaux membres et permet de centraliser les bonnes pratiques.

Gestion des incidents et dépannage

Lors d’un incident, les LLM jouent un rôle crucial en analysant en temps réel les logs et les fichiers de trace. Grâce à leur capacité à croiser des informations provenant de multiples sources, ils identifient les anomalies et proposent des solutions fondées sur des incidents similaires passés. Cette approche réduit significativement le temps de diagnostic. De plus, les LLM peuvent automatiser la création de rapports d'incidents détaillés et recommander des actions correctives précises.

Création et amélioration des pipelines CI/CD

Les grands modèles de langage révolutionnent la configuration des pipelines CI/CD. Ils peuvent non seulement aider à créer des pipelines, mais aussi à automatiser ce processus et proposer des configurations optimales basées sur des standards de l'industrie. En adaptant les workflows selon vos besoins spécifiques, ils assurent une cohérence parfaite entre les différents environnements de développement. Les tests automatisés sont renforcés par des suggestions pertinentes, limitant ainsi les risques de défaillance. Les LLM surveillent également en continu l’efficacité des pipelines et ajustent les processus pour garantir un déploiement fluide et sans interruption.

Sécurité et conformité

Dans un environnement DevSecOps, les grands modèles de langage deviennent des alliés précieux pour la sécurité et la conformité. Ils analysent le code source à la recherche de vulnérabilités potentielles et génèrent des recommandations correctives détaillées. Les LLM peuvent également surveiller l'application des normes de sécurité en temps réel, produire des rapports de conformité complets et automatiser l'application de correctifs de sécurité dès qu'une faille est identifiée. Cette automatisation renforce la sécurité globale et garantit un respect constant des exigences légales et industrielles.

Quels sont les avantages des grands modèles de langage ?

Les grands modèles de langage transforment en profondeur les approches DevOps et DevSecOps, apportant des améliorations substantielles en matière de productivité, de sécurité et de qualité logicielle. En s’intégrant aux workflows existants, les LLM bouleversent les approches traditionnelles en automatisant des tâches complexes et en fournissant des solutions innovantes.

Amélioration de la productivité et de l’efficacité

Les grands modèles de langage jouent un rôle central dans l’amélioration de la productivité et de l’efficacité des équipes techniques. En automatisant un large éventail de tâches répétitives, ils libèrent les équipes de développement des opérations routinières. Ces dernières peuvent ainsi se concentrer sur des activités stratégiques à plus forte valeur ajoutée.

En outre, les LLM agissent comme des assistants techniques intelligents capables de fournir instantanément des extraits de code pertinents, adaptés au contexte spécifique de chaque projet. De cette manière, ils réduisent considérablement le temps de recherche en proposant des solutions prêtes à l’emploi pour assister les équipes dans leur travail. Cette assistance ciblée accélère la résolution des problèmes et diminue les interruptions dans les workflows.

Ainsi, la productivité augmente et les projets avancent plus rapidement. Les équipes techniques peuvent prendre en charge un plus grand nombre de tâches sans compromettre la qualité des livrables.

Amélioration de la qualité du code et de la sécurité

L’utilisation des grands modèles de langage dans le développement logiciel constitue un levier majeur pour améliorer autant la qualité du code que la sécurité des applications. Grâce à leurs capacités d’analyse avancées, les LLM peuvent examiner le code source ligne par ligne et détecter instantanément les erreurs syntaxiques, incohérences logiques et vulnérabilités potentielles. Leur aptitude à reconnaître le code défectueux permet de recommander des corrections adaptées et conformes aux meilleures pratiques du secteur.

Les LLM jouent aussi un rôle préventif essentiel. Ils excellent dans l'identification des failles de sécurité complexes, souvent difficiles à repérer par les humains. En analysant les dépendances, ils peuvent signaler des bibliothèques obsolètes ou vulnérables, et recommander des versions mises à jour plus sûres. Cette approche contribue au maintien d’un environnement sécurisé et conforme aux normes de sécurité en vigueur.

Au-delà de la correction des erreurs existantes, les LLM proposent des améliorations en suggérant des pratiques de codage et des structures de projet optimisées. Ils peuvent générer du code respectant les normes de sécurité les plus avancées, et ce, dès les premières étapes du développement.

Accélération des cycles de développement

Les grands modèles de langage jouent un rôle déterminant dans l’accélération des cycles de développement logiciel en automatisant des tâches clés qui, autrement, mobiliseraient de précieuses ressources humaines.

Les tâches complexes et répétitives, comme l’écriture de fonctions, la création de tests unitaires ou l’implémentation de composants standards, sont automatisées en quelques instants.

Les LLM accélèrent également la phase de validation grâce à leur capacité à suggérer des scénarios de test complets et adaptés. Ils garantissent une couverture de test plus étendue en un minimum de temps, réduisant les risques d’erreurs et facilitant la détection précoce des anomalies. Cette approche préventive raccourcit le cycle de corrections et limite les retards liés aux problèmes de qualité du code.

En simplifiant les tâches techniques et en fournissant des solutions rapides et adaptées, les grands modèles de langage favorisent une réponse plus agile des entreprises aux exigences du marché. Cette accélération du cycle de développement se traduit par des mises à jour plus fréquentes, des itérations plus rapides et une meilleure capacité à adapter les produits aux besoins changeants des utilisateurs.

Les cycles de développement deviennent ainsi plus courts, offrant un avantage stratégique essentiel dans un environnement technologique toujours plus exigeant.

Quels sont les défis liés à l’utilisation des LLM ?

Malgré leurs nombreux avantages, les grands modèles de langage présentent certaines limites qui nécessitent une gestion attentive. Leur efficacité dépend fortement de la qualité des données utilisées lors de leur entraînement et de la mise à jour régulière de leurs bases de connaissances. De plus, des problèmes liés aux biais algorithmiques, à la sécurité des données et à la confidentialité peuvent survenir, exposant les entreprises à des risques opérationnels et juridiques. Une supervision humaine rigoureuse demeure indispensable pour garantir la fiabilité des résultats, assurer la conformité réglementaire et éviter les erreurs critiques.

Confidentialité et sécurité des données

L’entraînement des LLM repose sur de vastes volumes de données, souvent issues de sources diverses, ce qui soulève des questions quant à la protection des informations confidentielles. Les données sensibles partagées avec des plateformes cloud peuvent donc être exposées à des violations potentielles. Cela inquiète particulièrement les entreprises opérant dans des secteurs réglementés.

En Europe, où des réglementations strictes comme le RGPD régissent la gestion des données, de nombreuses entreprises hésitent à transférer leurs informations vers des services externes. Les exigences réglementaires, associées à la crainte d'une exploitation non autorisée des données sensibles, incitent certaines entreprises à privilégier des solutions auto-hébergées pour conserver un contrôle total sur leurs systèmes.

Des fournisseurs comme GitLab ont mis en place des garanties de sécurité robustes, telles que la non-rétention intentionnelle des données à caractère personnel et le chiffrement de bout en bout. Toutefois, cela peut ne pas suffire pour les clients les plus exigeants, qui préfèrent une maîtrise complète de leurs environnements. La mise en œuvre de solutions hybrides ou sur site devient alors une nécessité stratégique pour répondre aux exigences de sécurité de certaines entreprises.

Pour en savoir plus sur GitLab Duo Self-Hosted, cliquez sur l'image ci-dessous pour accéder à la visite guidée.

<a href="https://gitlab.navattic.com/gitlab-duo-self-hosted"><img src="//images.ctfassets.net/r9o86ar0p03f/2pwIuKnYugpw309BVVMjou/84dd883d0332876b731faaed6d649140/gitlab-duo-self-hosted-product-tour.png" alt="GitLab Duo Self-Hosted Product Tour"></a>

Précision et fiabilité

Bien que les grands modèles de langage soient capables de générer des résultats impressionnants, leur performance n’est pas infaillible. Ils peuvent produire des réponses incorrectes, incomplètes ou incohérentes. Cette imprécision devient particulièrement problématique dans le cadre de tâches critiques comme la génération de code de sécurité ou l'analyse de données sensibles.

De plus, les LLM fonctionnent sur la base de modèles probabilistes, ce qui signifie qu’ils ne « comprennent » pas véritablement le contenu qu'ils traitent, mais produisent des prédictions basées sur des probabilités statistiques. Cela peut entraîner des recommandations techniquement incorrectes, voire dangereuses, lorsqu'elles sont utilisées sans validation humaine.

Pour éviter ces pièges, il est essentiel de maintenir une supervision constante et d’établir des processus de validation rigoureux. Les résultats fournis par les LLM doivent alors toujours être examinés par des humains avant leur intégration dans des systèmes critiques.

Une stratégie de mise à jour régulière des modèles, associée à une surveillance humaine proactive, permet de réduire les erreurs et d'améliorer progressivement la fiabilité des résultats.

Comment GitLab utilise les LLM pour ses fonctionnalités GitLab Duo ?

GitLab Duo exploite la puissance des grands modèles de langage pour transformer les processus DevSecOps en intégrant des fonctionnalités alimentées par l’IA, et ce, tout au long du cycle de vie du développement logiciel. Cette approche vise à améliorer la productivité, renforcer la sécurité et automatiser des tâches complexes afin de permettre aux équipes de développement de se concentrer sur des tâches à forte valeur ajoutée.

Une assistance IA pour le développement logiciel

GitLab Duo propose un soutien continu tout au long du cycle de développement logiciel grâce à des recommandations en temps réel. Les équipes de développement peuvent automatiquement générer des tests unitaires, obtenir des explications détaillées sur des segments de code complexes et bénéficier de suggestions pour améliorer la qualité de leur code.

Analyse proactive des défaillances CI/CD

L’une des fonctionnalités clés de GitLab Duo est son assistance à l'analyse des échecs des jobs CI/CD. Grâce au LLM et l’IA, les équipes parviennent à identifier rapidement les sources d'erreurs dans leurs pipelines d’intégration et de déploiement continus.

Sécurité du code renforcée

GitLab Duo intègre des fonctionnalités de sécurité basées sur l’IA. Le système détecte les vulnérabilités dans le code source et propose des correctifs détaillés pour en réduire les risques. Les équipes reçoivent des explications claires sur la nature des failles identifiées et peuvent appliquer des correctifs automatisés via des merge requests générées directement par GitLab Duo. Cette fonctionnalité permet de sécuriser le développement sans pour autant ralentir les cycles de développement.

Pour en savoir plus sur cette fonctionnalité, cliquez sur l'image ci-dessous pour accéder à notre visite guidée.

<a href="https://gitlab.navattic.com/ve-vr-short"><img src="//images.ctfassets.net/r9o86ar0p03f/R6uuYPxQoSwo56kWygRkJ/9972ec8e5371cfc30391c6f656ed35fb/gitlab-duo-enterprise-product-tour.png" alt="GitLab Vulnerability Report Product Tour"></a>

Fonctionnalités clés de GitLab Duo

• GitLab Duo Chat : cette fonctionnalité conversationnelle traite et génère du texte et du code de manière intuitive. Elle permet aux utilisateurs de rechercher rapidement des informations pertinentes dans des volumes importants de texte, notamment dans les tickets, les epics, le code source et la documentation GitLab.

• GitLab Duo Self-Hosted : GitLab Duo Self-Hosted permet aux entreprises ayant des exigences strictes en matière de confidentialité de leurs données de bénéficier des fonctionnalités d’IA de GitLab Duo avec une flexibilité dans le choix du déploiement et des LLM parmi une liste d’options supportées.

• Suggestions de code : les équipes de développement bénéficient de suggestions de code automatisées, ce qui leur permet d'écrire du code sécurisé plus rapidement. Les tâches de codage répétitives et routinières sont ainsi automatisées, accélérant considérablement les cycles de développement logiciel.

GitLab Duo ne se limite pas à ces fonctionnalités. Il offre une gamme étendue de fonctionnalités destinées à simplifier et à optimiser le développement logiciel. Que ce soit pour automatiser des tests, améliorer la collaboration entre les équipes ou renforcer la sécurité des projets, GitLab Duo constitue une solution complète pour des processus DevSecOps intelligents et efficaces.

Pour en savoir plus sur GitLab Duo Enterprise, cliquez sur l'image ci-dessous pour accéder à notre visite guidée.

<a href="https://gitlab.navattic.com/duo-enterprise"><img src="//images.ctfassets.net/r9o86ar0p03f/4nclgZ2JUeQ0hR4wjOS30P/ba948ae1a0dce0cff4469ca06490efb1/Screenshot_2024-08-27_at_9.24.32_AM.png" alt="GitLab Duo Enterprise Product Tour"></a>

Après avoir exploré les bases de l'approche CI/CD de GitLab dans notre précédent article, concentrons-nous à présent sur les variables CI/CD afin de tirer pleinement parti de leur potentiel.

Qu’est-ce qu’une variable CI/CD ?

Les variables CI/CD sont des paires clé-valeur dynamiques que vous pouvez définir à différents niveaux (projet, groupe ou instance par exemple) au sein de votre environnement GitLab. Elles permettent de personnaliser les pipelines CI/CD, de centraliser les configurations et de gérer en toute sécurité des données sensibles. Intégrées directement dans le fichier .gitlab-ci.yml comme des espaces réservés pour les valeurs correspondantes, elles facilitent la maintenance, renforcent la sécurité et améliorent la flexibilité des workflows CI/CD.

Quel est le rôle des variables CI/CD ?

Les variables CI/CD offrent de nombreux avantages :

• Flexibilité : adaptez facilement vos pipelines à différents environnements, configurations ou cibles de déploiement sans modifier votre script CI/CD principal.
• Sécurité : stockez en toute sécurité des informations sensibles telles que des clés API, des mots de passe et des tokens sans les exposer dans votre code.
• Maintenabilité : en centralisant les valeurs, elles simplifient la gestion et les mises à jour de votre configuration CI/CD pour qu'elle reste structurée correctement.
• Réutilisation : définies une seule fois, elles peuvent être réutilisées dans plusieurs projets, ce qui favorise la cohérence et réduit les doublons.

Portées des variables CI/CD : projet, groupe et instance

GitLab permet de définir des variables CI/CD à différentes niveaux hiérarchiques du projet, avec un contrôle précis sur leur visibilité, leur portée et leur accessibilité :

• Variables au niveau du projet : elles sont propres à un seul projet et idéales pour stocker des paramètres spécifiques, notamment :

  • L'URL de déploiement : définissez des URL distinctes pour les environnements de préproduction et de production.
  • Les identifiants de connexion à la base de données : stockez les données de connexion à la base de données afin de pouvoir les utiliser lors d'un test ou d'un déploiement.
  • Les feature flags : activez ou désactivez les fonctionnalités à différentes étapes de votre pipeline.
  • Exemple : dans le cadre de votre projet MyWebApp, vous souhaitez stocker l'URL de déploiement de production. Vous pouvez définir une variable au niveau du projet, nommée DPROD_DEPLOY_URL, avec la valeur https://mywebapp.com d'URL de production.

• Variables au niveau du groupe : elles sont partagées par tous les projets d'un groupe GitLab. Elles sont utiles pour centraliser des paramètres communs à plusieurs projets, notamment :

  • Les clés API de services partagés : stockez-les pour des services tels qu'AWS, Google Cloud ou Docker Hub qui sont utilisés par plusieurs projets au sein du groupe.
  • Les paramètres de configuration généraux : définissez des paramètres de configuration communs qui s'appliquent à tous les projets du groupe.
  • Exemple : dans votre groupe Web Apps, vous souhaitez stocker une clé API pour Docker Hub. Vous pouvez définir une variable au niveau du groupe, nommée DOCKER_HUB_API_KEY, avec la valeur de clé API correspondante.

• Variables au niveau de l'instance : elles sont disponibles pour tous les projets d'une instance GitLab et couramment utilisées pour les paramètres généraux qui s'appliquent à l'ensemble de l'entreprise, notamment :

  • Le token d'enregistrement de runner par défaut : fournissez un token par défaut pour l'enregistrement de nouveaux runners.
  • Les informations sur la licence : stockez les clés de licence des fonctionnalités GitLab ou des outils tiers.
  • Les paramètres d'environnement généraux : définissez des variables d'environnement qui doivent être disponibles pour tous les projets.
  • Exemple : vous souhaitez définir une image Docker par défaut pour tous les projets de votre instance GitLab. Vous pouvez définir une variable au niveau de l'instance, nommée DEFAULT_DOCKER_IMAGE, avec la valeur ubuntu:latest.

Comment définir des variables CI/CD ?

Pour définir une variable CI/CD, voici comment procéder :

1. Cliquez sur les boutons Paramètres > CI/CD de votre projet, groupe ou instance.
2. Accédez à la section Variables.
3. Cliquez sur Ajouter une variable.
4. Saisissez la clé (par exemple, API_KEY) et la valeur correspondante.
5. Facultatif : cochez l'option Protéger la variable si elle contient des données sensibles afin de restreindre son utilisation aux pipelines qui s'exécutent sur des branches ou des tags protégés.
6. Facultatif : cochez la case Masquer la variable pour masquer sa valeur dans les job logs, afin d'éviter toute exposition accidentelle.
7. Cliquez sur Enregistrer la variable.

Comment utiliser des variables CI/CD ?

Pour utiliser une variable CI/CD dans votre fichier .gitlab-ci.yml, faites simplement précéder le nom de la variable du symbole $ :

deploy_job:
  script:
    - echo "Deploying to production..."
    - curl -H "Authorization: Bearer $API_KEY" https://api.example.com/deploy

Comment utiliser les variables CI/CD prédéfinies dans GitLab ?

GitLab met à disposition un ensemble de variables CI/CD prédéfinies que vous pouvez utiliser dans vos pipelines CI/CD. Celles-ci fournissent des informations contextuelles sur le pipeline, le job, le projet en cours, et bien plus encore.

Voici les variables plus couramment utilisées :

• $CI_COMMIT_SHA : SHA de validation qui déclenche le pipeline
• $CI_PROJECT_DIR : répertoire dans lequel le projet est cloné
• $CI_PIPELINE_ID : ID du pipeline en cours
• $CI_ENVIRONMENT_NAME : nom de l'environnement de déploiement cible (le cas échéant)

Bonnes pratiques pour l'utilisation des variables CI/CD

• Gérez en toute sécurité les variables sensibles : utilisez des variables protégées et masquées pour stocker les clés API, les mots de passe et tout autre secret.
• Évitez de coder en dur les valeurs : stockez les valeurs de configuration dans des variables afin de renforcer la flexibilité et la maintenance de vos pipelines.
• Organisez vos variables : utilisez des noms explicites et regroupez les variables par usage pour faciliter leur gestion.
• Choisissez la portée appropriée : définissez vos variables au niveau du projet, groupe ou instance en fonction de leur utilisation prévue et de leur visibilité.

Tirez parti de la puissance des variables CI/CD

Les variables CI/CD sont un outil puissant pour personnaliser et sécuriser vos pipelines GitLab. En maîtrisant leur fonctionnement et en comprenant leurs différentes portées, vous pouvez créer des workflows plus flexibles, plus faciles à maintenir et plus efficaces.

Prêt à passer à l’action ? Commencez à utiliser les variables CI/CD dès aujourd'hui et profitez d'un essai gratuit de 60 jours de GitLab Ultimate avec Duo Enterprise.

Articles de la série « Premiers pas avec GitLab »

Découvrez les autres articles de notre série « Premiers pas avec GitLab » :

• Comment gérer les utilisateurs
• Comment importer vos projets dans GitLab
• Comment maîtriser la gestion de projet
• La gemme gitlab-triage : votre alliée pour des workflows Agile automatisés
• Comprendre l'approche CI/CD

L'IA au service des équipes de développement

L'intelligence artificielle occupe désormais une place centrale dans le quotidien des équipes de développement. Elle optimise l'écriture de code en analysant le code base en temps réel, en proposant des suggestions au fil de la saisie, en générant des fonctions et méthodes adaptées au contexte du projet, en automatisant les tâches répétitives et en simplifiant les revues de code.

Depuis plusieurs années, nous développons GitLab Duo pour intégrer ces capacités d'IA générative et agentique à notre plateforme, car l'écriture du code ne représente qu'une partie du cycle de développement logiciel : notre Rapport Global DevSecOps révèle en effet que les développeurs consacrent 79 % de leur temps à des tâches autres que la création de code. Nous avons donc fait le choix d'intégrer l'IA à chaque étape du cycle de développement logiciel.

Nous franchissons aujourd'hui un nouveau cap en incluant les fonctionnalités clés de GitLab Duo dans nos éditions GitLab Premium et GitLab Ultimate, afin que chaque développeur et développeuse puisse bénéficier des avantages de l'IA, sans frais supplémentaires.

En effet, en intégrant les fonctionnalités de chat et de suggestions de code de GitLab Duo aux éditions GitLab Premium et Ultimate, les ingénieurs logiciels peuvent accélérer leur workflow au sein même de l'IDE, sans devoir installer d'autres outils, gérer des licences distinctes ou se soucier de la gouvernance. Il suffit aux clients Premium et Ultimate existants de passer à GitLab 18.0 pour bénéficier d'un accès instantané à ces fonctionnalités. Elles seront également disponibles pour tous les nouveaux clients.

« GitLab a déjà joué un rôle déterminant en nous aidant à nous affranchir d'une chaîne d'outils fragmentée, ce qui a permis de réduire les coûts liés à des solutions disparates et de rationaliser notre workflow. L'ajout de GitLab Duo à GitLab Premium nous permettra d'optimiser notre productivité et de réaliser encore plus d'économies, car nos développeurs consacreront moins de temps aux tâches de codage répétitives et plus de temps à la résolution de défis complexes qui génèrent une valeur métier réelle. »

• Andrei Nita, Chief Technology Officer chez McKenzie Intelligence Services

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1083723619?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="GitLab Premium with Duo Core"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

<br></br> Les clients Premium et Ultimate bénéficient désormais des capacités d'IA natives suivantes :

Suggestions de code de GitLab Duo

• Génération de fonctions complètes et de blocs de code à partir de commentaires
• Complétion de code intelligente au fil de la saisie
• Prise en charge de plus de 20 langages de programmation
• Intégration aux IDE les plus populaires

Découvrez la fonctionnalité de suggestions de code de GitLab Duo dans cette présentation interactive (cliquez sur l'image pour démarrer la présentation).

<a href="https://gitlab.navattic.com/code-suggestions"><img src="//images.ctfassets.net/r9o86ar0p03f/4nclgZ2JUeQ0hR4wjOS30P/ba948ae1a0dce0cff4469ca06490efb1/Screenshot_2024-08-27_at_9.24.32_AM.png" alt="GitLab Duo Code Suggestions cover image"></a>

Consultez notre documentation sur les suggestions de code de GitLab Duo pour en savoir plus.

GitLab Duo Chat

• Explication de code pour faciliter la compréhension des fonctions complexes
• Refactorisation du code existant pour améliorer sa qualité et sa maintenabilité
• Génération de scénarios de test complets pour vous aider à détecter les bugs dès les premières étapes du développement
• Correction des anomalies directement dans votre workflow

Pour en savoir plus, consultez notre documentation sur GitLab Duo Chat.

« Pour nous, en tant qu'utilisateurs de GitLab, les suggestions de code intelligentes de GitLab Duo sont devenues un atout quotidien pour nos développeurs. Combinées à la fonctionnalité de chat, elles permettent d'effectuer des itérations rapides, avec un retour immédiat, pour des cycles de développement plus fluides et un code plus sécurisé. Elles constituent une intégration à la fois fluide et puissante à nos workflows. »

• Felix Kortmann, Chief Technology Officer, Ignite by FORVIA HELLA

GitLab Duo Enterprise disponible pour les clients GitLab Premium

Face à une forte demande, nous avons le plaisir d'annoncer que les clients GitLab Premium peuvent désormais acheter une licence GitLab Duo Enterprise, notre suite complète de solutions d'IA, sans avoir à passer à GitLab Ultimate. Ils bénéficient ainsi d'une expérience d'IA exceptionnelle, avec des fonctionnalités avancées parfaitement intégrées à chaque étape du développement logiciel :

• L'analyse des causes profondes pour diagnostiquer et résoudre rapidement les échecs de pipelines CI/CD et veiller à leur bon fonctionnement.

• La revue de code qui utilise GitLab Duo comme relecteur pour accélérer la révision des modifications proposées dans une merge request.

• Le chat avancé pour résumer les conversations. Il aide à comprendre les modifications apportées au code et fournit une assistance avancée pour la configuration.

• GitLab Duo Self-Hosted pour déployer GitLab Duo dans des environnements air-gapped et hors ligne en hébergeant des modèles d'IA approuvés.

Au-delà de la disponibilité de GitLab Duo Enterprise, nous renforçons en continu notre engagement auprès des clients GitLab Premium. Depuis le lancement de GitLab 17, nous avons déployé plus d'une centaine de nouvelles fonctionnalités et d'améliorations, dont voici quelques exemples notables :

• Le catalogue CI/CD permet aux équipes de développement de partager, découvrir et réutiliser
  des configurations et des composants CI/CD préexistants.
• Le registre des artefacts offre aux équipes de développement un accès sécurisé aux artefacts et une intégration homogène aux pipelines CI/CD.
• Le développement à distance permet aux équipes de développement de travailler dans des environnements de développement à la demande, hébergés dans le cloud.

Découvrez les fonctionnalités de GitLab Premium.

GitLab Duo : une IA qui s'adapte aux besoins des entreprises

GitLab propose une gamme complète de fonctionnalités GitLab Duo dans ses offres Pro et Enterprise, pour accompagner ses clients à chaque étape de leur cycle d'adoption de l'IA. Plus vos équipes progressent dans ce cycle, et plus vous pouvez utiliser de fonctionnalités pour créer, tester et déployer plus rapidement des logiciels sécurisés.

Comment les clients GitLab Ultimate et Premium peuvent-ils activer GitLab Duo ?

À partir de GitLab 18.0, pour les clients Ultimate et Premium existants, les fonctionnalités de suggestions de code et de chat de GitLab Duo sont désactivées par défaut, mais peuvent facilement être activées.

Vous trouverez la procédure à suivre ci-dessous :

1. Vérifiez avant tout que vous disposez de GitLab Premium ou Ultimate. Dans le cas contraire, vous pouvez démarrer un essai gratuit de 60 jours.

2. Activez GitLab Duo dans vos paramètres.

3. Si vous utilisez un IDE local, installez l'extension d'éditeur de code GitLab de votre choix.

4. Commencez à utiliser les suggestions de code et le chat dans l'IDE local de votre choix, s'il est pris en charge, ou dans le Web IDE de GitLab.

Remarque : les fonctionnalités d'IA de GitLab seront activées automatiquement pour les nouveaux clients et les versions d'essai.

Le développement IA native avec une plateforme DevSecOps

L'IA redéfinit l'expérience de développement. Les entreprises ne vont pas seulement recruter davantage de talents pour créer leurs logiciels. Elles vont également disposer de davantage de code généré par l'IA et prêt à être déployé en production, ce qui rend GitLab plus essentiel que jamais.

Nous avons conçu GitLab Premium et Ultimate avec GitLab Duo spécifiquement dans cet état d'esprit, afin d'offrir aux équipes une base sécurisée pour l'ensemble de leur code. À mesure que l'IA génère du code à l'échelle de votre entreprise, GitLab devient votre plateforme de contrôle, éliminant ainsi le recours à des outils distincts pour le scanning de sécurité, les contrôles de conformité ou la gestion des pipelines. Vous pouvez entièrement vous appuyer sur notre plateforme unique et unifiée, qui évolue avec votre entreprise. Elle vous garantit la qualité, la sécurité et la conformité de votre code jusqu’à sa mise en production.

Pour en savoir plus sur GitLab Duo et tous ses avantages pour votre équipe, consultez notre page GitLab Premium ou, si vous êtes un client GitLab, contactez votre représentant GitLab pour organiser une démonstration. Enfin, nous vous invitons à participer au lancement virtuel de GitLab 18 le 24 juin 2025, afin de découvrir l'avenir du développement logiciel basé sur l'IA native.

L'IA agentique désigne une forme avancée d'intelligence artificielle capable d'agir de manière autonome en s'appuyant sur des modèles de langage sophistiqués et le traitement du langage naturel.

Contrairement à l'IA générative traditionnelle, qui nécessite une intervention humaine constante, l'IA agentique comprend les instructions, prend des décisions éclairées et exécute plusieurs séquences d'action pour atteindre un objectif défini. Elle décompose les tâches complexes en étapes plus simples et adapte sa stratégie en temps réel grâce à sa capacité d'apprentissage adaptatif lorsqu'elle rencontre des obstacles.

Informations clés sur l'IA agentique

• Vers une nouvelle ère du développement logiciel grâce à l’IA agentique : découvrez comment l'IA agentique transforme le développement logiciel en remplaçant le codage isolé par des workflows intelligents qui améliorent la productivité et garantissent la sécurité.
• IA agentique : libérez le plein potentiel des développeurs à grande échelle : découvrez comment l'IA agentique révolutionne le développement logiciel en dépassant la simple complétion de code pour donner naissance à de véritables partenaires d'IA capables de gérer des tâches complexes de manière proactive.
• Tendances de l'IA en 2025 : IA agentique, modèles auto-hébergés et bien plus encore : découvrez les principales tendances du développement logiciel alimenté par l'IA, des déploiements de modèles sur site aux agents d'IA intelligents et adaptatifs.
• L'IA agentique au service des équipes d'ingénierie de plateforme : découvrez comment l'IA agentique révolutionne l'ingénierie de plateforme en automatisant les workflows complexes et en intensifiant les efforts de standardisation.

Bonnes pratiques pour intégrer l'IA agentique

• Agents d’IA : sécurisez leur autonomie avec des garde-fous efficaces : découvrez les garde-fous de sécurité indispensables à l'approche DevSecOps pour encadrer les agents d'IA, tels que les contrôles de conformité, la sécurisation de l'infrastructure et la gestion des accès utilisateurs.

Les offres de GitLab en matière d'IA agentique

GitLab Duo combiné à Amazon Q

• GitLab Duo combiné à Amazon Q : l'IA agentique optimisée pour AWS est désormais disponible à tous les utilisateurs : la plateforme DevSecOps complète alimentée par l'IA de GitLab, combinée aux fonctionnalités de cloud computing les plus avancées, accélère les cycles de développement, augmente l'automatisation et améliore la qualité du code.
• DevSecOps + IA agentique : maintenant disponibles avec GitLab Self-Managed Ultimate sur AWS : utilisez des agents d'IA optimisés pour l'approche DevSecOps dans votre instance GitLab Self-Managed Ultimate sur AWS et tirez pleinement parti des fonctionnalités de GitLab Duo combiné à Amazon Q au sein de votre entreprise.

Pour en savoir plus, consultez notre page GitLab et AWS et visionnez une démonstration de GitLab Duo combiné à Amazon Q :

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1075753390?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="Technical Demo: GitLab Duo with Amazon Q"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

Visite guidée

Cliquez sur l'image pour une visite guidée de GitLab Duo combiné à Amazon Q :

Tutoriel GitLab Duo combiné à Amazon Q

• GitLab Duo combiné à Amazon Q : créez de nouvelles fonctionnalités en quelques minutes : GitLab Duo combiné à Amazon Q analyse les descriptions de vos tickets et génère automatiquement des solutions de code complètes et opérationnelles, pour des workflows de développement plus rapides.

GitLab Duo Workflow

• GitLab Duo Workflow : l'avenir du développement logiciel basé sur une IA agentique sécurisée
• GitLab Duo Workflow : une IA agentique offrant visibilité et contrôle à l'échelle de l'entreprise : nos agents d'IA sécurisés et autonomes comprennent le contexte et prennent en charge les tâches complexes. Les équipes de développement sont ainsi en mesure de livrer des logiciels innovants plus rapidement. La liste d'attente pour l'accès à la version bêta privée de GitLab Duo Workflow est ouverte.
• Documentation GitLab Duo Workflow

Regardez cette présentation de GitLab Duo Workflow :

<!-- blank line -->

<figure class="video_container"> <iframe src="https://www.youtube.com/embed/eN2Sd5UNc0g?si=C9HibBJ3QDDHADq2" frameborder="0" allowfullscreen="true"> </iframe> </figure> <!-- blank line -->

Visite guidée

Cliquez sur l'image pour démarrer une visite de GitLab Duo Workflow :

Tutoriels et cas d'utilisation de GitLab Duo Workflow

• Refactorisation de JavaScript en TypeScript avec GitLab Duo Workflow
• Automatisation des tâches de codage fastidieuses avec GitLab Duo Workflow : découvrez comment l'IA agentique peut réduire le temps que vous consacrez aux tâches répétitives afin de vous aider à vous concentrer sur le développement et la livraison de solutions innovantes.
• GitLab Duo Workflow : améliorez l'assurance qualité de vos applications : découvrez étape par étape comment ajouter des tests unitaires à une application Java à l'aide de l'IA agentique.
• Résolution de défis complexes avec GitLab Duo Workflow : découvrez comment l'équipe Customer Success de GitLab utilise l'IA agentique pour résoudre des problèmes concrets comme les limites des charts Helm dans le registre de paquets.

Autres ressources sur l'IA

• Rapport Global DevSecOps 2024 : la maturité de l'IA dans l'approche DevSecOps
• Le rôle de l'IA dans l'approche DevOps
• Les articles récents de GitLab sur l'IA et le ML

Découvrez dans cet article tout ce que vous devez savoir sur les frameworks de conformité personnalisés de GitLab et comment les utiliser de façon optimale.

Qu’est-ce qu’un framework de conformité personnalisé ?

Les frameworks de conformité personnalisés de GitLab vous permettent de définir, d'appliquer et de faire respecter vos propres normes de conformité directement dans votre instance GitLab. GitLab propose déjà des fonctionnalités de conformité « prêtes à l’emploi », mais chaque entreprise a ses propres obligations. Avec les frameworks personnalisés, vous pouvez donc définir vos propres stratégies de conformité en fonction de réglementations spécifiques, de vos politiques internes ou des normes de votre secteur.

Ces frameworks offrent les principaux avantages suivants :

• Réduction significative du suivi manuel
• Accélération de la préparation aux audits
• Intégration native des contrôles de conformité

GitLab propose à ce jour plus de 50 contrôles préconfigurés, modifiables, que vous pouvez activer selon vos besoins. Ils couvrent un large éventail de réglementations, comme la loi HIPAA dans le domaine de la santé, le RGPD pour la protection des données, la norme SOC 2 relative aux prestataires de services et bien d'autres réglementations propres à des secteurs d'activité spécifiques. En voici quelques exemples :

• Séparation des tâches : au moins deux approbateurs requis, y compris l'auteur de la merge request
• Scanners de sécurité : scans SAST et analyse des dépendances exécutés automatiquement
• Authentification/autorisation : visibilité du projet définie sur privé et authentification unique (SSO) activée
• Configuration de l'application : vérification obligatoire des statuts de conformité et utilisation de fichiers de configuration Terraform exigée

En outre, vous pouvez étendre les capacités de conformité de GitLab en configurant vos propres contrôles sur des environnements externes à l'aide de l'API GitLab.

Comment créer un framework de conformité personnalisé dans GitLab ?

Maintenant que nous avons clarifié l’importance des frameworks de conformité personnalisés, voyons comment les mettre en œuvre dans votre environnement GitLab, en utilisant l'application de démonstration reprise dans la vidéo ci-dessous.

Remarque : un abonnement GitLab Ultimate est requis.

<!-- TODO: EMBED_YT_VIDEO -->

<!-- blank line -->

<figure class="video_container"> <iframe src="https://www.youtube.com/embed/bSwwv5XeMdQ?si=unDwCltF4vTHT4mB" title="Adhering to compliance requirements with built-in compliance controls " frameborder="0" allowfullscreen="true"> </iframe> </figure> <!-- blank line -->

Étape 1 : définissez vos exigences de conformité

Avant de créer votre framework de conformité personnalisé, vous devez définir clairement vos exigences en la matière :

1. Identifiez les réglementations applicables : déterminez les obligations légales et normes qui s'appliquent à votre entreprise (par exemple, le RGPD, la norme PCI DSS ou la loi HIPAA).
2. Associez les exigences à des contrôles : décomposez chaque exigence réglementaire identifiée en contrôles spécifiques et exploitables.
3. Hiérarchisez les exigences : concentrez vos efforts sur les domaines à haut risque et les exigences à fort impact.

Étape 2 : créez votre framework de conformité personnalisé dans GitLab

Voici comment procéder :

1. Accédez à la section Sécurisation > Centre de conformité de votre groupe GitLab.
2. Cliquez sur le bouton Nouveau framework.
3. Sélectionnez Créer un framework vide.

4. Renseignez son nom, sa description et choisissez sa couleur.

5. Ajoutez des exigences :
   a. Accédez à l'onglet Exigences.

   b. Cliquez sur le bouton Nouvelle exigence.

   c. Fournissez un nom et une description.
   d. Dans la section Contrôles, sélectionnez Choisir un contrôle GitLab.
   e. Sélectionnez un contrôle dans la liste (par exemple, au moins deux approbations, l'exécution de scans SAST).
   f. Cliquez ensuite sur le bouton Créer une exigence.

6. Cliquez sur le bouton Créer un framework.

Une fois créé, ce framework pourra être appliqué à vos projets selon les paramètres définis. Par ailleurs, GitLab permet également d'importer des frameworks de conformité au format JSON, selon le schéma prévu.

Étape 3 : appliquez le framework à vos projets

Une fois votre framework de conformité créé, suivez les étapes ci-dessous pour l’appliquer à un ou plusieurs projets :

1. Accédez au Centre de conformité de GitLab, puis sélectionnez l'onglet Projets.
2. Utilisez la barre de recherche pour Rechercher ou Filtrer les projets concernés.
3. Sélectionnez le ou les projets dans la liste.
4. Cliquez sur le bouton Choisir une action groupée.
5. Sélectionnez Appliquer les frameworks aux projets sélectionnés.
6. Cliquez sur le bouton Sélectionner des frameworks.
7. Sélectionnez le ou les frameworks de votre choix dans la liste.
8. Cliquez sur le bouton Appliquer.

Une fois cette opération effectuée, le framework sélectionné est associé aux projets choisis. Les exigences définies sont alors visibles et peuvent être vérifiées directement dans l'interface GitLab.

Étape 4 : surveillez et générez des rapports de conformité

Une fois votre framework de conformité en place, GitLab vous offre un suivi continu et centralisé dans le Centre de conformité :

1. Suivez le statut de conformité de vos projets, y compris les détails sur les contrôles appliqués, ainsi que des correctifs suggérés pour les contrôles ayant échoué.
2. Générez des rapports de conformité pour les audits et l'examen par les parties prenantes.
3. Configurez des alertes de conformité pour informer les parties prenantes des problèmes de conformité potentiels.
4. Consultez les événements d'audit pour une vue d'ensemble des mesures prises concernant les paramètres de conformité.

Exemple : mise en œuvre d'un framework de conformité SOC 2

Le SOC 2 (System and Organization Controls 2), développée par l'American Institute of Certified Public Accountants, est une norme d'audit rigoureuse qui évalue les contrôles mis en œuvre par les prestataires de services en matière de sécurité, de disponibilité, d'intégrité du traitement des données, de confidentialité et de protection des données personnelles. Pour en savoir plus, consultez le guide sur le respect des exigences de sécurité SOC 2 avec GitLab.

Voici un exemple concret d'implémentation d'un framework de conformité personnalisé GitLab dont l'objectif est de vérifier la conformité à la norme de sécurité SOC 2 à l’aide des contrôles GitLab préconfigurés suivants :

• Contrôles contre les accès non autorisés
• Procédures d'identification et d'atténuation des risques
• Systèmes de détection et de gestion des incidents de sécurité

Avertissement : il ne s'agit là que d'un exemple qui illustre certains des contrôles possibles pour vérifier l'adhésion à la norme SOC 2. Avant toute mise en production, validez votre configuration avec votre équipe sécurité ou conformité.

Ce framework se présentera comme suit :

• Nom : Exigences de sécurité SOC 2

• Description : Ajout des exigences de sécurité pour la conformité au framework SOC 2

• Exigences :

  • Contrôles contre les accès non autorisés

    • Authentification SSO activée
    • Portée des tokens pour les jobs CI/CD activée
    • Authentification multifacteur requise au niveau de l'entreprise

• Procédures d'identification et d'atténuation des risques

  • Au moins deux approbations requises avant tout merge
  • Merge request approuvée par l'auteur
  • Merge request approuvée par les validateurs
  • Branche par défaut protégée

• Systèmes de détection et de gestion des incidents de sécurité

  • Analyse des dépendances activée
  • SAST activé
  • DAST activé

Lorsqu'il est appliqué à vos projets, ce framework vous permet de surveiller toute erreur de conformité et d'identifier les corrections envisageables. Notez que vous pouvez associer plusieurs frameworks de conformité à vos projets, par exemple, pour couvrir les exigences d'intégrité des processus SOC 2.

Comment définir des stratégies de sécurité en accord avec les exigences de conformité ?

Bien que cet aspect ne soit pas obligatoire, il est fortement recommandé d'appliquer des stratégies de sécurité aux projets associés à un framework de conformité personnalisé. Cette approche garantit que les exigences de conformité critiques sont correctement appliquées de manière automatisée et cohérente dans les pipelines CI/CD. Par exemple, si votre framework de conformité personnalisé impose que des scans de sécurité soient exécutés sur chaque pipeline, une stratégie de sécurité peut en forcer l’exécution.

GitLab fournit différentes stratégies de sécurité pour répondre aux différents objectifs de sécurité et de conformité :

• Stratégie d'exécution des scans : impose l'exécution de scans de sécurité dans les pipelines ou selon un calendrier précis.
• Politique d'approbation des merge requests : définit des paramètres et règles d'approbation au niveau du projet en fonction des résultats des scans.
• Stratégie d'exécution de pipeline : force l'exécution de jobs CI/CD spécifiques dans les pipelines.
• Stratégie de gestion des vulnérabilités : corrige automatiquement les vulnérabilités afin qu’elles soient supprimées de la branche par défaut.

Si votre framework de conformité personnalisé exige l'exécution de scans SAST, voici comment créer une stratégie de sécurité pour en garantir l’exécution automatique :

1. Accédez à un projet qui dispose d'un framework de conformité personnalisé incluant les scans SAST.
2. Dans la barre latérale du projet, sélectionnez Sécurisation > Politiques.
3. Cliquez sur le bouton Nouvelle stratégie.
4. Dans la section Stratégie d'exécution des scans, cliquez sur le bouton Sélectionner une stratégie.
5. Renseignez le Nom et la Description.
6. Dans la section Actions, sélectionnez SAST comme type de scan à exécuter.

7. Dans la section Conditions, sélectionnez tous les pipelines, quelle que soit la branche.

8. Cliquez sur le bouton Configurer avec une merge request.
9. Une merge request est alors créée dans un projet distinct dédié aux stratégies de sécurité appliquées à ce projet.
10. Cliquez sur le bouton Fusionner.

Désormais, les scans SAST s'exécuteront automatiquement sur toutes les branches du projet afin de garantir le respect continu des exigences de conformité. Nous vous conseillons de parcourir les autres types de stratégies de sécurité pour identifier celles qui répondent le mieux à vos besoins.

5 bonnes pratiques pour des frameworks de conformité efficaces

Pour tirer pleinement parti des frameworks de conformité personnalisés de GitLab, nous vous conseillons de suivre les principes suivants :

1. Avancez pas à pas : commencez par une seule réglementation ou norme critique avant d'aller plus loin.
2. Impliquez les principales parties prenantes : incluez les équipes de conformité, de sécurité et de développement dans la création du framework.
3. Automatisez dans la mesure du possible : utilisez GitLab CI/CD pour automatiser les contrôles de conformité.
4. Documentez minutieusement votre approche : conservez une documentation claire du lien entre chaque exigence réglementaire et les contrôles GitLab mis en place.
5. Révisez régulièrement vos frameworks : mettez à jour vos frameworks à mesure que les réglementations évoluent ou que de nouvelles exigences sont nécessaires.

Lancez-vous dès aujourd'hui

Les frameworks de conformité personnalisés de GitLab marquent une avancée majeure pour intégrer la conformité directement dans le workflow de développement DevSecOps. En les adoptant, vous réduisez les frais liés à la conformité, améliorez votre gestion des risques et accélérez vos cycles de développement logiciel, tout en garantissant la meilleure conformité possible aux exigences réglementaires.

Grâce à cette approche, vos équipes bénéficient à la fois de la flexibilité dont elles ont besoin pour répondre aux exigences réglementaires et de la structure indispensable pour garantir des pratiques de conformité cohérentes dans l'ensemble de l'entreprise.

Dans un contexte réglementaire de plus en plus exigeant, des outils comme les frameworks de conformité personnalisés de GitLab sont essentiels pour traiter la conformité comme un processus continu, sans compromettre la vélocité de développement.

Lancez-vous dès aujourd'hui avec un essai gratuit de 60 jours de GitLab Ultimate.

Pour en savoir plus, consultez nos ressources connexes :

• Documentation sur les frameworks de conformité personnalisés
• Epic sur les frameworks de conformité personnalisés
• Documentation sur les stratégies de sécurité
• Solutions de sécurité et de conformité de GitLab

Et si les capacités de l'IA agentique pouvaient tout changer ? C'est exactement ce que propose GitLab Duo combiné à Amazon Q. En associant la plateforme DevSecOps complète alimentée par l'IA de GitLab aux fonctionnalités avancées de cloud computing d'AWS, cette intégration vous permet d'accélérer considérablement votre processus de développement d'applications, le tout au sein de votre workflow GitLab habituel. Le code que vos équipes de développement écrivent en plusieurs jours peut désormais être généré automatiquement en quelques minutes à partir des descriptions et exigences incluses dans vos tickets GitLab.

Transformer un ticket en code opérationnel

Découvrons comment cette fonctionnalité d'IA agentique fonctionne en pratique. Imaginez que vous deviez développer une application de calcul de prêt immobilier. Voici comment procéder à l'aide de GitLab Duo combiné à Amazon Q :

1. Créez votre ticket dans GitLab : créez un ticket classique, contenant la liste complète des exigences de votre application. Ce ticket sert de point de départ pour développer votre solution logicielle.

2. Activez Amazon Q : une fois votre ticket créé, ajoutez simplement un commentaire contenant la commande d'action rapide “/q dev” pour lancer Amazon Q et laisser la magie opérer.

3. Génération automatique du code : GitLab Duo combiné à Amazon Q analyse votre ticket et le contexte de votre code source, puis génère automatiquement un code répondant à toutes vos spécifications. Et cerise sur le gâteau : l'IA soumet également ce code dans une merge request, prête pour la revue.

4. Revue de l'application générée : consultez la merge request pour vérifier que le code correspond bien à vos attentes et apportez des ajustements si nécessaire.

5. Testez votre application : enfin, assurez-vous que l'application s'exécute correctement. Vous disposez désormais d'un code opérationnel conforme à vos exigences initiales, sans effort superflu.

Une nouvelle ère pour votre développement logiciel

GitLab Duo combiné à Amazon Q révolutionne le développement logiciel en automatisant intelligemment les tâches complexes, réduisant ainsi drastiquement le temps nécessaire pour produire du code opérationnel. En tirant parti de l'IA agentique, vous pouvez accélérer le déploiement de vos nouvelles fonctionnalités, ce qui permet à vos équipes de se concentrer sur des tâches plus stratégiques.

Avec GitLab Duo combiné à Amazon Q, dites adieu aux tâches manuelles et développez des logiciels plus rapidement, plus efficacement et plus facilement. Vous pouvez ainsi :

• Accélérer votre processus de développement en automatisant la création de code conformément aux exigences du projet.
• Maintenir une qualité constante lors de la génération de code, pour l'ensemble de vos projets.
• Réduire la charge mentale en limitant la traduction manuelle des exigences en code opérationnel.
• Accélérer vos cycles de sortie des nouvelles versions en supprimant les goulots d'étranglement, notamment ceux liés à l'implémentation.
• Optimiser l'expertise de votre équipe en la recentrant sur la revue de code et l'optimisation de ce dernier, plutôt que sur son écriture.

Vous souhaitez découvrir GitLab Duo combiné à Amazon Q ? Regardez notre vidéo de démonstration et découvrez dès aujourd'hui comment optimiser votre workflow de développement.

<!-- blank line --> <figure class="video_container"> <iframe src="https://www.youtube.com/embed/jxxzNst3jpo?si=j_LQdZhUnwqoQEst" title="GitLab Duo with Amazon Q demo video for dev workflow" frameborder="0" allowfullscreen="true"> </iframe> </figure> <!-- blank line -->

Pour en savoir plus sur GitLab Duo combiné à Amazon Q, consultez notre documentation ou contactez notre équipe.

Qu'est-ce que l'approche CI/CD ?

• L'intégration continue est une pratique de développement qui consiste à fusionner régulièrement les modifications apportées au code dans un dépôt partagé, de préférence plusieurs fois par jour, afin qu'elles soient vérifiées via un processus automatisé de compilation et de tests. Les équipes de développement peuvent ainsi détecter rapidement les problèmes et conflits éventuels.
• La livraison continue complète l'intégration continue en automatisant le pipeline pour la sortie de nouvelles versions. À tout moment, l'application reste déployable vers un environnement donné (par exemple, préproduction, production), en un seul clic ou par le biais d'un déclenchement automatique.
• Le déploiement continu pousse encore plus loin la logique d’automatisation. Chaque compilation réussie est directement mise en production, sans validation manuelle. Ce niveau d'automatisation requiert une confiance totale dans vos tests automatisés et vos processus de déploiement.

Pourquoi choisir GitLab CI/CD ?

Entièrement intégré à la plateforme GitLab, GitLab CI/CD est un système puissant, qui permet d'automatiser facilement chaque étape de votre cycle de développement logiciel. Avec GitLab CI/CD, vous pouvez notamment :

• Automatiser l'intégralité de votre cycle de développement : compilation, tests, déploiement, tout peut être orchestré via le pipeline CI/CD.
• Détecter les bogues en amont : les problèmes sont identifiés et corrigés bien avant d’atteindre l'environnement de production.
• Obtenir des retours immédiats : les équipes de développement obtiennent un retour rapide sur leurs modifications de code.
• Renforcer la collaboration : les workflows automatisés fluidifient le travail en équipe.
• Accélérer la livraison : les livraisons de nouvelles versions sont plus rapides et plus fréquentes.
• Réduire les risques : les erreurs de déploiement et les retours en arrière sont considérablement réduits.

Quels sont les principaux composants de GitLab CI/CD ?

• .gitlab-ci.yml : ce fichier YAML, situé dans le répertoire racine de votre projet, définit l'ensemble du pipeline CI/CD, y compris les étapes, les jobs et les runners.
• GitLab Runner: cet agent exécute les jobs CI/CD sur l'infrastructure de votre choix (par exemple, machines physiques, machines virtuelles, conteneurs Docker ou clusters Kubernetes).
• Étapes: elles définissent l'ordre d'exécution des jobs (par exemple, compilation, tests et déploiement).
• Jobs: chaque job représente une unité de travail spécifique exécutée lors de l'étape correspondante (par exemple, compiler du code, exécuter des tests ou déployer dans l'environnement de préproduction).

Comment configurer GitLab CI ?

GitLab CI est très facile à prendre en main. Voici un exemple basique de fichier .gitlab-ci.yml :

stages:
  - build
  - test
  - deploy

build_job:
  stage: build
  script:
    - echo "Building the application..."

test_job:
  stage: test
  script:
    - echo "Running tests..."

deploy_job:
  stage: deploy
  script:
    - echo "Deploying to production..."
  environment:
    name: production

Cette configuration définit trois étapes : « compilation », « test » et « déploiement ». Chaque étape contient un job qui exécute un script simple.

Exemples de configuration CI/CD

Explorons quelques exemples plus concrets.

Création, compilation et déploiement d'une application Node.js

Prenons l'exemple du pipeline ci-dessous qui compile et teste une application Node.js à l'aide de npm, puis la déploie sur Heroku via dpl. L'étape de déploiement du pipeline utilise des variables GitLab CI/CD, qui permettent de stocker des informations sensibles (par exemple, des identifiants de connexion) et de les utiliser en toute sécurité dans les processus CI/CD.

Dans cet exemple, une clé API pour déployer l'application sur Heroku est stockée sous le nom de variable $HEROKU_API_KEY, cette clé étant utilisée par l'outil dpl.

stages:
  - build
  - test
  - deploy

build:
  stage: build
  image: node:latest
  script:
    - npm install
    - npm run build

test:
  stage: test
  image: node:latest
  script:
    - npm run test

deploy:
  stage: deploy
  image: ruby:latest
  script:
    - gem install dpl
    - dpl --provider=heroku --app=$HEROKU_APP_NAME --api-key=$HEROKU_API_KEY

Déploiement vers différents environnements (préproduction et production)

GitLab propose également la gestion des environnements au sein du pipeline CI/CD pour suivre les déploiements vers des cibles d'infrastructure. Dans l'exemple ci-dessous, le pipeline ajoute des étapes avec une propriété « environnement » pour les environnements de préproduction et de production. Alors que l'étape deploy_staging exécute son script automatiquement, l'étape deploy_production nécessite une approbation manuelle afin d'éviter tout déploiement accidentel en production.

stages:
  - build
  - test
  - deploy_staging
  - deploy_production

build:
  # ...

test:
  # ...

deploy_staging:
  stage: deploy_staging
  script:
    - echo "Deploying to staging..."
  environment:
    name: staging

deploy_production:
  stage: deploy_production
  script:
    - echo "Deploying to production..."
  environment:
    name: production
  when: manual  # Requires manual approval

GitLab Auto DevOps

GitLab Auto DevOps simplifie encore plus l'approche CI/CD en fournissant une configuration prédéfinie pour compiler, tester et déployer automatiquement vos applications. Cette suite de fonctionnalités tire parti des bonnes pratiques et des normes du secteur pour rationaliser votre workflow.

Pour activer Auto DevOps :

1. Accédez à Paramètres > CI/CD > Pipelines généraux.
2. Activez l'option Auto DevOps.

Auto DevOps détecte automatiquement le langage et le framework de votre projet et configure les étapes de compilation, de tests et de déploiement nécessaires. Il est donc inutile de créer un fichier .gitlab-ci.yml.

Catalogue CI/CD

Le catalogue CI/CD est une liste de projets contenant des composants CI/CD publiés par la communauté, que vous pouvez utiliser pour optimiser votre workflow CI/CD. Vous pouvez y contribuer en ajoutant vos propres composants ou en enrichissant ceux déjà existants. Les composants publiés dans le catalogue CI/CD sont disponibles sur GitLab.com.

Tutoriel : Comment configurer votre premier composant GitLab CI/CD

Templates CI

Vous pouvez également créer vos propres templates CI afin de standardiser et de réutiliser les configurations de vos pipelines CI/CD entre plusieurs projets. Cette pratique favorise la cohérence et réduit les doublons.

Pour créer un template CI :

1. Créez un fichier .gitlab-ci.yml dans un projet ou un dépôt dédié.
2. Définissez la configuration CI/CD souhaitée dans ce template.
3. Dans le fichier .gitlab-ci.yml, utilisez le terme include pour inclure ce template.

Optimisez votre processus de développement

GitLab CI/CD transforme en profondeur votre workflow de développement de logiciels. En maîtrisant ses concepts, en configurant efficacement vos pipelines CI/CD et en tirant parti de fonctionnalités tels qu'Auto DevOps, le catalogue CI/CD et les templates CI, vous pouvez automatiser l'ensemble de votre cycle de développement logiciel et livrer des logiciels de haute qualité plus rapidement et plus efficacement.

Vous souhaitez approfondir vos connaissances ? Inscrivez-vous aux cours disponibles sur le portail GitLab University.

Essayez GitLab Ultimate gratuitement pendant 60 jours.

Articles de la série « Premiers pas avec GitLab »

Découvrez les autres articles de notre série « Premiers pas avec GitLab » :

• Comment gérer les utilisateurs
• Comment importer vos projets dans GitLab
• Comment maîtriser la gestion de projet
• La gemme gitlab-triage : votre alliée pour des workflows Agile automatisés

Fenêtres de déploiement GitLab 18.0

GitLab.com

Les changements cassants sur GitLab.com sont concentrés sur ces trois périodes clés :

• Du 21 au 23 avril 2025
• Du 28 au 30 avril 2025
• Du 5 au 7 mai 2025

De nombreux autres évolutions continuent d'être déployés au fil des mois. Pour en savoir plus sur les modifications les plus sensibles apportées prévues à ces dates, consultez notre documentation dédie aux changements cassants.

Remarque : exceptionnellement, certaines mises à jour importantes peuvent intervenir légèrement en dehors de ces périodes.

GitLab Self-Managed

GitLab 18.0 est disponible depuis le 15 mai. Consultez le calendrier complet des sorties de nouvelles versions sur cette page.

GitLab Dedicated

La mise à niveau vers GitLab 18.0 aura lieu pendant votre fenêtre de maintenance, entre le 24 et le 29 juin 2025. Pour en savoir plus et connaître votre fenêtre de maintenance, consultez cette page.

Nous mettons également à votre disposition des outils et ressources adaptés pour vous aider à mesurer l'impact de ces changements sur votre environnement et préparer votre passage à la version 18.0. N'hésitez pas à consulter toutes les informations sur ces outils, ressources et les mesures d'atténuation.

En outre, la page des obsolescences répertorie l'ensemble des suppressions prévues dans la version 18.0. Découvrez ci-dessous les nouveautés de cette année et comment vous y préparer selon la configuration de votre déploiement.

Changements cassants

Impact élevé

1. Token pour job CI/CD : suppression du paramètre « Limiter l'accès depuis votre projet »

GitLab.com | GiitLab Self-Managed | GitLab Dedicated

Dans GitLab 14.4, nous avions mis en place le paramètre Limiter l'accès à CI_JOB_TOKEN pour améliorer la sécurité en restreignant l'accès depuis les tokens de job CI/CD de votre projet (CI_JOB_TOKEN) Dans la version 16.3 de GitLab, ce paramètre a été renommé Limiter l'accès à partir de ce projet pour plus de clarté. Dans la version 15.9 de GitLab, nous avions introduit une solution alternative : le paramètre Groupes et projets autorisés. Celui-ci contrôle l'accès au token pour job CI/CD de votre projet à l'aide d'une liste d'autorisations et constitue une amélioration significative par rapport à l'original. La première itération a été rendue obsolète dans GitLab 16.0 et sa suppression est prévue dans GitLab 18.0.

Le paramètre Limiter l'accès à partir de ce projet est désactivé par défaut pour tous les nouveaux projets. Depuis GitLab 16.0, une fois ce paramètre désactivé dans un projet, il n’est plus possible de le réactiver, mais vous pouvez utiliser le paramètre Groupes et projets autorisés pour contrôler l'accès au token pour job de vos projets.

• Avis d'obsolescence
• Vérification GitLab Detective disponible

2. Token pour job CI/CD : application de la liste d'autorisation « Groupes et projets autorisés »

GitLab.com | GitLab Self-Managed | GitLab Dedicated

Introduit dans GitLab 15.9, le paramètre « Groupes et projets autorisés » (renommé Limiter l'accès à ce projet dans la version 16.3 de GitLab), vous permet de gérer l'accès au token pour job CI/CD de votre projet. Lorsque le paramètre est défini sur Uniquement ce projet et tous les groupes et projets de la liste d'autorisation, seuls les groupes ou projets explicitement ajoutés à cette liste peuvent accéder à votre projet par le biais d'un token de job.

• Avant GitLab 15.9, le token de job était accessible depuis n'importe quel projet, car la liste d'autorisation était désactivée par défaut et définie sur « Tous les groupes et projets », sans restriction d'accès.
• Depuis GitLab 17.6, les administrateurs des instances GitLab Self-Managed ou GitLab Dedicated peuvent désormais imposer des règles de sécurité plus strictes pour tous les projets et empêcher les chargés de maintenance des projets de sélectionner Tous les groupes et projets. Cette modification garantit un niveau de sécurité plus élevé entre les projets.
• Dans GitLab 18.0, ce paramètre sera activé par défaut. Sur GitLab.com, nous remplirons automatiquement les listes d'autorisations de vos projets en fonction des logs d'authentification de votre projet.
• Pour anticiper ce changement sur GitLab.com, les chargés de maintenance du projet qui utilisent le token de job pour l'authentification inter-projets doivent remplir les listes d'autorisations Groupes et projets autorisés, puis définir le paramètre sur Uniquement ce projet et tous les groupes et projets de la liste d'autorisation. Nous vous encourageons à utiliser les outils de migration disponibles pour automatiser la création de la liste d'autorisation en fonction des logs d'authentification du projet avant le passage à la version GitLab 18.0.
• Les utilisateurs de GitLab Self-Managed doivent remplir les listes d'autorisations avant d'effectuer la mise à niveau vers la version 18.0.
• Les utilisateurs de GitLab Dedicated doivent élaborer, en collaboration avec l'équipe chargée de leur compte GitLab, une approche adaptée à leur instance.

• Avis d'obsolescence
• Documentation
• Vérification GitLab Detective disponible

3. Renforcement de la portée des tokens pour le proxy de dépendances

GitLab.com | GitLab Self-Managed | GitLab Dedicated

Actuellement, le proxy de dépendances pour les conteneurs accepte les commandes docker login et docker pull en utilisant des tokens d'accès personnels, de projet ou de groupe, sans vérifier leurs portées.

À partir de GitLab 18.0, il exigera la présence des portées read_registry et write_registry pour valider toute authentification. Après cette modification, les tentatives d'authentification avec des tokens ne disposant pas de ces portées seront rejetées.

Avant de procéder à la mise à niveau, vous devez générer de nouveaux tokens avec les portées requises, puis mettre à jour les variables et scripts de vos workflows avec ces nouveaux jetons.

Vous avez également la possibilité d'utiliser Dependency Token Checker, un script développé par la communauté, qui vous permet de visualiser les tokens et de procéder à leur rotation automatique.

• Avis d'obsolescence

Impact modéré

1. Nouvelles limites de conservation des données relatives aux vulnérabilités sur GitLab.com

GitLab.com - Réservé aux clients Ultimate

À partir de GitLab 18.1, nous mettrons en place progressivement, sur une période de six mois, une nouvelle limite de conservation des données pour les clients de l'édition GitLab Ultimate sur GitLab.com, afin d'améliorer les performances et la fiabilité du système. Celle-ci aura une incidence sur la durée de conservation des données relatives aux vulnérabilité.

Les vulnérabilités datant de plus de 12 mois qui n'ont pas été mises à jour seront automatiquement déplacées vers des archives de stockage à froid qui  :

• restent accessibles et téléchargeables via l'interface utilisateur (UI) de GitLab
• sont conservées pendant 3 ans
• sont définitivement supprimées après 3 ans

• Avis d'obsolescence
• Documentation

2. Rejet des stratégies de pull d'image de conteneur qui ne figurent pas dans allowed_pull_policies

GitLab.com | GitLab Self-Managed | GitLab Dedicated

Toutes les stratégies de pull configurées doivent être présentes dans la configuration allowed_pull_policies spécifiée dans le fichier config.toml du runner. Si ce n'est pas le cas, le job devrait échouer avec une erreur de type**incompatible pull policy**.

Actuellement, les jobs ne sont pas rejetés tant qu'au moins une stratégie de pull figure dans allowed-pull-policies, même si d'autres sont exclues.

Dans GitLab 18.0, un job ne sera en échec que si aucune stratégie de pull définie ne figure dans allowed-pull-policies. Toutefois, maintenant, seules les stratégies autorisées dans allowed-pull-policies seront effectivement appliquées. Avec GitLab 18.0, cette distinction risque de provoquer l'échec de jobs qui s'exécutent actuellement avec succès.

• Avis d'obsolescence
• Documentation

3. Fin de la prise en charge de PostgreSQL 14 et 15

GitLab Self-Managed

GitLab suit une cadence de mise à niveau annuelle pour PostgreSQL.

La prise en charge de PostgreSQL 14 et 15 sera supprimée dans GitLab 18.0 et PostgreSQL 16 deviendra la version minimale requise.

PostgreSQL 14 et 15 seront pris en charge pendant l'ensemble du cycle de sortie de nouvelles versions de GitLab 17. PostgreSQL 16 sera également pris en charge pour les instances qui souhaitent effectuer une mise à niveau avant la sortie de GitLab 18.0.

Pour anticiper ce changement, les instances qui n'utilisent pas PostgreSQL Cluster (comme celles installées avec un paquet Omnibus sur une seule instance PostgreSQL), bénéficieront d'une mise à niveau automatique vers PostgreSQL 16 à partir de GitLab 17.11. Si vous utilisez PostgreSQL Cluster ou si vous désactivez cette mise à niveau automatique, vous devrez effectuer une mise à niveau manuelle vers PostgreSQL 16 pour passer à GitLab 18.0. Assurez-vous de disposer de suffisamment d'espace disque pour effectuer la mise à niveau.

• Avis d'obsolescence
• Documentation
• Instructions pour la migration

4. Obsolescence des templates CI/CD Terraform

GitLab Self-Managed

Les templates CI/CD Terraform sont déclarés obsolètes et sont supprimés dans GitLab 18.0. Les templates concernés sont les suivants  :

• Terraform.gitlab-ci.yml
• Terraform.latest.gitlab-ci.yml
• Terraform/Base.gitlab-ci.yml
• Terraform/Base.latest.gitlab-ci.yml

GitLab ne pourra pas mettre à jour le binaire terraform dans les images de job vers une version sous licence Business Source License (BSL).

Pour continuer à utiliser Terraform, clonez les templates et l'image Terraform, et maintenez-les à jour si nécessaire. GitLab fournit des instructions détaillées pour migrer vers une image personnalisée.

À la place, nous vous recommandons d'utiliser le nouveau composant CI/CD OpenTofu sur GitLab.com ou le nouveau template CI/CD OpenTofu sur GitLab Self-Managed. Les composants CI/CD ne sont pas encore disponibles sur GitLab Self-Managed. Toutefois, le ticket n° 415638 propose d'ajouter cette fonctionnalité. Si les composants CI/CD deviennent disponibles sur GitLab Self-Managed, le template CI/CD OpenTofu sera supprimé.

En savoir plus sur le nouveau composant CI/CD OpenTofu.

• Avis d'obsolescence

5. Mise à jour majeure du sous-chart Prometheus

GitLab Self-Managed

Avec GitLab 18.0 et le chart GitLab 9.0, le sous-chart Prometheus sera mis à jour de la version 15.3 à la version 27.3.

Avec cette mise à jour, Prometheus 3 sera livré par défaut.

Vous devrez effectuer certaines étapes manuelles pour effectuer la mise à niveau. Si Alertmanager, Node Exporter ou Pushgateway sont activés, vous devrez également mettre à jour vos valeurs Helm.

Veuillez vous référer au guide sur la migration pour plus d'informations.

• Avis d'obsolescence

Impact faible

1. Arrêt de la compilation des paquets SUSE Linux Enterprise Server 15 SP2

GitLab Self-Managed

Le version avec service et support à long terme (LTSS) pour SUSE Linux Enterprise Server (SLES) 15 SP2 a pris fin en décembre 2024.

Par conséquent, nous ne prendrons plus en charge la distribution de SLES SP2 pour les installations de paquets Linux. Veuillez effectuer une mise à niveau vers SLES 15 SP6 pour bénéficier d'une prise en charge continue.

• Avis d'obsolescence

2. Suppression du limiteur de débit Gitaly

GitLab Self-Managed

Auparavant, Gitaly prenait en charge la limitation de débit basée sur RPC. Nous rendons aujourd'hui cette fonctionnalité obsolète, car elle ne donne pas les résultats escomptés. Veuillez consulter le ticket relatif à l'obsolescence pour plus de détails.

Si vous avez procédé à la configuration du limiteur de débit (bientôt obsolète), aucune erreur ne sera renvoyée et celle-ci sera simplement ignorée.

À la place, vous devez utiliser le limiteur de simultanéité.

• Avis d'obsolescence

3. Obsolescence de la prise en charge de l'image du contrôleur NGINX 1.3.1

GitLab Self-Managed

Nous passons à la version 1.11.2 du contrôleur NGINX par défaut, laquelle impose de nouvelles règles de contrôle d'accès basé sur les rôles (RBAC). Les utilisateurs qui utilisent nginx-ingress.rbac.create: false pour gérer leurs propres règles RBAC

devront les mettre à jour avant de migrer vers la version 1.11.2 ou une version ultérieure. Un mécanisme alternatif permet désormais de déployer la version 1.3.1 uniquement si la valeur Helm est définie comme indiqué ci-dessus. Par ailleurs, nous avons ajouté la valeur nginx-ingress.controller.image.disableFallback, qui est définie par défaut sur « false ». Si vous gérez vos propres règles RBAC, vous pouvez définir cette valeur sur « true » une fois les nouvelles règles en place, afin de permettre le déploiement de la version 1.11.2.

La version 17.5 marquera la fin de la prise en charge de l'image 1.3.1 et du mécanisme alternatif, afin de généraliser l'utilisation de la version 1.11.2, plus sécurisée.

Avis d'obsolescence

4. Mise à jour de la version majeure des analyseurs de tests de sécurité des applications

GitLab.com | GitLab Self-Managed | GitLab Dedicated

Avec GitLab 18.0, les analyseurs utilisés pour les tests de sécurité des applications passeront à de nouvelles versions majeures.

Si vous n'utilisez pas les templates inclus par défaut ou si vous avez épinglé vos versions d'analyseur, pensez à mettre à jour votre job CI/CD en retirant la version épinglée ou en passant à la dernière version majeure.

Jusqu'à GitLab 18.0, les analyseurs seront toujours mis à jour sur les versions 17.0 à 17.11. Ensuite, seuls les analyseurs de la nouvelle version majeure bénéficieront des correctifs et des nouvelles fonctionnalités.

Conformément à notre politique de maintenance, nous ne rétroportons pas les bogues ni les nouvelles fonctionnalités vers les versions obsolètes. Seuls les correctifs de sécurité peuvent être appliqués aux trois dernières versions mineures.

• Avis d'obsolescence

5. API Discovery utilisera les pipelines de branche par défaut

GitLab.com | GitLab Self-Managed | GitLab Dedicated

Dans GitLab 18.0, nous mettrons à jour le comportement par défaut du template CI/CD pour API Discovery (API-Discovery.gitlab-ci.yml).

Jusqu'à GitLab 18.0, il configurait par défaut les jobs pour qu'ils s'exécutent dans des pipelines de merge requests (MR) dès l'ouverture d'une MR.

Dès GitLab 18.0, ce template adoptera le même comportement que les éditions stables de templates des autres scanners d'arbre de syntaxe abstraite (AST) :

• Par défaut, le template exécutera des jobs de scan dans les pipelines de branche.
• Vous pourrez définir la variable CI/CD AST_ENABLE_MR_PIPELINES: true pour utiliser les pipelines MR lors de l'ouverture d'une MR. Le suivi de la mise en œuvre de cette variable est disponible via le ticket n° 410880.

• Avis d'obsolescence

6. Réduction par défaut de la valeur du DAST DAST_DEVTOOLS_API_TIMEOUT

GitLab.com | GitLab Self-Managed | GitLab Dedicated

La variable d'environnement DAST_DEVTOOLS_API_TIMEOUT détermine la durée pendant laquelle un test dynamique de sécurité des applications (DAST) attend une réponse du navigateur. Avant GitLab 18.0, la variable avait une valeur statique de 45 secondes. Dès GitLab 18.0, la variable d'environnement DAST_DEVTOOLS_API_TIMEOUT aura une valeur dynamique, calculée en fonction d'autres configurations de délai d'attente dépassé.

Dans la plupart des cas, la valeur de 45 secondes était supérieure à la valeur du délai d'attente dépassé de nombreuses fonctions du scanner. Le passage à un calcul dynamique permet d'adapter la variable DAST_DEVTOOLS_API_TIMEOUT à un plus grand nombre de situations.

• Avis d'obsolescence

Outils et ressources pour gérer l'impact sur votre environnement

Nous avons développé des outils spécifiques pour aider nos clients à comprendre l'impact de ces changements planifiés sur leur(s) instance(s) GitLab. Après avoir évalué l'impact sur votre projet, consultez les mesures d'atténuation décrites dans la documentation pour assurer une transition fluide vers GitLab 18.0.

• Obsolescence de la recherche avancée : cet outil s'appuie sur l'API de recherche avancée de GitLab pour repérer les chaînes liées aux obsolescences dans vos groupes et projets, et signale aussi les fichiers nécessitant une vérification manuelle. Remarque : peut comporter des faux positifs.
• Assistant de détection de prise en charge de la compilation pour l'analyse des dépendances : cet outil détecte les projets concernés par trois obsolescences liées à l'analyse des dépendances (1, 2, 3 ; toutes reportées à la version 19.0) et s'appuie sur l'API pour analyser les fichiers et les nom de jobs CI.
• GitLab Detective (GitLab Auto-géré uniquement) : cet outil expérimental analyse automatiquement votre installation GitLab pour détecter les problèmes connus, en s'appuyant sur des vérifications poussées des fichiers de configuration et valeurs issues de la base de données. Remarque : l’outil doit s'exécuter directement sur vos nœuds GitLab.

Pour vous accompagner dans cette transition, nous avons lancé sur GitLab University des micro-cours pratiques (de 15 minutes maximum) dédiés à la préparation et à la mise en œuvre des actions d'atténuation nécessaires. Commencez votre parcours d'apprentissage ici.

Si vous disposez d'un forfait payant et que vous avez des questions ou besoin d'aide concernant ces changements, veuillez créer un ticket d'assistance sur le portail d'assistance GitLab.

Si vous utilisez la version gratuite de Gitlab.com, vous pouvez obtenir de l'aide via les ressources communautaires : documentation GitLab, forum de la communauté GitLab et Stack Overflow.

Les agents d'Amazon Q étant directement intégrés à la plateforme DevSecOps de GitLab, les développeurs peuvent continuer à utiliser leur environnement de développement habituel tout en bénéficiant de puissantes fonctionnalités d'IA. Le résultat ? Une expérience fluide qui permet d'accélérer les cycles de développement, de réduire les tâches manuelles et d'améliorer la qualité du code.

« Le programme d'accès anticipé de GitLab Duo combiné à Amazon Q nous a permis de découvrir tout le potentiel de transformation de cette solution pour nos workflows de développement », explique Osmar Alonso, ingénieur DevOps chez Volkswagen Digital Solutions. « Même lors de la phase d'amorçage, nous avons vu comment une intégration plus avancée d'agents autonomes pouvait rationaliser notre processus, de la validation du code à la production. Nous avons hâte de découvrir comment cette technologie va nous permettre de nous concentrer sur l'innovation et d'accélérer notre transformation digitale. »

L'IA agentique s'invite dans les environnements clients complexes

En combinant l'IA agentique avec une infrastructure cloud sécurisée et fiable, GitLab et AWS apportent une sécurité, une évolutivité et une fiabilité intégrées aux environnements clients complexes, ce qui se traduit par de nombreux avantages :

Une expérience de développement unifiée pour un développement rationalisé

Les développeurs peuvent interagir avec Amazon Q via l'interface GitLab Duo Chat à partir de leur environnement de développement intégré (IDE) préféré ou de l'interface Web GitLab. Les utilisateurs n'ont ainsi pas besoin de changer de contexte pour utiliser d'autres outils et peuvent rester concentrés sur le projet en cours.

Une solution unique pour l'ensemble du cycle de développement logiciel

Les suggestions et optimisations de code exploitent les modèles et pratiques spécifiques à AWS, tandis que les outils de test comprennent les interactions et les dépendances des services AWS. Un magasin de données commun à toutes les étapes fournit un contexte essentiel aux agents d'IA, permettant une visibilité et une traçabilité complètes pour les actions pertinentes.

Un développement sécurisé avec des garde-fous à l'échelle de l'entreprise

La sécurité et la conformité tout au long du cycle de développement logiciel sont intégrées directement dans la plateforme de développement avec des garde-fous qui aident à réduire les risques sans entraver la vélocité du développement. Cette approche sécurisée du développement logiciel garantit la transparence et l'auditabilité grâce aux agents d'IA, tout en s'intégrant de façon homogène aux services liés à la sécurité et aux frameworks de conformité d'AWS.

Comment utiliser GitLab Duo combiné à Amazon Q ?

Voici cinq cas d'utilisation initiaux que nous ciblons pour aider les équipes à créer plus rapidement des logiciels sécurisés avec une IA agentique :

1. Accélération du développement des fonctionnalités : créez des descriptions dans les tickets, générez des plans de mise en œuvre en fonction de votre code base existant et produisez des merge requests complètes prêtes pour la vérification. Vous accélérez ainsi la livraison des fonctionnalités tout en appliquant vos normes de développement internes.
2. Modernisation des applications existantes : analysez votre code base Java existant, créez un plan de mise à niveau complet et générez des merge requests contenant toutes les modifications de code nécessaires. Cela permet de réduire le temps de mise à niveau de Java, tout en maintenant une piste d'audit claire de toutes les transformations de code. La prise en charge de .NET et d'autres langages est prévue pour les prochaines versions.
3. Amélioration de l'assurance qualité : analysez le code et créez automatiquement des tests unitaires complets qui comprennent la logique de votre application et les interactions avec les services AWS. Vous pouvez ainsi augmenter la couverture des tests, réduire les tâches manuelles de rédaction des tests et contribuer à assurer une qualité de test constante pour toutes les applications.
4. Optimisation de la revue de code : insérez des commentaires inline sur les modifications de code, suggérez des améliorations basées sur les normes de développement, mettez en évidence les considérations de sécurité et de performances. Vous pouvez ainsi réduire les cycles de revue de code et fournir des merges de code de meilleure qualité pour le déploiement.
5. Correction des vulnérabilités : expliquez les vulnérabilités détectées de façon claire et détaillée, puis corrigez-les en un seul clic en fonction des modifications de code recommandées, ce qui contribue à réduire considérablement le délai entre la détection des failles et leur correction.

Découvrez GitLab Duo combiné à Amazon Q en action :

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1075753390?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="Technical Demo: GitLab Duo with Amazon Q"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

Profitez dès aujourd'hui des avantages de GitLab Duo combiné à Amazon Q

La combinaison de la plateforme DevSecOps unifiée de GitLab alimentée par l'IA et des fonctionnalités d'IA avancées d'Amazon Q offre aux clients AWS une solution qui transforme la façon dont les équipes créent et déploient les logiciels. Pour en savoir plus sur GitLab Duo combiné à Amazon Q, n'hésitez pas à nous retrouver à l'occasion d'un AWS Global Summit dans votre région ou à contacter votre représentant GitLab.

Découvrez dans cet article les principes fondamentaux du développement open source.

Qu’est-ce que l’open source ?

L'open source est un modèle de développement fondé sur la transparence et la collaboration. Contrairement aux logiciels propriétaires, où seul le détenteur des droits peut modifier le code source ou redistribuer le produit, l'open source rend ce code accessible à tous. Les développeurs du monde entier peuvent ainsi l'examiner, l'améliorer et le partager librement, favorisant l'innovation et le progrès collectif.

Essayez GitLab Ultimate gratuitement pendant 60 jours et commencez à développer des logiciels open source dès aujourd'hui.

Quels sont les avantages de l'open source ?

Bien plus qu'une alternative technologique, l'open source est un modèle offrant de nombreux avantages. Réduction des coûts, accélération de l'innovation, meilleure sécurité des logiciels, ou encore personnalisation, sont autant d'atouts qui peuvent transformer les projets et stimuler la croissance des entreprises.

Des coûts réduits

À l'opposé des solutions propriétaires parfois onéreuses, les logiciels open source se distinguent souvent par leur faible coût, vous dispensant des dépenses traditionnellement associées aux licences et au support technique. Chez GitLab par exemple, les utilisateurs ont la possibilité d’utiliser gratuitement GitLab Community Edition (CE) qui est open source.

Une meilleure transparence

L'accès au code source permet à qui le souhaite d'examiner, de modifier et d'améliorer les logiciels. Pour les développeurs, cette transparence facilite leur compréhension des logiciels, de la manière dont ils sont construits et des failles de sécurité potentielles qu'ils peuvent contenir. Par exemple, le code source de GitLab est disponible publiquement sur GitLab.com et offre aux utilisateurs l'opportunité d’inspecter le code, de comprendre son fonctionnement et même de contribuer activement à son développement.

Des logiciels personnalisables

L'open source offre aux entreprises la possibilité d'adapter leurs logiciels à leurs besoins spécifiques, là où les solutions propriétaires limitent souvent cette liberté. Grâce à leur nature modulable, les logiciels open source permettent d'optimiser l'efficacité opérationnelle en s'adaptant précisément aux besoins des entreprises. GitLab illustre cette flexibilité en offrant à tous la possibilité de contribuer de façon traditionnelle, et en offrant également aux entreprises la possibilité de développer des intégrations et des fonctionnalités sur mesure grâce à son programme Co-Create.

Une communauté engagée

Les projets open source reposent sur l'engagement d'une communauté qui partage ses connaissances pour résoudre des problèmes ou proposer des améliorations sur les logiciels. GitLab tire pleinement parti de cet écosystème en s'appuyant sur une base d'utilisateurs et de développeurs qui enrichissent activement son développement et partagent leur expertise. GitLab collabore également avec d'autres entreprises sur des projets open source comme Git, renforçant son engagement pour l'innovation collective et la création de solutions évolutives.

Un accélérateur d’innovations

En réunissant des talents du monde entier autour de projets communs, l'open source devient un puissant moteur d'innovation. Cette synergie stimule l'amélioration continue et l'enrichissement des logiciels grâce à la diversité des compétences partagées. Ce modèle accélère ainsi le développement technologique en rendant les outils open source accessibles à un large public. GitLab, avec son cycle de release mensuel, intègre régulièrement de nouvelles fonctionnalités et améliorations fondées sur les retours et contributions de sa communauté d'utilisateurs.

Des logiciels évolutifs

Les logiciels open source reposent souvent sur des normes ouvertes qui simplifient leur intégration avec d'autres systèmes. Conçus pour s'adapter à divers environnements, ils offrent aux entreprises la possibilité de créer des solutions sur mesure, performantes et évolutives.

Une sécurité logicielle renforcée

La sécurité et la fiabilité sont des piliers essentiels des logiciels open source. Grâce à l'examen continu du code par une large communauté de développeurs, les failles de sécurité sont rapidement identifiées et corrigées. Bien que cette approche ne garantisse pas une sécurité absolue, elle favorise grandement la réactivité des équipes de développement face aux vulnérabilités de toutes sortes. GitLab applique ce principe en s'appuyant sur sa communauté pour renforcer la sécurité de sa plateforme.

Un savoir-faire enrichi

Les logiciels open source représentent une mine d'opportunités d'apprentissage pour les développeurs. En s'impliquant dans ces projets, ils peuvent perfectionner leurs compétences et gagner en expérience auprès d'autres professionnels du domaine, enrichissant leur savoir-faire et accélérant leur développement professionnel.

Par exemple, les développeurs peuvent étudier la base de code de GitLab pour apprendre les meilleures pratiques en matière de développement de plateformes DevSecOps. Les membres de l'équipe GitLab participent par ailleurs à des programmes de mentorat comme Google Summer of Code et Outreachy qui permettent d'apprendre aux nouveaux participants comment contribuer à GitLab ou autres logiciels open source comme Git.

Des logiciels plus qualitatifs

De nombreux projets open source bénéficient de la contribution de développeurs talentueux. Grâce à leur expertise, le code des logiciels open source est constamment examiné, amélioré et renforcé, ce qui permet de développer des solutions robustes et performantes.

Quels sont les défis liés à l’open source

Explorer l'univers des logiciels open source peut être aussi stimulant qu'exigeant. De la création de relations solides avec une communauté au renforcement de la sécurité des projets, chaque étape comporte ses propres défis. Pour réussir, il est essentiel de comprendre ces obstacles et de mettre en place des stratégies adaptées.

Construire une relation solide avec sa communauté

Le succès du développement open source repose sur la capacité à établir et à maintenir une relation solide avec une communauté de développeurs et d'utilisateurs. Cela nécessite des échanges continus afin de comprendre et de répondre à ses attentes. Puisque la majorité des contributeurs sont bénévoles, il est essentiel de coordonner leurs efforts de manière agile et structurée.

Pour maintenir leur motivation sur le long terme, notamment pour les contributeurs œuvrant sans contrepartie financière, il est crucial de reconnaître et de valoriser leur travail. Cela peut passer par des mentions officielles (crédits), des opportunités de formation ou d'autres formes de reconnaissances professionnelles. Sans cette valorisation, les contributeurs risquent de se détourner des projets, voire de créer des initiatives parallèles. Bâtir une communauté engagée et durable est donc au cœur du succès de tout projet open source.

Trouver un équilibre entre les intérêts de la communauté et celle des entreprises

Trouver un équilibre entre les intérêts des entreprises et ceux de la communauté est un défi central dans le développement open source. Les entreprises impliquées dans ces projets ont généralement des objectifs prioritaires. Ces priorités, souvent commerciales, peuvent entrer en conflit avec les attentes plus larges de la communauté, dont les intérêts sont plutôt axés sur l'innovation libre ou la personnalisation des logiciels.

Lorsque les décisions semblent trop axées sur les intérêts de l'entreprise, la communauté risque de se sentir exclue, ce qui peut réduire son engagement et limiter ses contributions. Pour éviter ce désengagement, les entreprises doivent partager clairement leurs objectifs et échanger régulièrement avec leur communauté pour garantir la pérennité et le succès à long terme des projets open source.

Maintenir la sécurité des logiciels

Les logiciels open source sont exposés à certains défis en matière de sécurité. La transparence du code, bien qu'étant l'un de leurs plus grands atouts, peut aussi les exposer à des attaques ciblées, ce qui peut devenir un risque majeur si l'entreprise à l’origine du projet open source ne corrige pas rapidement les failles identifiées.

Les utilisateurs comptent ainsi sur la réactivité de l'entreprise pour garantir la sécurité de leurs systèmes et de leurs données.

GitLab : un partenaire incontournable pour les projets open source

Les projets open source sont un moteur d'innovation technologique, et choisir la bonne plateforme pour les héberger est essentiel. Grâce à son système de gestion de versions basé sur Git, GitLab permet aux équipes de développement de collaborer efficacement, de suivre les modifications de code et de conserver un historique complet de leurs projets.

Une suite complète de fonctionnalités collaboratives

GitLab met à disposition de ses utilisateurs une suite complète de fonctionnalités adaptées au développement et à la gestion de projets open source. Parmi ces fonctionnalités figurent le suivi des tickets, les merge requests, la revue de code, les wikis et les GitLab Pages. Ces fonctionnalités permettent aux équipes de suivre l'évolution des projets, de collaborer, de proposer des améliorations, de corriger des bogues et de documenter leurs progrès en temps réel.

Des pratiques CI/CD au service des projets open source

Les fonctionnalités CI/CD de GitLab sont un atout majeur pour les projets open source. Elles automatisent des étapes clés du développement logiciel, comme les tests, la validation du code et le déploiement de nouvelles versions, assurant ainsi une meilleure fiabilité des logiciels open source et un développement accéléré. Chaque contribution est automatiquement testée dans un environnement dédié, ce qui permet de détecter rapidement les erreurs et de corriger les bogues. Cela réduit les risques de défaillances tout en assurant la stabilité des projets.

Un cycle de développement logiciel sécurisé

GitLab propose une suite complète de fonctionnalités conçues pour aider les développeurs de projets open source à sécuriser leurs logiciels. Parmi ces fonctionnalités, nous retrouvons :

• Le test statique de sécurité des applications (SAST) qui examine le code source à la recherche de failles de sécurité en amont de la mise en service des logiciels.
• Le test dynamique de sécurité des applications (DAST)* qui teste les applications en cours d'exécution au sein d’un environnement déployé pour détecter d'éventuelles vulnérabilités encore non repérées.
• L'analyse des dépendances* qui envoie des alertes sur les bibliothèques obsolètes ou vulnérables. Des rapports détaillés sont générés à chaque étape du développement, offrant une visibilité claire sur l'état de la sécurité du projet. Grâce à cela, les développeurs peuvent rapidement éviter ou corriger les composants à risque.

** Fonctionnalité disponible uniquement pour les utilisateurs de GitLab Ultimate.*

En intégrant ces fonctionnalités directement dans le pipeline CI/CD, GitLab réduit le risque d'erreurs humaines et accélère l’identification et la correction des vulnérabilités. Cette approche permet ainsi aux développeurs de projets open source de maintenir un niveau élevé de sécurité tout au long du cycle du développement logiciel.

Une gestion de projet Agile

GitLab met à disposition des équipes de développement un certain nombre de fonctionnalités pour faciliter la gestion des projets open source comme les tableaux de tickets, les listes des jalons ou encore le suivi du temps. Ces dernières permettent de voir facilement les tâches à réaliser, de suivre l'avancement des projets en fixant des échéances claires, mais aussi d’évaluer la charge de travail en vue d'optimiser l'utilisation des ressources. En combinant ces fonctionnalités, GitLab permet aux équipes de mieux coordonner leurs efforts, de maintenir un processus de travail fluide et de progresser efficacement dans la réalisation de leurs projets open source.

Des contributions simplifiées

Les équipes de développement peuvent facilement contribuer au développement de projets open source en les dupliquant (fork) et en créant des merge requests. Elles peuvent créer leurs propres copies du code, travailler sur des améliorations ou des correctifs dans des branches distinctes, puis soumettre leurs changements via des merge requests. Ce processus permet aux équipes de réviser et de valider chaque modification avant son intégration dans la branche principale, favorisant ainsi une amélioration continue des logiciels, tout en renforçant la qualité et la stabilité du code.

Une intégration facilité avec d’autres outils

GitLab facilite considérablement son intégration avec d’autres outils et workflows , permettant aux équipes de développement de créer un environnement personnalisé en fonction des exigences spécifiques de leur projet. Pour en savoir plus, consultez notre documentation.

Développez des logiciels open source avec GitLab

L’open source continue de s'imposer dans le monde du développement logiciel. Avec des plateformes DevSecOps comme GitLab, les équipes de développement disposent de tous les outils et ressources nécessaires au bon développement de leurs logiciels open source.

En plus d’aider les entreprises à développer des logiciels performants et sécurisés, GitLab fait évoluer continuellement sa plateforme grâce aux contributions et aux retours de ses utilisateurs. En écoutant sa communauté en permanence, GitLab s'adapte aux transformations du développement logiciel, renforçant ainsi sa présence au sein de l'écosystème open source.

Essayez GitLab Ultimate gratuitement pendant 60 jours et commencez à développer des logiciels open source dès aujourd'hui.

Remontez le temps avec nous pour retracer les grandes étapes de son évolution.

Le premier commit

Le premier commit a été effectué le 7 avril 2005 par Linus Torvalds, le créateur du noyau Linux : e83c5163316 (Initial revision of "git", the information manager from hell, 2005-04-07).

Comme vous pouvez le constater, ce commit ne contient pas beaucoup de fichiers :

$ git ls-tree e83c5163316
100644 blob a6bba79ba1f46a1bbf7773449c3bd2bb9bf48e8b	Makefile
100644 blob 27577f76849c09d3405397244eb3d8ae1d11b0f3	README
100644 blob 98a32a9ad39883c6d05a000a68511d4b1ee2b3c7	cache.h
100644 blob 74a0a234dd346fff51c773aa57d82fc4b83a8557	cat-file.c
100644 blob 840307af0cfaab31555795ce7175d5e9c9f981a0	commit-tree.c
100644 blob 25dc13fe101b219f74007f3194b787dd99e863da	init-db.c
100644 blob c924a6e0fc4c36bad6f23cb87ee59518c771f936	read-cache.c
100644 blob 1b47742d8cbc0d98903777758b7b519980e7499e	read-tree.c
100644 blob b8522886a15db861508fb6d03d4d88d6de912a4b	show-diff.c
100644 blob 5085a5cb53ee52e1886ff6d46c609bdb2fc6d6cd	update-cache.c
100644 blob 921f981353229db0c56103a52609d35aff16f41b	write-tree.c

Outre l'infrastructure de compilation, le premier commit fournit sept commandes principales :

• init-db pour initialiser un nouveau dépôt Git
• update-cache pour ajouter des fichiers à l'index
• write-tree pour créer un nouvel arbre à partir des éléments de l'index
• read-tree pour lire un objet arbre
• commit-tree pour créer un commit à partir d'un arbre
• cat-file pour lire un objet spécifique dans un fichier temporaire

Notez que la commande git n'existait pas encore à ce moment-là. Il fallait dès lors les exécuter directement.

Pour vous montrer un exemple concret, créons un nouveau dépôt :

$ mkdir repo
$ cd repo
$ init-db
defaulting to private storage area
$ ls -a
.  ..  .dircache

Cela peut surprendre : il n'y a pas de répertoire .git, mais un répertoire .dircache. Ce dernier représentait une zone de stockage privée.

Git distinguait alors deux types d'espaces de stockage des objets : un espace « privé » et un espace « partagé ». Ceux-ci regroupaient tous vos objets Git : vos commits et vos blobs, par exemple.

Par défaut, init-db créait un espace de stockage des objets privé qui n'était utilisé que pour le répertoire géré dans lequel il avait été créé. L'espace de stockage des objets « partagé », quant à lui, permettait de centraliser les objets communs à plusieurs répertoires, ce qui évitait d'avoir à les stocker deux fois.

Créer un commit

Nous disposons maintenant d'un dépôt, mais comment procéder pour créer un commit ? Autant vous dire que ce n'est pas aussi simple qu'avec la commande actuelle git add . && git commit. À l'époque, vous deviez :

1. Mettre à jour l'index en appelant update-cache pour chaque fichier que vous souhaitiez ajouter.
2. Écrire un nouvel arbre en appelant write-tree pour prendre le contenu que vous aviez ajouté à l'index.
3. Configurer les variables d'environnement pour indiquer à Git que vous en étiez l'auteur.
4. Créer un objet de commit en appelant commit-tree.

Créons un commit dans le dépôt pour illustrer ce processus :

$ echo content-1 >file-a
$ update-cache file-a
$ echo content-2 >file-b
$ update-cache file-b
$ write-tree
3f143dfb48f2d84936626e2e5402e1f10c2050fb
$ export COMMITTER_NAME="Patrick Steinhardt"
$ export COMMITER_EMAIL=ps@pks.im
$ echo "commit message" | commit-tree 3f143dfb48f2d84936626e2e5402e1f10c2050fb
Committing initial tree 3f143dfb48f2d84936626e2e5402e1f10c2050fb
5f8e928066c03cebe5fd0a0cc1b93d058155b969

Certes, ce processus n'est pas très pratique, mais il fonctionne ! Découvrons maintenant le commit généré :

$ cat-file 5f8e928066c03cebe5fd0a0cc1b93d058155b969
temp_git_file_rlTXtE: commit
$ cat temp_git_file_rlTXtE
tree 3f143dfb48f2d84936626e2e5402e1f10c2050fb
author Patrick Steinhardt <ps@pks.im> Wed Mar 26 13:10:16 2025
committer Patrick Steinhardt <ps@pks.im> Wed Mar 26 13:10:16 2025

commit message

Notez que cat-file n'a pas affiché le contenu directement, mais l'a d'abord écrit dans un fichier temporaire. Toutefois, le contenu du fichier ressemblait déjà en tous points à celui des commits actuels.

Apporter des modifications

Maintenant que nous avons des fichiers, comment pouvons-nous obtenir leur statut ? Vous l'aviez peut-être deviné, en utilisant show-diff :

$ show-diff
file-a: ok
file-b: ok

$ echo modified-content >file-a
$ show-diff
--- -	2025-03-26 13:14:53.457611094 +0100
+++ file-a	2025-03-26 13:14:52.230085756 +0100
@@ -1 +1 @@
-content-1
+modified-content
file-a:  46d8be14cdec97aac6a769fdbce4db340e888bf8
file-b: ok

Étonnamment, la commande show-diff permettait déjà de générer des diffs entre l'ancien et le nouvel état des fichiers modifiés ! Et pour l'anecdote, Git accomplissait cette tâche en exécutant simplement l'outil Unix diff(1).

En somme, tout était encore rudimentaire, mais suffisant pour assurer le suivi de l'historique. À ce stade, Git était encore très limité :

• Il était impossible de passer facilement d'un commit à un autre.
• Il était impossible d'afficher les logs.
• Il n'y avait pas de branches, de tags ou même de références. Les utilisateurs devaient manuellement conserver une trace des ID d'objet.
• Il était impossible de synchroniser deux dépôts. Par conséquent, les utilisateurs devaient utiliser rsync(1) pour synchroniser les répertoires .dircache.
• Il était impossible de fusionner des modifications.

Git 0.99

La version 0.99 de Git a été la première à entrer en phase de test. Celle-ci a été publiée seulement deux mois après le commit initial, mais contenait déjà 1 076 commits. Près de 50 développeurs différents ont participé à son développement. À ce stade, Linus Torvalds était encore le principal contributeur, talonné de près par Junio Hamano, qui est aujourd'hui le chargé de maintenance.

De nombreuses améliorations avaient été mises en place depuis le premier commit :

• Git avait commencé à suivre différentes branches de développement à l'aide de références, ce qui, dans la grande majorité des cas, dispensait les utilisateurs de suivre les ID d'objets manuellement.
• Un nouveau protocole distant permettait désormais à deux dépôts d'échanger des objets entre eux.
• Le répertoire .dircache avait été renommé .git.
• Il était désormais possible de fusionner des fichiers uniques entre eux.

Mais le changement le plus marquant a sans doute été l'arrivée de la commande principale git et de ses nombreuses sous-commandes. C'est aussi à cette occasion qu'est née la distinction entre les commandes dites de « plomberie » (plumbing) et de « porcelaine » (porcelain) :

• Les outils de « plomberie » sont les commandes de bas niveau qui accèdent au dépôt Git sous-jacent.
• Les outils de « porcelaine » sont des scripts shell qui encapsulent les commandes de « plomberie » pour fournir une interface utilisateur plus conviviale et performante.

Cette distinction existe encore aujourd'hui, comme expliqué dans git(1), mais avec la réécriture en C de nombreuses commandes de « porcelaine » initialement en shell, la frontière entre ces deux catégories a commencé à s'estomper significativement.

Linus Torvalds passe la main

Linus Torvalds n'a jamais créé Git par passion pour les systèmes de contrôle de version, mais parce qu'il était nécessaire de remplacer BitKeeper pour le développement du noyau Linux. Dès le départ, il n'avait pas l'intention d'en assurer la maintenance indéfiniment, mais juste le temps de trouver quelqu'un de confiance pour reprendre le flambeau.

Et cette personne fut Junio Hamano. Junio a rejoint Git une semaine à peine après le premier commit de Linus Torvalds et comptait déjà plusieurs centaines de commits dans l'historique au moment de la sortie de la version 0.99. Ainsi, le 26 juillet 2005, Linus Torvalds l'a désigné comme nouveau chargé de maintenance du projet Git. Même si Linus Torvalds a continué à contribuer à Git, son implication s'est progressivement réduite, ce qui n'a rien de surprenant, vu ses responsabilités à la tête du projet Linux.

A ce jour, Junio Hamano dirige toujours le projet Git.

Git 1.0

La première version majeure de Git est sortie le 21 décembre 2005 par Junio Hamano. Fait intéressant : pas moins de 34 nouvelles versions ont été publiées entre la version 0.99 et la version 1.0 : 0.99.1 à 0.99.7, 0.99.7a à 0.99.7d, 0.99.8 à 0.99.8g, et 0.99.9 jusqu'à 0.99.9n.

Parmi les évolutions majeures depuis la version 0.99, l'une des plus importantes a sans doute été l'introduction de la commande git-merge(1) pour fusionner deux arbres. Un changement radical par rapport à la version précédente, dans laquelle chaque merge devait être effectuée manuellement, fichier par fichier.

Dépôts distants

Un autre changement majeur a été l'introduction de la notation abrégée pour les dépôts distants. Git savait déjà communiquer avec eux, mais jusque-là, les utilisateurs devaient entrer l'URL complète à chaque récupération de modifications. Ce processus était plutôt contraignant, car dans la grande majorité des cas, les utilisateurs interagissaient toujours avec le même dépôt distant.

Aujourd'hui, vous connaissez probablement le fonctionnement des dépôts distants, mais à l'époque, le mécanisme était encore très différent. Il n'existait pas de commande git-remote(1)
pour les gérer. Ils n'étaient même pas stockés
dans votre fichier.git/config file. À vrai dire, lorsque les dépôts distants ont fait leur apparition dans la version 0.99.2, Git ne disposait même pas encore de fichiers de configuration.

Pour les configurer, il fallait créer un fichier dans le répertoire .git/branches, un mécanisme qui semble aujourd'hui plutôt contre-intuitif. Mais
il fonctionne encore aujourd'hui :

$ git init repo --
Initialized empty Git repository in /tmp/repo/.git/
$ cd repo
$ mkdir .git/branches
$ echo https://gitlab.com/git-scm/git.git >.git/branches/origin
$ git fetch origin refs/heads/master

Et ce n'est pas tout ! Le répertoire a été renommé en « dépôts distants » dès la version 0.99.5 de Git. Aujourd'hui, il existe donc trois méthodes distinctes pour configurer des dépôts distants dans un client Git actuel.

Mais soyons honnêtes : la plupart d'entre vous n'ont sans doute jamais eu à utiliser .git/branches ni .git/remotes, deux mécanismes devenus obsolètes en 2005 et 2011, respectivement. Ces répertoires seront d'ailleurs définitivement supprimés dans la version Git 3.0.

Image de marque de Git

En 2007, Git créé son premier logo. Le terme « logo » est peut-être un peu excessif : il ne s'agissait en réalité que de trois signes moins rouges au-dessus de trois signes plus verts, une référence visuelle directement inspirée de la sortie de git diff :

Le site web git-scm.com voit quant à lui le jour en 2008 :

En 2012, le site web de Git est remanié par Scott Chacon et Jason Long et son design ne changera que très peu par la suite :

Cette refonte du site arbore le nouveau logo rouge-orange conçu par Jason Long, qui est encore utilisé aujourd'hui :

Git 2.0

Dès la version 1.0, Git ressemblait déjà fortement à la version d'aujourd'hui, c'est pourquoi nous allons faire un grand saut dans le temps et passer directement à une autre étape clé de son histoire : Git 2.0. Publiée environ dix ans après Git 1.0, cette version a été la première à introduire délibérément des changements non compatibles avec les versions précédentes dans les workflows principaux.

Comportement par défaut de git-push(1)

Le changement le plus déroutant de cette version a sans doute été l'ajustement du comportement par défaut de la commande git-push(1).

Si vous réalisiez un push dans un dépôt distant sans en indiquer explicitement l'objet, Git pouvait réagir de plusieurs façons :

• Refuser d'agir et vous inviter à préciser l'objet de votre push.
• Effectuer un push de la branche actuellement extraite.
• Effectuer un push de la branche actuellement extraite, mais uniquement s'il détectait une branche correspondante dans le dépôt distant.
• Effectuer un push de toutes vos branches disposant d'un équivalent dans le dépôt distant.

Aujourd’hui, le comportement par défaut de Git suit la stratégie dite « simple », c'est-à-dire la troisième option mentionnée ci-dessus. Mais avant Git 2.0, le comportement par défaut était la stratégie de « correspondance », soit la dernière option.

La stratégie de « correspondance » était nettement plus risquée. Avant le push, vous deviez toujours vous assurer que vous vouliez vraiment effectuer un push de toutes vos branches locales disposant d'un équivalent dans le dépôt distant. Dans le cas contraire, vous risquiez d'envoyer des modifications par erreur. C'est pourquoi Git a opté pour la stratégie dite « simple », afin de limiter les risques et de faciliter la prise en main pour les nouveaux utilisateurs.

git-add(1)

Le comportement par défaut de git-add(1) vis-à-vis des fichiers supprimés a lui aussi connu une évolution importante. Avant Git 2.0, la commande git-add(1) ne prenait pas en compte les fichiers supprimés : il fallait les ajouter manuellement avec git-rm(1) pour qu'ils soient inclus dans un commit. À partir de la version 2.0, la commande git-add(1) détecte également les suppressions de fichiers et les ajoute à l’index.

La communauté Git à l'honneur

Nous n'allons pas entrer dans les détails du fonctionnement actuel de Git : vous l'utilisez probablement déjà au quotidien, et dans le cas contraire, de nombreux tutoriels existent pour bien débuter. Prenons plutôt un moment pour célébrer et remercier la communauté Git, qui a permis à ce système de rester aussi performant après deux décennies.

Au fil du temps, Git a :

• Accumulé 56 721 commits depuis Git 2.49.0
• Reçu des contributions de plus de 2 000 personnes différentes.
• Publié 60 nouvelles versions majeures.

Le projet Git continue aussi de se renouveler grâce à l'arrivée régulière de nouveaux contributeurs, notamment par le biais des programmes Google Summer of Code et Outreachy. Ce sont eux qui assurent la pérennité du projet Git.

L'avenir de Git

Git s'est clairement imposé comme le grand gagnant dans la course aux systèmes de contrôle de version. Il domine largement le marché et il est rare aujourd'hui de voir un projet open source qui n'utilise pas Git. C'est bien la preuve que Git a su faire les bons choix.

Cela dit, le développement de Git est loin d'être terminé et de nombreux défis restent à relever. Sur le plan technique :

• la modernisation d'un code base vieillissant
• la mise à l'échelle face à la croissance continue des monorepos
• la gestion plus efficace des fichiers binaires volumineux

Sur le plan communautaire :

• l'amélioration de la convivialité de Git
• la promotion de la communauté Git pour garantir la pérennité du projet

Le travail ne s'arrête pas là et chez GitLab, nous sommes fiers de contribuer activement à faire en sorte que Git reste un système de contrôle de version de référence pour les vingt années à venir.

En savoir plus sur Git

• Git fête ses 20 ans : entretien avec son créateur Linus Torvalds
• Format reftable de Git : guide pour les débutants
• Git fetch vs git pull : quelle est la différence entre ces deux commandes Git ?
• Commits Git : comment et pourquoi maintenir un historique propre
• Git en ligne de commande sous Windows avec Git Bash
• Améliorez votre workflow avec Git rebase

GitLab Duo Workflow est actuellement proposé en version bêta privée. Inscrivez-vous sur la liste d'attente pour découvrir ce qu'il est possible de faire avec des agents d'IA qui comprennent l'ensemble de votre cycle de développement logiciel.

Ouverture de votre projet dans VS Code

1. Commencez par cloner votre projet Java sur votre ordinateur local, puis ouvrez-le dans Visual Studio Code. Assurez-vous d'utiliser une branche de fonctionnalité (et non pas la branche principale ou par défaut). Si vous travaillez déjà sur une merge request, celle-ci doit être associée à sa propre branche de fonctionnalité.

2. (Étape facultative.) Accédez au fichier contenant la classe Java pour laquelle vous souhaitez que GitLab Duo Workflow crée des tests unitaires. Inspectez-le afin de pouvoir confirmer ultérieurement que les tests unitaires générés couvrent bien les éléments de cette classe. Voici ce que vous verrez :

Remarque : ce tutoriel suppose que vous avez déjà installé l'extension GitLab Duo Workflow et que vous l'avez activée dans votre VS Code. Si ce n'est pas le cas, veuillez vous référer à la documentation d'installation.

3. Lancez GitLab Duo Workflow en ouvrant la palette de commandes de VS Code [Ctrl + Shift + P]. Saisissez « GitLab Duo Workflow », puis sélectionnez GitLab : afficher GitLab Duo Workflow. Un onglet apparaîtra alors, comme suit :

4. L'étape suivante consiste à ajouter des tests pour tester le constructeur par défaut, vérifier la création de l'objet et tester l'état initial des propriétés de la classe « Product » Java. Pour ce faire, saisissez le prompt suivant dans la zone de texte de GitLab Duo Workflow :

Create unit tests for class defined in the Product.java file and store the unit tests in its own file titled ProductTest.java

5. Cliquez sur le bouton Démarrer dans la fenêtre GitLab Duo Workflow. Deux nouvelles fenêtres apparaissent alors : une au centre de l'écran et une à droite. Celle de droite affiche l'analyse que GitLab Duo Workflow a effectuée pour proposer un plan d'action qui permettra d'atteindre l'objectif spécifié dans votre prompt. Le plan d'action détaillé est affiché dans la fenêtre centrale. Une fois l'analyse terminée et le plan d'action élaboré, vous obtenez les données de sortie suivantes :

6. Si l'analyse et le plan d'action vous conviennent, cliquez sur Approuver le plan en bas de la fenêtre.

7. Une fois votre plan d'action approuvé, GitLab Duo Workflow exécute les modifications nécessaires dans votre projet.

8. Vous voyez alors s'afficher un nouveau répertoire src/test/java/csaa/jspring/ProductManager contenant un nouveau fichier nommé ProductTest.java, lequel regroupe tous les tests unitaires pour la classe Product.java.

9. En consultant ce fichier ProductTest.java, vous remarquerez qu'il contient des déclarations d'importation soulignées en rouge indiquant des erreurs d'importation :

Demandons alors à GitLab Duo Workflow de les corriger à notre place.

Remarque : nous aurions également pu demander à GitLab Duo Workflow dans notre premier prompt de mettre à jour le fichier pom.xml. Comme nous ne l'avons pas fait, nous allons donc corriger ces erreurs dans un nouveau workflow.

Correction des erreurs dans le code généré avec GitLab Duo Workflow

10. Démarrez un nouveau workflow en cliquant sur le bouton Nouveau workflow en bas de la fenêtre d'analyse sur le côté droit de votre écran.

11. Saisissez le prompt suivant :

The file ProductTest.java has an error “The import org.junit cannot be resolved”. Please fix it

12. Approuvez le plan d'action proposé pour que GitLab Duo Workflow commence son analyse en lisant votre fichier pom.xml actuel, puis l'édite et supprime la dépendance JUnit obsolète en la remplaçant par la dépendance et la version correctes de JUnit. Enfin, GitLab Duo Workflow élimine toutes les erreurs de dépendance dans le fichier ProductTest.java.

Tutoriel vidéo

En exécutant le plan d'action proposé, GitLab Duo Workflow met concrètement à jour votre projet afin de réaliser ce que vous lui avez demandé dans le prompt. Il vous aide à gagner un temps précieux, en toute simplicité, et augmente la productivité de votre équipe : vos équipes de développement peuvent ainsi consacrer plus de temps à innover et à créer de la valeur.

Pour découvrir ce guide étape par étape en action, regardez la vidéo du tutoriel :

<!-- blank line --> <figure class="video_container"> <iframe src="https://www.youtube.com/embed/Tuj7TgqY81Q?si=RReuL1pUsLafvAzs" frameborder="0" allowfullscreen="true"> </iframe> </figure> <!-- blank line -->

Inscrivez-vous à la version bêta privée de GitLab Duo Workflow pour découvrir ce qu'il est possible de faire avec des agents d'IA qui comprennent l'ensemble de votre cycle de développement logiciel.

En savoir plus sur GitLab Duo Workflow et l'IA agentique

• GitLab Duo Workflow : une IA agentique offrant visibilité et contrôle à l'échelle de l'entreprise
• Documentation GitLab Duo Workflow
• GitLab Duo
• IA agentique : libérez le potentiel des développeurs à grande échelle (The Source)

Cette séparation crée des silos entre les équipes et entraîne une multitude de problèmes au quotidien : les équipes de développement passent constamment d'un système à l'autre, les chefs de produit peinent à obtenir une image précise de l'avancement des projets, et au final, ce sont tous les contributeurs aux projets qui perdent un temps précieux à transférer manuellement des informations entre les différents systèmes. Or, SAFe a précisément été conçu pour résoudre ce type d'expérience fragmentée.

Si vos équipes de développement utilisent déjà GitLab pour la gestion du code source, les processus CI/CD et la sécurité des logiciels, vous vous demandez peut-être s'il est possible d'y intégrer également la planification SAFe. La réponse est oui. Grâce à ses solides capacités de gestion de projets Agile, GitLab prend en charge le framework SAFe à chaque étape du développement logiciel.

Dans cet article, découvrez comment GitLab vous aide à mettre en place les concepts et les cérémonies SAFe, le tout au sein d'une seule et même plateforme DevSecOps.

Qu'est-ce que le Scaled Agile Framework (SAFe) ?

Le Scaled Agile Framework (SAFe) est une approche de gestion conçue pour appliquer les principes Agile à l'échelle des grandes entreprises. Il optimise la livraison de valeur, assure un alignement constant entre les équipes et se concentre sur les besoins des clients.

SAFe transpose le modèle collaboratif et itératif des petites équipes aux environnements complexes des grandes entreprises impliquant de nombreuses équipes, parties prenantes et roadmaps.

Cette approche permet d'harmoniser tous les efforts de planification et d'exécution vers un objectif commun. Pour les chefs de produit, le Scaled Agile Framework (SAFe) fait le lien entre la stratégie et l'exécution : il ne s'agit pas uniquement de livrer rapidement, mais de livrer les bons produits, en s'appuyant sur des priorités claires et une coordination transversales entre les différentes équipes.

SAFe réduit les silos, encourage la collaboration et aide les équipes à se mobiliser autour des résultats attendus par les clients, et non plus uniquement autour des tâches à accomplir. Une fois intégré à GitLab, la magie opère : visibilité, traçabilité et livraison sont réunies au sein d'une seule et même plateforme.

Correspondance de la terminologie SAFe dans GitLab

Voici un aperçu des concepts SAFe et leur correspondance dans GitLab :

<br></br>

En vous basant sur cette correspondance, vous pouvez configurer GitLab pour refléter fidèlement votre implémentation SAFe. La structure des groupes vous permet d'organiser vos équipes autour de vos chaînes de valeur (Value Stream) et de vos Agile Release Trains (ART), tandis que la hiérarchie des éléments de travail (avec jusqu'à sept niveaux d'epics imbriqués) vous offre toute la profondeur nécessaire pour gérer des portefeuilles produits complexes. Que vous travailliez au niveau du portefeuille (groupes principaux), du programme (sous-groupes) ou de l'équipe (projets), la structure organisationnelle de GitLab s'aligne parfaitement avec la hiérarchie SAFe.

Les cérémonies SAFe dans GitLab

Découvrez maintenant comment organiser vos cérémonies SAFe dans GitLab. Voici comment procéder, étape par étape.

Planification PI (Program Increment)

Pour faciliter l'alignement entre les équipes et la gestion des dépendances qui font le succès de la planification PI, GitLab offre plusieurs fonctionnalités :

• La vue Roadmap : visualisez les fonctionnalités par équipe et sur plusieurs périodes.
• Les jalons : associez chaque fonctionnalité au jalon correspondant à votre PI.
• Les dépendances : documentez et visualisez les dépendances entre équipes dès qu'elles sont identifiées.

GitLab vous offre une grande flexibilité pour la planification PI grâce à deux vues principales : les tableaux des epics (qui peuvent être configurés pour afficher les affectations par équipe) et la vue Roadmap (qui affiche les fonctionnalités au fil du temps, façon diagramme de Gantt). Vous pouvez facilement passer d'une vue à l'autre pendant votre session de planification, selon que vous souhaitez vous concentrer sur la chronologie ou l'organisation des équipes.

<br></br>

Affinement

En tant que chef de produit, animer des sessions d'affinement efficaces repose sur une visibilité complète de votre backlog de fonctionnalités. Vous pouvez exécuter votre session d'affinement directement dans GitLab. Il n'est plus nécessaire de mettre à jour un outil pendant la réunion, puis un autre après coup.

GitLab facilite les sessions d'affinement grâce aux éléments suivants :

• Les tableaux des epics : regroupez les fonctionnalités en fonction de leur statut.
• Les story points : visualisez-les directement dans l'aperçu.
• Les vues dans un volet latéral : interagissez avec vos éléments de travail sans jamais perdre de vue le contexte.
• Les tickets enfants : créez et associez des tickets directement à partir des epics.

Planification de sprint

GitLab vous offre tous les outils nécessaires pour planifier vos sprints sans frictions :

• Les tableaux des tickets : visualisez clairement l'ensemble de votre backlog.
• Le poids total des user stories : visualisez-le directement dans les tableaux.
• L'ordonnancement des tickets : déplacez les tickets entre les différentes itérations, par simple glisser-déposer.
• Une vue repliable : simplifiez le réordonnancement des stories d'un sprint à l'autre.

Plus besoin de jongler entre plusieurs outils, toute la planification se fait dans GitLab. Vous pouvez ainsi consacrer vos réunions de planification à prendre les bonnes décisions.

💡 Consultez ce tutoriel dédié à la mise en œuvre de la méthode Scrum avec GitLab et découvrez en détail la puissance de GitLab dans la planification Agile et le suivi des sprints.

Points quotidiens

Votre équipe peut se réunir autour du tableau de bord lors de vos points quotidiens, plus besoin de naviguer entre plusieurs outils ou de deviner l'avancement des projets : tout est visible en un clin d'œil dans GitLab. Votre équipe voit instantanément qui travaille sur quoi, ce qui bloque, et ce qui est prêt pour la revue. GitLab vous permet d'effectuer les actions suivantes lors de vos points quotidiens :

• Les tableaux filtrés par itération : affichez le travail du sprint en cours.
• Les story points : affichez le poids des stories directement sur les cartes.
• La vue du volet latéral : accédez aux détails sans quitter le contexte.
• Les indicateurs de progression : mettez en évidence les tâches à risque.

Revue de sprint

Pour avoir une vision claire des performances de votre équipe au fil des sprints, GitLab met à votre disposition des indicateurs puissants avec les éléments suivants :

• Des graphiques d'avancement burndown et burnup : visualisez facilement l'avancement des itérations.
• Le suivi de la vélocité : mesurez l'efficacité de votre équipe.
• Les délais d'exécution et la durée de cycle : obtenez des indicateurs précis pour évaluer vos workflows.
• Des tableaux de bord personnalisables : créez des vues adaptées à chaque équipe.

Ces indicateurs vous aident à comprendre si votre équipe gagne en rapidité, à détecter les goulots d'étranglement et les points de friction à aborder lors de votre prochaine rétrospective.

5 bonnes raisons d'adopter une plateforme unifiée

Il existe de nombreux outils de planification capables de gérer les cérémonies SAFe. Mais GitLab se distingue véritablement de ses concurrents pour les raisons suivantes :

1. Plus de changement de contexte : la planification, le développement, les tests et la sécurité s'effectuent tous sur une seule plateforme.
2. Une traçabilité totale : de l'épic stratégique et prioritaire jusqu'au déploiement, en passant par l'écriture du code, chaque élément est relié et facile à suivre.
3. Une collaboration efficace : toutes les équipes (développement, produit, sécurité) collaborent dans le même outil.
4. Une visibilité instantanée : toutes les parties prenantes accèdent aux informations clés mises à jour, sur une seule plateforme.
5. Une vue d'ensemble : les indicateurs de planification et de développement sont regroupés pour comprendre exactement où en est le projet.

Si vos équipes de développement apprécient déjà GitLab, pourquoi leur imposer un nouvel outil de planification ou créer des intégrations complexes et disparates ? En intégrant votre planification SAFe à GitLab, vous offrez à tous les contributeurs une expérience unifiée, cohérente et bien plus efficace.

Principes de mise en œuvre

Après avoir accompagné plusieurs équipes dans leur transition depuis des outils SAFe traditionnels vers GitLab, voici ce qu'il faut retenir : concentrez-vous sur les objectifs propres à chaque cérémonie SAFe plutôt que d'essayer de reproduire les processus de vos anciens outils.

Les équipes qui tirent pleinement parti des fonctionnalités natives de GitLab sont plus performantes que celles qui essaient de les contourner. Cela demande un peu de travail au départ pour comprendre comment associer vos concepts SAFe et configurer vos workflows. Mais une fois cette étape franchie, vous constaterez rapidement que vos processus sont en réalité bien plus simples.

La clé du succès réside dans la définition de conventions partagées entre tous les contributeurs : quels labels utiliser ? Comment suivre les équipes ? Quelle différence entre un epic et un ticket ? En investissant un minimum d'effort dans cette phase de clarification, vous créez un système intuitif qui éliminera toute la charge de travail liée à la coordination entre les différents outils.

Mise en place du framework SAFe dans GitLab

Envie de vous lancer ? Voici les étapes pour mettre en œuvre un Scaled Agile Framework (SAFe) dans GitLab :

1. Structurez votre environnement : créez des groupes et des sous-groupes qui s'alignent sur l'organisation de vos équipes.
2. Définissez la répartition de votre travail : décidez comment vous allez utiliser les epics, les tickets et les tâches.
3. Créez vos itérations : configurez votre calendrier de sprints.
4. Ajoutez vos jalons : les jalons représentent vos Program Increments (PI) SAFe dans GitLab.
5. Personnalisez vos tableaux : créez des vues dédiées à chaque cérémonie SAFe.
6. Accordez-vous sur des conventions : documentez la façon dont vous utiliserez les labels et les champs personnalisés.

Prendre le temps de bien poser ces bases dès le départ vous évitera bien des tracas par la suite. Votre configuration n'a pas besoin d'être parfaite dès le premier jour : vous pourrez faire des ajustements au fur et à mesure.

Rassemblez toutes les pièces du puzzle

GitLab vous offre une base solide pour exécuter le Scaled Agile Framework (SAFe), en particulier si vos équipes de développement sont déjà adeptes de GitLab. En centralisant la planification et le développement dans un seul et même outil, vous éliminez les silos et les transferts fastidieux, facilitez la collaboration et accélérez la livraison de vos produits.

La flexibilité des outils de planification de GitLab vous permet d'adapter l'approche SAFe à vos besoins spécifiques. Vos équipes ne sont pas soumises à des workflows rigides : vous pouvez faire évoluer votre approche à mesure que vos équipes gagnent en maturité et que vos besoins changent.

Découvrez à quel point la planification sans effet de silo peut être plus simple et plus efficace. Essayez GitLab Ultimate gratuitement pendant 60 jours et simplifiez l'implémentation de votre approche SAFe.

💡 Pour en savoir plus à ce sujet, n'hésitez pas à consulter également cet article : Comment utiliser GitLab pour le développement logiciel agile