Discussione 'Migliorare il suporto per la condivisione di progetti e il debug di gruppo'

Migliorare il suporto per la condivisione di progetti e il debug di gruppo

Salve,

Mi chiamo Roberto e mi sto occupando dello sviluppo di un sito Web che fornisce servizi di varia natura per l'azienda per la quale lavoro.
In particolar modo sto effettuando il restiling del sito per adattarlo alle nuove modifiche apportate alla banca dati presente su SQL Server 2000.
L'attuale veste del sito è completamente creata in ASP.
Vista la notevole quantità di cambiamenti apportati alla banca dati ho pensato di sviluppare ex novo il sito sfuttando a tal proposito il nuovo ASP.NET. Dopo un' inizio sconfortante, data la natura delle diversità sintattiche e strutturali del linguaggio ho avuto modo di verificare che le potenzialità offerte da ASP.NET erano di ben lunga superiori rispetto a quelle offerte da ASP come linguaggio di script, oltretutto non compilato. Ho scoperto inoltre che è possibile scrivere pagine .NET strutturate in due modi differenti. Il primo modo prevede di inserire il codice di script (così definito anche se tale non lo è più) nella stessa pagina contenente il codice HTML e i relativi WEB FORM. Il secondo, invece, quello di separare il codice di script in un file *.cs o *.vb (code-behind).
Raccolte tutte le informazioni necessarie ho cominciato qundi a sviluppare il mio progetto utilizzando Visual Studio.NET, scoprendo mio malgrado che non forniva pressochè alcun supporto per lo sviluppo di pagine ASP.NET con codice C# + WEB FORM, ma completo supporto per le pagine con codice separato.
Essendo il sito composto da numerose pagine web mi sono visto costretto all'utilizzo di tale Tool della Microsoft che mi permetteva di oganizzare e strutturare la varie pagine.
Il primo enorme impedimento però l'ho visto quando ho copiato il progetto dal server di test al server di pubblicazione e mi sono permesso di modificare una riga di codice direttamente sul server di pubblicazione! Infatti non riuscivo a vedere la modifica, pur essendo certo di averla effettuata! Mi sono qundi cimentato nella lettura della documentazione MSDN ed ho scoperto che per far visualizzare le modifiche dovevo ricompilare il progetto dalla riga di comando, operazione effettuata con successo, se non fosse che tutte le Session impostate andavano a farsi benedire, dovendo in tal modo effettuare nuovamente il login....!
Non solo, se invece creo le pagine ASP.NET con il relativo codice C# + etc. (cioè codice inline) naturalmente i file si compilano da soli, e mi sembra che le session non scadano! Scusate se è poco. La Microsoft quandi ha creato un ambiente (Visual Studio.Net) che è stato pensato solo per lo sviluppo di un sito ma non per il mantenimento! Pensiamo soltanto se dovo effettuare una serie di modifiche con una certa frequenza dal server di test al server di pubblicazione, gli utenti connessi (non uno o dieci ma centinaia) sarebbero costretti ad effettuare il login costantemente! Questo non mi sembra alquanto produttivo!

A tal proposito, dopo questa estenuante lettura mi chiedo (ma naturalmente rigiro le domande): devo abbandonare Visual Studio.NET per uno schernito e poco produttivo WEB Matrix?
Oppure ci sono altri Tools dei quali non conosco l'esistenza che installati sul server mi permettono di compilare le pagine senza dovermi cimentare sulla riga di comando del server di pubblicazione e far cadere le session?
Inoltre, è possibile condividere il progetto WEB in VS.NET da più utenti senza essere costretti ad attendere che il collega corregga il codice sorgente, visto che se dal mio client compilo il progetto vedo anche gli errori di compilazione del/i collega/hi?
Oppure... Si accettano altri consigli?


Granzie fin d'ora per la cortese disponibilità prestatami.

Distinti saluti.

