Bonjour, pour ceux qui sont intéressés, voici mon expérience avec la gestion "par package". En effet, j'ai mis en place une gestion de produit où tout est package : les produits mais aussi les configurations. Les développeurs ont la responsabilité des packages "produit" et des packages "config de dev/test". Les devOps ont la responsabilité des packages "config de prod". Avantages : - Très facile de reproduire un environnement - Tout est tracé et consigné "as code" (les scripts de migration sont dans les 'postinst') - Définition claire des responsabilités devs / devOps - Les devs sont sensibilisés aux problèmes de production Inconvénients : - C'est lourd (par ex, il faut créer un package quand on change une config) - Les devs doivent être formés et accepter de faire autre chose que du code. - Cela ne fonctionne que sur des distributions d'un même type (soit que des .deb, soit que des .rpm) ... mais j'ai un projet pour construire des .rpm à partir de scripts de génération de .deb.
Bonjour, pour ceux qui sont intéressés, voici mon expérience avec la gestion "par package". En effet, j'ai mis en place une gestion de produit où tout est package : les produits mais aussi les configurations. Les développeurs ont la responsabilité des packages "produit" et des packages "config de dev/test". Les devOps ont la responsabilité des packages "config de prod".
Avantages :
- Très facile de reproduire un environnement
- Tout est tracé et consigné "as code" (les scripts de migration sont dans les 'postinst')
- Définition claire des responsabilités devs / devOps
- Les devs sont sensibilisés aux problèmes de production
Inconvénients :
- C'est lourd (par ex, il faut créer un package quand on change une config)
- Les devs doivent être formés et accepter de faire autre chose que du code.
- Cela ne fonctionne que sur des distributions d'un même type (soit que des .deb, soit que des .rpm) ... mais j'ai un projet pour construire des .rpm à partir de scripts de génération de .deb.