Dans toutes les équipes de dev que j'ai vues, les environnements applicatifs des développeurs étaient indépendants : Chacun a son compilateur, sa machine virtuelle (Java ou autre, ce n'est pas le sujet), son serveur d'application.
Les développeurs piochent leur code dans un gestionnaire de source (CVS, Subversion), le modifie, le teste, puis le redéposent et régulièrement, on voie ce que cela donne sur un poste d'intégration.
Tout cela fonctionne très bien. Ce qui m'intrigue, c'est que cette méthode de développement bien huilée pour le code de type applicatif n'est pas le même pour les modifications apportées dans les bases de données. En tout cas pas dans les équipes ou j'ai travaillé.
Contrairement aux environnements applicatifs indépendants pour chacun des postes, les bases de données sont communes à tous les développeurs.
...Et tout le monde passe des scripts de son côté, avec des règles... pas toujours respectées.
De plus, contrairement à l'applicatif, on ne peut pas recréer une base de données dans son intégralité lorsqu'on est en maintenance applicative ou corrective. Le client comprendrait mal que toutes ses données soient perdues.
Cela m'a déjà posé de sérieux problèmes lors du packaging du code source pour une livraison sur un environnement de recette. Les modifs réalisées sur la base de données de développements étaient mal tracés.
Or, je considère mon code comme un tout, c'est le code source applicatif ET le schéma de la base de données qui va avec (et n'importe quel autres composants d'ailleurs).
Ma question est donc la suivante :
Comment gérer vous les modifications des bases de données et comment livrez vous ces modifications sur d'autres environnemnets ?
Partager