none
MOSS OOTB - Dev - Préprod et production... RRS feed

  • Question

  • Bonjour,

     

    Avant de poser ma question, une brève présentation:

    J'ai travaillé avec SPS2003 pendant quelques temps dans une SSII, surtout en mode OOTB. Très peu de dév, au maximum du natif, de la configuration, du Frontpage 2003 à la limite, un peu d'XSLT dès fois.

     

    Je suis actuellement Admin MOSS et n'ai pas encore d'application en production mais des gros morceaux vont arriver prochainement exporant chacun des piliers de MOSS (Portail, Recherche, Formulaires, ECM...).

     

    Ma question concerne surtout le passage des environnements de dev vers la pré-prod puis vers la prod.

     

    On peut remplir bien des besoins en configuration quelques bibliothèques de documents, quelques listes, deux trois webparts d'affichage et le tour est joué. (pour les éléments de base). Mais comment basculer le résultat de ces clics en production ? Comment embarquer cela dans une feature ? Est-ce possible ?

     

    Un petit exemple :

    BESOIN

    Projet d'archivage de documents. Chaque métadonnées est basée sur un code. Chaque code a une description simple, une description détaillée + un ou deux éléments complémentaires.

     

    SOLUTION

    Une dizaine de listes MOSS avec autant de colonnes que nécessaire. Chaque liste correspondant au descriptif complet de chaque métadonnées (Code, descriptif simple, descriptif complet).

    Une librairie de formulaire ou chaque champ est lié aux listes précédentes où un menu déroulant affiche les codes, quand un code est sélectionné, on affiche la description et les autres détails que l'on retrouve dans la liste (via Infopath).

    Deux ou trois vues adaptées pour afficher les documents selon différents axes dans la librairie de formulaire, et le tour est joué.

     

    Cette solution a été implémentée simplement en environnement de développement que par des clics. Pas une ligne de code.

    Comment basculer cela en prod ? Même en utilisant un "Content Type" pour chaque composant (liste et formulaire), il n'est pas possible de basculer cela en production, les liens vers les listes MOSS sont en dur dans le formulaires.

     

    En gros, un rappel de mes questions :

    1. Comment déployer en production ce qu'on peut faire avec des clics ? --> Surtout, comment maintenir cela ?

    2. Comment déployer en production un formulaire Infopath qui fait du lookup dans des listes MOSS ?

    3. Doit-on banir tous les clics pour tout faire toujours en dév (features) ? Mais alors, on perd tout l'intérêt du OOTB de MOSS...

    4. Comment basculer des données validées en test (contenu de listes, de doclib avec versionning...) vers la production ? En fait, dans les deux sens... bon, les backups / restore peuvent peut-être résoudre ce point. Mais disons, le problème est dans la granularité des backups / restore. Peut-on descendre au niveau d'une liste ?

     

    Merci à ceux qui auront tout lu, et un grand merci à ceux qui pourront m'apporter des éléments de réponse.

    Si vous avez besoin de précisions, si je ne suis pas clair... ne pas hésiter !

     

    Charles

     

     

    mardi 25 mars 2008 16:42

