[MOSS 2007] Modes de livraison

Bonjour,

il y a certainement autant de méthodes que environnements et de besoins,
exemples:
Pour les solutions, les features et le branding, STSADM (extension incluses)
pour les modifications de contenu en bulk: du code simplement à éxécuter, du
code-callout, du scripting PowerShell, des content deployment jobs...
Pour de l'upload de documents et autres en bulk (images...): le
mini-redirecteur WebDAV fait des merveilles et semble "habituel" aux system
engineers...

... Oui je sais, cela ne constitue pas LA réponse ultime :)
Que devez vous déployer exactement? Et dans quel cadre Quelle est la
maturité du processus DTAP? Avez-vous des outils tiers pour vous aider à
l'heure actuelle?

--
Marc
[Heureux celui qui a pu pénétrer les causes secrètes des choses]



"Houdini" <Houdini@discussions.microsoft.com> wrote in message
news:475E13B7-05BF-4E6E-8FCA-DB4DD1050164@microsoft.com...

Bonjour à toutes et à tous,

Dans la vraie vie et hors formations et maquettes, comment s'effectue les
livraisons des solutions MOSS 2007 ? Comment faites-vous (retour
d'expériences) pour livrer les applications et solutions ?

Nous avons demandé à plusieurs consultants (dont MS) et personne n'est
capable à ce jour de nous donner des méthodes fiables, sécurisées et
simples
de mise en oeuvre. Les cours de formations officielles et non officielles
n'apportent rien de plus.

Par exemple, comment mettre en production: collection de site, site,
contenu
...
Déployer des solutions avec STSADM, cela fonctionne, déployer des features
aussi, mais comment déployer des portions de sites ? comment faire des
livraisons de mises à jour ? Faut-il créer des templates de sites
(structures
+ contenu + autorisations) et s'en servir pour livrer ? .....

Merci d'éclairer ma lanterne la-dessus, j'ai déjà visité plusieurs sites
US,
c'est vraiment aléatoire les méthodes de livraison et personne n'est
vraiment
au point la-dessus. Si vous avez des "best practices de livraison" (des
vraies), merci d'avance pour les pistes.

Cordialement,
Houdini

Bonjour Marc,

Merci pour tous ces précieux renseignements. Je navigue en eaux troubles
avec un client à qui les hautes instances ont imposé Moss à contre coeur.
Bref pas facile.

Nous comptons utiliser des sites Wiki, collaboratifs, CMS, un peu tous les
types de solutions qu'offre Moss. Au final, il faudrait pouvoir créer des
méthodes de livraison, d'installation et de déploiement "identiques" pour
tous ces projets. Est-ce jouable, de part votre expérience ? (même chez MS,
ils ne sont pas d'accord ou bottent en touche)

Nous n'avons pas de budjet pour utiliser des outils tiers, mais l'équipe de
développement a créé des outils pour déployer notamment des solutions, des
webparts, des modifications d'autorisations. Le hic, c'est qu'il n'y pas de
solutions automatiques. Au final, les passages entre "recette, préprod et
prod" doivent s'effectuer le plus simplement possible, avec le moins de
manips pour les intégrateurs et le personnel de production en charge des
déploiements.

Actuellement, nous devons manuellement créer une collection de sites, puis
lancer les solutions de livraisons (feature, solutions) développées (qui
fonctionnent très bien).

Par contre, en terme de livraison de contenu, on est "à poil". La seule
chose que l'on puisse faire actuellement, c'est faire du "backup/restore",
mais je trouve que ce n'est pas très "pro".

Je ne connais pas les termes "code call-out", "branding" et qu'est-ce que le
mini redirecteur Webdav ?

En terme de déploiement de contenu, que pourrions-nous envisager ?

Nous avions pensé à faire des modèles de sites complets (.stp), à les
backuper et à les restorer. C'est peut-être valable une première fois, mais
si l'on veut faire des mise à jour, cela n'est peut-être pas valable ?

je suis conscient qu'il n'y a pas de solutions miracles, mais qu'il doit
certainement exister des solutions autres, j'espère assez simple à mettre en
place, pour qu'au final, on pousse un bouton et hop, tout se déploie.

Au passage, avez-vou sdéjà utilisé cet outil ?
SPDeploymentWizard basé sur la Content Migration API (PRIME)

Merci d'avance pour votre aide.
Cordialement,
Houdini
-----------------------------------------
"Lognoul, Marc (Private)" a écrit :

Bonjour,

il y a certainement autant de méthodes que environnements et de besoins,
exemples:
Pour les solutions, les features et le branding, STSADM (extension incluses)
pour les modifications de contenu en bulk: du code simplement à éxécuter, du
code-callout, du scripting PowerShell, des content deployment jobs...
Pour de l'upload de documents et autres en bulk (images...): le
mini-redirecteur WebDAV fait des merveilles et semble "habituel" aux system
engineers...

... Oui je sais, cela ne constitue pas LA réponse ultime :)
Que devez vous déployer exactement? Et dans quel cadre Quelle est la
maturité du processus DTAP? Avez-vous des outils tiers pour vous aider à
l'heure actuelle?

--
Marc
[Heureux celui qui a pu pénétrer les causes secrètes des choses]



"Houdini" <Houdini@discussions.microsoft.com> wrote in message
news:475E13B7-05BF-4E6E-8FCA-DB4DD1050164@microsoft.com...
> Bonjour à toutes et à tous,
>
> Dans la vraie vie et hors formations et maquettes, comment s'effectue les
> livraisons des solutions MOSS 2007 ? Comment faites-vous (retour
> d'expériences) pour livrer les applications et solutions ?
>
> Nous avons demandé à plusieurs consultants (dont MS) et personne n'est
> capable à ce jour de nous donner des méthodes fiables, sécurisées et
> simples
> de mise en oeuvre. Les cours de formations officielles et non officielles
> n'apportent rien de plus.
>
> Par exemple, comment mettre en production: collection de site, site,
> contenu
> ...
> Déployer des solutions avec STSADM, cela fonctionne, déployer des features
> aussi, mais comment déployer des portions de sites ? comment faire des
> livraisons de mises à jour ? Faut-il créer des templates de sites
> (structures
> + contenu + autorisations) et s'en servir pour livrer ? .....
>
> Merci d'éclairer ma lanterne la-dessus, j'ai déjà visité plusieurs sites
> US,
> c'est vraiment aléatoire les méthodes de livraison et personne n'est
> vraiment
> au point la-dessus. Si vous avez des "best practices de livraison" (des
> vraies), merci d'avance pour les pistes.
>
> Cordialement,
> Houdini

Bonjour,

<disclaimer>Mes propose n'engagent que moi. toutes les solutions proposées
sont à tester et valider</disclaimer>

Merci pour tous ces précieux renseignements. Je navigue en eaux troubles
avec un client à qui les hautes instances ont imposé Moss à contre coeur.
Bref pas facile.

Nous comptons utiliser des sites Wiki, collaboratifs, CMS, un peu tous les
types de solutions qu'offre Moss. Au final, il faudrait pouvoir créer des
méthodes de livraison, d'installation et de déploiement "identiques" pour
tous ces projets. Est-ce jouable, de part votre expérience ? (même chez
MS,
ils ne sont pas d'accord ou bottent en touche)

Pour un client qui agit à cœur, cela en fait du contenu :)
D'un manière générale, je ne vois pas de problème à déployer des templates,
code, web part et branding via STSADM et des fichier wsp.
Quelles sont les objections opposées? Quelles sont les besoins qui ne sont
pas rencontrés par cette méthode?

Nous n'avons pas de budjet pour utiliser des outils tiers, mais l'équipe
de
développement a créé des outils pour déployer notamment des solutions, des
webparts, des modifications d'autorisations. Le hic, c'est qu'il n'y pas
de
solutions automatiques. Au final, les passages entre "recette, préprod et
prod" doivent s'effectuer le plus simplement possible, avec le moins de
manips pour les intégrateurs et le personnel de production en charge des
déploiements.

Il est relativement aisé de déployer automatiquement via STSADM, à condition
que les fichiers soit correctement générés. Mais encore une fois, tout
dépends des besoins, contraintes etc...

Actuellement, nous devons manuellement créer une collection de sites, puis
lancer les solutions de livraisons (feature, solutions) développées (qui
fonctionnent très bien).

Tous cela est automatisable, via STSADM ou via code, voire PowerShell

Je ne connais pas les termes "code call-out", "branding" et qu'est-ce que
le
mini redirecteur Webdav ?

Le code call-out, c'est une manière de déployer des modification à un site
en déployant une feature, qui, lorsque le site sera utilisé, permettre
exécuter du code pour effectuer la MAJ.
Le branding : modification du look and feel (master pages, css, images...)
Le mini redirecteur Webdav est un client webdav complètement intégré à
Windows (aussi connu sous le nom de Web Folder), qui permet non seulement
d'accéder à un serveur utilisant le protocol WebDAV (comme SharePoint) via
des applications client classique (browser...) mais également via la ligne
de commande: net use z: http://MOSSSERVER/Site01/Doclib01. C'est
particulièrement pratique pour charger du contenu de type document, images
etc...

Nous avions pensé à faire des modèles de sites complets (.stp), à les
backuper et à les restorer. C'est peut-être valable une première fois,
mais
si l'on veut faire des mise à jour, cela n'est peut-être pas valable ?

Le code call-out pourrait peut être une solution dans ce cas de figure. il
est également possible de scripter des modification de sites "à la volée"
avec PowerShell.

J'en profite pour recommander, mais ça n'engage que moi, d'utiliser pour les
templates, solutions, features etc une convention de nom et de version bien
conçue, visible dans l'interface (cela aide aussi l'utilisateur dans
certains cas) et utilisable dans le future pour déployer des MAJ ou
effectuer des inventaires.

je suis conscient qu'il n'y a pas de solutions miracles, mais qu'il doit
certainement exister des solutions autres, j'espère assez simple à mettre
en
place, pour qu'au final, on pousse un bouton et hop, tout se déploie.

Voici un exemple de ce qui se passe chez un client:
Une fois les fichiers WSP finalisé, cad prêts pour la production, ils sont
copiés sur un shared folder. L'administrateur MOSS édite un petit fichier de
config qui contient qq instructions d'installation succinctes
Tous les soirs, une tâche tournant sur tous les WFEs, lit ce fichier de
config, installe les packages via STSADM, reset IIS si nécessaire et rapport
le statu de l'installation par mail et par SCOM
Système identique pour les MAJ: livraison de feature et automatisation de la
même manière
C'est simple, automatique et fiable MAIS cela sous entend que l'équipe de
développement livre les solution sous forme de WSP

Au passage, avez-vou sdéjà utilisé cet outil ?
SPDeploymentWizard basé sur la Content Migration API (PRIME)

A ma connaissance, cet outil permet uniquement de "facilement" transférer du
contenu, ce qui n'est déjà pas mal, c'est vrai:).
D'une manière générale, je pense que toutes les solution proposée sur
codeplex sont intéressante mais nécessitent souvent un sérieux effort de
"finition" et adaptation pour est 100% utilisables et donc "vendables".