Re: Migliorare il suporto per la condivisione di progetti e il debug di gruppo

Per prima cosa, grazie per il tempo che hai voluto dedicare a raccontare le
difficoltà e le problematiche che hai incontrato nell'utilizzo della tecnologia ASP.NET nel tuo lavoro di tutti i giorni.
I tuoi suggerimenti, così come quelli di tutti le persone e le aziende che utilizzano i prodotti e le tecnologie Microsoft, sono estremamente
importanti.
L'obbiettivo fondamentale di Microsoft è quello di costruire software che possa aiutare le persone e le aziende a semplificare i processi
di lavoro e la gestione delle loro attività. I feedback ed i suggerimenti sono estremamente importanti per fare sempre meglio e per
perseguire la direzione giusta che porti a sviluppare software sempre più vicino alle esigenze di chi lo deve utilizzare.

Per cercare di risolvere nell'immediato la tua problematica cerco di fornirti alcuni suggerimenti.
Parlavi di autenticazione e di utenti costretti a rieffettuare i Logon .... se utilizzi la Forms Autentication di ASP.NET non dovrebbe
esserci questo tipo di effetto perchè l'Autenticazione in quel caso viene basata su un Cookie cifrato e non viene influenzata dalla sessione.
Che tipo di meccanismo stai usando ? Ti consiglio di valutare la Forms Authentication.
Se non vuoi assolutamente far morire la sessione della tua applicazione, ti suggerisco di impostare la sessione su StateServer
modificando l'attributo dell'elemento SessionState nel Web.config. In questo caso devi anche attivare il servizio asp state service ovviamente.
In questo modo la sessione viene mantenuta dal servizio, sopravvive anche ad un riavvio di IIS e può essere condivisa da più macchine in caso
di utilizzo di bilanciamento del carico su più server. Attenzione il servizio ASP State Service di default è configurato in manuale per cui
non si avvia con la partenza del SO, se vuoi utilizzarlo ti consiglio di metterlo in automatico cosi in caso di eventuali reboot della macchina
si riavvii automaticamente.

