February 2012 Blog Posts

E’ appena stata rilasciata una wave *enorme* di roba!

Windows 8 Consumer Preview penso sappiate dove procurarvelo Smile parliamo invece di developer tools, ma prima un accenno a Windows 8 Server: qui!

Tutto quello di cui potete avere bisogno lo trovate a questa pagina.

Ci sono le SKU di Visual Studio, gli SDK, gli Agent, la Shell, Team Foundation Server sia in versione full che Express, Team Explorer e Team Explorer Everywhere.

Buon download!

Ieri sono state rilasciate un mucchio di informazioni a riguardo della nuova release di Visual Studio, con questo post tento di creare un recap Smile

Innanzitutto, nuova UI in Metro style.

Non voglio soffermarmi sulla UI, in quanto ancora ci sarà molto da dire.

Le nuove funzionalità le stiamo sviscerando io e Gian Maria nei nostri post, ne abbiamo affrontate alcune, ne arriveranno altre Smile tra cui il Search, l’IntelliTrace in produzione, Code Clone  Analysis etc.

Il .NET Framework passa alla versione 4.5, e con la Beta si potrà anche andare in produzione con licenza Go-Live. Si aprono quindi gli scenari di aggiornamento:

  • .NET 4.5 Developer Preview to Beta
  • .NET 4.5 Beta to RTM
  • .NET 4.5 Release Candidate to RTM
  • .NET 4.5 Beta e Visual Studio 11 Beta to .NET 4.5 RC e Visual Studio 11 RC
  • .NET 4.5 Beta e Visual Studio 11 RC to RTM (quindi la RC di Visual Studio potrà avere come target la Beta del framework)

Non sono invece supportati:

  • Visual Studio 11 Developer Preview to Beta
  • Visual Studio 11 Beta to RTM

Attenzione ai sistemi operativi sui quali installate i prodotti. Sono supportati esclusivamente Windows 7 e Windows Server 2008 R2 per Visual Studio 11 e Windows 7, Windows Server 2008 e Windows Server 2008 R2 per Team Foundation Server 11.

In questo caso, non supportati non significa ‘non funzionano’, significa ‘il CSS vi risponde picche se avete installato Windows 8 Consumer Preview o Windows Server 8 Beta’ Smile

Inoltre tutti i dati contenuti in Team Foundation Server 11 Beta saranno aggiornati senza problemi.

A proposito di Team Foundation Server 11, ieri ho postato una news parecchio importante: verrà rilasciata una versione Express di TFS!

Insomma…staremo a vedere quali altre sorprese ci riserverà Microsoft per la prossima wave Open-mouthed smile

Reggiamoci forte, molto forte.

Anni fa, sostenevo la necessità di una versione Express di TFS. Poi negli anni il licensing è cambiato, e la necessità era davvero inferiore se non inesistente.

Arrivò TFS Basic, e tutti erano felici. Tranne chi non aveva una MSDN, ossia molti appassionati, hobbisti, ecc. che non hanno fatto dello sviluppo software un lavoro ma solo un qualcosa fatto nei ritagli di tempo.

Microsoft fornisce le versioni Express dell’IDE, vero, ma manca quell’anello di congiunzione fra più persone (es.: gruppo di amici geek a scuola che si scrivono un giochino in XNA).

Bene, Brian Harry ci fa felici! Open-mouthed smile

Parliamo subito dei limiti:

  • SQL Server Express
  • Niente SharePoint
  • Niente Reporting Services
  • Massimo cinque utenti gratuiti
  • Solo single server
  • Include solo la Agile Taskboard ma niente strumenti di pianificazione agile o feedback
  • Non c’è il Version Control Proxy

E’ simile alla installazione basic, ma questa è completamente free of charge Smile

Ed inoltre: anche le versioni Express dell’IDE avranno supporto per *qualunque* versione di Team Foundation Server.

E questo è solo l’inizio…Winking smile

Un’altra delle grandi novità di Visual Studio ALM 11 è la possibilità di effettuare revisioni del codice in modo proattivo direttamente durante il processo di sviluppo, con la funzionalità di Code Review.

vs11cr1

Richiedendo una review si crea un nuovo Work Item di tipo Code Review Request, che ovviamente viene memorizzato in Team Foundation Server

vs11cr2

Banalmente si inseriscono uno o più revisori, un titolo e un commento.

