Se você vai participar de um projeto que envolva customização do SharePoint – um tipo de projeto cada vez mais comum, dada a crescente popularidade do SharePoint – pode usar o TFS como suporte para a gestão do ciclo de vida da aplicação que será criada.

Para saber mais sobre como usar o TFS num projeto de SharePoint, consulte os links abaixo. Eles contêm alguns dos materiais disponíveis sobre o assunto.

• SharePoint Guidance
• Using Team Foundation Server to Develop Custom SharePoint Products and Technologies Applications
• Microsoft Office SharePoint Server Custom Application Development Series:  Document Workflow Management Project

Ao usar o teste de carga do VSTS você encontrou o seguinte erro:

---------------------------
Microsoft Visual Studio
---------------------------
Error occurred running test. (Computer  <computador>) Could not access the load test results repository: The load test results repository is out of space.  Allocate more space to the repository (if possible), or delete results of older load test runs.
---------------------------
OK  
---------------------------

Sua primeira reação é checar o disco da máquina indicada na mensagem de erro e limpar a pasta TestResults, apagando todos os arquivos (ex. TRX) existentes lá. Só que não vai adiantar – o problema é outro…

Na verdade, o espaço que se esgotou foi o do banco de dados de resultados de testes, não a pasta TestResults. Isso se deve ao fato de que o VSTS Test Edition armazena os resultados dos testes de cargas (todos aqueles indicadores que podemos acompanhar em tempo real ao executarmos um teste) num banco de dados SQL Server. Por padrão, esse banco de dados é um SQL Server Express, que tem um limite máximo de 4GB por banco de dados.

Se você pretende executar muitos testes de carga – ou durante longos períodos – pode acabar alcançando o limite de 4GB. Nesse caso você tem duas opções:

1. Usar uma versão completa do SQL Server (por exemplo a Standard); ou
2. Exclua resultados antigos do banco de dados: abra um teste de carga no Visual Studio, encontre o botão "Manage Load Test Results" e use essa caixa de diálogo para ver, excluir, exportar e importar resultados de testes. Você poder exportar antes de excluir resultados antigos para poder visualizá-los posteriormente.

Para mais informações, procure por "Working with Load Tests" no MSDN.

Conheça algumas dicas muito boas para melhorar a velocidade dos seus builds – cortesia de Jim Lamb, Program Manager do Team Build.

• Reduza o escopo do seu Get ao mínimo possível – com isso você reduz o tempo de download do código-fonte. Ajuste os mapeamentos do espaço de trabalho do build para baixar apenas o essencial.
• Reduza a verbosidade do loogger do MSBulid (o default é “diagnostic” no .NET 3.5) adicionando a seguinte chave ao seu arquivo TfsBuild.rsp: “/flp:verbosity=normal”.
• Defina a propriedade IncrementalGet como True no arquivo TFSBuild.proj se você puder reaproveitar o código-fonte entre os builds (isto é, baixar apenas os arquivos alterados desde o último build).
• Defina a propriedade IncrementalBuild como True se você puder reaproveitar as compilações entre os builds (isto é, recompilar apenas os arquivos alterados desde o último build).
• Ative o suporte a multiprocessadores do MSBuild para obter uma paralelização da compilação das soluções – funciona melhor em Agentes de Build com processadores multi-core.
• Instale o Service Pack 1 do VSTS/TFS e o Hotfix 'TargetsNotLogged' em seus Agentes de Build para reduzir o “ruído” nos logs de build.
• Avalie uma eventual divisão do seu processo de build em várias definições de build. Por exemplo (a) um build incremental de integração contínua que apenas valida o último changeset sem copiar um drop (os binários resultantes do build) e (b) um build noturno, a partir do zero, que compila o mesmo label do último build de integração contínua bem-sucedido e executa um conjunto de testes automatizados.
• Agende desfragmentações de disco em seus agentes de build. Se você faz integração contínua e builds diários, provavelmente o ideal é que você faça essa desfragmentação aos finais de semana.
• Use máquina de build com HDs rápidos. Atualizar seu agente de build com um disco rígido mais novo e mais rápido é uma maneira relativamente barata de aumentar o desempenho do seu build. Por exemplo, a velocidade do HD WD 750 GB 7200 RPM é bem próxima à dos mais rápidos HDs mecânicos com preço abaixo de US$100.
• Use um sistema operacional de servidor (não um workstation) para hospedar os drop folders. Por exemplo, prefira o Windows Server 2003 ao XP.

