SharePoint Summit 2012 - Gouvernance et évolution d'une équipe de développement SharePoint
•
2 likes•927 views
Présentation donnée lors du SharePoint Summit 2012 de Québec le 18 avril 2012.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to SharePoint Summit 2012 - Gouvernance et évolution d'une équipe de développement SharePoint
Similar to SharePoint Summit 2012 - Gouvernance et évolution d'une équipe de développement SharePoint (20)
More from Sébastien Levert
More from Sébastien Levert (20)
SharePoint Summit 2012 - Gouvernance et évolution d'une équipe de développement SharePoint
- 1. Gouvernance et évolution d'une équipe de développement SharePoint Sébastien Levert Directeur technique, Développement SharePoint, Les Solutions Victrix
- 2. À propos de moi ! Directeur technique, Développement SharePoint Les Solutions Victrix MCTS, MCITP & MCPD Twitter : @sebastienlevert LinkedIn : http://ca.linkedin.com/in/sebastienlevert Blog : http://blog.sebastienlevert.com/ 2
- 3. À qui ça s’adresse ? Chefs d’équipe Développeurs Gestionnaires d’équipes techniques 3
- 4. Agenda La gouvernance d’une équipe de développement Faire évoluer une équipe de développement grâce à la gouvernance Questions 4
- 5. Objectifs Être en mesure de mettre en place une gouvernance relative à une équipe de développement SharePoint Avoir les outils nécessaires afin de favoriser son adoption Connaître les étapes permettant à l’équipe d’évoluer Proposer un plan d’évolution selon le niveau de maturité de votre équipe 5
- 6. Gouvernance 6
- 7. La gouvernance d’une équipe de développement « La gouvernance d’entreprise est l’ensemble des processus, réglementations, lois et institutions influençant la manière dont l’entreprise est dirigée, administrée et contrôlée. » - Wikipédia Mise en contexte de la gouvernance aux différents niveaux de gestion Niveau stratégique Niveau tactique Niveau opérationnel 7
- 8. Les étapes L’établissement des rôles et responsabilités Mise en place de la fondation de la gouvernance Identification des processus et de leurs outils 8
- 9. Établissement des rôles et responsabilités Une équipe de réalisation de projet SharePoint contient habituellement les rôles suivants Gestionnaire de projet Analyste d’affaires Analyste fonctionnel Architecte de solution Développeur Testeur Gestionnaire de livraison Rôle trop souvent omis Expert en infrastructure 9
- 10. Établissement des rôles et responsabilités Développeur / Intégrateur Paqueter les éléments natifs de SharePoint Développer les fonctionnalités supplémentaires Créer une image de marque Scripter le déploiement de la solution Testeur Créer des scripts de tests fonctionnels appuyés sur l’analyse fonctionnelle du projet Élaborer et maintenir les tests unitaires / tests d’interface Gestionnaire de livraison Rôle clé dans le succès et l’adoption de la gouvernance de l’équipe de développement SharePoint Récupérer / assembler une version spécifique d’une solution S’assurer de la validité de la solution à chacun des déploiements 10
- 11. La fondation de la gouvernance Les objectifs Promouvoir les meilleures pratiques de développement Hausser la productivité des développeurs Livrer une solution de qualité Comment Standardiser les environnements de développement Établissement de règles de développement Création de matrice d’accès aux environnements 11
- 12. Standardisation des environnements de développement Pourquoi ? Être le plus près possible de l’environnement du client Éviter les problèmes associés à l’environnement (services SharePoint, versions de logiciels, etc.) pendant la phase de réalisation Favoriser le temps de développement au lieu de la configuration de l’environnement Permettre l’initialisation rapide d’un environnement Techniquement Environnement virtuel de base, prêt à cloner Outils de développement (Visual Studio, SharePoint Designer, etc.) Binaires de SharePoint SQL Scripts de configuration de l’instance de l’environnement Configuration de la ferme Création / configuration des applications web nécessaires 12
- 13. Établissement de règles de développement Pourquoi ? Favoriser un code uniforme et selon les meilleures pratiques Faciliter la maintenance du code Intégration de nouvelles ressources simplifiée Techniquement Gestion d’erreur et journalisation des exceptions Éradication des valeurs forgées dans le code Nom internes des champs, identifiants, URL, etc. Éviter les valeurs littérales dans le code Utilisation de fichiers de ressources pour chacune des valeurs littérales Séparer les responsabilités du code (SoC) Permet de tester plus facilement les unités de code Gestion de mémoire et disposition des objets SPWeb, SPSite, etc. Requêtes au contenu optimales (CAML, API de recherche, etc.) 13
- 14. Matrice des accès aux environnements Pourquoi ? Assurer l’intégrité des environnements Favoriser la création de scripts et de paquets de déploiement au profit de la configuration manuelle Techniquement 14
- 15. Identification des processus à gouverner Le processus de développement Processus permettant de transformer une analyse fonctionnelle en solution logicielle Le processus des opérations Processus permettant à une solution SharePoint d’être promue d’un environnement à l’autre 15
- 16. Gestion du cycle de vie d’une solution SharePoint Gouvernance Développement Opérations Idée Déploiement initial Fin de vie 16
- 17. Le cycle de développement 17
- 18. SharePoint Designer ? Oui, mais… Quand l’utiliser ? Phases de prototypage Générer des artéfacts réutilisables Favoriser les méthodologies de développement rapide Avantages Rapide et simple à manipuler Peut être gouverné par l’établissement d’une sécurité granulaire Développement possible depuis n’importe quel poste Inconvénients Difficile à faire évoluer d’un environnement à l’autre Aucun support pour la localisation (multilinguisme) Ajout d’attributs dans les définitions CAML Paquets complexes, plus ou moins utilisables tels quels Génère des solutions « Sandbox » N’offre pas de « vraie » gestion de source Difficulté à travailler en équipe 18
- 19. Visual Studio Quand l’utiliser ? Développer tous les éléments plus complexes (Webparts, événements, etc.) Réutiliser les éléments exportés des paquets générés par SharePoint Designer Avantages Intégration à un gestionnaire de sources Contrôle complet sur le comportement de la solution Une tonne d’outils existent pour augmenter la productivité Inconvénients Plus complexe que SharePoint Designer Demande un environnement complet pour développer avec l’outil 19
- 20. Les outils du développeur CKS:DEV (http://cksdev.codeplex.com/) Ensemble de fonctionnalités exclusives aux développeurs permettant d’améliorer le cycle de développement Plusieurs outils d’extraction de données (Gabarits de page, type de contenu, colonnes, etc.) Ajout de type d’artéfacts pouvant être créés avec Visual Studio (Colonnes, services web, pages d’application, etc.) 20
- 21. Les outils du développeur SPDisposeCheck (http://archive.msdn.microsoft.com/SPDisposeCheck) Traduction de l’article « Best Practices: Using Disposable Windows SharePoint Services Objects » en règles d’analyse de code statique Intégration aux environnements de développement (Visual Studio) pour garder un contrôle constant Intégration aux environnements d’intégration continue 21
- 22. Les outils du développeur Camlex.NET (http://camlex.codeplex.com/) Système facilitant l’écriture de requêtes CAML Utilise un interpréteur Linq pour générer la requête CAML utilisée Élimine les requêtes forgées directement dans le code vs. 22
- 23. Les outils du développeur Pex & Moles (http://research.microsoft.com/en- us/projects/pex) Système d’isolation de méthodes .NET Utilisé pour permettre de faire des tests unitaires ULSViewer (http://archive.msdn.microsoft.com/ULSViewer) Permet de déboguer une application SharePoint efficacement Permet la recherche d’informations par « Correlation Id » Vos outils Créer des outils pour vos besoins internes spécifiques Éviter de répéter les mêmes tâches, encore et encore 23
- 24. Le processus des opérations Environnement de Environnement développement Extraction / Déploiement d’assurance-qualité Archivage Développeurs Anomalies Anomalies Clients Tests Testeurs VM Gestionnaire de sources Extraction Environnement Gestionnaire TFS Environnement de d’intégration de livraison production Anomalies Anomalies Utilise Développeurs Tests Clients Déploiement Déploiement Gère Testeurs Administrateurs 24
- 25. Le point névralgique du processus d’opérations Le gestionnaire de source est le point névralgique du processus d’opérations Extraction / Déploiement Archivage Il comprend chacune des entrées / sorties Anomalies Anomalies Peut devenir rapidement l’entonnoir Gestionnaire de sources Extraction Il s’agit de l’élément permettant l’évolution d’une équipe de développement Gestionnaire TFS de livraison SharePoint Anomalies Anomalies Déploiement Déploiement 25
- 26. Évolution 26
- 27. Évoluer sans la gouvernance Les objectifs à atteindre sont connus La façon de s’y rendre est inconnue L’équipe semble évoluer dans plusieurs directions sans suivre un plan pré établi Exemple Savoir que nous devons se rendre à Québec Ne pas savoir par où passer Ne pas savoir où est Québec Ne pas savoir par quel moyen se rendre 27
- 28. Évoluer sans la gouvernance 28
- 29. La gouvernance & l’évolution La gouvernance détermine le cadre de l’évolution d’une équipe L’évolution d’une équipe de développement se fait à travers la gouvernance mise en place Exemple Savoir que nous devons se rendre à Québec S’informer sur les meilleures routes (meilleures pratiques) S’équiper d’un GPS (outils technologiques) Ne pas être à l’abris des entraves routières, mais préparer des itinéraires facultatifs (agilité) S’informer sur le code de la route pour ne pas être pris en défaut (règles) 29
- 30. Évoluer avec la gouvernance 30
- 31. Les points à considérer lors d’un plan d’évolution Évaluer la maturité de votre équipe avant de procéder à son évolution Assurer l’évolution par l’adoption de la gouvernance Placer la gouvernance au centre du processus d’amélioration continue 31
- 32. La maturité de votre équipe en est où ? Tests automatisés Déploiements automatisés Assemblages automatisés Utilisation d’un gestionnaire de source 32
- 33. Utilisation d’un gestionnaire de sources Symptômes Le cycle de déploiement est impossible à réaliser Aucune centralisation des versions Aucune centralisation des anomalies Solution Mise en place d’un gestionnaire de sources Mise en place d’un gestionnaire d’anomalies Gestionnaire de sources Outils à mettre en place Extraction TFS (sources, anomalies, etc.) Visual Studio 2010 Gestionnaire TFS Gains de livraison Centralisation du code source Centralisation des anomalies Facilité à suivre les activités de développement 33
- 34. Intégration continue La mise en place de l’intégration continue comporte 3 composantes complémentaires Serveur d’assemblage automatisé Serveur de déploiement automatisé Exécution de tests automatisés Demande l’installation de Team Foundation Server 2010 Très bonne série d’articles de Chris O’Brien sur le sujet http://www.sharepointnutsandbolts.com/2011/06/sp2010- continuous-integrationpt-1.html 34
- 35. Serveur d’assemblage automatisé Symptômes Les versions générées par le gestionnaire de livraison n’ont pas la certitude d’être fonctionnelles Solution Mise en place d’un serveur qui compilera le code source et qui validera que sa construction est valide Gains Les versions déployées par le gestionnaire de livraison sont toujours valides Les développeurs sont avertis lorsqu’un assemblage a causé une erreur Permet d’avoir une version intégrée de la solution à n’importe quel moments Permet d’exécuter des règles de code statiques au moment de l’assemblage Intégration de SPDisposeCheck 35
- 36. Serveur d’assemblage automatisé Archivage du code Gestionnaire de sources Extraction Assemblage d’une version Gestionnaire de Serveur livraisons d’assemblage Dépôt [Si assemblage = réussi] 36
- 37. Serveur de déploiement automatisé Symptômes Les versions générées peuvent être compilées, mais ne peuvent être déployées Les versions générées ne fonctionnent que sur les environnements de développement Solution Mise en place d’un serveur qui utilisera le dépôt des versions assemblées et tentera de déployer la solution Gains Les versions déployées par le gestionnaire de livraison ne causent pas d’erreur Les développeurs sont avertis lorsqu’un déploiement a causé une erreur Permet d’avoir une version déployable de la solution à tous moments 37
- 38. Serveur de déploiement automatisé Déploiement Gestionnaire de Archivage livraisons du code Serveur de déploiement Gestionnaire de sources VM Assemblage Extraction d’une version Extraction Serveur [Si déploiement = réussi] d’assemblage Dépôt [Si assemblage = réussi] 38
- 39. Exécution automatisée des tests Symptômes Les versions générées sont déployées, mais ne sont pas fonctionnelles Solution Configuration des serveurs d’assemblage et de déploiement afin de lancer une série de tests (unitaires ou d’interface) Gains Les versions déployées par le gestionnaire de livraison sont toujours fonctionnelles et validées contre les spécifications Les développeurs sont avertis lorsqu’un déploiement a soulevé des anomalies Permet d’avoir une version testée de la solution à tous moments 39
- 40. Exécution automatisée des tests Déploiement + Gestionnaire de tests d’interface Archivage livraisons du code Serveur de déploiement Gestionnaire de sources VM Assemblage Extraction d’une version + exécution des tests unitaires Extraction Serveur [Si déploiement = réussi] d’assemblage [Si tests d’interface = succès] Dépôt [Si assemblage = réussi] [Si tests = succès] 40
- 41. L’intégration continue Inconvénients L’implantation d’une telle solution est relativement coûteuse Un expert de la suite TFS doit accompagner l’équipe pour les premières semaines Avantages Le gain en temps est immédiat Ne pas déployer des versions non fonctionnelles Tests d’intégration sont faits par le processus d’intégration continue La rétroaction des anomalies est immédiate Le gain en qualité est immédiat La solution est testée en grande partie avant d’être déployée Faciliter la création de versions Augmente la cohésion d’équipe 41
- 42. En conclusion… L’évolution d’une équipe de développement SharePoint est un processus continu Cette évolution repose sur une gouvernance claire et bien définie La gouvernance permet à une organisation d’établir Les règles d’utilisation des outils de développement Les rôles et responsabilités des acteurs du développement SharePoint Les processus à utiliser 42
- 43. Questions ? 43