Visita ao Microsoft Technology Center

Na última quinta-feira (26/01), todos os MVPs do Brasil tiveram a grande oportunidade de conhecer o recém-inaugurado Microsoft Technology Center.

IMG_3373 IMG_3377

Trata-se de um espaço com 1.300m2, onde empresas, parceiros e clientes poderão experimentar as mais recentes tecnologias, conhecer todo o potencial dos produtos Microsoft aplicados em cenários completos de demonstração, além de terem laboratórios, auditório e um “mini-azure” a disposição.

IMG_3386 IMG_3394 IMG_3407 IMG_3419

Com 360 processadores e capacidade para até 7 petabytes de armazenamento este “mini-azure”, estará disponível para realização provas de conceitos, testes de aplicações e qualquer outro cenário que necessite deste poder de hardware.

Após a visita ao MTC, voltamos para a Microsoft onde tivemos algumas conversas com arquitetos, gerentes de produtos, gerentes de TI e com o nosso MVP Lead para um alinhamento sobre o status do programa MVP.

IMG_3433 IMG_3441

Para fechar a noite, um happy hour no Badaró para rever os amigos, conhecer os novos MVPs e, sem dúvida, aumentar ainda mais o nosso networking.

IMG_3450 IMG_3470

Resumindo, mais um MVP Connection sensacional. Deixo aqui o meu muito obrigado ao Péricles Rocha pela grande apresentação no MTC, ao Markus Christen e a Rodrigo Dias por compartilharem suas experiências conosco e, principalmente, ao JP Clementi por ter coordenado e viabilizado esse grande evento.

Até a próxima,
André Dias

Tudo o que você precisa saber sobre testes no Visual Studio – Parte 2

Dando continuidade à série de vídeos sobre testes com o Visual Studio 2010, acabamos de publicar a 2a. parte na Lambda3 TV. Neste segundo episódio, abordamos os seguintes assuntos:

  • Testes de Métodos Privados
    • PrivateObject
    • PrivateType
  • Asserts
    • Assert
    • CollectionAssert
    • StringAssert
  • TraceContext
  • Atributos Inicialização/Finalização
    • [AssemblyInitialize]
    • [AssemblyCleanup]
    • [ClassInitialize]
    • [ClassCleanup]
    • [TestInitialize]
    • [TestCleanup]
  • Ordered Test
  • TDD (Test Driven Development)
  • Refactoring

Se você perdeu o episódio anterior, não deixe de assistí-lo.

Gostaria de ver outros assuntos sobre testes ou algum outro conteúdo completamente diferente? Deixe seu comentário abaixo.

Até a próxima,
André Dias

Como mostrar o “Display Name” ao invés do “Username” no Source Control do TFS

Recentemente, fui questionado por um cliente sobre como fazer o source control do TFS mostrar o nome do usuário ao invés do login em janelas como Pending Changes, View History, etc. No início, achei a pergunta bastante estranha, porém, assim que vi o problema, eu pude entender a dor do cliente.

Podemos dizer que o TFS tem uma “inconsistência de usabilidade” entre os componentes de Source Control e Work Item. Isso por que enquanto o Source Control apresenta o login dos usuários que fizeram determinadas ações, os Works Items utilizam o campo Display Name do AD (Active Directory) que normalmente é um nome muito mais legível.

Em grande parte dos clientes isso não é perceptível, porém alguns clientes acabam utilizando códigos como usernames, por exemplo o número de matrícula (M787878). Imagine que informação útil saber que o usuário M787878 fez aquele check-in que você tanto procurava.

Enfim, fui pesquisar se era possível mostrar o Display Name ao invés do login do usuário e me deparei com um “BUG” no Connect. Basicamente, temos um usuário como esse mesmo problema e uma informação do Brian Harry, um dos pais do TFS, dizendo que esse é um pedido antigo, porém que estava com prioridade baixa e que já está sendo corrigido na próxima versão do TFS, provavelmente o TFS 2012.

Com isso a resposta por enquanto é: “Não dá pra fazer isso agora, mas na próxima versão do produto será possível”. Vamos aguardar!