Veja as mais recentes estatísticas em http://blogs.msdn.com/vstsbrasil/archive/2009/02/05/estat-sticas-de-uso-do-vsts-na-microsoft-dezembro-2008.aspx

Estamos tão acostumados com a expressão “Atualização de Segurança” que é fácil deixar mensagens como esta “passarem batido”. Entretanto, se você tem o Team System Web Access (TSWA) instalado – em especial se ele puder ser acessado pela internet – então você realmente vai querer atualizá-lo para a versão abaixo:

http://go.microsoft.com/fwlink/?LinkID=136577

Esta versão inclui uma importante correção de segurança que você deve instalar imediatamente. Esse download não é um patch e sim uma versão completa do TSWA, por isso você deverá desinstalar o produto e reinstalar a nova versão. Logo teremos um artigo na KB; fique de olho no blog do Hakan para mais informações.

Para saber se você tem a versão correta do TSWA: Acesse o site do TSWA e vá em "Help -> About". Se a versão exibida for Build 9.0.3275 então você já tem a correção instalada. Qualquer versão anterior a isso deve ser atualizada. Especificamente, 9.0.3160 é o número de build do TSWA SP1.

Essa é uma dúvida muito comum. Um amigo MVP me fez essa pergunta há algum tempo. Assim, achei que era uma excelente oportunidade para blogar e tentar registrar a resposta.

A ferramenta de teste de carga do VSTS é o Visual Studio Test Edition.

Ponto. Simples assim. :-)

Isso quer dizer que, para estressar aplicações Web (ASP.NET, PHP, Java, Ruby etc.), Web Services (ASMX, WCF, JEE etc.) e bancos de dados (SQL Server e quaisquer outros suportados pelo ADO.NET) você deve usar o Visual Studio Team System Test Edition (a ferramenta de testes do Team System). Com ela você pode:

• Criar as definições (scripts) do teste de carga;
• Executar os testes (contra um ou mais servidores ao mesmo tempo);
• Consolidar os dados (recebendo os indicadores de performance de todos os servidores envolvidos);
• Analisar os dados (através de gráficos e tabelas no próprio ou através de exportação para Excel e relatórios em SQL Server Reporting Services);
• Notificar a equipe de desenvolvimento em caso de problemas de desempenho (através da criação de itens de trabalho do tipo  Bug).

Agora que esclarecemos que o VSTS Test Edition é a ferramenta que devo usar para fazer os testes de carga, vem a pergunta: para quê serve então o Test Load Agent?

Use o VSTS Test Load Agent para aumentar a quantidade de usuários virtuais dos seus testes

O VSTS Test Edition pode gerar tantos usuários virtuais quantos você quiser. O único limite será a capacidade do seu hardware. É difícil estimar quanta carga um determinado computador é capaz de gerar, porém eu arriscaria dizer que uma boa estação de desenvolvimento deve conseguir algo entre 500 e 1000 usuários virtuais (esse número pode variar muito dependendo do tipo de teste que você faz).

A fim de criar um estresse que simule as condições reais de uso de sua aplicação, pode ser que você precise simular mais do que 500 ou mil usuários virtuais – especialmente se você pretende colocar essa aplicação na internet. Nesse caso, você precisaria de mais computadores, trabalhando lado a lado com o seu, cada um deles executando parte dos usuários virtuais.

É aí que entra o Test Load Agent.

Com o Test Load Agent, você pode promover máquinas em sua rede a agentes de carga – dividindo a responsabilidade do trabalho com o computador onde está o Test Edition.

Assim, imaginemos o seguinte cenário:

1. Preciso estressar uma aplicação web;
2. Essa aplicação vai estar na internet;
3. Espero uma carga de cinco mil usuários simultâneos;
4. Nos primeiros testes executados pôde-se perceber que um computador consegue gerar no máximo mil usuários virtuais.

Para poder gerar a carga de cinco mil usuários você utiliza o Test Edition em conjunto com um ou mais computadores rodando o Test Load Agent para criar um conjunto de máquinas chamado de Test Rig. Test Rigs são o conjunto de um controlador e um ou mais agentes de teste de carga.

Uma outra distinção importante: testes de cargas executados a partir do Visual Studio estão limitados a um único core da minha máquina; o Load Agent, por outro lado, utiliza todos os cores. Como tipicamente o principal limitador na quantidade de usuários virtuais é a CPU, o Test Load Agente conseguiria gerar o dobro de usuário numa máquina dual-core, quando comparado com o Test Edition.