--
Marc
[Heureux celui qui a pu pénétrer les causes secrètes des choses]

Bonjour Marc,

Pour ce qui est du PowerShell, je ne pourrais pas l'utiliser (c'est bien
dommage, je l'utilise depuis
les versions non officielles, mais le client ne souhaite pas s'investir dans
cette technologie, peut-être dans quelques années).

Les templates, features et solutions sont nommées de manière très précise par
le comité de développement.

L'architecture est la suivante (encore que pas très bien définie)
BDD (1 serveur SQL 2005) sera transformé par la suite en cluster
Dev/Recette (1 serveur avec tous les rôles)
Préproduction (2 FWE, 1 index)
Production (2 FWE, 1 index)

La création de la ferme, des bases, de la collection de site est pour
l'instant manuelle,
Les sites, sous-sites, sous-sous-sites, templates, features sont automatisés
via un
outil à base de stsadm.

La mise a jour des sites, des features, templates est plus problématique.
Les développeurs
n'utilisent pas le "code call-out", cela leur a été formellement déconseillé
par les
consultants MS de chez MS. Pour une mise à jour, on supprime tout et on
recommence.
Je ne sais pas si cela est très rentable, mais les raisons invoquées par MS
ne sont pas
claires ... d'autant qu'ils ne nous ont pas explicitement dit pourquoi ....