Abraços e até a próxima,
André Dias

Tudo o que você precisa saber sobre testes no Visual Studio – Parte 1

Acabamos de inaugurar mais um canal de comunicação entre a Lambda3 e a comunidade, a Lambda3 TV. Trata-se de um canal no YouTube, onde iremos publicar não só conteúdo técnico, mas também treinamentos gratuitos, entrevistas entre outros conteúdos relevantes para a comunidade.

Para inaugurar este canal, acabei de publicar um vídeo que faz parte de uma série onde falarei sobre diversas ferramentas e frameworks de testes que estão presentes na plataforma Visual Studio ALM. Confira:

 

Abraços e até a próxima,
André Dias

Contribuição com o Azure Storage Explorer

Entendendo o cenário

Há algum tempo venho trabalhando em um projeto que está hospedado no Windows Azure e que possui uma grande quantidade de conteúdo estático (vídeos, slides, etc).

No início do projeto, quando esse conteúdo era bem menor, eu não dei muita importância e optei por fazer o deployment deste conteúdo junto com a aplicação web. O tempo do deployment aumentava um pouco, porém era algo suportável. Algo em torno de 30 minutos para o upload e implantação do pacote.

O problema foi quando esse conteúdo começou a crescer absurdamente e o tempo de deployment da aplicação pulou de 30 minutos para mais de 5 horas. Nem preciso falar que é um tempo inaceitável e que fui praticamente obrigado a migrar todo esse conteúdo para BLOB.

Porém, trabalhar com BLOB não é uma das tarefas mais divertidas de se fazer com Azure. Se você ainda não teve essa oportunidade, vale a pena dar uma olhada no código necessário para amazenar um simples arquivo no storage do Windows Azure.

Azure Storage Explorer

Para a felicidade de muitos, temos uma aplicação bastante conhecida chamada de Azure Storage Explorer que funciona como um Windows Explorer para Azure. É uma ferramenta bastante poderosa que nos permite manipular Tabelas, Mensagens, Contêineres e BLOBs de uma forma bastante simples.

Apesar de bastante poderosa, ela não era muito útil pra mim, afinal eu precisava de duas features que ela não suportava:

  1. Upload de pasta com recursividade;
  2. Gravação dos arquivos com nomes que possam ser acessados como se estivessem em uma estrutura de pastas. Algo como “Minha Pasta Falsa/Minha Sub Pasta Falsa/Meu Arquivo” e com isso eu poderia acessar o seu conteúdo atráves de uma URL como http://<nome>.blob.core.windows.net/<conteiner>/Minha Pasta Falsa/Minha Sub Pasta Falsa/Meu Arquivo.

Contribuição

Como vocês já devem ter percebido. Ela não suportava, mas agora suporta.

Como o Azure Storage Explorer é uma ferramenta open source, pude baixar o código, implementar os recursos que eu precisava e submeti o patch para o owner do projeto. Enquanto, o patch está em avaliação para ser incorporado ao projeto final, você pode baixar a versão modificada no seguinte endereço http://azurestorageexplorer.codeplex.com/SourceControl/list/patches (Patch ID 11226).

Abaixo, vocês podem ver alguns screenshots das modificações e espero que essas mudanças sejam tão úteis para vocês como foram para mim.

Azure Storage Explorer 1
Imagem 1: Selecionando uma pasta para upload

Azure Storage Explorer 2
Imagem 2: Pasta enviada e arquivos com o seu path no nome

Um abraço e até a próxima!
André Dias

Benefícios de ser MVP

Hoje faz exatamente 16 dias que fui nomeado Microsoft MVP de ALM. Confesso que fiquei extremamente feliz em receber esse prêmio, ainda mais por tê-lo recebido durante o Community Zone ao lado de grandes amigos que também comemoraram muito.

Eu não vou entrar em detalhes do que é o programa ou como se tornar um MVP, afinal estou há poucos dias no programa e tenho muito que aprender e, além disso, temos o blog oficial que responde a todas essas dúvidas. 

