SharePoint 2010: Definizione dell'ambiente adeguato
Il modo in cui si impostano gli ambienti di sviluppo e di test, nonché i processi può avere significative ripercussioni sulle applicazioni.
Steve Wright e Corey Erkes
Adattato da "Pro SharePoint 2010 Governance" (Apress, 2012)
Nel corso di qualsiasi progetto di grande sviluppo, è necessario gestire diversi tipi di informazioni. È preferibile avere un repository centrale per questa informazione che si integra con gli altri strumenti utilizzati dal team di sviluppo.
Ci sono diversi prodotti per aiutare il vostro team di sviluppo di collaborare e comunicare, e Microsoft Visual Studio Team Foundation Server (TFS) ha vantaggi quando viene utilizzato per lo sviluppo di SharePoint. Esso è strettamente integrato con Visual Studio e SharePoint. Se l'organizzazione non dispone già di un tale strumento e sviluppo di applicazioni principalmente per l'ambiente Microsoft Windows, si dovrebbe considerare TFS.
Indipendentemente dal metodo che scelto e prodotto, ci sono alcune caratteristiche che dovrebbe avere tale piattaforma, tra cui:
- **Controllo del codice sorgente:**Questo mantiene un record di ogni modifica di ogni file di origine nella soluzione. Delle versioni library di SharePoint non sono appropriata per questo scopo. Un sistema di controllo vera fonte supporta molte funzioni di là di una singola sequenza di modifiche apportate ai file di rilevamento.
- **Gestione dei requisiti:**Questa traccia ogni bug, lavoro e file sorgente articolo back to i requisiti a cui è legato.
- **Elementi di lavoro:**Questo registra il bug report, help desk ticket, richieste di funzionalità, comunicati e compiti associati al progetto.
- **Build Automation:**Questo compila i file sorgente in file di soluzione implementabile.
- **Gestione dei test:**Questo registra i casi di test automatizzati e manuali, automatizza la regressione e unit test, gestisce la distribuzione per testare la server farm ed esegue test di carico.
Non tutte le piattaforme di sviluppo squadra sosterrà tutte queste caratteristiche. Tuttavia, il controllo del codice sorgente è una funzione che è assolutamente necessaria per mantenere una stabile applicazione base. Le altre funzioni possono essere più o meno importante a una particolare organizzazione. Può anche essere accettabile per utilizzare strumenti separati, non integrati per quelle funzioni.
Ambienti di sviluppo
Uno degli aspetti più impegnativi di sviluppo di SharePoint è l'istituzione di un ambiente di sviluppo produttivo. Questo si riferisce alla zona dove un singolo sviluppatore può lavorare per creare ed eseguire il debug suoi componenti assegnati o aggiornamenti. SharePoint è una tecnologia server-side, quindi componenti progettati per funzionare su un server SharePoint generalmente devono essere sviluppato anche su uno.
Un errore comune è quello di avere uno "sviluppo server" utilizzato da tutti gli sviluppatori del team. A meno che i membri del team stanno lavorando su componenti totalmente estranei e mai bisogno di fare comuni cose come riavviare IIS o collegare un debugger a un processo IIS, questo tipo di ambiente in generale non funziona bene. Gli sviluppatori hanno bisogno di controllo completo sopra il server per eseguire il debug in modo efficace problemi. Isolando gli sviluppatori da altra è il modo migliore per tenere tutti produttivi.
Un'altra idea sbagliata è che può sviluppare su un sistema client in esecuzione Visual Studio ed eseguire il debug su un server remoto che esegue SharePoint. Mentre è possibile eseguire il debug di una soluzione SharePoint in esecuzione su un altro server, è necessario avere ancora installato sul sistema di compilazione di codice lato server SharePoint SharePoint. Le librerie che utilizza il codice sul lato server sono disponibili solo su un server SharePoint. Non li hai installato separatamente su un computer client per consentire al codice di essere compilato. Se si stanno sviluppando applicazioni client utilizzando solo il nuovo oggetto modelli Client (Client OMs) introdotto con SharePoint 2010, è possibile compilare su un sistema che non ha installato SharePoint.
Un ambiente di sviluppo SharePoint minimo dovrebbe includere i seguenti:
- Un sistema operativo Windows a 64 bit compatibile con SharePoint 2010 (Windows 2008, Windows Vista SP1 o Windows 7)
- Visual Studio 2010
- SQL Server Express Edition
- Componenti Server o SharePoint Foundation come necessario
I seguenti strumenti sono spesso utili e si dovrebbe includere questi quando possibile:
- Applicazioni di Microsoft Office
- SQL Server Developer Edition
- Microsoft Visio
- InfoPath Designer
- SharePoint Designer (download gratuito)
Hai anche diverse opzioni da considerare per quanto riguarda dove si installano questi strumenti. L'opzione prima e più semplice è quello di caricare tutti gli strumenti e SharePoint direttamente sul computer dello sviluppatore. Questo richiede un sistema operativo a 64 bit compatibile con SharePoint. Questa configurazione è facile da usare perché tutti gli strumenti necessari sono facilmente reperibili.
Purtroppo, questa configurazione è limitata dalla potenza del computer desktop, l'immagazzinaggio di disco rigido e il fatto che è possibile utilizzare solo una configurazione di SharePoint. Uno sviluppatore che frequentemente si muove tra progetti potrebbe trovare questo tipo di configurazione difficile da gestire.
Opzioni di ambiente di sviluppo
L'opzione successiva è quello di utilizzare un prodotto di virtualizzazione del desktop come Oracle VirtualBox o VMware Workstation. Ancora una volta, è necessario essere certi che qualunque strumento di virtualizzazione utilizzato supporta guest a 64-bit OS. Questa configurazione ha molte delle stesse limitazioni come installare direttamente l'ambiente sul desktop. In genere, le prestazioni non sono molto buona e avrete bisogno di file disco di grandi dimensioni per supportare la virtualizzazione del desktop.
Il vantaggio di questo tipo di ambiente è che ti consente di ospitare più configurazioni di SharePoint in separata macchine virtuali (VM) sul desktop stesso. In genere, requisiti di memoria e prestazioni non consentono di eseguire più di una VM alla volta, tuttavia.
È anche possibile creare un file disco rigido virtuale (VHD) ed eseguirlo direttamente sul sistema senza passare attraverso un prodotto di virtualizzazione del desktop. Questo è simile alla vecchia configurazione "dual-boot" per un sistema. Invece di usare una partizione separata per il secondo sistema operativo, utilizzare un file VHD all'interno del sistema di file OS esistente. Questa configurazione ha il vantaggio dell'utilizzo di hardware del sistema senza la necessità di un secondo OS in esecuzione per ospitare il server di sviluppo.
L'unico svantaggio è che tutte le applicazioni caricate sul client di desktop OS non sono disponibili durante l'esecuzione dell'ambiente di sviluppo. Questo sta diventando rapidamente la configurazione più popolare per gli sviluppatori SharePoint perché fornisce la flessibilità della virtualizzazione del desktop senza dover sostenere i costi delle prestazioni. Per ulteriori informazioni sull'esecuzione di più sistemi operativi con la nuova configurazione di avvio di Windows 7, vedere dei Keith Combs post di blog, "Dual Boot da VHD utilizzando Windows 7 e Windows Server 2008 R2."
La configurazione finale utilizza la virtualizzazione dei server. Questo potrebbe essere Microsoft Hyper-V, VMWare o qualsiasi altro prodotto di virtualizzazione server. Questa è un'opzione eccellente per un'impresa con un'infrastruttura di virtualizzazione buona. Una macchina virtuale su un server host macchina virtuale il provisioning e utilizzare tale server a casa l'ambiente di sviluppo intero.
Utilizzando un client di Remote Desktop Protocol (RDP), il vostro sviluppatore ha accesso a un ambiente completo senza apportare eventuali modifiche o installazioni sul suo ambiente locale. L'unico svantaggio con questa configurazione è che si deve essere in grado di connettersi al server VM per eseguire attività di sviluppo. Non si può "prendere esso con voi."
Ambienti di test
Una volta completato lo sviluppo, dovrete mettere l'applicazione attraverso un regime di prova rigoroso, ben definito. Questo richiede che si carica in uno o più ambienti non di produzione prima della distribuzione di produzione. Questi ambienti vanno da molti nomi, tra cui integrazione, test, stage, test di accettazione utente (UAT), pre-produzione, e così via.
Si potrebbe usare una farm di integrazione per testare tutti i componenti compilati in un ambiente che non contiene tutti gli strumenti di sviluppo. La presenza di Visual Studio o altri strumenti di sviluppo su un sistema a volte può mascherare gli errori che si verificano solo quando tali strumenti non sono disponibili.
Una volta che il rilascio è testato, consegnarlo per il gruppo di assicurazione di qualità, o qualunque dipartimento è responsabile dell'UAT. Quindi quel gruppo di test verrà caricato il rilascio per la fattoria di pre-produzione. Questa fattoria dovrebbe essere simile alla fattoria produzione possibile aiutare il gruppo di test valutare readiness produzione di rilascio.
Ad esempio, se l'azienda di produzione ha più server Web front-end, così, troppo, dovrebbe pre-farm. Server virtuali sono spesso sostituiti per server fisici rendere gli ambienti di test più redditizio. Una volta UAT è completo, è possibile distribuire l'applicazione per la server farm di produzione finale.
Quando si prova una nuova release, è importante utilizzare contenuto come simile al contenuto in produzione come possibile. Ad esempio, se un utente ha personalizzato qualche elemento in un sito della farm di produzione che interferisce con una modifica apportata all'applicazione, si potrebbe non notare se il cambiamento è solo testato contro dati test "fasullo". Un'ottima fonte di dati contenuti realistici per il test è la server farm di produzione. Si può facilmente eseguire il backup e ripristinare i database del contenuto di produzione negli ambienti di prova nella maggior parte dei casi.
Un'altra configurazione comune per il testing e la distribuzione di applicazioni di SharePoint è possibile utilizzare una server farm di gestione temporanea. Con questa tecnica, ci sono due completo server farm, sempre in esecuzione. Gli altri stand ricevere la nuova release e gli utenti utilizzano uno. Una volta che il rilascio è distribuito per la farm di gestione temporanea, la rete è riconfigurata per instradare il traffico in entrata per la farm di gestione temporanea. Così, il server di gestione temporanea diventa la produzione e i server di produzione passa alla messa in scena.
Questa è una tecnica utile per i siti Web pubblico su cui non è permesso di inattività. Il tempo necessario per sostituire la server farm è solo finchè prende per reindirizzare il traffico di rete. Ovviamente, è fondamentale che tutti gli aggiornamenti contenuti di produzione vengono spostati per la farm di gestione temporanea prima di distribuire la nuova release. Per impedire gli aggiornamenti dopo il contenuto inizia a essere copiato, SharePoint consente temporaneamente bloccare i database del contenuto.
Quando si utilizza questa tecnica, l'ambiente di gestione temporanea può anche servire come un hot standby per l'azienda di produzione. Se la produzione subisce un guasto catastrofico, si può rapidamente portare il server di gestione temporanea per ripristinare il servizio. Se questo è parte del vostro piano di disaster recovery, si devono copiare regolarmente contenuti di produzione per la farm di gestione temporanea, anche quando non sono distribuzione di nuove versioni. Può anche essere utile avere le fattorie di produzione e messa in scena ospitate in luoghi fisici separati per fornire ridondanza di posizione. Qualsiasi di queste tecniche e configurazioni può aiutare a sviluppare un ambiente di sviluppo di SharePoint che meglio si adatta alle vostre esigenze e risorse.
.jpg)
Steve Wright è un senior manager nella gestione di business intelligence (BIM) per Sogeti USA LLC in Omaha, Neb Negli anni ultimi coltivano, Wright ha lavorato sul controllo del traffico aereo, finanziario, assicurativo e una moltitudine di altri tipi di sistemi. Ha creato ed eseguite valutazioni tecniche per molti titoli precedenti riguardanti prodotti Microsoft, tra cui Windows, SharePoint, SQL Server e BizTalk.
.jpg)
Corey Erkes è un consulente di gestione per Sogeti USA LLC in Omaha, Neb Erkes ha lavorato con una vasta gamma di aziende in diversi punti del ciclo di vita delle loro implementazioni di SharePoint. Egli è anche uno dei membri fondatori del gruppo di utenti SharePoint Omaha.
© 2012 Apress Inc. Tutti i diritti riservati. Stampato con il permesso da Apress. Copyright 2012. "Pro 2012 Governance di SharePoint" da Steve Wright e Corey Erkes. Per ulteriori informazioni su questo titolo e altri libri simili, si prega di visitare apress.com.