Il y maintenant quelques années, alors que je travaillais pour mon premier client : Promod, l'équipe de développement était dotée d'une chose merveilleuse : chaque lundi, notre base de développement était mise à jour à partir des données de la production. Depuis ce jour, j'ai essayé de mettre en place cette astuce sur chacun des projets sur lesquels j'ai eu l'occasion de travailler.
Je ne vais pas vous dire que c'était fait de façon élégante, ce n'était pas le cas ! Tous les lundi, une restauration de la base de production avait lieu dans l'environnement de dev. Toutes les modifications que nous faisions sur la base étant sauvegardées sous forme de script sql, il était assez facile de rejouer (automatiquement) ces scripts pour obtenir une base de données de developpement opérationnelle.
Cette semaine, en voulant instaurer ce principe sur un nouveau projet, la procédure vbscript que j'avais déjà utilisé à maintes reprises n'as pas voulu fonctionner pour une raison indeterminée. J'en ai donc profité pour la ré-écrire en Powershell...
Le script se découpe en plusieurs phases :
- Dans un premier temps, il faut s'assurer que personne ne bloque la base. La je dois avouer que, comme j'ai plusieurs bases sur lesquelles appliquer ce même principe, j'ai utilisé une méthode un peu bourrin : je redemarre le service Sql Server, en n'oubliant pas de démarrer aussi les services dépedants :
- un script sql, lancé par osql, s'occupe de la restauration proprement dite
- il suffit ensuite de récupérer tous les scripts de mise à jour depuis Team Foundation Server
- et de les appliquer un par un sur la base
En (grosso-modo) 10 lignes - en prenant en compte la définition des variables d'environnement pointant vers les dossiers importants et un peu de gestion d'erreur-, le script powershell remplace sa version vbscript de pas loin de 150 lignes. Impressionnant non ?