Réponses

  • Bonjour

     

    Ce que vous désirez faire s'apparente tout simplement à du déploiement de contenu et non de développement.

    Ainsi, les features ne sont pas forcément la solution (mais toujours dans une solution <= humour Sharepointesque):

    • devez vous recréer n fois le site et sa structure ? si oui ==> provisionning de site et industrialisation étant un des (nombreux) piliers de SharePoint, c'est là que les features s'avèrent utiles s'il faut recréer toute une structure à l'envie
    • vos listes, types de contenu & co sont ils propres à votre site/collection de site ? si oui ==> cela vaut-il d'être automatisé ? intérêt plus mitigé, surtout si vous créez le tout par l'interface web et SharePoint Designer

    Aussi, vous l'évoquez, le moyen plus adapté serait un backup/restore. Mais le backup / restore n'a comme scope que la collection de site : donc pas de salut pour mettre à jour uniquement un sous site, voire une liste.

     

    Pour cela, 2 méthodes qui au fond utilisent la même chose, l'API "Prime" :

    Dans les 2 cas, l'élément le plus fin est le site et non plus la collection. Pour aller plus finement dans les éléments à exporter et réimporter, il faut développer. Mais certains l'ont déjà fait pour vous : http://stsadm.blogspot.com/2007/08/stsadm-commands_09.html

     

    Ensuite, tout dépend aussi de votre politique de mise à jour et d'authoring:

    • le content deployment (automatisé ou oneshot) est plutôt destiné à de la mise à jour régulièrement vers un site en lecture seul, ou du moins sur lequel peu de modifs seront faites
    • le backup/restore garde les mêmes identifiants internes et sera plus adapté pour une initialisation

    J'espère que cela vous aidera à y voir plus clair. N'hésitez surtout pas à poser d'autres questions ou demander des clarifications.

    mardi 25 mars 2008 22:06

Toutes les réponses

  • Bonjour

     

    Ce que vous désirez faire s'apparente tout simplement à du déploiement de contenu et non de développement.

    Ainsi, les features ne sont pas forcément la solution (mais toujours dans une solution <= humour Sharepointesque):

    • devez vous recréer n fois le site et sa structure ? si oui ==> provisionning de site et industrialisation étant un des (nombreux) piliers de SharePoint, c'est là que les features s'avèrent utiles s'il faut recréer toute une structure à l'envie
    • vos listes, types de contenu & co sont ils propres à votre site/collection de site ? si oui ==> cela vaut-il d'être automatisé ? intérêt plus mitigé, surtout si vous créez le tout par l'interface web et SharePoint Designer

    Aussi, vous l'évoquez, le moyen plus adapté serait un backup/restore. Mais le backup / restore n'a comme scope que la collection de site : donc pas de salut pour mettre à jour uniquement un sous site, voire une liste.

     

    Pour cela, 2 méthodes qui au fond utilisent la même chose, l'API "Prime" :

    Dans les 2 cas, l'élément le plus fin est le site et non plus la collection. Pour aller plus finement dans les éléments à exporter et réimporter, il faut développer. Mais certains l'ont déjà fait pour vous : http://stsadm.blogspot.com/2007/08/stsadm-commands_09.html

     

    Ensuite, tout dépend aussi de votre politique de mise à jour et d'authoring:

    • le content deployment (automatisé ou oneshot) est plutôt destiné à de la mise à jour régulièrement vers un site en lecture seul, ou du moins sur lequel peu de modifs seront faites
    • le backup/restore garde les mêmes identifiants internes et sera plus adapté pour une initialisation

    J'espère que cela vous aidera à y voir plus clair. N'hésitez surtout pas à poser d'autres questions ou demander des clarifications.

    mardi 25 mars 2008 22:06
  • Merci pour ces informations.

     

    Comme vous le dites, l'export/import est surtout adapté pour une initialisation. Ce n'est donc pas applicable au quotidien.

     

    Pour ce qui est du "content deployment", c'est autre chose. C'est juste dommage que ce ne soit applicable qu'au site de publication, si j'ai bien compris la documentation. Au revoir donc pour les "Team Site" et autres modèles de sites custom.

    => Me confirmez-vous cela ?

     

    Par ailleurs, je souhaiterais des précisions sur la problèmatique des formulaires infopath qui embarqueraient des connexions à des listes sharepoint.

    J'ai l'impression que les librairies du types "Data Connection Library" sont là pour répondre à mon problème de passage d'un formulaire d'un environnement de dev/test vers l'environnement de production.

    => Savez-vous si, théoriquement, un formulaire utilisant des connexions présentes dans ce type de libraries dans un site donnée peut basculer vers un autre site (celui-ci respectant le même nommage et structure) et utiliser les connexions locales à ce nouveau site ?

     

    Merci encore pour votre aide.

    mercredi 2 avril 2008 12:19