MVP_FullColor_ForScreenNo entanto, eu gostaria de compartilhar a enorme quantidade de benefícios oferecidos aos MVPs, principalmente os benefícios “não-Microsoft”. Galera, eu não tinha ideia de como as empresas valorizam esses profissionais. Você vira MVP e começa a ser convidado para reuniões com os times de produtos na Microsoft, ganha assinatura de treinamentos sobre tudo o que você imaginar, licenças de softwares, brindes em eventos, enfim, você começa a ficar mal acostumado com tanto “mimo” que recebe.

Vou listar abaixo alguns dos benefícios que já recebi, mas a ideia é manter uma lista ativa para que os próximos MVPs já saibam o que eles têm direito além do mundo Microsoft. Vamos lá:

  • Benefícios da Microsoft
    • Assinatura MSDN
    • Participação no MVP Summit (evento mundial para todos os MVPs)
    • Convite para participar de reuniões com times de produtos
    • Acesso a listas de discussão internas onde você pode esclarecer dúvidas e discutir o futuro dos produtos e tecnologias Microsoft
  • Benefícios de outras empresas

Bom galera, por enquanto é isso. Assim que eu for descobrindo o mundo de oportunidades que o programa MVP oferece eu vou atualizando esse post e se você souber de algo que não está listado aqui, deixe no comentário que eu também atualizo.

Abraços e até a próxima.
André Dias

Teched 2011 – Implantando Continuous Delivery com TFS

Pessoal, muito obrigado a todos que puderam participar da palestra DEV307 -Implantando Continuous Delivery com TFS, realizada por mim e pelo Igor Abade. Espero que vocês tenham gostado.

Segue abaixo os slides da palestra, além de alguns links importantes.

 

Até a próxima,
André Dias

Publicando arquivos em servidor FTP usando MSBuild

Esse post foi motivado pelo seguinte tweet que recebi do @TucaZ: “@AndreDiasBR Poxa, eu só queria fazer FTP dos meus arquivinhos aqui 🙁”. Na verdade, essa foi à mensagem final depois de diversas sugestões “mais robustas” que tanto Eu como o Igor Abade demos ao Tuca.

Entre as sugestões que mencionamos, estão a utilização do Web Deploy, que é uma ferramenta fantástica para fazer automação de deployment, que pode empacotar a sua solução, enviar para o servidor, criar o site do IIS, configurá-lo, entre outras coisas, e o BRD Lite dos ALM Rangers, que nada mais do que é um template de build que simplifica diversas atividades comuns de Build, Release e Deployment que temos que fazer no nosso dia a dia.

Essas duas soluções fazem muito mais do que o Tuca precisa, mas sem dúvida tem um custo de implantação e configuração que muitas pessoas podem achar desnecessário e, que no caso dele, faz total sentido não utilizar, uma vez que ele já tinha todo o pacote montado e queria apenas enviar o pacote para o servidor ftp.

Vamos lá! Vamos entender como fazer isso então:

MSBuild Extension Pack

Para essa solução, vamos utilizar um projeto open source chamado MSBuild Extension Pack, que contém diversas tasks úteis para o MSBuild e é coordenado pelo Mike Fourie, Visual Studio ALM Ranger e pelo Sayed Hashimi, autor do livro Inside the Microsoft Build Engine: Using MSbuild and Team Foundation Build.

A instalação desta ferramenta é bastante tranquila e segue o padrão next, next, finish. Ao final da instalação, você verá que uma pasta chamada ExtensionPack foi criada dentro da pasta C:Program FilesMSBuild.

O próximo passo é criar um script MSBuild que fará uso das novas tasks fornecidos pelo Extension Pack.

<Import Project="$(MSBuildExtensionsPath)ExtensionPack4.0MSBuild.ExtensionPack.tasks"/>

