Plug-in Team Foundation Server para o Eclipse
Você pode usar o Team Explorer Everywhere para melhorar a previsibilidade de seus processos de desenvolvimento. Team Explorer Everywhere inclue Plug-in do Team Foundation Server para Eclipse e Cliente de linha de comando de plataforma híbrida para Team Foundation Server. Você pode usar os recursos de acompanhamento de item de trabalho para capturar o que é importante para seus clientes e acompanhar o progresso do seu projeto. Isto o permite que você ordene processos e monitore sua qualidade para ajudar sua equipe a virar requisitos do cliente em um software funcional. Você pode gerenciar seus códigos-fonte e artefatos de projeto usando o Controle de versão do Team Foundation. Usando controle de versão, você reduz riscos e ajuda a melhorar a qualidade de seu aplicativo. Você pode compilar seu aplicativo usando o sistema de compilação integrado de forma que sua equipe possa assegurar que barreiras de qualidade que forem encontrada e possam visualizar que requisitos foram cumpridos em cada compilação.
Usando o Team Explorer Everywhere o Desenvolvimento Iterativo
Tarefa |
Conteúdo suportado |
|---|---|
Guia de Introdução: Antes de usar os recursos do Plug-in do Team Foundation Server para Eclipse, primeiro você deve estabelecer uma conexão a uma instância de Visual Studio Team Foundation Server. |
|
Configure o ambiente de desenvolvimento local: Na maioria dos ambientes de desenvolvimento de equipe, você deve obter acesso à versão correta dos arquivos de código-fonte. Você atualiza seu computador local em seguida, com os arquivos de origem para as partes do seu aplicativo que você deve atualizar. |
|
Faça alterações no código para realizar uma tarefa ou corrigir um bug: Durante um ciclo de desenvolvimento, você gasta a maior parte do seu tempo fazendo alterações de código. Este processo inclui a seleção de uma tarefa ou bug, fazendo o check-out dos arquivos necessários, modificando o código e então verificando que suas alterações estão corretas antes de você fazer seus check-ins. Esta tarefa inclui as alterações na feitura de código do aplicativo e de código de banco de dados. |
|
Crie e solicite compilações: Você pode usar o sistema de compilação integrado para executar compilações automatizadas por agenda ou sob demanda. |
|
Defina portões de qualidade: Você pode especificar diretivas de check-in para ajudar a proteger a qualidade dos arquivos de origem cujos check-ins são feitos em controle de versão. |
|
Solucionando problemas: Se você encontrar problemas que quando usar Team Explorer Everywhere, você poderá localizar informações sobre os problemas comuns e suas resoluções. |
Execute Tarefas de Desenvolvimento Iterativas
Você executa um conjunto de etapas comuns para cada tarefa de desenvolvimento. Dependendo do processo usado por sua equipe, você pode executar estas tarefas em uma ordem diferente. Por exemplo, você pode definir seus testes antes de fazer as alterações no código.
Depois de identificar uma tarefa de codificação e de ter atualizado seu computador de desenvolvimento local com a versão correta do código-fonte, você pode fazer as alterações necessárias ao seu código. Porém, a alteração de código é apenas a primeira etapa, pois normalmente você deve testar suas alterações. Depois de verificar o comportamento de seu aplicativo, você pode concluir sua tarefa de desenvolvimento e seguir para a próxima.
Tarefa |
Conteúdo suportado |
|---|---|
Identifique o trabalho a ser executado: Seu trabalho normalmente consiste em uma ou mais tarefas de codificação devem ser executadas ou um ou mais bugs que devem ser resolvidos. Você recupera os itens de prioridade mais alta que estão atribuídos a você a partir do banco de dados de acompanhamento de item de trabalho. Você também pode analisar a agenda global para a iteração atual para verificar se pode concluir suas tarefas no prazo esperado. Você também deveria revisar as dependências que outros membros da equipe podem estar usando nas suas tarefas, para evitar bloquear o andamento. Se sua equipe tiver testadores em tempo integral, você deve discutir o trabalho com o testador responsável para as áreas de recurso afetadas para que ele possa começar qualquer planejamento de teste que seja necessário. |
|
Prepare seu ambiente de desenvolvimento: Depois de identificar o trabalho que você deve executar, você pode ter que atualizar seu ambiente de desenvolvimento de forma que você tenha o código-fonte exigido. Se você estiver corrigindo um bug em uma versão liberada ou implantada do aplicativo, você pode atualizar seu ambiente para ter uma versão específica das origens em vez da versão mais recente. Se você estiver trabalhando com bancos de dados, você também pode configurar um servidor de desenvolvimento local. |
|
Identifique a causa de defeitos de código: Frequentemente, o primeiro passo a se seguir quando você deve corrigir um bug é usar o depurador para identificar a causa do problema. Se o problema foi introduzido recentemente, você pode verificar os dados históricos dos arquivos de origem que contenham o erro para determinar quando e por quem o problema foi introduzido. Em algumas situações, você pode reverter a alteração original e considerar uma alteração de código diferente. |
|
Faça alterações de código: Você identifica quais alterações têm de ser feitas, faz um ou mais alterações de código, testa essas alterações e verifica se suas alterações satisfazem os padrões de codificação de sua equipe. |
|
Conclua o trabalho: Quando você acha que as alterações no seu código estão prontas, você geralmente os revisa com um ou mais colegas, executa uma compilação final completa e os testes de check-in. Depois de verificar suas alterações e solucionar quaisquer conflitos de mesclagem, solucione quaisquer tarefas relacionadas, bugs e outros itens de trabalho. |
Concluíndo Tarefas de Desenvolvimento
Quando você concluir a implementação e teste de uma alteração de código para endereçar uma tarefa, um bug ou outro item de trabalho, normalmente você executa várias tarefas adicionais. Em um ambiente de equipe, você frequentemente pede a um ou mais membros de sua equipe de desenvolvimento para revisar seu código. Você também deveria executar uma última compilação completa do aplicativo.
Você pode ter um conjunto de testes de check-in que devem ser aprovados antes que possa fazer o check-in no código. Depois de todos os critérios estarem completos, você pode verificar as alterações no código e resolver quaisquer conflitos de mesclagem.
Apenas quando todas as etapas requiridas forem concluídas que você resolve as tarefas correspondentes, bugs ou outro itens de trabalho.
Tarefa |
Conteúdo suportado |
|---|---|
Tenha o código revisado por seus colegas: Em muitos ambientes de desenvolvimento em equipe, você deve ter as alterações de código revisadas por um ou mais colegas antes de fazer o check-in dessas alterações. Você deveria considerar ter um de seus colegas para revisar qualquer código complexo, mesmo se esta etapa não for requerida por sua equipe. Para facilitar uma revisão de código, você pode preparar um check-in particular que contém suas alterações. Outros membros da equipe podem examinar os conteúdo do check-in particular. Adicionalmente, as alterações serão salvas em controle de versão para que você possa trabalhar com outras tarefas, e para que suas alterações não corram risco se algo inesperado acontecer a seu ambiente de desenvolvimento. |
|
Execute uma compilação completa final e testes relacionados: Frequentemente, quando você estiver fazendo alterações de código, compile apenas estas partes do aplicativo que você está alterando. Em um ambiente de equipe, você deve considerar a compilação o aplicativo inteiro antes de fazer o check-in das alterações. Em algumas equipes, você pode enviar check-ins a um computador que execute compilações contínuas. Em muitas equipes, você também deve executar um subconjunto de testes do aplicativo conhecido como testes de check-in. Estes testes verificam que você não interrompeu o comportamento do aplicativo em áreas diferente destas que você modificou diretamente. |
|
Fazer check-in de todas as alterações: Depois que você fizer o check-in das suas alterações, você tem de fazer o check-in para controle de versão para que elas fiquem disponíveis à equipe. Fazendo o check-in de suas alterações você também pode fazer com que elas apareçam na próxima compilação completa do produto. Você também pode reverter alterações pendentes se, por exemplo, elas apresentam um muito risco na fase atual de um ciclo de produto. Se você estiver alterando um código que é protegido por uma compilação de check-in com barreira, um check-in particular será criado e suas alterações pendentes devem ser compiladas com êxito antes de ser feito o check-in. |
|
Resolver tarefas, bugs e outros itens de trabalho: Depois de ter feito o check-in das alterações, você pode resolver as tarefas relacionadas, bigs ou outros itens de trabalho associados com as mudanças. Você normalmente associa o conjunto de alterações que contêm as alterações com o item de trabalho; se fizer isto e então o bug ocorrer novamente, será mais fácil de localizar o conjunto de alterações relacionadas. Você deveria incluir informações suficientes nos comentários do item de trabalho para que outros leitores possam entender que alteração foi feita e por que. Também, você pode considerar a aplicação de um rótulo para que você possa consultar esta versão do seu código-fonte. Depois que você concluir um item de trabalho, você pode ter que ajustar a agenta de desenvolvimento se aquele item levou um tempo significativamente maior ou menor do que o esperado. |
|
Forneça comentários de design: Quando você fizer uma alteração de código, você pode ter que alterar elementos no design ou arquitetura do aplicativo. Se você alterar o design, você deve atualizar qualquer documento arquitetural ou de design (incluindo modelos) para refletir as alterações. Além disso, se você corrigir uma falha, você pode fornecer orientação a outros membros da equipe sobre a natureza da falha e os instruir sobre como evitá-la no futuro. |