GitLab Branch Protection Rules

Ce document décrit la configuration recommandée pour protéger la branche main et assurer la qualité du code.

Configuration des Push Rules

1. Protection de la branche `main`

Dans GitLab : Settings > Repository > Protected branches

Branch: main
Allowed to push: No one
Allowed to merge: Maintainers
Allowed to force push: No one

2. Merge Request Settings

Dans GitLab : Settings > General > Merge requests

Merge method: Merge commit
Squash commits when merging: Optional
Delete source branch when merging: Yes
Enable merged results pipelines: Yes
Enable merge trains: Yes (GitLab Premium)

3. Pipeline Requirements

Dans GitLab : Settings > General > Merge requests > Merge checks

Pipelines must succeed: ✓ Enabled
All discussions must be resolved: ✓ Enabled
Enable security-related features: ✓ Enabled
Prevent merge when security reports contain vulnerabilities: ✓ Enabled

4. Approval Rules

Dans GitLab : Settings > General > Merge request approvals

Merge request approval is required: ✓ Enabled
Required approvals: 1 (minimum)
Prevent approval by merge request author: ✓ Enabled
Prevent approval by merge request committers: ✓ Enabled
Require approval from code owners: ✓ Enabled

Configuration YAML pour automation (.gitlab-ci.yml)

Pipeline Gates

# Notre pipeline existant inclut déjà ces gates :
stages:
  - test        # Tests unitaires et fonctionnels
  - security    # Scan de sécurité et audit
  - build       # Build Docker
  - deploy      # Déploiement

# Gates automatiques :
- PHPStan (analyse statique)
- Pint (style de code)
- Tests unitaires et fonctionnels
- Audit de sécurité des dépendances
- Détection de secrets

Code Owners (.gitlab/CODEOWNERS)

Créer le fichier .gitlab/CODEOWNERS :

# Global code owners
* @rdem @maintainer-team

# PKI Core Services - Requires expert review
app/Services/ @rdem @pki-experts
app/Console/Commands/License* @rdem
docker/ @rdem @devops-team

# Configuration files
*.yml @rdem @devops-team
*.yaml @rdem @devops-team
Dockerfile @rdem @devops-team
docker-compose*.yml @rdem @devops-team

# Security-sensitive files
app/Services/LicenseService.php @rdem
app/Services/CryptoService.php @rdem @security-team
config/database.php @rdem @devops-team

Workflow Recommandé

1. Feature Branch Workflow

# Créer une branche feature
git checkout -b feature/nouvelle-fonctionnalite

# Développer et commiter
git add .
git commit -m "feat: implement new feature"

# Pousser vers GitLab
git push gitlab feature/nouvelle-fonctionnalite

# Créer une Merge Request via GitLab UI

2. Merge Request Process

Création MR : Description claire, liens vers issues
Pipeline automatique : Tous les tests doivent passer
Code Review : Au moins 1 approbation requise
Discussion : Toutes les discussions doivent être résolues
Merge : Seulement par les maintainers

Notifications et Alertes

Configuration des notifications

# Dans GitLab : Settings > Integrations
Slack/Teams Integration:
  - Pipeline failures
  - Merge request approvals
  - Security vulnerabilities
  - Failed deployments

Email Notifications:
  - Pipeline status
  - Merge request mentions
  - Push to protected branches (denied)

Exceptions et Hotfixes

Pour les urgences critiques uniquement

# Créer une branche hotfix
git checkout -b hotfix/critical-security-fix

# Développer le fix
git add .
git commit -m "fix: critical security vulnerability"

# Push et MR d'urgence
git push gitlab hotfix/critical-security-fix

# Dans GitLab : Marquer MR comme "Critical" pour review prioritaire

Emergency Override (Maintainers uniquement)

En cas d'urgence absolue, les maintainers peuvent : 1. Temporairement désactiver les protections 2. Push direct sur main 3. OBLIGATOIRE : Réactiver immédiatement les protections 4. OBLIGATOIRE : Créer une issue post-mortem

Commandes GitLab CLI

Configuration automatique (si GitLab CLI disponible)

# Installer GitLab CLI
curl -s https://raw.githubusercontent.com/glab-cli/glab/main/install.sh | sudo sh

# Configurer le projet
glab auth login --hostname git.pa4.rdem-systems.com
glab repo clone rdem-systems/pkiaas

# Configurer les protections via API
glab api projects/:id/protected_branches -d '{
  "name": "main",
  "push_access_level": 0,
  "merge_access_level": 40,
  "allow_force_push": false
}'

Monitoring et Métriques

Métriques à surveiller

Temps de résolution des MR
Taux de pipeline failures
Couverture de tests
Violations de sécurité
Temps de déploiement

Dashboard GitLab recommandé

Analytics > Repository : Contribution analytics
Analytics > CI/CD : Pipeline performance
Security & Compliance : Vulnerability reports
Operations > Environments : Deployment frequency

Migration et Formation

Étapes de migration

✅ Actuel : Push libre sur main
Phase 1 : Activer les protections de base
Phase 2 : Ajouter les approval rules
Phase 3 : Intégrer code owners
Phase 4 : Monitoring avancé

Formation équipe

Workshop Git flow avec protections
Utilisation GitLab MR interface
Code review best practices
Emergency procedures