<Target Name="PublicacaoFTP">
  <Message Text="Iniciando Publicao FTP" Importance="high" />
    
  <ItemGroup>      
    <FilesToUpload Include="$(ProjectDir)***.aspx" />
    <FilesToUpload Include="$(ProjectDir)***.js" />
    <FilesToUpload Include="$(ProjectDir)***.css" />
    <FilesToUpload Include="$(ProjectDir)***.dll" />
    <FilesToUpload Include="$(ProjectDir)***.config" />
  </ItemGroup>
    
  <MSBuild.ExtensionPack.Communication.Ftp TaskAction="UploadFiles" 
                                            Host="localhost" 
                                            UserName="ftpuser" 
                                            UserPassword="P2ssw0rd" 
                                            FileNames="@(FilesToUpload)"/>

  <Message Text="Publicao FTP Concluída" Importance="high" />

</Target>

Note que o script não é nada complexo. No início, ele faz a importação das tarefas do Extension Pack, em seguida cria uma target para agrupar as atividades, então ele seleciona quais os arquivos que serão publicados e por último e o mais importante, ele chama a task MSBuild.ExtensionPack.Communication.Ftp que fará todo o trabalho pesado de enviar os arquivos para o servidor FTP.

Essa tarefa também pode ser utilizada para fazer download de servidores FTP caso você mude o parâmetro TaskAction para “DownloadFiles”.

Executando o Script

O script acima está praticamente pronto para ser executado através de linha de comando usando o MSBuild.exe, mas a solução fica mais “elegante” se a integrarmos com o processo de build do Visual Studio.

Para isso, vamos criar uma simples Web Application e modificar o arquivo do projeto para que toda vez que a solução for compilada em modo Release, ele seja também publicada em um servidor FTP.

Depois da Web Application criada, clique com o botão direito no projeto e selecione a opção Unload Project, depois clique com o botão direito novamente sobre o projeto e clique em Edit. O que você verá nada mais é do que um XML que é um script MSBuild.

Vá ao final do arquivo, descomente o target AfterBuild e dentro dele utilize a task CallTarget para chamar o script que nós criamos. Utilize também o atributo Condition para garantir que essa chamada seja realizada apenas se o modo de compilação for Release. O seu código deverá ficar parecido com o script abaixo:

<Target Name="AfterBuild">
  <CallTarget Targets="PublicacaoFTP" Condition="'$(Configuration)' == 'Release'" />
</Target>

Está pronto! Para testar é só compilar a sua solução em modo Release e tudo deverá funcionar.

É isso aí pessoal. Espero que essa solução ajude, não apenas o Tuca, mas também a todos os Build Masters.

Abraços e até a próxima
André Dias

TFS Aggregator: Cálculos e Agregações em Work Items

Alguns dos pedidos mais frequentes que ouço durante as consultorias que dou, são:

  • Gostaria de fechar um Work Item pai, quando todos os filhos forem fechados;
  • Quando eu atualizar as horas de uma tarefa, eu quero que a User Story ou o PBI mostre as horas restantes consolidadas;
  • Assim que uma atividade filha (task) tiver o seu status alterado para “In Progress” eu gostaria que o pai fosse automaticamente alterado para “In Progress” também.

Uma das formas de atender esses pedidos é utilizar o SDK do TFS assinando eventos de servidor, porém essa abordagem exige um conhecimento avançado do produto para que você possa manipular as APIs de conexão e de work items. Outra forma que também atende essas necessidades, porém de uma maneira muito mais simples, pois ela encapsula toda a manipulação das APIs do TFS, é com a utilização de um plug-in open source chamado TFS Aggregator.

Com o TFS Aggregator, você pode configurar ações para interpretar mudanças em work items e atualizar campos dos próprios work items alterados, campos de work items pais, simplesmente manipulando um único arquivo xml. Vamos conhecê-lo um pouco melhor:

Instalação

O processo de instalação do TFS Aggregator é bastante simples. Basta você fazer o download do plug-in e descompactar o arquivo dentro da pasta de plug-ins do TFS, normalmente no seguinte endereço: C:Program FilesMicrosoft Team Foundation Server 2010Application TierWeb ServicesbinPlugins.

Após descompactar o zip, você verá dois arquivos:

  • TFSAggregator.dll: é o plug-in que fará a interpretação dos eventos;
  • AggregatorItems.xml: é o arquivo onde definiremos os eventos que iremos tratar;

