SVNBridge: Integre seu TFS 2010 com clientes Subversion

image
80

Um dos grandes desafios de muitas empresas que pretendem migrar do Subversion para o TFS é: como integrar meu time – e suas ferramentas – ao novo servidor?

Se você usa ferramentas que oferecem suporte nativo ao TFS – como o Visual Studio, o Eclipse (com o Team Explorer Everywhere) ou até mesmo o IntelliJ IDEA – fica mais fácil. O problema é quando o time está usando ferramentas que só sabem falar com o Subversion, tal como o Adobe Dreamweaver ou o Apple Xcode.

Para esses casos, uma alternativa pode ser o SVNBridge – um tradutor de protocolos (ou “bridge”) que emula o protocolo do Subversion, “enganando” os clientes como o Dreamweaver ou o Xcode e fazendo-os acreditar que estão conectados a um repositório Subversion, quando na verdade estão falando com o TFS.

O SVNBridge foi criado pelo time do CodePlex para que clientes SVN (em especial o TortoiseSVN) pudessem ser usados para conexão com os TFS oferecidos pelo serviço CodePlex. O time percebeu que muitas empresas poderiam se beneficiar disso e portanto decidiram compartilhar o código.

Se você já usa (ou pretende usar) o TFS e tem pessoas no seu time que dependem de ferramentas que não “falam” TFS mas “falam” Subversion, experimente o SVNBrigde!

Um abraço,
    Igor

Microsoft Dynamics AX e Team Foundation Server

Brian Harry acabou de anunciar: o recém-lançado Dynamics AX 2009 agora oferece integração com o controle de versão do TFS!

Less than a month ago, Dynamics AX 2009 was released.  This new version enables Dynamics developers to store their source code and have an integrated experience for checkout, check in, get and history – the basic version control operations in TFS.  I’m excited about this because I get the question fairly often and people are always surprised when I tell them we don’t have a solution.  Now I don’t have to disappoint any longer.

Para saber como configurar o AX para armazenar o código-fonte no TFS, veja a documentação disponível em http://www.microsoft.com/downloads/details.aspx?FamilyId=EFC24EDC-522E-40AA-8F36-6367ED7AB92D&displaylang=en.

 

Technorati Marcas: ,,,

TFS também ama o Java (e o Delphi, e o PowerBuilder…)

O Team Foundation ainda é alvo de muito preconceito da comunidade de desenvolvedores. Só porque o nome do produto é “Microsoft Visual Studio Team System Team Foundation Server” (pequeno, né?) a maioria presume que TFS = .NET, já que assumem que Visual Studio = .NET. Bem, nada mais equivocado.

O ponto importante a se lembrar aqui é: O Visual Studio Team System é uma plataforma de ALM. ALM, ou Application Lifecycle Management, refere-se às práticas envolvidas na gestão do ciclo de vida de uma aplicação – desde a sua concepção, especificação e planejamento até a efetiva implantação no ambiente de produção. Repare que em nenhum lugar estava escrito “.NET Application Lifecycle Management”. Assim, ainda que obviamente a plataforma tenha recursos específicos para .NET (capazes de aumentar a qualidade e eficiência do trabalho da equipe de desenvolvimento), eu realmente acredito que nossa plataforma brilha nos cenários em que há vários ambientes (e linguagens) de desenvolvimento envolvidos.

Na sua empresa há um ambiente heterogêneo de programação? Há grandes chances que a resposta seja “sim”. Na maioria dos clientes que tenho visitado o mais comum é termos algo como “VB6 + .NET”, ou “Java + .NET”, ou “Delphi + VB + Java”, ou qualquer outra combinação que você imaginar. Como se não bastasse o fato de ter que lidar com múltiplas linguagens de programação, esses clientes normalmente acabam lidando com várias ferramentas usadas ao mesmo tempo no apoio à ALM: VSS, CVS, Subversion, Jira, Trac, Project Server, Primavera etc…

Quem já não viu esse cenário? “Projetos Java no Subversion, projetos VB no SourceSafe”. Como conseguir gerenciar isso de forma efetiva?

A resposta é clara: Use o Team Foundation Server para todos os projetos, independentemente da linguagem!

Eclipse

Veja o caso do Eclipse, um dos IDEs mais utilizados no desenvolvimento de aplicações Java (usando o plugin Teamprise). Com ele, você tem acesso total aos recursos do TFS – controle de versão, rastreamento de itens de trabalho, relatórios e documentos:

rad_wit_win

MSSCCI Provider

Há vários IDEs que ainda não oferecem suporte nativo ao TFS. Porém, se eles tiverem suporte ao Visual SourceSafe, há grandes chances de usar o TFS no lugar do VSS. Basta que eles se conectem ao VSS através de uma API chamada MSSCCI (Microsoft Source Code Control Interface). Com o Visual Studio Team Foundation Server MSSCCI Provider é possível “enganar” seu IDE, de modo que ele “fale” com o TFS pensando que é o SourceSafe. Alguns dos IDEs que utilizam essa API e que foram testados pela Microsoft para usar o MSSCCI Provider são:

  • Visual Studio .NET 2003
  • Visual C++ 6 SP6
  • Visual Visual Basic 6 SP6
  • Visual FoxPro 9 SP1
  • Microsoft Access 2003 SP2
  • SQL Server Management Studio
  • Sparx Systems Enterprise Architect 6.1
  • Sybase PowerBuilder 10.5
  • Toad for SQL Server 2.0

 

Para saber mais, há um artigo (já um tanto antigo, mas ainda válido) sobre o assunto em http://www.microsoft.com/brasil/msdn/tecnologias/vs2005/tfs.mspx.

 

Integração TFS – CA Harvest

Recentemente, participei do processo de adoção do TFS em um grande banco brasileiro. A equipe do projeto gostaria de utilizar o Team System – e em especial o TFS – para melhorar seu processo de desenvolvimento de software. Todos os envolvidos já conheciam a ferramenta e tinham ciência dos ganhos de produtividade e visibilidade oferecidos. Excelente, não?

Mas como nada na vida é tão simples assim, eles tinham um porém: o banco já havia adotado algumas ferramentas da Computer Associates (CA) para gestão do ciclo de vida. Essa decisão se deu, em parte, pela necessidade de integração com o mainframe. Dentre essas ferramentas, destaque para o CA Software Change Manager (anteriormente chamado de Harvest). Como o Harvest é a ferramenta de controle de versão "oficial" do banco, nosso desafio era integrar o TFS e o Harvest.

A solução

No cenário definido pelo banco, não havia a exigência de que toda e qualquer versão do código-fonte fosse mantida no servidor do Harvest. Ou seja, como o TFS oferece um controle de versão seguro e auditável, poderia ser usado durante toda a fase de desenvolvimento, sem precisar "conversar" com o Harvest. A integração se daria apenas nos milestones definidos pela equipe de projeto – ou seja, quando fossem "gerar um pacote" (ou "fechar uma baseline") para que as equipes de teste e homologação pudessem testar o produto.

Com esse requisito, a solução desenvolvida utilizou o Team Build para "fechar o pacote". Através de um conjunto de custom tasks do MSBuild, foi possível criar scripts de build que, de forma simples, interagiam com o Harvest.

Essas custom tasks encapsulam a API COM do Harvest (CHSDK), de modo que seu script pode conter tags tais como <Harvest.CheckIn> ou <Harvest.CreatePackage>. Simples assim :).

CodePlex!

Minha intenção é publicar esse código no CodePlex (assim que definirmos as questões legais e de licença do código-fonte). Avisarei aqui no blog quando tiver novidades. Fique atento!