vs11cr3

I revisori troveranno nella sezione My Work una nuova attività all’interno di Code Reviews & Requests.

vs11cr4

Aprendola si trovano tutti i file coinvolti nella review, il richiedente e se ci sono work item collegati. Si può aggiungere un commento per ogni file coinvolto nella review.

vs11cr5

Infine, si può chiudere la sessione di review completandola o abbandonandola.

vs11cr6

La grande utilità di questa funzionalità è che permette di inserire un qualcosa di ‘esterno’ come la code review senza attrito all’interno delle normali attività di sviluppo.

Come abbiamo visto il nuovo Team Explorer è radicalmente diverso dal precedente.

Ma la novità più grossa consiste nella completa ristrutturazione del processo di utilizzo, che ora si basa sul concetto di ‘cosa devo fare?’

Partiamo un attimo dalle basi: come detto in passato, uno dei pillar di Visual Studio ALM 11 è rendere la comunicazione all’interno del team di sviluppo un elemento portante. Su questo quindi si  basa il nuovo Team Explorer.

La prima cosa che notiamo è che tutto è rapidamente accessibile a colpo d’occhio: niente menù contestuali, niente tasto destro.

 

Capture1

Web Access, Pending Changes, tutto accessibile con un click.

Andando nel dettaglio, il grosso lo vediamo nel My Work

Capture2

Quello che ‘si deve fare’ lo abbiamo davanti agli occhi, senza dover eseguire query o cercare.

Nell’utilizzo poi, si nota come la My Work evolva verso uno stato più completo:

Capture3

Al momento del check-in, sappiamo cosa abbiamo modificato, in relazione a quale work item, ecc, rendendo l’intera esperienza utente molto più fluente e ‘semplice’.

Uno dei punti cardine di un buon processo di sviluppo è stabilire chiaramente cosa significhi che un qualcosa sia completato.

La cosiddetta Definition of Done [DoD] nasce in Scrum, ma è evidente che può, anzi deve, essere adattata a qualunque processo per raggiungere dei risultati accettabili

Sostanzialmente si tratta di una lista di attività, che vanno dallo scrivere codice, al testing, arrivando fino alle release note che aggiungono valore al prodotto. In Scrum è estremamente enfatizzata, cosiccome dalla Continuous Delivery, che quindi pretende che done corrisponda a shippable.

Naturalmente non esiste una DoD universale: va adattata in base allo scenario, al processo utilizzato e soprattutto al livello in cui la stiamo applicando: una DoD di un check-in non corrisponde alla DoD di uno sprint o di un backlog.

E’ essenziale che sia trasparente a tutti i membri del team, e tutti i criteri della DoD devono essere soddisfatti per ogni Product Backlog Item.

Modellare la DoD sul processo significa sostanzialmente utilizzare gli strumenti a disposizione per far si che il workflow di lavoro vada a configurarsi per seguire i passaggi della DoD del team.

Team Foundation Server ci aiuta in vari modi: innanzitutto con le Check-In Policy. Rispettare una serie di Check-In Policy significa dover rispettare alcune regole, quindi aderire alla DoD. Queste regole raggiungono il loro apice con un Gated Check-In, che funge da barriera netta: dentro o fuori. Ovviamente è possibile scrivere altre policy oltre a quelle presenti di default in TFS oppure utilizzare il Check-In Policy Pack for TFS, disponibile su CodePlex.

Nel caso in cui il check-in sia rigettato, è possibile eseguire uno shelve (che purtroppo vedo ancora poco utilizzato in molti casi). Con lo shelve, oltre a poter accantonare quel determinato task e quindi essere pronti per eseguirne un altro in attesa di nuovi sviluppi, si hanno molti piacevoli side effects.

Il primo è sempre in ombra ma in realtà estremamente importante: il backup. Infatti tutti gli shelveset sono coperti dal backup di Team Foundation Server.
Inoltre uno shelveset può essere oggetto di Code Review (in vari modi, a breve dedicherò un post alla nuova funzionalità in Visual Studio 11) da parte di altri membri del team, a tutto vantaggio della qualità.
Senza contare poi che gli shelveset rimangono proprietà intellettuale del proprietario, non essendo solamente un pezzo di codice che rimane lato client ma comunque qualcosa che rimane lato server e quindi all’interno dell’organizzazione.