pasta plugins tfs

Configuração

O processo de configuração também é bastante simples. Dentro do arquivo XML, você possui um elemento principal chamado AggregatorItems, onde você definirá a URL do seu servidor TFS e depois você criará uma série de elementos do tipo AggregatorItem, onde cada elemento desse tipo representa um regra que o plug-in irá tratar.

O arquivo de configuração, de maneira bastante simplificada, fica da seguinte forma:

<?xml version="1.0" encoding="utf-8"?> 
<AggregatorItems tfsServerUrl="http://tfs2010dev:8080/tfs" >
<AggregatorItem operationType="Numeric" operation="Sum" 
		linkType="Self" workItemType="Task">
	<TargetItem name="Estimated Work"/>
	<SourceItem name="Estimated Dev Work"/>
	<SourceItem name="Estimated Test Work"/>
</AggregatorItem>
</AggregatorItems>

No exemplo acima, temos a configuração do nosso servidor e uma única regra de agregação que monitora todos os work items do tipo Task, soma os valores dos campos Estimated Dev Work e Estimated Test Work e insere no campo Estimated Work.

Obviamente existem cenários bem mais complexos que esse e para conhecer todo o potencial do plug-in, não deixe de visitar a documentação do TFS Aggregator.

Cenários de Utilização

Vamos ver abaixo como o plug-in resolve de forma bastante objetiva algumas das principais dúvidas citadas no início do post:

Cenário 1: Fechar um work item pai quando todos os filhos forem fechados

<AggregatorItem operationType="String" linkType="Parent" linkLevel="1" workItemType="Task">
  <Mappings>
    <Mapping targetValue="Done" inclusive="And">
      <SourceValue>Done</SourceValue>
    </Mapping>
  </Mappings>
  <TargetItem name="State"/>
  <SourceItem name="State"/>
</AggregatorItem>

Cenario 1 

Cenário 2: Somar o remaining work de todos os filhos e inserir em um campo do work item pai

<AggregatorItem operation="Sum" linkType="Parent" linkLevel="1" workItemType="Task">
  <TargetItem name="Business Value"/>
  <SourceItem name="Remaining Work"/>
</AggregatorItem>

Cenario 2

Cenário 3: Mudar um PBI para Commited assim que qualquer tarefa tiver seu status como In Progress

<AggregatorItem operationType="String" linkType="Parent" linkLevel="1" workItemType="Task">
  <Mappings>
    <Mapping targetValue="Committed" inclusive="Or">
      <SourceValue>In Progress</SourceValue>        
    </Mapping>
  </Mappings>
  <TargetItem name="State"/>
  <SourceItem name="State"/>
</AggregatorItem>

Cenario 3

Agora, você que já teve que trabalhar com a API do TFS para fazer a mesma coisa deve estar se perguntando: “Por que eu não descobri isso antes?”. Pois é, foi a pergunta que me fiz quando descobri esse plug-in.

Espero que seja útil para vocês.

Até a próxima,
André Dias

Como adicionar um novo item na Quick Launch do TFS Project Portal

O título deste post foi exatamente o pedido que um cliente me fez. Nós tínhamos acabado de criar uma Document Library e ele queria, simplesmente, adicionar um link para ela no Quick Launch. Ahhh, um pequeno detalhe: ele queria que essa alteração fosse válida para todos os sites novos, ou seja, a alteração deveria ser no template do portal.

Na mesma hora eu pensei: “Beleeeeza, vou lá no Site Settings, Quick Launch, adiciono o novo link, exporto o site alterado como um template, faço a importação do template alterado com um outro nome, altero o WssTasks.xml para usar o novo template e pronto. Problema resolvido”.

Mal sabia eu que essa solução tão simples não funcionava mais com o TFS 2010. Pois é, devido a grande mudança nos Dashboards da versão 2010, o TFS passou a utilizar features como meio de customização dos Portais. Com isso, durante a criação de um Team Project, o PCW (Project Creation Wizard) verifica quais recursos instalados o SharePoint possui (Excel Services, por exemplo) e segue habilitando as features de Dashboard de acordo com esses recursos.

