Cette question suscite toujours une discussion animée lors des sessions de conception du FIM, car ce sujet présente de nombreux points de vue différents.
Un projet FIM est très différent de la plupart des projets informatiques en ce sens qu'il s'agit d'un projet "typique d'infrastructure" et d'un projet "typique de développement" fusionnés, qui s'intègrent également à un ensemble d'autres systèmes. Cette affirmation, prise au pied de la lettre, ne semble pas indiquer qu'un laboratoire FIM serait radicalement différent d'un laboratoire de projet typique, jusqu'à ce que vous commenciez à réfléchir à la signification sous-jacente de ce qui est nécessaire pour atteindre vos objectifs en matière de développement et de test.
Bien qu'il n'existe pas d'approche unique pour créer un bon environnement de laboratoire, j'ai remarqué que plus l'environnement de développement est proche de l'environnement de production, plus le développement et la mise en œuvre du FIM sont réussis. Le respect de la configuration du laboratoire par rapport à la configuration de la production permet de réduire les risques et de favoriser une mise en œuvre réussie pour les raisons suivantes :
- Validation des hypothèses de conception
- Valide les configurations de hardware et du serveur
- Augmente la précision de l'effort de développement
- Amélioration de la capacité à effectuer des tests précis
- Permet d'identifier et d'atténuer les problèmes que l'on rencontrera avec les données de production avant le déploiement.
- peut réduire le nombre de problèmes rencontrés lors du portage du code et des configurations de produits entre les environnements
- Il est plus facile de transférer les changements de configuration du développement à la production.
J'utilise la série de questions suivante pour guider la discussion et identifier les objectifs de haut niveau du laboratoire :
- Quel est le profil de risque (niveau de tolérance) de l'organisation ?
- Quel est l'objectif du laboratoire ?
- Développement ponctuel
- Développement continu après le déploiement initial
- Tests d'intégration avant la production (par exemple, correctifs, service packs, changements de configuration, configuration de l'équilibreur de charge, etc...)
- Tests de performance avant la production
- Quels sont les systèmes qui doivent être ajoutés au laboratoire ?
- Chaque système auquel le FIM doit se connecter doit faire partie du laboratoire.
- Peut-on faire une copie des données de production pour les utiliser dans le laboratoire ? (Exportation de données physiques vers des données virtuelles (P2V) ou de VM)
- Quel type d'informations le FIM gérera-t-il dans la conception ? (par exemple, types d'objets - utilisateurs AD, groupes AD, contacts AD, dossier RH, utilisateur Sun, etc...)
- Quel est l'équipement disponible pour mettre en place l'environnement de développement ?
- Quelle est la plate-forme de virtualisation utilisée par l'organisation ?
- Toutes les sources de données peuvent-elles être isolées dans le laboratoire ? (par exemple, certains systèmes ne peuvent pas être ajoutés au laboratoire, tels que les systèmes de milieu de gamme ou les systèmes centraux) Un serveur TMG peut-il être configuré pour permettre le trafic d'un laboratoire isolé vers un système de production ?
- Quels types de tests souhaitez-vous effectuer ?
- Tests unitaires
- Tests d'intégration
- Test du système
- Tests de performance
- Tests d'acceptation
- Quels sont les éléments de la conception que vous souhaitez développer et tester avant la production ?
- Un certain nombre de tests différents doivent être envisagés dans le cadre du projet. Vous trouverez ci-dessous quelques-uns des domaines de test à prendre en considération :
Aspect de la conception | Zone | Description |
Connectivité MA | Moteur de synchronisation | Les informations d'identification se connectent, le schéma et les autorisations sont corrects. |
Filtrage | Moteur de synchronisation | Filtrage des unités d'organisation, critères de filtrage des objets |
Adhésion | Moteur de synchronisation | Configuration de la MA |
Projections | Moteur de synchronisation | Configuration de la MA |
Provisionnement | Moteur de synchronisation | Code de provisionnement/test de provisionnement sans code |
Déprovisionnement | Moteur de synchronisation | Règles de suppression d'objets, paramètres MA, code de déprovisionnement |
Flux d'attributs | Moteur de synchronisation | Flux directs, transformation des données (flux avancés) |
Priorité | Moteur de synchronisation | Priorité égale/manuelle/ordonnée |
PCNS | Moteur de synchronisation | Les modifications de mot de passe apportées au compte AD de l'utilisateur sont répliquées sur d'autres systèmes "cibles". |
Connexion au portail | Portail FIM | Connexion au système |
Personnalisation du site portail | Portail FIMSites RSSP | Le site affiche-t-il correctement les personnalisations ? |
Jeux | Service FIM | Ensembles basés sur des critères, ensembles temporels |
Groupes basés sur des critères | Service FIM | Possibilité de remplir automatiquement la liste des membres d'un groupe en classant les objets qui devraient en devenir membres |
TPM (octroi de permission) | Service FIM | Délégation de l'administration du portail - Administration des utilisateurs - Administration des groupes |
TPM (flux de travail déclenchés) | Service FIM | Flux de travail intégrés - flux d'approbation du propriétaire, contenu du message - flux de notification, contenu du message |
Flux de travail personnalisé | Service FIM | Composants de flux de travail personnalisés... |
Déploiement du client | Service FIM | Différents composants de la livraison de software : - Emballage et livraison de SCCM - Tests d'intégration du système d'exploitation - Tests d'intégration d'Office |
SSPR | Service FIM | Les composants du SSPR fonctionnent-ils comme prévu : - Site d'enregistrement du PW - Site de réinitialisation du PW
|
Règles de publication du pare-feu | Pare-feu | Accès externe au FIM - Site d'enregistrement du PW - Site de réinitialisation du PW |
Rapport R2 | SCSM | Rapports - Rapports standard - Rapports personnalisés |
Administration basée sur les rôles | BHOLD | Composantes du BHOLD : - Exploration des rôles - Attribution des rôles - Attestation de l'appartenance à un groupe |
Gestion du système | SCOM | Gestion des systèmes - Identification et résolution des problèmes - Données sur les performances - Alerte en cas de panne |
- Quelles sont les compétences nécessaires à la mise en place et à la maintenance de l'environnement ?
- Compétences en matière d'administration interne
- De nouvelles technologies sont-elles introduites, telles que le clustering ou le SCSM ?
Meilleures pratiques autour d'un laboratoire FIM :
Une fois que l'on a compris quels sont les objectifs du laboratoire, il est important d'examiner et d'appliquer les meilleures pratiques suivantes à la conception du laboratoire :
1. Recueillir toutes les exigences avant de construire le laboratoire
- La modification des exigences du laboratoire après sa construction peut nécessiter une reconstruction complète du laboratoire.
2. Les systèmes de laboratoire doivent être séparés des systèmes de production
- Les erreurs de développement peuvent entraîner des problèmes de production
- La possibilité de tester les modifications apportées à la configuration avant le déploiement de la production est limitée.
3. S'il n'y a pas assez de hardware pour construire un véritable laboratoire, envisagez l'utilisation de technologies de virtualisation telles que Hyper-V.
- Moins de hardware nécessaire
- Il est plus facile de créer des sauvegardes ponctuelles de la configuration et de revenir à des configurations antérieures.
4. L'environnement de laboratoire doit comporter une représentation de chaque système auquel le FIM se connectera.
- Une représentation de chaque système que la FIM va gérer
- Les systèmes devraient être de la même plate-forme
- Identifier le niveau de version du système d'exploitation (hotfixes, service packs) et des produits installés
- Les systèmes doivent avoir la même version et les mêmes niveaux de correctifs.
- Le schéma de chaque système doit refléter le système de production (par exemple, le schéma de la base de données SQL, le schéma AD, etc...).
- Maintenir la configuration des systèmes existants (par exemple, configurations Windows Trust, configuration DNS , configuration du site AD, etc...)
- Les systèmes devraient être de la même plate-forme
- Dans une forêt multidomaine, Active Directory doit avoir le même nombre/emplacement de partitions d'annuaire que la production.
- Tous les systèmes pour lesquels FIM peut fournir des objets doivent exister dans le laboratoire. Voici quelques exemples de systèmes supplémentaires que FIM peut gérer :
- Échange
- LYNC
- Accueil Serveurs d'annuaire
5. Outre les systèmes que FIM gérera, des services d'infrastructure supplémentaires sont également nécessaires pour soutenir un réseau fonctionnel. Les services suivants devraient également être pris en considération pour être placés dans le laboratoire :
- DNS
- Système de sauvegarde
- Autorité de certification
- Système de courrier électronique pour les activités de notification de flux de travail
- Référentiel de code (par exemple Team Foundation Server)
- DHCP
- Software Déploiement (SCCM)
- Pare-feu (TMG/UAG) - pour la publication d'applications
6. En fonction de la solution conçue et des exigences en matière d'essais, les systèmes suivants devraient également être pris en compte pour être complets :
- Hardware équilibreur de charge
- UAG/TMG/pare-feu
- Appareils clients (IPADs/IPhones/Smart Phones)
- Possibilité de se connecter à un serveur de courrier électronique externe pour l'OTP
- Possibilité de se connecter à la passerelle SMS pour l'OTP
- Authentification à deux facteurs (RSA/Cartes à puce)
7. Tous les systèmes d'exploitation clients qui doivent être testés avant le déploiement du client FIM
- Système d'exploitation supporté
- OS
- Version (x86 ou x64)
- Niveaux de service pack
- Versions et niveaux de correctifs de Microsoft Office
- Diverses versions du ou des systèmes d'exploitation pris en charge
8. Représentation des données - Lorsque je crée un laboratoire IDM, j'aime exporter les données de production et les importer dans mon environnement de laboratoire afin de pouvoir voir toutes les modifications qui seront apportées aux données existantes.
- Les données doivent être actuelles et pertinentes
- Les données doivent exister à partir d'un instantané dans tous les systèmes afin de permettre l'alignement des données (par exemple, le système RH doit avoir des enregistrements qui peuvent être mis en correspondance avec un compte AD).
- Les données doivent contenir une représentation de toutes les données qui seront importées/exportées dans chaque système.
- Différentes classes d'objets doivent être présentes (par exemple, les utilisateurs, les groupes, les contacts).
- Les objets doivent être placés au même endroit que la production (par exemple, par rapport à la partition du répertoire de l'environnement).
- L'emplacement de production OU des objets : ou=Company Users, dc=prod, dc=company, dc=com se traduirait par ou=Company Users, dc=dev, dc=company, dc=com en développement.
- Les attributs doivent être renseignés avec des valeurs de production (prénom, SN, nom d'affichage, etc...). Cela permet de tester la façon dont les attributs seront modifiés.
- Les comptes d'utilisateurs doivent être compatibles avec la boîte aux lettres afin de faciliter les processus de travail.
9. Qualité des données - Une fois le laboratoire initial construit et alimenté en données, un certain nombre de décisions prises dans le cadre de la conception vous obligeront à examiner les données actuelles afin de déterminer si elles sont suffisantes pour répondre aux décisions de conception.
- Quel sera l'attribut de liaison entre les différents systèmes ? Un attribut de liaison devrait être disponible dans chaque système pour faciliter le processus d'association des objets des différents systèmes (dossier RH, compte AD) à une identité FIM (objet MV).
- Si les données ne sont pas disponibles dans un système, existe-t-il un ou plusieurs autres systèmes pouvant fournir les données d'attribut dont j'ai besoin ?
- Les données sont-elles formatées de manière cohérente ? Des données mal formatées peuvent entraver la logique décisionnelle.
- Quelles sont les données d'attribut nécessaires pour déterminer les droits ?
- Qui est autorisé à posséder un compte ?
- Qui peut disposer d'une boîte aux lettres ?
- Quelles sont les données d'attribut nécessaires pour les règles de provisionnement ?
- Comment le DN est-il déterminé ?
- Comment l'intitulé du compte est-il calculé ?
- Qui reçoit une boîte aux lettres ?
- À quelle base de données sont-elles affectées ?
- Seront-ils approvisionnés pour LYNC ?
- Quelles sont les données d'attributs nécessaires pour les transformations d'attributs ?
- Pour les transformations d'un nom d'affichage, les données d'attribut existent-elles pour construire un nom d'affichage valide ?
- Quelles sont les données d'attribut nécessaires à la personnalisation des applications ?
- Où doit-il exister ?
- Dans quel format les données doivent-elles exister ?
- Quelles sont les données d'attribut nécessaires à la création de groupes basés sur des critères ?
- Quelles sont les données d'attribut nécessaires pour établir des autorisations déléguées ?
- Les MPR qui délèguent des droits à l'aide d'une relation avec un objet. (par exemple, un manager autorisé à mettre à jour les comptes d'utilisateur de ses rapports dans le portail FIM doit renseigner l'attribut "manager" sur chacun de ses rapports).
- Les MPR qui délèguent des droits administratifs exigent que les objets soient dotés d'un ou de plusieurs attributs qui permettront au FIM de les identifier dans des ensembles. Par exemple, pour tous les utilisateurs d'une unité opérationnelle et d'un lieu particuliers, les attributs doivent être renseignés avec l'unité opérationnelle et le lieu de l'utilisateur.
- Les activités de flux de travail, telles que les flux de travail d'approbation du propriétaire, doivent avoir l'attribut de propriétaire affiché rempli avec le propriétaire du groupe.
10. Confidentialité des données
- L'un des systèmes contient-il des données sensibles qui devront être protégées ou masquées ?
- Paiements
- SSN
- Date de naissance
11. Essais
- Comme dans tous les projets de développement, il est utile de séparer le rôle du développeur de celui du testeur. Les testeurs trouvent souvent des moyens de casser le code qui n'ont pas été envisagés par le développeur.
- La construction d'un excellent laboratoire, bien qu'importante, n'est que la première partie du projet. Un plan de test approfondi est nécessaire pour valider que la conception mise en œuvre fait ce que vous voulez.