En ce qui concerne le contenu, c'est une autre équipe qui le gère, en
utilisant
directement un éditeur "RadEditorMoss v4.5.3" (celui fourni avec Moss étant
complètement buggé pour cette utilisation). L'utilisateur n'a pas pour
l'instant la
main sur le contenu.

Si on doit faire des mises à jour, actuellement, on supprime et on recrée
si on doit transférer entre serveurs, les solutions Backup/Restore,
éventuellement
STSADM sont les seules solutions, à moins d'utiliser des outils commerciaux.

Ce que je cherche aussi c'est la possibilité de pouvoir mettre à jour un
sous-site,
de restaurer uniquement une partie d'un site ou un lien.

Le but est de simplifier aussi bien la livraison que l'exploitation ou la
mise à
jour, sachant que ces solutions sont mises en production par des personnels
qui ne
connaissent pas Moss, ce sont de simples exécutants.

Cordialement,
Houdini


"Houdini" a écrit :

Bonjour à toutes et à tous,

Dans la vraie vie et hors formations et maquettes, comment s'effectue les
livraisons des solutions MOSS 2007 ? Comment faites-vous (retour
d'expériences) pour livrer les applications et solutions ?

Nous avons demandé à plusieurs consultants (dont MS) et personne n'est
capable à ce jour de nous donner des méthodes fiables, sécurisées et simples
de mise en oeuvre. Les cours de formations officielles et non officielles
n'apportent rien de plus.

Par exemple, comment mettre en production: collection de site, site, contenu
...
Déployer des solutions avec STSADM, cela fonctionne, déployer des features
aussi, mais comment déployer des portions de sites ? comment faire des
livraisons de mises à jour ? Faut-il créer des templates de sites (structures
+ contenu + autorisations) et s'en servir pour livrer ? .....

Merci d'éclairer ma lanterne la-dessus, j'ai déjà visité plusieurs sites US,
c'est vraiment aléatoire les méthodes de livraison et personne n'est vraiment
au point la-dessus. Si vous avez des "best practices de livraison" (des
vraies), merci d'avance pour les pistes.

Cordialement,
Houdini

Bonjour,

L'architecture est la suivante (encore que pas très bien définie)
BDD (1 serveur SQL 2005) sera transformé par la suite en cluster
Dev/Recette (1 serveur avec tous les rôles)
Préproduction (2 FWE, 1 index)
Production (2 FWE, 1 index)

Si je comprends bien, tous les environnement utilisent le même serveur de
BDD?
Sans tenir compte du contexte que je ne connais pas, je dirais que c'est
risqué à plusieurs titre: conflit entre les différents environnements
(utilisation des mauvaises BDD), impacte sur les performances, sécurité...

La création de la ferme, des bases, de la collection de site est pour
l'instant manuelle,
Les sites, sous-sites, sous-sous-sites, templates, features sont
automatisés
via un
outil à base de stsadm.

La mise a jour des sites, des features, templates est plus problématique.
Les développeurs
n'utilisent pas le "code call-out", cela leur a été formellement
déconseillé
par les
consultants MS de chez MS. Pour une mise à jour, on supprime tout et on
recommence.
Je ne sais pas si cela est très rentable, mais les raisons invoquées par
MS
ne sont pas
claires ... d'autant qu'ils ne nous ont pas explicitement dit pourquoi
....

Encore une fois, je ne connais pas environnement ni ses contraintes: tout
supprimer et recommencer cela fonctionne hors production mais quid de la
production? Qu'en pense le business et les utilisateurs?

de restaurer uniquement une partie d'un site ou un lien.

Cela me parait difficile sans développement ou outil tiers.

--
Marc
[Heureux celui qui a pu pénétrer les causes secrètes des choses]

PS: la bonne nouvelle, c'est qu'avec le pseudo que vous utilisez, il ne vous
sera facile de vous échapper de tout cela :)

