none
Cycle de vie d'une application SharePoint - Méthodologie RRS feed

  • Question

  • Bonjour à tous,

    Je termine actuellement un projet SharePoint (mon premier) . La fonctionnalité développée sous Visual Studio 2010 à scope "Site" contient un content Type, une définition de liste et une instance de liste, des customs actions ainsi que  des "Application pages" et autres  user control.

    Lors l'étape de développement (que je termine), chaque nouveau déploiement provoquait  la perte des données dans la liste . Ce qui est normal  car la première étape du déploiement consiste en la désactivation de la fonctionnalité, retrait de la solution et suppression .

    Nous arrivons donc en phase de recette et bientôt j'espère en production. Faut-il passer par une étape de Sauvegarde/Restauration des données utilisateurs lors d'une MAJ (corrective ou évolutive) de la fonctionnalité? 

    J'ai bien vu qu'il existait  une option upgradeAction Mais j'ai du mal à comprendre son fonctionnement.  Comment faire par exemple si la modification à apporter concerne uniquement une "application page" ou un usercontrol ? Je veux pouvoir déployer cette mise à jour sans forcément écraser la liste contenu dans cette fonctionnalité? Faut-il créer 2  solutions (une avec le contentType et les listes) et l'autre avec le code qui est plus susceptible d'évoluer?

    Si vous pouvez m'éclairer sur une méthodologie, je suis preneur

    Merci d'avance!

    NicoBzh

    mercredi 23 mai 2012 15:27

Réponses

  • Bonjour NicoBzh,

    Je vais commencer par la question facile :)

    Comment faire par exemple si la modification à apporter concerne uniquement une "application page" ou un usercontrol ?

    Les pages d'application et les user controls etant simplement des fichiers copiés parmis les fichiers de SharePoint, lors d'une mise à jour de la solution (wsp), ces fichiers seront écrasés par leurs nouvelles versions, et la mise à jour sera ainsi appliquées instantanément.

    Il n'y a rien à faire en dehors de la simple upgrade de la solution.

    Upgrade d'une définition de liste

    Ici non plus pas vraiment de problemes. La mise à jour consiste juste à mettre à jour des fichiers sur le serveur. Les nouvelles instances de cette liste serons créées avec la nouvelle définition. Nous ne touchons pas aux données existantes.

    Upgrade d'une instance de liste

    Voila nous y sommes. On commence a monter le niveau de difficulté.

    Par défaut, lorsqu'une feature, ayant créée des instances de liste, est désactivée, les listes créées ne sont pas supprimées. Vous semblez dire que dans votre cas oui. Avez vous codé ce comportement?

    C'est trés dangereux et je ne le conseilles pas; vous risquez de perdre toutes les données de vos utilisateurs.

    Dissociez les mises à jour de vos définitions de liste et de vos instances. Mettez à jour les définifion de liste simplement en écrasant ces fichiers pour leurs nouvelles versions mais traitez les instances au cas par cas, par code ou manuellement. La fonctionnalité "UpgradeAction" permet de gérer ces cas.

    Upgrade d'un type de contenu

    On est ici dans une situation similaire qu'avec les listes, mais ca devient encore un peu plus compliqué...

    Par exemple, la mise à jour d'un type de contenu au niveau d'un site, n'implique par forcement la mise à jour de celui ci dans chaque liste ou il est utilisé.

    Je vous conseille les lectures suivantes:

    Généralement

    Les mises à jour touchant à la structure de données déja existantes dans SharePoint sont risquées et peuvent etre compliquées.

    Upgrading Features - http://msdn.microsoft.com/en-us/library/aa544511
    Feature Versioning and Upgrades in SharePoint 2010 - http://www.dotnetmafia.com/blogs/dotnettipoftheday/archive/2010/01/04/feature-versioning-and-upgrades-in-sharepoint-2010.aspx

    Ici encore c'est un vaste sujet. N'hésitez pas si vous avez plus de questions.

    Cordialement,

    Ludovic Caffin


    jeudi 24 mai 2012 09:27

Toutes les réponses

  • Bonjour NicoBzh,

    Je vais commencer par la question facile :)

    Comment faire par exemple si la modification à apporter concerne uniquement une "application page" ou un usercontrol ?

    Les pages d'application et les user controls etant simplement des fichiers copiés parmis les fichiers de SharePoint, lors d'une mise à jour de la solution (wsp), ces fichiers seront écrasés par leurs nouvelles versions, et la mise à jour sera ainsi appliquées instantanément.

    Il n'y a rien à faire en dehors de la simple upgrade de la solution.

    Upgrade d'une définition de liste

    Ici non plus pas vraiment de problemes. La mise à jour consiste juste à mettre à jour des fichiers sur le serveur. Les nouvelles instances de cette liste serons créées avec la nouvelle définition. Nous ne touchons pas aux données existantes.

    Upgrade d'une instance de liste

    Voila nous y sommes. On commence a monter le niveau de difficulté.

    Par défaut, lorsqu'une feature, ayant créée des instances de liste, est désactivée, les listes créées ne sont pas supprimées. Vous semblez dire que dans votre cas oui. Avez vous codé ce comportement?

    C'est trés dangereux et je ne le conseilles pas; vous risquez de perdre toutes les données de vos utilisateurs.

    Dissociez les mises à jour de vos définitions de liste et de vos instances. Mettez à jour les définifion de liste simplement en écrasant ces fichiers pour leurs nouvelles versions mais traitez les instances au cas par cas, par code ou manuellement. La fonctionnalité "UpgradeAction" permet de gérer ces cas.

    Upgrade d'un type de contenu

    On est ici dans une situation similaire qu'avec les listes, mais ca devient encore un peu plus compliqué...

    Par exemple, la mise à jour d'un type de contenu au niveau d'un site, n'implique par forcement la mise à jour de celui ci dans chaque liste ou il est utilisé.

    Je vous conseille les lectures suivantes:

    Généralement

    Les mises à jour touchant à la structure de données déja existantes dans SharePoint sont risquées et peuvent etre compliquées.

    Upgrading Features - http://msdn.microsoft.com/en-us/library/aa544511
    Feature Versioning and Upgrades in SharePoint 2010 - http://www.dotnetmafia.com/blogs/dotnettipoftheday/archive/2010/01/04/feature-versioning-and-upgrades-in-sharepoint-2010.aspx

    Ici encore c'est un vaste sujet. N'hésitez pas si vous avez plus de questions.

    Cordialement,

    Ludovic Caffin


    jeudi 24 mai 2012 09:27
  • Bonjour et Merci pour cette réponse complète.

    Pour la suppression de l'instance de liste, c'est le cas uniquement lors du déploiment via Visual Studio. Une mise à jour via un script Power Shell (Update-SPSolution), mets bien à jour la solution sans suppression de l'instance de liste (donc pas de suppression des données utilisateurs).

    Pour la modification  de la structure des données, je vais faire quelques tests avant la mise en production. Pour le projet en cours, pas trop de conséquence mais je prépare les suivants.

    La technique commence à être acquise mais reste à mette en place une  bonne méthodologie  de travail (moins facile...)

    Merci encore

    NicoBzh

    
    
    
    jeudi 24 mai 2012 11:25
  • Salut Nico

    Pour la petite histoire Visual Studio fait un equivalent à "Reset to Site Definition" à chaque déploiement (en plus des actions de déploiement de wsp) c'est ce qui explique la suppression de la liste...


    Blog Sharepoint : www.paslatek.net Twitter : @LimozinLionel

    jeudi 7 juin 2012 07:07