tf rollback: Como voltar os fontes para um determinado ponto do desenvolvimento

Comé que a gente volta o código da nossa aplicação pra um determinado ponto do sistema no TFS?

Bem, a ferramenta dá o suporte, mas você tem que ter processo. Tem várias formas de fazer isto. Uma delas é usando labels. Pra poder voltar em um ponto no tempo, você tem que fazer o seguinte:

1. Combinar com a equipe. É, porque todo mundo tem que saber dessa combinação, preparar os fontes nos quais estão trabalhando para isto, e fazer checkin.
2. Aplicar um label aos fontes. Na janela do Solution Explorer, botão direito no diretório no qual estão os fontes desejados, opção "Apply Label".

Esta label vai ser seu "ponto no tempo" para o qual você pode voltar os fontes. Depois de tocar horror no código, pra voltar pro momento no qual você colocou a label, faça o seguinte:

1. Abra um "Visual Studio 2010 Command Prompt".
2. (opcional) Use o comando tf labels para listar o nome da label para a qual você quer fazer o rollback:
   

   tf labels *@$/Projeto /owner:* /collection:http://server:8080/tfs/testcollection

3. Mude para o diretório aonde estão os itens nos quais você deseja fazer o rollback.
4. Rode o comando tf rollback para voltar o código para o ponto desejado:
   

   tf rollback /toversion:L"Solução Criada" HelpDesk /recursive

Este último comando volta os fontes para o estado em que estavam quando a label "Solução Criada" foi aplicada. O diretório atual é o diretório imediatadamente acima do diretório "HelpDesk", no qual estão os fontes do sistema. O utilitário tf faz checkout de todos os arquivos a modificar e retorna os mesmos para o estado da label "Solução Criada". Quando você fizer o checkin agora, a solução estará como estava quando a label "Solução Criada" foi aplicada.

DSI e SDM

A MS tá investindo num trem chamado DSI - Dynamic Systems Iniciative, que tem como um dos componentes básicos uma linguagem de descrição de sistemas distribuídos: o SDM (System Definition Model), que é basicamente um esquema XML pra descrever sistemas distribuídos, seus componentes, datacenters, e a distribuição dos sistemas em um datacenter. Essa idéia vem pelo menos desde o Windows 2003 - o paper de overview da DSI no site da MS é de 2004, e segue a seguinte idéia: hoje temos o hardware e o software básico - recursos do sistema operacional e suporte nas liguagens de programação - para substituir mainframes por redes de PC's nos datacenters. A visão da MS é poder descrever sistemas e suas subdivisões (ex: executáveis e DLL's), juntamente com datacenters (máquinas, redes, appliances, etc) e a distribuição destes sistemas nos datacenters através de uma linguagem formal. O objetivo é minimizar o esforço de instalação, monitoração e modificação destes ambientes de execução de aplicações (HW + SW), automatizando o máximo possível dessas tarefas. Aí se abre um monte de possibilidades:

• IDE para o monitorar e modificar sistemas distribuídos.
• Linguagem de consulta e de modificação destes sistemas.
• Scripts para automação de deploys.
• ...

O VS hoje já tem designers para sistemas (system Designer), seus componentes (Application Designer) (EXE, DLL, web services, etc) e para "datacenters lógicos" (Logical Datacenter Designer) (sem os servidores físicos). E faz a junção disto num modelo de deploy (Deplyment Designer) e verifica se há algum problema de configuração e comunicação na arquitetura física da sua aplicação. O uso destes designers na fase de modelagem da aplicação é muito legal porque (a) obriga você, arquiteto da aplicação, a pensar nessas coisas "mundanas" e incluí-las na sua modelagem - pra não dar problemas que só serão detectados quando a aplicação for posta no ambiente de produção, e também porque (b) envolve o pessoal de administração de rede no design da arquitetura, o que é ótimo, porque eles montaram, conhecem e controlam o ambiente de hardware no qual sua aplicação vai rodar, então eles tem que ter uma palavra no assunto.

Imagina só, criar diagramas de sistemas e de datacenters em uma ferramenta, depois apertar um botão "Deploy" e aí a ferramenta pega um monte de ISO a partir de uma "biblioteca de VM's", cria as VM's no Hyper-V, configura a comunicação entre elas, configura os serviços, e instala os componentes do sistema em cada uma delas. Pronto. Um ambiente de produção instalado e funcionando em o que? meia hora? uma hora?Tamo rapidamente caminhando pra isso... Dá uma olhada no TFS Lab Manager!

[]s,
GB