GitLab Server
Découvrez les fonctionnalités, les configurations et les bonnes pratiques d'utilisation de votre instance GitLab.
Gabarits d'instance proposés
| GitLab Professional | GitLab Business | GitLab Enterprise |
|---|---|---|
| Recommandé pour 50 utilisateurs | Recommandé pour 200 utilisateurs | Recommandé pour 500 utilisateurs |
| 4 vCPUs | 6 vCPUs | 8 vCPUs |
| 10 GB RAM | 16 GB RAM | 32 GB RAM |
| 50 GB SSD OS 50 GB SSD data | 50 GB SSD OS 200 GB SSD data | 50 GB SSD OS 450 GB SSD data |
| Sauvegarde Veeam B&R | Sauvegarde Veeam B&R | Sauvegarde Veeam B&R |
| Support e-mail | Support e-mail | Support e-mail |
Vous pouvez également consulter les gabarits de GitLab Runner proposés.
Options proposées
- Import de données depuis un GitLab existant
- Authentification : SSO, AD, OmniAuth
- GitLab Pages
- Advanced Search
- Kroki
- Certificats personnels
- Chiffrement des disques
- Espace disque supplémentaire
- VPN / Filtrage par IP
- Bande passante supplémentaire
- Export des sauvegardes applicatives GitLab vers le support de votre choix
- Externalisation des logs applicatifs chez vous
Application des mises à jour GitLab
Chez adista, nous appliquons deux types de mises à jour :
- Les mises à jour mensuelles
- Les mises à jour de sécurité
Mises à jour mensuelles
Afin de garantir la stabilité et la sécurité de votre instance GitLab, nous appliquons une politique de mise à jour mensuelle.
Les mises à jour sont appliquées le 4ème jeudi de chaque mois, à partir de 21h30.
GitLab publie une nouvelle version mineure le troisième jeudi de chaque mois. Dès sa disponibilité, notre équipe procède à son installation en interne, où elle est soumise à une batterie de tests pendant une semaine. Cette période permet également d'intégrer les éventuels correctifs publiés par GitLab dans l'intervalle.
À l'issue de cette phase de validation, la version mineure ainsi que les éventuels correctifs publiés entre temps sont déployés sur votre plateforme lors de la fenêtre de maintenance mensuelle. Cette approche vise à limiter les risques liés à l'introduction de nouvelles fonctionnalités ou des régressions non détectées.
Calendrier des prochaines mises à jour
| Version | Date de publication | Date de déploiement par adista |
|---|---|---|
| 19.4 | 17 septembre 2026 | 24 septembre 2026 |
| 19.5 | 15 octobre 2026 | 22 octobre 2026 |
| 19.6 | 19 novembre 2026 | 26 novembre 2026 |
| 19.7 | 17 décembre 2026 | 28 décembre 2026 (car fêtes de fin d'année) |
| 19.8 | 21 janvier 2027 | 28 janvier 2027 |
| 19.9 | 18 février 2027 | 25 février 2027 |
| 19.10 | 18 mars 2027 | 25 mars 2027 |
| 19.11 | 15 avril 2027 | 22 avril 2027 |
| 20.0 | 20 mai 2027 | 27 mai 2027 Pas de montée de version, mais mise à jour en dernière 19.11 |
| 20.1 | 17 juin 2027 | 24 juin 2027 |
| 20.2 | 15 juillet 2027 | 22 juillet 2027 |
| 20.3 | 19 août 2027 | 26 août 2027 |
Particularités du déploiement des versions majeures
GitLab publie une nouvelle version majeure chaque année, au mois de mai. Ces versions introduisent des changements significatifs et des dépréciations, ainsi que des bugs potentiels.
Par précaution, nous ne déployons pas cette version immédiatement, mais attendons le mois suivant et la publication du prochain patch (qui intègre les premiers correctifs), avant de procéder à son installation.
GitLab assure le support des trois dernières versions mineures : N, N-1 et N-2. Ainsi, le fait de différer l'installation d'une version majeure d'un mois n'a aucun impact sur la sécurité de votre instance. Les correctifs de sécurité continuent d'être publiés sur la version N-1, en place à ce moment sur votre instance, permettant de maintenir votre environnement sécurisé.
Mises à jour de sécurité
Il n'est pas nécessaire d'ouvrir un ticket lorsque GitLab vous signale qu'une mise à jour est disponible. Nos équipes sont déjà informées de la publication du correctif et prennent en charge son analyse et son déploiement selon les procédures établies.
Lors de la publication d'un correctif, une fenêtre contextuelle s'affiche sur l'interface de votre GitLab, vous incitant à procéder à la mise à jour dans les plus brefs délais. Nous sommes alors déjà informés de la disponibilité de ce correctif, et nous entreprenons une analyse approfondie de l'impact potentiel de cette mise à jour sur vos infrastructures.
Dans l'éventualité où nos équipes détermineraient que votre système est affecté par une vulnérabilité critique, vous en seriez immédiatement informé. Dans ce contexte, nous programmerions une mise à jour exceptionnelle dans les plus brefs délais.
En revanche, si nous concluons que votre système n'est pas affecté, notre équipe ne vous sollicitera pas inutilement et votre GitLab sera mis à jour à la fin du mois, conformément à notre routine mensuelle. Cette démarche a pour objectif de garantir une sécurité optimale de votre plateforme.
Si vous avez des questions relatives à votre offre ou des interrogations sur la solution GitLab proposée par adista, nous vous invitons à contacter votre commercial dédié qui se fera un plaisir de vous accompagner.
Consulter les releases notes
Pour suivre les évolutions de GitLab et connaître les détails des nouvelles versions, vous pouvez consulter les releases notes officielles.
Anticiper les breaking changes
Certaines mises à jour peuvent introduire des changements majeurs ou des dépréciations. Pour anticiper ces évolutions et adapter vos usages, nous vous recommandons de consulter régulièrement la documentation dédiée.