Le tue osservazioni mi forniscono anche lo spunto per fare anche una piccola riflessione sulla natura delle tecnologie Web
e delle caratteristiche offerte da ASP.NET e Visual Studio .NET per questo tipo di soluzione.
Negli ultimi anni abbiamo assistito ad un proliferare dell'utilizzo delle interfacce Web per lo sviluppo di applicazioni che precedentemente
venivano sviluppate con altre tecniche. Le motivazioni di questa crescita sono evidenti e credo chiare a tutti. Ad esempio: uno dei grandi
vantaggi del Web consiste nella possibilità di portare un' applicazione ovunque, eliminando le problematiche di distribuzione e
gestione delle versioni sui client. Con questo approccio i siti si sono trasformati da un semplice insieme di pagine a vere e proprie
applicazioni, in alcuni casi estremamente sofisticate e complesse.
Scrivere software di qualità significa anche gestire in modo complessivo la qualità totale del ciclo di vita dell'applicazione,
dallo sviluppo , alla fase di test, la produzione e alla sua manutenzione.
ASP ha avuto un enorme successo ed ha contribuito enormemente allo sviluppo di questo tipo di applicazioni. ASP ci ha abituato molto
ad un approccio basato sulla pagina e non sull'applicazione nella sua totalità. In ASP modifichiamo singole pagine in modo separato dalla
globalità dell'applicazione. Il codice così prodotto è estremamente flessibile ma, all'aumentare della complessità e delle dimensioni
dell'applicazione, sempre meno gestibile. Il codice ASP è basato su script e non è tipizzato, nessuna verifica può essere effettuata
sullo stesso prima dell'esecuzione ed a causa di ciò alcuni errori si producono solo in particolari condizioni di esecuzione che diventano
difficilmente individuabili.
L'utilizzo del Web per applicazioni enterprise ha bisogno di massimizzare performance, affidabilità e sicurezza , cose a cui e
possibile fornire una risposta migliore usando codice tipizzato e verificabile, eseguito in linguaggio macchina, pensato per applicazioni.
Su queste problematiche i feedback ed i suggerimenti dei clienti portano a capire come il Web si sia modificato in pochissimo tempo e
l'esigenza di sicurezza , verificabilità, performance etc assolutamente fondamentali.
Da ciò la necessità di considerare in modo diverso lo sviluppo e l'approccio alla manutenzione di software scritto per il WEB
e la richiesta di tecnologie e strumenti che permettano di ottimizzare le operazioni collegate alla gestione di di questo tipo
di applicazioni.
ASP.NET e la tecnologia .NET in generale nascono proprio per permettere lo sviluppo e la gestione di applicazion Web che possano rispondere
a queste esigenze superando i limiti imposti dagli script, permettendo di migliorare drasticamente verificabilità , sicurezza,
affidabilità e performance, mantenendo la maggiore flessibilità possibile.
L'approccio di Visual Studio .NET è quello di considerare l'applicazione nella sua totalità, con una gestione delle sue versioni complessiva.
Una modifica ad una pagina, significa (come è giusto che sia a mio avviso) una modifica, anche se minima, all'applicazione.
Stiamo scrivendo applicazioni e quindi occorre anche strutturare un ciclo di vita per lo sviluppo ed il testing delle modifiche.
L'approccio è quello di creare un ambiente di sviluppo, uno di test ed uno di produzione. Con questa mentalità il codice non si modifica
nell'ambiente di produzione, anzi, i sorgenti non si portano nemmeno in produzione. In caso di necessità di modifica si procede
dall'ambiente di sviluppo, si compila una nuova versione dell'applicazione , si porta in test e dopo si porta in produzione.
ASP.NET può anche essere usato con un approccio sulla pagina tipo ASP ed in alcuni casi può essere assolutamente utile mantenere lo
stesso stile. I vantaggi dell'approccio complessivo, però, sono molteplici, basta entrare nella mentalità APPLICAZIONE non insieme di
pagine e mantenere l'approccio in ogni aspetto dallo sviluppo al test , fino al deployment.
Ad esempio si può stabilire di realizzare una Build al giorno dell'applicazione: durante la mattina si lavora alle modifiche
nell'ambiente di sviluppo, assegnando i task a ciascun developer. Dopo pranzo si fa una Build e si porta in test. Se la build passa il
Test si porta in produzione e si ricomincia il giro.
Per modificare il codice in un team è importantissimo utilizzare tool che consentano la gestione del versioning del codice ed il lavoro
in gruppo sullo stesso progetto. Non c'è niente di più pericoloso di più persone che possano modificare contemporaneamente i sorgenti di
un'applicazione senza possibilità di lock e di gestione ed eventuale reverse delle modifiche effettuate. Come strumento MS si può
utilizzare Source Safe ma ne esistono anche altri di terze parti .
Anche con ASP modificare il codice in produzione è un operazione sconsigliabile. Una modifica apportata ad una pagina in produzione
senza opportuno test, può portare ad effetti imprevedibili ed in una applicazione di qualità questo deve essere evitato.
Ovviamente il massimo sforzo deve essere fatto per fornire strumenti che consentano di semplificare sempre più lo sviluppo ed il
deployment, mantenendo ferma la verificabilità e la sicurezza del codice. Per questo aspetto i suggerimenti di chi lavora sul campo sono
fondamentali ed importantissimi per fare sempre meglio.



Grazie ancora e continuate a fornire richieste e suggerimenti che possano aiutarci a migliorare sempre più e che ci consentano di
fornirvi gli strumenti e le tecnologie che più vi occorrono .

Giuseppe Guerrasio
.NET Developer Evangelist
giusguer@microsoft.com



Il presente posting viene fornito “così come é”, senza garanzie, e non conferisce alcun diritto