[SharePoint][BPOS-D] Processus spécifiques au contrôle du code spécifique…
Après avoir décrit la documentation disponible puis détaillé :
nous allons voir dans ce message les processus spécifiques destinés à contrôler l’ajout de code spécifique sur une infrastructure SharePoint BPOS-D.
Objectifs
Comme on peut le constater en analysant la documentation BPOS-D, le document spécifiant ces processus est tout à fait spécifique à SharePoint Online puisque les autres produits de cette offre ne permettent pas d’embarquer un code spécifique, comme peut le faire SharePoint.
De plus, il convient de noter que l’ajout de code sur une plateforme étant potentiellement très impactant, les processus mis en place pour encadrer cette activité sont particulièrement bien spécifiés.
Il y a 3 niveaux de personnalisation possibles pour un client SharePoint :
| 1. La personnalisation accessible à l’utilisateur final, directement dans le navigateur. | 
|
| 2. La personnalisation accessible aux designers Web, via l’outil SharePoint Designer. | 
|
| 3. La personnalisation accessible aux développeurs, via le développement .Net et l’outil Visual Studio. Le code produit et les fichiers liés doivent être déployé par les équipes Online Services sur les serveurs SharePoint. | 
|
Les 2 premiers niveaux de personnalisation sont accessibles sans passer par les processus décrits ci-dessous. Ceux-ci couvrent donc la 3e catégorie de personnalisation. Et ils s’appliquent par contre aussi bien au code développé par le client en interne (par ses propres équipes ou des sous-traitants) qu’à des produits tiers.
Le but des process mis en place est de s’assurer que le code produit est plus sécurisé et conforme aux bonnes pratiques. A cette fin, les ingénieurs des équipes Microsoft Online Services passent en revue les personnalisations proposées, les compare à d’éventuelles solutions existant nativement dans le produit et déroule le processus afin d’assurer le déploiement facile, la supportabilité et la pérennité de la solution proposée.
L’impact potentiel d’un déploiement de code spécifique peut être fort notamment en terme de consommation de ressources. Dans le cas où du matériel supplémentaire serait nécessaire, Microsoft se réserve le droit de rejeter la demande de personnalisation ou de facturer le coût du matériel supplémentaire requis.
Environnements
SharePoint Online ne fournit que deux environnements : un pour la Production et un pour la Pré-Production. En conséquence, le client doit gérer les autres environnements nécessaires. On recommande en général les environnements suivants :
L’environnement de production n’est pas précisément décrit en tant que tel mais on peut en avoir une bonne idée dans l’appendice E du document “Microsoft SharePoint Online Dedicated Custom Solution Policies and Process” :
avec les caractéristiques suivantes :
| Eléments | Frontaux Web, Index et serveurs d’application | Serveur Base de données SQL Server |
| Modèle | HP DL380 G5 | HP DL380 G5 |
| Processeur | 2x4 Intel Xeon 2.33-GHz Quad Core | 2x4 Intel Xeon 2.33-GHz Quad Core |
| Mémoire | 16 Go | 32 Go |
| Disque dur | 550,4 Go | 9 894 Go |
L’environnement de pré-production est à entendre comme un environnement de validation.
Il a la même architecture que l’environnement de production avec les limitations suivantes :
- Le volume total de contenu ne dépasse pas 150 Go
- Le nb total de bases de contenu par Applications Web ne dépasse pas 2
- Jusqu’à 250 utilisateurs simultanées peuvent accéder à cet environnement
Processus de déploiement des personnalisations
L’introduction de code spécifique sur l’environnement de production SharePoint Online nécessite de suivre le processus suivant.
Les principaux livrables de ce process sont :
- le document de Conception de haut niveau (HLD – High Level Design)
- Il s’agit d’un document de conception technique de haut niveau décrivant la personnalisation.
- le package de personnalisation qui inclus :
- le code final testé
- le code source
- les scripts d’installation et de désinstallation
- le guide de déploiement
- la documentation de test
Il peut être synthétisé par le diagramme suivant :
Les activités en orange sont à la charge du client, les activités en bleu sont à la charge de Microsoft OnLine Services.
Les principales activités sont donc :
- Expression de besoins
- Création du document de Conception de haut niveau (HLD)
- On détermine la taille de la personnalisation en fonction des critères suivants :
| Taille | Lignes de code | Nb de fichiers WSP |
| Petite | 0 à 1000 | 1 à 2 |
| Moyenne | 1000 à 3000 | 1 à 4 |
| Grosse | 3001 ou plus | 1 à 10 |
- Analyse du document de Conception de haut niveau par les équipes Microsoft
- A ce stade Microsoft peut demander d’incorporer des modifications dans le code
- Développement du code
- Tests, Validation et Packaging
- Les tests doivent inclure côté client des tests de scalabilité et de performance. L’outil CAT.Net doit être utilisé.
- La validation est assurée par l’outil CAF (Code Analysis Framework)
- Déploiement tout d’abord dans l’environnement de pré-production puis enfin sur la production.
Un maximum de 10 fichiers WSP est accepté. Au-delà une refonte de l’application est demandée.
Un exemple de processus complet est représenté sur ce calendrier.
Personnalisations déployées
Le code déployé est monitoré pour détecter au plus vite tout comportement impactant négativement la plateforme complète. Si le code spécifique impacte l’expérience utilisateur ou bien empêche Microsoft d’atteindre son engagement de service, les équipes Online Services réagissent immédiatement. Cela peut signifier debugger l’application ou retirer le code de la plateforme. Un Comité consultatif de changement (CAB – Change Advisory Board) est convoqué et le client est consulté pour prendre la meilleure décision possible.
La surveillance du code déployé n’est possible que si le client fournit des documentations complètes et instrumente correctement son code.
Produits et solutions tiers
Les produits tiers sont éligibles pour une installation dans l’environnements BPOS-D s’ils remplissent les règles de personnalisation.
Un certain nombre de solutions du marché ont déjà été évaluées et sont ajoutées à la liste des solutions validées.
Le client reste responsable de l’achat des licences associées à ces produits tiers.
Le code open source est supporté, si le client prend au préalable la responsabilité du code concerné. En particulier, il devra assurer la maintenance de ce code et les correctifs éventuels.
La liste suivante est la liste des produits tiers actuellement supportés :
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
