none
Versionning d'un projet MOSS RRS feed

  • Question

  • Bonjour,

     

    Je voudrai savoir comment se passe la gestion de conf. lors d'un projet MOSS 2007 . En clair , si nous avons plusieurs developpeurs qui travaillent sur la meme appli, comment faire pour que l'on puisse gerer des versions  sur cette appli?

    quelle methode la plus courante est utilisée pour que l'on puisse integrer toutes les modifications des developpeurs (faite en local) sur le serveur de recette ??

    jeudi 28 juin 2007 13:29

Toutes les réponses

  • Je ne suis pas expert en SharePoint, mais dans le cadre d'un suivi de développement d'application, je doute que MOSS soit le mieux adapté.
    Personellement, je préférerais d'autres solutions telles que SVN ou CVS, notamment parce que la gestion de la concurrence est plus fine : possibilité pour 2 développeurs de modifier un même fichier et faire un "merge" des 2, résolution de conflits, et surtout synchronisation entre une copie locale et le repository (une copie locale est idéale pour la recompilation de sources par exemple).

    Ce que propose MOSS de plus en revanche, c'est les flux de travail entre autres.
    jeudi 28 juin 2007 18:19
  • Pour ce point je suis tout a fait d'accord. Je pense que nous alllons utiliser SVN pour les sources. Mais Quid  de la base de données?? Comment intégrer les modifications de chacun  au niveau de la base de données??
    lundi 2 juillet 2007 07:22
  • Personnellement je séparerai bien 2 types de choses :

    • les développements : et là effectivement vous gérer avec votre contrôleur de source préféré
    • le contenu : je passerai par le backup d'une collection de site qui servira de base, en la mettant à jour lorsqu'il y en a besoin

    Les modifications opérées au niveau de la base de données ne sont que des modifications en terme de contenu, et comme il ne faut pas toucher directement à la base, il vous reste la sauvegarde de la collection via stsadm ou backup de base. Si vous êtes plusieurs à travailler en VM, un backup via stsadm serait pratique car facilement réintégrable sur chacun des postes. Les mises à jour importants seront à réalisés sur le serveur d'intégration qui rafraichira au besoin le contenu qui sera de nouveau poussé vers les VM.

     

    J'espère que ça vous éclairera un peu plus.

    lundi 2 juillet 2007 07:34
  • Ok ! merci ! en effet toutes ces indications m'aident.

    Aussi si chacun à sa VM , faut -il avoir une base de donnéées commune ou faut-il mieux avoir sa propre Base de données  et faire ses backup-restore (ceci impliquerait que chaque developpeur travaille sur une collection de site distincte)?

    vendredi 6 juillet 2007 07:28
  • Je verrai plutôt chacun sa base, plus simple pour faire des tests sans ennuyer les autres.

     

    Mais il faudra mettre en place le nécessaire pour les merges des différents devs, et donc d'une base de données commune, surtout si le contenu doit évoluer.

     

    Si c'est pour préparer tout le contenu d'un site, faites le dans ce cas sur une machine bien à part et faites les backup/restore vers les machines de dev, puis merge des developpements vers la machine initiale pour tester le tout de A à Z (contenu et dev).

    vendredi 6 juillet 2007 08:55
  • Ok merci pour votre aide precieuse...MAIS j'ai pas finis Smile

     

    Autre question importante à soulever je pense lors de l'élaboration d'un projet MOSS . Il exsite des backup/restore sur MOSS 2007 avec des backups complets et des backups differentiels. Jusque là OK.

    Mais lorsque qu'on met en place une application en prod et qu'apres un certain temps l'on veuille rajouter et/ou modifier un site ou une collection de sites ou une application on peut faire un backup/restore differentiel ...

     

    Mais ce restore va-t-il ecraser tout le contenu rajouté entre temps par les utilisateurs?

    Si oui, quelle pourrait être la meilleure facon de faire?

     

    Merci à vous Wink

     

    lundi 9 juillet 2007 16:19
  • Le restore/backup "différentiel" est dispo via l'admin centrale et je n'ai jamais testé son utilisation avec des backups récupérés d'autres machines, à valider donc.

     

    Un backup différentiel ne vaut que par rapport au dernier backup complet, ça revient donc au final à une restauration éliminant les modifications effectuées entre temps. Il vous reste l'option d'export/import, mais je ne suis pas sûr que vous obteniez la finesse recherchée (après il reste l'API qui pourrait affiner un peu, mais ca se complique).

     

    Si vos modifications concernent une seule liste (ou seulement qqs listes), vous pouvez imaginer passer par une sauvegarde en tant que modèle de liste avec le contenu, récupérer le modèle sur le disque, faire la restauration et remettre le modèle/recréer la liste (attention, si vous utilisiez l'ID, ça ne sera plus le même).

    mardi 10 juillet 2007 07:08