Aggiornamento sito Sharepoint

Premetto che sono nuovo dello sviluppo in questo ambiente, quindi spero
passerete sopra a delle cretinate che probabilmente scrivero'.
Abbiamo sviluppato un sito in un ambiente dedicato allo sviluppo.
Per permettere agli utenti di provare le varie funzionalita' abbiamo
allestito un ambiente di collaudo.
Tutte le volte che abbiamo fatto qualche modifica in sviluppo, abbiamo poi
portato il sito "pulito" nell'ambiente di collaudo, sovrascrivendo quindi i
dati di prova che gli utenti avevano inserito.
Naturalmente nessun problema per questo in questa fase del progetto.
Dopo varie peripezie stiamo portando il sito definitivo nell'ambiente di
produzione.
Naturalmente ci sara' la necessita' di correggere qualcos'altro.
Come dovremo portare le modifiche fatte in sviluppo e provate in collaudo
nell'ambiente di produzione senza perdere i dati inseriti nel corso del
tempo dagli utenti ?
Spero di essermi spiegato.
Grazie.
Fabio

Ciao Fabio.

Urca che domanda da 1M di dollari :-P

Provo a scriverti due righe, sapendo che non possono essere nemmeno vicine
alla completezza che questo argomento richiede.

Innanzitutto una considerazione.
Le "personalizzazioni" che si possono apportare ad un sito SharePoint
possono essere catalogate in base a criteri diversi.
Uno di questi, molto macroscopico ma utile in questa discussione, discrimina
fra:
1. Modifiche che sono memorizzare nei content db
2. Modifiche che sono apportate a livello di file system dei server membri
della farm.

Per chiarire con un esempio, se sviluppi una web part, al di là dei file
necessari per renderla "visibile" e "utilizzabile", stai scrivendo codice,
che viene compilato in assembly e distribuito nella GAC o nella bin folder
del/dei front-end. In questo caso ricadiamo nel punto 2.

Altro discorso va fatto, ad esempio, per la creazione di liste, campi,
content-type.
Se utilizzi il browser (o SharePoint Designer) per creare quel tipo di
artefatti, stai andando a modificare "live" il database che ospita la
site-collection su cui stai operando.

Di conseguenza, nel momento in cui ti trovi a dover "spostare" le tue
personalizzazioni da un ambiente ad un altro, sei di fronte ad un punto
critico.
1. Puoi certamente effettuare backup/restore (o import/export). Chiaramente
però in quel caso vai a sovrascrivere il contenuto presente nel sito target.
2. Ripeti le personalizzazioni da capo, eventualmente apportando modifiche a
strutture già create da un deploy precedente: ad esempio agguingi una
colonna ad una lista o modifichi una master page.

Il punto è critico perchè:
1. Import / Export sovrascrivono i contenuti del db target: ma nel db sono
memorizzati tanto i dati (che tu giustamente vorresti preservare intatti)
che la struttura (che invece vorresti aggiornare in maniera non
distruttiva).
2. Beh... è chiaro che il "rifai tutto" non è una gran soluzione :-D

Soluzioni?
Certamente.
Nessuna perfetta, tutte richiedono una learning curve talvolta ripida.
E' ciò che rende lo sviluppo in SharePoint talvolta "complicato": è
complicato per l'approccio, non per le tecniche :-)

Provando a darti risposta, e riassumendo quindi il punto da cui siamo
partiti, servirebbe un modo per:
1. Definire le modifiche e le personalizzazioni tramite file (XML, sorgenti
da cui ricavare assembly, JS, CSS, (X)HTML, ...)
2. Effettuare il packaging di tali file in modo da poter distribuire le
personalizzazioni

Il punto 1 ricade sotto il nome di "Feature".
Le feature sono un meccanismo di attivazione delle modifiche agli ambienti
SharePoint.
Tramite feature puoi definire, ad esempio, site column, content type e list
definitions. Puoi effetturare il provisioning di file (.aspx, .master, css,
....) a livello di singolo web. Puoi personalizzare diversi aspetti
dell'interfaccia utente aggiungendo voci di menu o link in pagine
amminstrative. E puoi "agganciare" codice custom se quanto presente
out-of-the-box non ti è sufficiente.
Qui (http://msdn.microsoft.com/en-us/library/ms460318.aspx) trovi davvero
molte informazioni.

Il punto 2 ricade sotto il nome di "Solution" (WSP Packages).
Un package wsp è un archivio (cab) contenente i file (ad esempio... quelli
che compongono le feature :-)) che vuoi distribuire, unitamente ad un file -
manifest.xml - che istruisce l'engine di deploy in maniera opportuna.
Qui (http://msdn.microsoft.com/en-us/library/aa543214.aspx) di nuovo trovi
un po' di info.

Ti segnalo, infine, questo articolo su MSDN:
http://msdn.microsoft.com/en-us/library/bb428899.aspx.
Sono le indicazioni che MS dà relativamente allo sviluppo "in team" su
SharePoint.
Molte delle problematiche legate al team-based development si applicano al
più generale processo di sviluppo in SharePoint.

Ripeto, sono questioni non proprio banali.
Trovi in giro per la rete una discreta quantità di materiale (in qualche
occasione ho trattato questi argomenti anche nel mio blog).
Prova a leggere anche:
http://msdn.microsoft.com/en-us/shar.../cc990283.aspx
http://www.codeplex.com/spg/ (moooooolto consigliato)

Ok...
Spero di esserti stato di aiuto.

Ciao


--
Claudio Brotto
MVP Windows SharePoint Services
Microsoft Certified Trainer
https://mvp.support.microsoft.com/pr...Claudio.Brotto
Read my blog *** http://blogs.devleap.com/devlizard




"Fabio" <fplat***tin.it> wrote in message
news:unrEF1OeJHA.4040***TK2MSFTNGP03.phx.gbl...
> Premetto che sono nuovo dello sviluppo in questo ambiente, quindi spero
> passerete sopra a delle cretinate che probabilmente scrivero'.
> Abbiamo sviluppato un sito in un ambiente dedicato allo sviluppo.
> Per permettere agli utenti di provare le varie funzionalita' abbiamo
> allestito un ambiente di collaudo.
> Tutte le volte che abbiamo fatto qualche modifica in sviluppo, abbiamo poi
> portato il sito "pulito" nell'ambiente di collaudo, sovrascrivendo quindi
> i dati di prova che gli utenti avevano inserito.
> Naturalmente nessun problema per questo in questa fase del progetto.
> Dopo varie peripezie stiamo portando il sito definitivo nell'ambiente di
> produzione.
> Naturalmente ci sara' la necessita' di correggere qualcos'altro.
> Come dovremo portare le modifiche fatte in sviluppo e provate in collaudo
> nell'ambiente di produzione senza perdere i dati inseriti nel corso del
> tempo dagli utenti ?
> Spero di essermi spiegato.
> Grazie.
> Fabio

Grazie dei suggerimenti.

Fabio