Burndown Dashboard   Infrastructure Team Dashboard

Depois de descobrir que a minha solução de customização de portal para o TFS 2008 não era mais válida para o TFS 2010, comecei a buscar outras soluções. Procurei em blogs, documentação do produto, questionei em listas privadas da Microsoft e nada. Até achei algumas soluções que faziam a inclusão de links via SDK, mas confesso que achei inadmissível ter que usar código pra fazer algo tão simples. Pedi ajuda pros MVPs e Rangers da Lambda3 e alguns dias depois, o grande Claudio Leite, me apareceu com uma solução digna de respeito: uma customização através features usando apenas arquivos .xml. Vamos ver abaixo como ficou isso.

Criação da Feature

O primeiro passo é a criação da Feature. Para isso, vamos criar dois arquivos XML, o primeiro é o feature.xml, que descreve a feature, e o segundo vamos chamar de elements.xml que será o arquivo que descreverá todos os recursos utilizados pela feature.

Vamos ao primeiro arquivo:



Como podemos ver, é um arquivo bastante simples e temos que nos preocupar, basicamente, com 3 parâmetros:

  • ID: Precisa ser um GUID. Se você não sabe como criar um, basta acessar o menu Tools do seu Visual Studio e acessar a opção Create GUID;
  • Title: Título da feature que aparecerá na lista de features ativadas no seu site;
  • Scope: Precisa ser Web, pois a feature funcionará para cada site instalado no servidor;

O próximo passo é criar o Elements.xml:



  
  
  

Esse arquivo já é um pouco mais complicado. Vamos entendê-lo:

Elemento ListInstance

É o elemento que vai criar a biblioteca de fato.

  • FeatureID: não pode ser alterado, ele é referente a feature base de Document Library do Sharepoint;
  • TemplateType: idem ao acima. É um modelo da biblioteca;
  • ID: nome interno da biblioteca no sharepoint. Não pode ter espaços;
  • Description: descrição da lista;
  • Title: título da biblioteca e o que aparecerá nos links dentro do Sharepoint. Deve ser único;
  • OnQuickLaunch: É o objetivo principal deste post! É o atributo que vai fazer a Document Library aparecer no Quick Launch;
  • Url: URL relativa do site, de preferência, sem acentuação e espaços;

Caso você queira publicar arquivos junto com a criação da document library, não deixe de consultar os elementos Module e File.

Instalação da Feature

Uma vez que temos os arquivos criados, vamos colocá-los em uma pasta chamada MinhaFeature e vamos copiá-la para pasta de features do SharePoint, normalmente em C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions12TEMPLATEFEATURES.

Feito isso, vamos rodar o seguinte comando para instalar a feature no servidor:

C:Program FilesCommon Filesmicrosoft sharedWeb Server 
Extensions12BINstsadm -o installfeature -name MinhaFeature

Pronto, a nossa feature está instalada e pronta para ser usada.

Configuração do Template

Agora vamos ao último passo, vamos informar ao nosso template para utilizar a feature que acabamos de criar. Para isso, acesse o arquivo <Process Template> Windows SharePoint ServicesWssTaks.xml e dentro do elemento activateFeatures, insira o novo elemento abaixo:

<feature featureId="23C75B71-7FFA-4E03-AD04-4A7FE7700AD7" /> 

Importante: O atributo featureId deve conter o mesmo GUID gerado para o arquivo feature.xml.

Depois do template configurado, basta fazer o upload do seu Process Template para o TFS 2010 e assim que um Team Project for criado, você deverá ver imagens parecidas com as imagens abaixo:

quick launch  moss feature

É isso aí. Por isso que eu adoro esse produto, não basta conhecer TFS para trabalhar com ALM, você precisa conhecer SharePoint, SQL Server, Reporting Services, Analysis Services, IIS, Project Server, Windows Server e isso para citar apenas produtos, ou seja, é diversão que não acaba mais e oportunidade para aprender sempre.

Espero que tenham gostado.

Abraços e até a próxima,
André Dias