Bonjour Marc,

Merci pour ces précisions. Chaque environnement possède, à l'heure actuelle,
le même serveur BDD (pour éviter que chacun créé des bases dans tous les
coins). A terme, "normalement", chacun aura son environnement BDD, sauf la
préprod et la prod qui seront sur un cluster 2005.

Les utilisateurs n'ont pas leur mot à dire et personne ne leur a demandé
leur avis. La décision de prendre Moss s'est faite ailleurs, sans
consultation et sans rien demander à ceux qui développent et qui
l'exploitent. Pas plus qu'il n'y a de spécifications ou de cahier des
charges. ... le principe, c'est : débrouillez-vous, faut que ça marche. ...
Avec cela, ce n'est pas facile. Business = direction. Même les coordinateurs
ne savent pas vendre cette solution à leurs directions.

Je suis d'accord: hors production pure et dure, on fait ce que l'on veut. En
production, c'est risqué. Je dois étudier toutes les solutions "magiques"
(les payantes ne sont pas prévues au budget) ... Même les consultants MS ne
se mouillent pas et ils ont peut-être bien raison de ne pas tomber dans le
chaudron.

Ils ont appelé un magicien .... mais j'ai plus d'un tour dans ma besace.
Cordialement,
Houdini

"Lognoul, Marc (Private)" a écrit :

Bonjour,
> L'architecture est la suivante (encore que pas très bien définie)
> BDD (1 serveur SQL 2005) sera transformé par la suite en cluster
> Dev/Recette (1 serveur avec tous les rôles)
> Préproduction (2 FWE, 1 index)
> Production (2 FWE, 1 index)
Si je comprends bien, tous les environnement utilisent le même serveur de
BDD?
Sans tenir compte du contexte que je ne connais pas, je dirais que c'est
risqué à plusieurs titre: conflit entre les différents environnements
(utilisation des mauvaises BDD), impacte sur les performances, sécurité...

> La création de la ferme, des bases, de la collection de site est pour
> l'instant manuelle,
> Les sites, sous-sites, sous-sous-sites, templates, features sont
> automatisés
> via un
> outil à base de stsadm.
>
> La mise a jour des sites, des features, templates est plus problématique.
> Les développeurs
> n'utilisent pas le "code call-out", cela leur a été formellement
> déconseillé
> par les
> consultants MS de chez MS. Pour une mise à jour, on supprime tout et on
> recommence.
> Je ne sais pas si cela est très rentable, mais les raisons invoquées par
> MS
> ne sont pas
> claires ... d'autant qu'ils ne nous ont pas explicitement dit pourquoi
> ....
Encore une fois, je ne connais pas environnement ni ses contraintes: tout
supprimer et recommencer cela fonctionne hors production mais quid de la
production? Qu'en pense le business et les utilisateurs?

> de restaurer uniquement une partie d'un site ou un lien.
>
Cela me parait difficile sans développement ou outil tiers.

--
Marc
[Heureux celui qui a pu pénétrer les causes secrètes des choses]

PS: la bonne nouvelle, c'est qu'avec le pseudo que vous utilisez, il ne vous
sera facile de vous échapper de tout cela :)