Quantcast
Channel: TFS | Lambda3

Sim, eu deixei de usar o TFS. E acho que você também deveria.

$
0
0

DidntSeeThatComingJá faz mais de dez anos que tenho confiado no TFS como minha ferramenta preferida de ALM para todas as minhas necessidades de desenvolvimento, bem como a de nossos clientes. Ao longo desse tempo, tenho visto uma impressionante evolução da ferramenta – só quem mexeu no TFS 2005 consegue entender o longo caminho que a Microsoft percorreu para chegar no que ela oferece agora com o TFS 2015.

Durante todos esses anos, eu tinha a nítida sensação que de o TFS seria sempre a melhor opção. A concorrência sempre pareceu estar sempre comendo poeira! Quem poderia ameaçar o lugar de destaque do TFS?

É, parece que eu estava errado e o que parecia improvável aconteceu. A bem da verdade, já faz algum tempinho:

O TFS deixou de ser minha ferramenta preferida de ALM.

“Como assim?!” Para os leitores desse blog, a surpresa deve ser inevitável. Afinal, nunca escondi de ninguém que era um aficionado pelo TFS.

Sendo assim, o que é que estou usando agora? Qual é o substituto do TFS para mim?

Bem, sabe aquele velho dito que “melhor que isso, só dois disso”? Então, para ser melhor que o TFS, só sendo um “TFS melhorado”.

Esse cara existe, e se chama Visual Studio Team Services (VSTS).

“Hein?”

OK, sei que ficou estranho :). Vou tentar explicar melhor. (Continue lendo…)

(Cross-post de https://www.tshooter.com.br/2016/02/15/sim-eu-deixei-de-usar-o-tfs-e-acho-que-voce-tambem-deveria/)


Como licenciar corretamente o SQL Server do TFS

$
0
0

Licensing / Legal

OK, eu entendo que apesar de tudo que falei em meu post sobre TFS e VSTS você pode ter suas razões para querer usar o TFS on-premises. Quando uma empresa decide usar o TFS e se prepara para fazer a instalação, descobre que um dos pré-requisitos da instalação é o SQL Server. É nesse momento que surge a dúvida: “como licencio corretamente o SQL Server que será usado pelo TFS?”

A resposta nem é tão complicada mas, como tudo que envolve licenciamento, requer cuidado e atenção. Eis as respostas a algumas das perguntas mais frequentes que já nos fizeram sobre esse assunto.

Preciso pagar pelo SQL Server?

Normalmente não. O TFS incluir uma licença de SQL Server Standard que pode ser usada apenas para uso do próprio TFS. Ou seja, não pode haver nenhum outro uso – nem banco de dados, nem nada – que não seja interno do próprio TFS.

De onde baixo a mídia do SQL Server do TFS?

Depende de como você obteve sua licença do TFS: via “caixinha”, através de uma licença de volume ou através de uma Assinatura MSDN:

  1. “Caixinha” (retail): Quando você compra uma versão de retail (a “caixinha”, com mídia física e tudo), recebe dois DVDs – um do TFS, outro do SQL Server. Nesse caso fica fácil – basta usar essa mídia do SQL Server;
  2. Licença de volume: Este cenário se aplica àqueles clientes que compraram uma licença de TFS através de algum contrato de volume como Open ou Enterprise Agreement (EA). Neste caso, tanto o TFS quanto o SQL Server Standard podem ser baixado do site VLSC;
  3. Assinatura MSDN: Esta é a maneira mais comum – e mais em conta – de se obter uma licença do TFS. Se você tiver um Visual Studio com uma Assinatura MSDN, pode baixar tanto o TFS quanto o SQL Server a partir do site de Assinantes MSDN.
    IMPORTANTE: Você sempre deve baixar o SQL Server Standard a partir do site de Assinantes MSDN, mesmo que tenha licenças de SQL Server à disposição no VLSC. Caso contrário, estará pegando a versão incorreta e não estará devidamente licenciado.

Posso instalar um dual-server?

Você pode instalar o TFS e o SQL Server em servidores separados, sem pagar por isso, apenas se você tiver mais de uma licença de TFS. O mais comum é: você tem várias licenças de Visual Studio com MSDN no seu time. Cada uma dessas licenças dá direito ao TFS. Nesse caso, separe duas licenças; cada uma delas licencia um servidor (TFS de um lado, SQL Server Standard do outro lado).

Posso usar a versão Enterprise?

O TFS inclui como versão gratuita apenas o SQL Server Standard. Caso você prefira usar o SQL Server Enterprise, deve licencia-lo à parte.

Posso usar a versão mais recente do SQL Server?

De graça não. Você pode usar apenas a versão que estiver explicitamente mencionada no Visual Studio Licensing White Paper. Portanto, se esse documento estiver dizendo (por exemplo) que o TFS é acompanhado pelo SQL Server 2014, então não é permitido instalar o SQL Server 2016. O documento é atualizado com frequencia; numa atualização futura do white paper a versão é atualizada e a partir daí você pode atualizar seu SQL Server.

Onde posso obter mais detalhes?

A fonte oficial de informação é o Visual Studio Licensing White Paper. Ele sempre terá a última palavra no tocante a licenciamento de Visual Studio e TFS.

 

Um abraço,
Igor

 

(Post publicado originalmente em http://www.tshooter.com.br/2016/03/04/como-licenciar-corretamente-o-sql-server-do-tfs/)

Team Foundation Server Update 2 RC1

$
0
0

Diferente do Visual Studio 2015 Update 2 CTP, veja post, o Update 2 para o TFS já se encontra em RC1, release candidate, ou seja, agora são correções de bug e dificilmente teremos mudanças nas features entregues.

Vamos analisar as principais.

Como já comentei antes aqui no blog, o TFS está atrasado em relação as features implementadas no VSTS. Isso se deve a política “cloud first” que a Microsoft abraçou em relação ao produto e também por que é muito mais fácil e rápido distribuir novidades para uma instalção na nuvem do que updates para download! Essa última é uma das grandes vantagens da versão on-line em relação a sua versão on-prem: velocidade nas atualizações.

Melhoria ao apagar e criar Team Projects

Agora é possível criar e apagar TP’s através da API REST. Também foi implementado a criação de TP através da drop-down, ficando mais próximo do VSTS e apagar um TP na visão administrativa da TPC.

Re-ordenação de cartões nos boards

Essa otimização traz uma mudança no modo de trabalho do time, ao reordenar cartões quando for mudada colunas: reordenar sem restrições ou seguir a ordem do backlog.

Considero a última opção melhor se você estiver tentando ser aderente a um processo como Scrum: o goal da Sprint é determinado pelo PO em um objetivo de negócio. Já se você está em um sistema Kanban/Lean, essa mudança dará mais liberdade.

Apagar work items

A ação de apagar WIT’s sempre aparece em um consultoria. O cliente quer apagar um WIT, pois pode distorcer métricas que são extraídas do TFS. Particularmente eu acho que o estado de Removido é melhor, pois mostra outras métricas… Mas isso é assunto para outro post. Além de contar com uma lixeira, que permitirá recuperar o WIT, não será preciso se preocupar de requisitos sumirem do backlog, já que a feature irá contar com uma permissão específica.

Teclas de atalho global

Eu gosto de teclas de atalho, talvez seja por que gosto de linha de comando. Mas elas realmente facilitam o trabalho.  São as mesmas teclas usadas no VSTS.

Modo de edição de dashboards

O dashboards, que estão ganhando cada vez mais features e estenções, agora tem um modo de edição para mover os tiles/widgets, evitando alterar o quadro acidentalmente. No modo de edição é possível mover, remover, configurar e adicionar widgets.

Auto-refresh dos dashboards

Se você usa Gestão a vista… não sabe o que é? Aguarde post!… Essa feature vai permitir utilziar o dashboard em um monitor, fazendo o refresh dos dados. É o fim de códigos javascript que faziam essa ação.

Contrução de widgets nos dashboard

Como eu disse acima, o dashboard está evoluindo bastante, e essa é mais uma das features que ele está ganhando. Colocar um gráfico baseado em WIT’s, build ou testes será muito fácil e será feito diretamente no quadro.

Gráficos baseados em querys de work item nos dashboard

Já era possível desde a versão 2013 fixar um gráfico baseado em uma query, agora com o widget no dashboard não será preciso ir até as querys para fazer o gráfico. E ainda está mais fácil de criar e customizar.

Variáveis @mentions e #ID

Agora é possível usar ‘@’ para mencionar pessoas em comentários ou discussões no pull request, também é possível usar ‘#” para se referir a um WIT. Esse simbolos vão criar links que vão abrir o perfil da pessoa ou o WIT descrito, tornando experiência do usuário mais interativa.

Widget de Pull request

Com este widget será possível visualizar pull requests para o time, por exemplo, ou para o usuário logado, ou criados por este. É possível navegar para o pull request selecionado ou visualizar um sumário.

Widget Markdown

Este widget dá a possibilidade de escolher um arquivo markdown, os famosos README.MD, no repositório e exibi-lo no dashboard. Avisos do que é preciso ter instalado na máquina do desenvolvedor, ou sobre a última versão do código, agora ficam a vista no dashboard.

Common identity picker

Melhoria na busca e descoberta de usuários e grupos, em vários locais, como controle de versão, release management e lugares que possam usar @, veja tópico acima.

Gated check-in para Team Foundation Version Control

Agora é possível acionar o gated check-in através de uma política de branch, como no Git. Portanto, se um check-in não tiver o build OK, ele será rejeitado.

Controle de versão web

O hub Code vem com várias novidades, aviso de build com sucesso na branch que está sendo exibida, mudanças de ícones, melhoria na rastreabilidade de pull requests, etc…

Support para Team Foundation Server extensions

Suporte para as extensions! O TFS já tinha permitia a construção de plug-ins server-side, agora foi implementado o mesmo suporte existente no VSTS. Ou seja, poderá ser instalado nas TPC’s as extenções disponíveis no marketplace.

Atalhos de teclado para board Kanban

Mais atalhos! Agora WIT’s no quadro Kanban, criar, mover entre colunas ou swinlanes e expandir ou retrair itens.

Já disse que gosto de atalhos de teclado?

Melhorias e features no Build, Melhorias e features de Testing e Nova versão do Release Management

Esses três últimos itens vou comentar com mais detalhes no post de amanhã!

Comentários sobre melhorias e features do Team Foundation Server Update 2 RC1 – Parte 2

$
0
0

Continuando do post anterior com os comentários sobre melhorias e novas features que o Update 2 do TFS 2015 traz.

Este post é sobre as melhorias e novas features relacionadas a build, test e release.

Melhorias e features relacionadas ao build

Administração de Build

Administradores de filas de build agora podem controlar quem cria definições de build e release para a fila. Isso permite a cada time ter e administrar os seus próprios recursos de build.

Estatísticas históricas

Estatísticas históricas dos agentes de build e release estão disponíveis através da visão de queue e do pool, dando aos administradores um melhor entendimento de quanto os recursos de build estão consumindo.

Melhoria de UI no build

O wizard de criação de uma nova definição de build foi simplificado, agora as principais informações sobre fontes e filas são selecionadas antes de escolher um template.

Visão estendida de resultados do build

O build summary,  pode ser estendida com informações customizadas e outras visões usando o extension framework. Também é possível estender através da publicação de um arquivo markdown, utilizados normalmente em arquivos README.md (arquivo texto plano com marcações específicas, leia mais aqui).

Publicação de tasks como extensões

Possibilidade de usar a gallery para publicação de tasks, além das existentes de extensões do TFS, Visual Studio, Code, …

Melhorias e features relacionadas a Testing

Resultados de Test no build

A análise de resultados de teste ganhou melhorias no sumário da página de Build:

  • Um sumário agora agrega todos os resultados de teste no build
  • Testes que falham pela primeira vez em uma correção de bug recebem um flag de New failure, facilitando a identificação em testes de regressão. Para testes que continuam falhando depois de vários builds é possível identificar em qual build o bug foi introduzido!
  • Gráficos de tendência mostram a contagem de testes que falharam e a duração do teste
  • O status do teste é disponibilizado através de uma notificação via email.

Melhorias no teste manual

    • Filtro de planos de teste, possível criar uma query de WIT’s baseada em filtros de planos de teste
    • Visualização dos testes de suítes filhas, trazendo uma visão única da suíte selecionada e suítes filhas com apenas um clique
    • Apagar planos de teste, diretamente do hub Test

Teste exploratório direto na web

Plug-in para o Chrome, através do Marketplace, com as seguintes features:

  • Captura de screenshot e notas simplificadas
  • Submissão de bugs, durante uma sessão de teste exploratório, as notas, screenshots com anotações, team area e iteration path, SO e navegador; são informações capturadas automaticamente.
  • Busca e alteração de bugs existentes, durante a criação de um bug, a extenção irá automaticamente buscar e listar bugs existentes baseado na correspondência do título, dando a opção de alterar um bug existente com as novas informações, barrando a criação de bugs duplicados.
  • Criação de WIT’s do tipo Task.
  • Busca de WIT’s para associação com a sessão de teste exploratório, aumentando os benefícios de rastreabilidade.

Release

Por último mas não menos importante, Release Management. Neste update o produto Release Management é absorvido pelo TFS, e se transforma em um serviço integrado. Este update é praticamente uma major version do TFS. O client é abandonado e da mesma maneira que o TFS Build foi migrado para a interface web, no hub Build, o RM virou o hub Release.

Essa mudança estrutural permite que releases managers, ou gerentes de configuração, não precisem mais do client para criar, editar e administrar o pipeline de release, assim como no build.

Para visualizar as features do Release veja este vídeo com o que já está implementado no VSTS:

No futuro irei publicar mais informações sobre releases no TFS aqui no blog, abordando assuntos como automação de ambientes através de Powershell DSC, container com Docker, etc…

 

Relatório no VSTS com Microsoft Excel

$
0
0

Como já escrevi no post sobre o VSTS, Adeus VSO… Olá VSTS!, o Power BI vem aí para cobrir o gap de relatório existente. Porém enquanto ele não vem, como resolver o problema?

É possível utilizar o Microsoft Execel! Como, é o que vamos ver a seguir…

Se você não tem Reporting Services e nem Power BI… vá de Excel

O Microsoft Excel pode ser usado para gerar relatórios, através do plug-in Microsoft Team Foundation Server Office Integration 2015 Update 1, para instalar utilize o link.

Para saber mais o Igor Abade fez o post A vida de analistas e gerentes acabou de ficar mais fácil com o “TFS Office Integration Installer”

Com o plug-in é possível executar querys do TFS, que funcionam como uma fonte de dados.

Query no TFS/VSTS

Para o exemplo será utilizado a VM do Brian, porém, da mesma maneira é possível conectar ao VSTS.

Vá em Queries no hub Work, uma das query disponível é a de backlog do time Web.

2016-02-22 05_21_10-Product Backlog - Web Team - Microsoft Team Foundation Server

Essa query retorna três work items.

Excel

Conectando

Abra o Microsoft Excel, depois de o plug-in instalado, clique na aba Team, em seguida no botão New List (1).

2016-02-22 05_25_00-Book1 - Excel

A mesma janela de conexão com o TFS ou VSTS usada no Visual Studio é aberta. É preciso usar o mesmo procedimento de conexão, e em seguida escolher a Team Project Collection e depois o Team Project.

2016-02-22 05_25_51-Relatório no VSTS - Open Live Writer

Selecionando a query

Em seguida, a janela New List é aberta e será nela que selecionaremos a query a ser executada.

No dropdown list da opção Query list, escolha Shared Queries > Product Backlog – Web Item.

2016-02-22 05_29_22-Greenshot

Relatório

Com query selecionada do passo anterior a planilha receber o resultado.

2016-02-22 05_30_31-Book1 - Excel

Este é um relatório bem simples e fácil de se fazer com o Excel. Deixando as querys prontas no TFS/VSTS, é só executá-las.

Agora os stakeholders não precisam mais do Visual Studio para gerar um relatório no Excel, como visto no post do Igor Abade

É possível incrementar os relatórios, com gráficos, mais informações. Vamos ver nos próximos posts como ter os relatórios default do process template Agile no VSTS.

Você conhece o Visual Studio Dev Essentials?

$
0
0

O programa Visual Studio Dev Essentials da Microsoft é direcionado tanto para desenvolvedores da plataforma Microsoft como para novos desenvolvedores que queiram aprender mais sobre as ferramentas da empresa.

Vamos conhecer um pouco mais sobre ele.

O programa

Para se cadastrar no programa você pode acessar o link:

https://www.visualstudio.com/pt-br/products/visual-studio-dev-essentials-vs.aspx

É preciso ter uma Microsoft Account.

O objetivo do Dev Essentials é prover de forma gratuita, para desenvolvedores que queiram estudar, ferramentas, que antes estavam disponíveis somente através de licenciamento pago, e também treinamentos on-line , suporte e voucher para gastar no Azure.

Agora não tem mais desculpa!

Benefícios

Ferramentas

O Dev Essentials tem uma licença de Visual Studio, versão Community. Diferente das versões gratuitas no passado da IDE Visua Studio, com esta é possível conectar no TFS/VSTS, e é bem completa. Eu disse TFS/VSTS? Tem uma versão do TFS, Express, e é possível também usar o VSTS até 5 usuários gratuitos.

Além de Azure App Service, Application Insights, Power BI, Office Online, Xamarin… A relação está disponível ao se cadastrar.

Destaque para um crédito de 25 dólares em Azure, além das camadas gratuitas é possível testar algum produto pago.

Treinamento

Microsoft Virtual Academy, provê diversos treinamentos online em linguagem, framework, ferramentas, redes, …

É possível montar vários planos de estudo, somente desenvolvimento, redes, … E existe até um board mundial para pontuar, no melhor estilo gamefication.

Um grande destaque aqui são 6 meses de cursos na Pluralsight! Um site que vale a pena acompanhar e assinar. Os instrutores são pessoas conhecida na comunidade e os treinamentos tem um ótimo valor agregado.

Suporte

Como membro do programa você tem direito a suporte prioritário em fóruns da Microsoft. Quando eu entrei na área de desenvolvimento de software, esse foi um meio que utilizei bastante como aprendizado. E tem também um voucher para uso no HackHands, para mentoring.

Stories Overview report no VSTS, com MS Excel e Powershell

$
0
0

Relatórios são o calcanhar de Aquiles do VSTS. Já escrevi sobre isso no post Adeus VSO… Olá VSTS!. Não adianta. Nuvem, zero infra, custo menor, etc… etc… Mas se o gerente não tiver como extrair métricas, ou mesmo a equipe, então não serve como acompanhamento. Não quero entrar no mérito do “me diga como me medes, que te direi como irei me comportar” (ou não direi…). Mas métricas são importantes.

Enquanto não temos o Power BI aberto e a todo o vapor, ou caso você queira aprender como extrair dados para fazer experimentações, este post é para você.

Vamos utilizar Powershell, o MS Excel, para reproduzir o mesmo relatório e por utilizá-lo com o VSTS. Ou você poderá utilizar com o TFS e ainda expandir informações apresentadas.

O problema

O TFS, a versão on-prem, tem uma integração muito boa com o Reporting Services, uma feature do MS SQL Server. Na versão SaaS, não existe essa integração… mas podemos fazer uso de uma ferramenta muito interessante, o add-in Team Foudation. Eu já escrevi sobre como instalar no post Relatório no VSTS com Microsoft Excel.

A ideia é reproduzir o relatório Backlog Overview, padrão do process template Scrum, então primeiro temos que conhecer ele melhor.

Stories Overview

2016-03-09 03_42_08-Stories Overview - Report Manager ‎- Microsoft Edge2

Para que serve este relatório

No ponto (1), da imagem acima, está a explicação da utilidade deste relatório: mostrar o quanto já foi gasto em implementação (%) de cada User Story e o quanto falta (horas) (2). O resultado dos testes de aceite (3). E o número de bugs relacionados a cada User Story (4).

É uma fotografia do instante em que o relatório é gerado sobre a Iteração.

O que este relatório ajuda responder

Normalmente os relatórios padrão trazem uma seção sobre o que o relatório ajuda a responder. Neste caso está faltando. Mas ela está disponível na documentação on-line do MSDN, no link https://msdn.microsoft.com/en-us/library/dd380648(v=vs.140).aspx

Procurando por Questions That the Report Answers, terá a seguinte relação:

Andamento do trabalho
  • O trabalho restante para cada User Story, corresponde a expectativa?
  • As User Storys foram implementadas conforme ranking?
  • Quantos testes estão definidos por User Story e quantos estão passando?
  • Quais User Storys que estão sendo implementadas e não possuem testes associados?
qualidade
  • Quantos Test Cases rodaram por história e quantos passaram?
  • Quantos bugs ativos cada User Story tem?
  • Os bugs foram encontrados em histórias que foram testadas?
  • Os bugs estão resolvidos ou continuam ativos?
Risco
  • Quais User Story estão em risco?
  • Quais User Storys não estão prontas para Release?
  • Quais User Storys podem ser entregues?

Se o coordenador, ou o gerente, ou o diretor olhar para esse relatório diariamente, não é preciso fazer micro-gerenciamento, ele é informado a cada instante que é gerado se o time está progredindo e se está chegando perto da meta; até mesmo se a qualidade de entrega está satisfatória.

Como usar este relatório

Esta última seção, também comum de ser encontrada, mas não neste exemplo; é a própria página em si, o link passado acima.

Com seções como permissões em relação ao relatório, dados, critério usados na query do relatório, atividades necessárias para colher as informações e até mesmo como interpretá-lo.

Portando para o Excel

Agora que temos todas as informações para reproduzir o relatório, vamos usá-las para começar a construi-lo no próximo post.

Estendendo o Team Foundation Server ou Visual Studio Team Services

$
0
0

A melhor definição para Team Foundation Server é, ao invés de um servidor ou serviço, uma plataforma. Porque ele é extensível. Assim como o Visual Studio Team Services, a versão SaaS do TFS.

E por isso é possível integrá-lo facilmente utilizando a estrutura Client Object Model com código .Net.

Client Object Model

Apesar de hoje termos disponível um conjunto de API’s REST, utilizar as client libraries disponibilizadas pela Microsoft é, ainda, a maneira mais fácil de fazer uma integração.

IC490584

Distribuição dos componentes

Até pouco tempo as dll’s não podiam ser distribuídas com uma aplicação e não existia um pacote, ou SDK. Portanto era preciso ter instalado o TFS na máquina do desenvolvedor para que fosse possível referenciar e usar as dll’s.

Junto com a versão 2013, foi lançado um pacote que resolvia esse problema, ou era possível instalar o Team Explorer e as dll’s estavam disponíveis. Mas, recentemente com a criação de um pacote Nuget com as bibliotecas disponíveis ficou ainda mais fácil!

Extracting effective permissions from TFS

Este nome comprido Extracting-effective-permissions-from-TFS, foi dado a uma ferramenta que começou a ser desenvolvida pelos ALM Rangers, que tem uma função muito solicitada por empresas que usam o TFS: um relatório com as permissões atuais dos usuários cadastrados. Ao invés de implementar essa feature no produto, ele foi “estendido”, demonstrando assim minha afirmação de o TFS ser mais que um servidor, e sim uma plataforma.

Eu já comentei sobre essa ferramenta no post Permissões no TFS/VSTS, e já que pretendo utilizá-la em um próximo post, vou mostrar no código dela o usuo do pacote Nuget.

Microsoft.TeamFoundationServer.ExtendedClient

Este é o pacote que iremos usar. É possível encontrar mais informações sobre os pacotes disponíveis e os seus usos em https://www.visualstudio.com/en-us/integrate/get-started/client-libraries/dotnet.

Alterando o código

A ferramenta está disponível na conta dos ALM Rangers no GitHub: https://github.com/ALM-Rangers/Extracting-effective-permissions-from-TFS
Mas como eu quero submeter uma alteração no futuro, vou fazer o fork para a minha conta, para isso é só acessar o link logado com a sua conta do GitHub e clicar em Fork.

2016-03-23 02_26_11-ALM-Rangers_Extracting-effective-permissions-from-TFS_ We are pleased to announc

Pronto! Já tenho um repositório clonado na minha conta.

2016-03-23 02_27_54-egomesbrandao_Extracting-effective-permissions-from-TFS_ We are pleased to annou

Agora é só clonar na máquina.

2016-03-23 02_24_04-Administrador_ Windows PowerShell

Ao abrir a solution no Visual Studio, em References você verá que as dll’s não estão disponíveis, elas não podem ser distribuídas com o código e eu não tenho o TFS instalado na minha máquina.

2016-03-23 02_34_57-Microsoft.ALMRangers - Microsoft Visual Studio (Administrator)

Vamos instalar o pacote Microsoft.TeamFoundationServer.ExtendedClient, mas antes vamos restaurar os que já estão sendo usados e para isso clique com o botão direito do mouse na solution, escolha Restore NuGet Packages. Como a solução já faz uso de um pacote ele será restaurado.

2016-03-23 02_41_49-Microsoft.ALMRangers - Microsoft Visual Studio (Administrator)

Agora sim, pesquise pelo pacote:

2016-03-23 02_51_41-Microsoft.ALMRangers - Microsoft Visual Studio (Administrator)

Clique em Options e escolha o projeto que deseja instalar o pacote:

2016-03-23 02_54_15-Microsoft.ALMRangers - Microsoft Visual Studio (Administrator)

Serão instalados pacotes adicionais que são referenciados neste que escolhemos, como por exemplo Microsoft.TeamFoundationServer.Client, se você acessou o link para os pacotes disponíveis, verá que este pode ser usado diretamente quando a sua aplicação acessa o TFS 2015, no caso precisamos usar o Extended para compatibilidade com versões anteriores. Outros pacotes serão baixados e solicitado as devidas aprovações.

Pronto! Perceba que os ícones de alerta nas referências desapareceu… porém…

Problema

Esse código faz referência a Microsoft.TeamFoundation.Git.Common, que não está disponível nos pacote NuGet!

2016-03-23 02_55_56-Microsoft.ALMRangers - Microsoft Visual Studio (Administrator)

Esse é um problema que irei resolver em um post futuro, por hora, vamos apenas comentar as linhas que fazem uso dessa referência:

2016-03-23 05_15_40-Microsoft.ALMRangers - Microsoft Visual Studio (Administrator)

CTRL + Shift + B… se reclamar que não tem o NuGet.exe

2016-03-23 03_42_46-Microsoft.ALMRangers - Microsoft Visual Studio (Administrator)

Baixe em https://www.nuget.org/nuget.exe e coloque no path indicado. Agora você deve conseguir buildar o código!

Esse post foi mais um setup de um projeto que estou iniciando e vou começar uma série de posts usando o pacote de extensão do TFS.

 


Smoke Tests, Deployment e Rollback Automatizados

$
0
0

Hoje – na verdade, agora há pouco Alegre – dei uma palestra sobre Smoke Tests no DevOps Summit Brasil 2016. Olha só do que falamos:

Já pensou se você pudesse ter um processo de deployment 100% automatizado, onde a validação do ambiente – e até mesmo a decisão de rollback – pudessem ocorrer de forma automática?

Nesta palestra vamos mostrar como devs e IT Pros podem trabalhar juntos para montar um pipeline automatizado de deployment, com foco no processo de smoke tests e de promoção/rollback automáticos.

Ah, quer o PPT da palestra? Ei-lo Alegre:

Você participou da palestra e quer compartilhar seu feedback? Não participou mas quer saber mais sobre o assunto? Então deixe seu comentário!

 

Um abraço,
Igor

 

(Cross-post de http://www.tshooter.com.br/2016/05/07/smoke-tests-deployment-e-rollback-automatizados/)

Monitorando um backup full na base de dados do Team Foudation Server

$
0
0

Quando fazemos migração de versão ou um update no Team Foundation Server é comum momentos antes executarmos um backup full da base de dados, porém quando temos uma base muito grande o tempo do backup acaba ultrapassando 30 minutos e a ferramenta do TFS corta o feedback visual e te dá uma outra maneira de acompanhar o processo. Porém ela não é muito amigável. Mas felizmente desde a versão 2005 do MS SQL Server temos uma feature chamada Dynamic Management Views (DMV), e com ela temos uma outra maneira de acompanhar o backup.

Backup no TFS

Configuração

Sempre é bom lembrar que para realizar o backup no TFS é recomendável o uso da ferramenta no Administration Console (1). É possível criar facilmente uma rotina de Schedule Backup (2), que atende, senão todos, a maioria dos cenários. Siga a documentação para maiores detalhes. A ferramenta executa procedimentos que se não forem feitos pode invalidar o backup e não será possível fazer restore.

2016-05-22 22_20_31

É altamente recomendável executar testes de disaster recovery regularmente, garantindo assim a restauração do ambiente em caso de falha

Bases adicionais

Normalmente o TFS acaba tendo um servidor de banco de dados exclusivo. E outras ferramentas de ALM podem utilizar esse servidor, como um serviço de Nuget privado ou mesmo o Release Management. Não se esqueça de adicionar essas bases ao seu processo de backup. Você pode incluí-las neste procedimento.

2016-05-22 22_11_55

Backup Full

Mesmo com os backups agendados, antes do upgrade ou update, tirar um backup full garante que foi armazenado com segurança as últimas transações executadas no TFS.

O Backup Full é executado baseado nas configurações do Scheduled Backup, portanto é necessário configurá-lo e adicionar Reporting Services ou bases do Sharepoint

Execução

Após clicar no link ele irá preparar o backup e executar em seguida.

2016-05-22 22_03_56-Greenshot

Passando os 30 minutos a janela irá fechar e será recomendados acompanhar o job através da tela de monitoramento. Porém, como ela não é tão amigável vamos usar uma instrução Dynamic Management Views (DMV) para dar um feedback melhor, através do SQL Management Studio.

Conecte-se no servidor do MS SQL Server através da ferramenta e abra uma janela para executar uma query, copie, cole e clique em Execute.

SELECT session_id as SPID, command, a.text AS Query, start_time, percent_complete, dateadd(second,estimated_completion_time/1000, getdate()) as estimated_completion_time 
FROM sys.dm_exec_requests r CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) a 
WHERE r.command in ('BACKUP DATABASE','RESTORE DATABASE')

2016-05-22 22_07_00-Greenshot

No destaque da imagem acima é possível ver a hora de início e de fim do backup, e principalmente o percentual executado, dando uma noção de quanto tempo irá levar a tarefa.

(Cross-post de http://egomesbrandao.com.br/2016/05/23/monitorando-um-backup-full-na-base-de-dados-team-foudation-server/)

Entenda o versionamento da API REST do TFS

$
0
0

Uma das coisas mais legais do TFS 2015 é a introdução da API REST. Como quase tudo que envolve o TFS e o VSTS, o desenvolvimento dessa API é incremental.

Porém, desenvolvimento incremental de serviços introduz dois problemas: Como evoluir a API sem quebrar clientes antigos? E em qual versão do produto foi introduzida uma certa API?

A resposta a ambas as perguntas é a mesma: o modelo de versionamento da API REST do TFS.

A documentação da API REST do TFS pode ser encontrada no site do Visual Studio. Lá, na página de introdução, há uma dica importante:

Tip: To avoid having your app or service broken as APIs evolve, specify an API version on every request.

A página com a documentação da versão da API, mencionada no link acima, indica:

  • Como incluir o número de versão numa chamada à API; e
  • Qual a versão mais recente de cada uma das APIs.

Essas informações são muito importantes para resolver o primeiro dos problemas que mencionei no início deste post; entretanto, não resolvem o segundo problema. Então agora vou te contar como saber quando uma certa API foi introduzida. O segredo está no número da versão.

O número da versão da API

A versão da API informa quando ela foi introduzida. O esquema de versionamento, por sua vez, é alinhado com as releases do TFS. Assim:

Versão da API

  • 2.0: TFS 2015 RTM
  • 2.1: TFS 2015 Update 1
  • 2.2: TFS 2015 Update 2
  • 2.3: TFS 2015 Update 3
  • 3.0: TFS v.next (TFS “15”)

A lista acima indica a versão inicial em que uma API foi introduzida. Assim, como exemplo, uma API marcada com a versão 2.0 estará disponível a partir do TFS 2015 RTM. Vale lembrar que todas as APIs estão disponíveis no VSTS, independentemente de versão.

Ah, em tempo: Muitas das APIs estão documentadas como “1.0”,  o que significa que elas foram introduzidas antes do TFS 2015 RTM. Por isso, com apenas algumas poucas exceções (Build APIs), todas as APIs com versão 1.0 estão disponíveis no TFS 2015 e posteriores.

 

Um abraço,
Igor

 

(Agradecimento especial a Will Smythe, da Microsoft, por ter compilado a lista de versões da API)

 

(Cross-post de http://www.tshooter.com.br/2016/05/25/entenda-o-versionamento-da-api-rest-do-tfs/)

Lambda3 no Mobile & Cloud Hack Days

$
0
0

Mobile & Cloud Hack Days foi um evento que ocorreu no final de maio, com o intuito de apresentar diversas tecnologias que fazem parte do ecossistema de Nuvem e Desenvolvimento móvel de aplicações. Nos 5 dias do evento, inúmeros palestrantes se revesaram apresentando conteúdo que auxiliará você a Planejar, Construir e Plugar dispositivos móveis na nuvem.…

Continue lendo

Evite que usuários acessem o VSTS de fora do ambiente de trabalho

$
0
0

Desde que o VSO VSTS começou a ser avaliado por empresas como alternativa ao TFS (você sabia que o VSTS é bem mais legal que o TFS, né?), uma dúvida surgia com uma certa recorrência:

Mas se eu colocar o código-fonte da minha empresa na nuvem, meus desenvolvedores podem acessar o código fora do ambiente de trabalho! Eu não quero que meus devs tenham acesso ao código quando estiverem fora da minha rede!

E aí, #comofaz?

Como é de praxe nos meus posts, não vou entrar no mérito da questão (“mas por que você quer proibir o acesso dos seus devs?”). O que interessa é que esse cenário é comum e vale a pena ser discutido.

O que nós queremos é limitar o acesso dos desenvolvedores, de modo que eles possam se conectar ao VSTS apenas quando estiverem na rede corporativa. Fora de lá, o acesso precisa ser barrado.

Normalmente, a primeira solução que vem à cabeça da maioria dos caras de Infra/Rede, quando deparados com esse problema, é “vamos limitar por IP. Libera apenas o IP público da empresa para conectar no VSTS e barra o resto.” Bem, só tem um probleminha: não funciona.

O “probleminha” é que o VSTS não oferece nenhum tipo de filtro baseado em IP – portanto, não dá para fazer como no SQL Azure, em que você adiciona e/ou remove os IPs que podem acessar o serviço no Azure.

Configuração de IPs no SQL Azure - que *não* funciona no VSTS!
Legal, né? Você vai, filtra os IPs e pronto! Pena que não funciona no VSTS – simplesmente porque o VSTS não tem nada parecido!

O “truque” está em tirar proveito da integração entre o VSTS e o Azure Active Directory (Azure AD), pois este oferece o recurso que precisamos para limitar o acesso à nossa conta: o Azure AD Conditional Access.

Azure Active Directory Conditional Access

O Azure AD Conditional Access é um recurso do Azure AD Premium que permite limitar as condições em que usuários de um domínio AAD podem se autenticar. Além de poder ser usado para, por exemplo, exigir um login por MFA (multi-factor authentication), o Conditional Access pode ser usar para bloquear logins que venham de fora da rede corporativa.

Azure AD Conditional Access
Azure AD Conditional Access (clique para ampliar)

Configurando o VSTS

Para ativar o Acesso Condicional, iremos partir das seguintes premissas (que, portanto, não serão discutidas neste post):

  1. A conta do Visual Studio Team Services já está atrelada a um diretório AAD; e
  2. Seus usuários do VSTS têm licenças de Azure AD Premium associadas às suas contas.

Para impedir que seus usuários possam acessar o VSTS quando eles estiverem fora do escritório, acesse o Portal Clássico do Azure, abra a seção do Active Directory (1), selecione seu diretório (2) – Lambda3, no nosso exemplo –  e, então, vá até a aba de Aplicações (3). Por fim, clique em Visual Studio Online (4):

Abrindo as configurações do VSTS no Azure AD
Abrindo as configurações do VSTS no Azure AD (clique para ampliar)

Agora, vamos configurar o VSTS.

Primeiramente, clique na aba de Configuração (1) e habilite as regras de acesso (2). Nesse momento, você deve decidir se pretende aplicar essas regras a todos os usuários de seu diretório ou apenas a algumas pessoas (3). Vem então o mais importante: impedir o acesso quando os usuários estiverem fora da rede corporativa (4).

Configurando o Azure AD para impedir logon fora da rede corporativa
Configurando o Azure AD para impedir login fora da rede corporativa (clique para ampliar)

Como ele sabe se estou fora do escritório?

Na página de configuração do serviço de Multi-factor Authentication do Azure AD, há uma área onde você pode informar quais são os intervalos de endereços IP que representam suas redes corporativas. São esses os endereços que o Acesso Condicional usará para saber se seus usuários estão dentro ou fora do escritório. Se ele estiver tentando fazer login a partir de um endereço IP fora de algum desses intervalos, o acesso será bloqueado.

Configuração dos intervalos de endereços IP que o Azure AD considera rede corporativa
Configuração dos intervalos de endereços IP que o Azure AD considera rede corporativa (clique para ampliar)

Conclusão

Apesar de o VSTS não ter suporte nativo a filtragem de acesso por IP, o Azure AD Conditional Access pode ser usado para se obter um resultado similar. Uma coisa importante de se destacar é que o acesso por PATs e Alt Creds não está coberto pelo Acesso Condicional – ou seja, podem ser usados normalmente quando fora da rede externa.

 

Um abraço,
Igor

 

(Cross-post de http://www.tshooter.com.br/2016/06/08/evite-que-usuarios-acessem-o-vsts-de-fora-do-ambiente-de-trabalho/)

Stories Overview report no VSTS, com MS Excel e Powershell – Parte 2

$
0
0

Na primeira parte desta série sobre como construir um relatório Stories Overview no VSTS com MS Excel e Powershell foi explicado as diversas partes do relatório existente no template Agile do Team Foudation Server.

Nesta segunda parte será visto como buscar as User Stories, que são a parte principal deste relatório.

Powershell + TfsCmdLets

A maneira mais fácil de trabalharmos com a API do TFS/VSTS é via scripts Powershell encapsulando a API, e para isso já existe um projeto bem abrangente, open source e que aceita contribuições da comunidade!

TfsCmdLets

Criado por Igor Abade o TfsCmdLets é um projeto que une o poder Cmdlets PowerShell  com as API’s do Team Foundation Server e Visual Studio Team Services. Eu já havia comentado brevemente sobre ele e usado no post Administrando usuários, grupos e permissões no console com TFSSecurity. Mas agora faremos um uso intensivo dele na construção do relatório.

Você pode baixar o código fonte aqui.

Com o Windows 10 e Powershell 5 é muito fácil de instalar, basta:

Install-Module TfsCmdLets

Para verificar se a instalação foi feita:

Get-Module

2016-06-08 22_06_43-

Agora para podermos usar com o TFS/VSTS precisamos conectar a Team Project Collection e a um Team Project, para isso, vamos executar as linhas abaixo, e lembrando que eu vou utilizar a nossa conhecida VM do Brian Keller, com o Team Project de exemplo TailspinToys:

Connect-TfsTeamProjectCollection http://vsalm:8080/tfs/TailspinToysCollection

Connect-TfsTeamProject "Tailspin Toys"

Para testar vamos ver as Iterations cadastradas para esse TP:

Get-TfsIteration

2016-06-08 22_08_26-

Bem fácil não?

Buscando as Stories

Vamos construir nossa primeira query do relatório, que é buscar as User Stories, obviamente, já que o relatório é sobre isso.

2016-06-08 22_14_02-

Baseado na imagem acima e usando o filtros Team Project e Iteration… vamos lá! Se eu não soubesse nada sobre o comando, para encontrá-lo posso usar o cmdlet Get-Command, usando o parâmetro para determinar o módulo que eu vou buscar, TfsCmdLets, e algo no sobre o nome, por isso o *workitem*:

Get-Command -Module TfsCmdLets -Name *workitem*

Retornaria:

2016-06-08 22_20_34-

Portanto o mais provável para o nosso relatório seria Get-TfsWorkItem, para saber sobre ele:

Get-Help Get-TfsWorkItem

2016-06-08 22_22_03-

Para esta query é preciso usar 2 parâmetros: Work Items do tipo User Story e que estejam na Iteration 2. Como este cmdlet não tem um param para eles vamos usar o parâmetro Filter. Para quem já customizou um WIT, será fácil lembrar os nomes desses campos: System.IterationPath e System.WorkItemType. Vai ficar:

Get-TfsWorkItem -Filter '[System.IterationPath] = "Tailspin Toys\Iteration 2" And [System.WorkItemType] = "User Story"'

Como ele está filtrando por IterationPath, nesse caso, irá retornar somente os WIT’s do Team Project Tailspin Toys!

2016-06-09 14_55_09-

Por enquanto o nosso script está assim:

Ainda sobre os novos agents do TFS / VSTS! – Parte 1

$
0
0

Em post anterior conhecemos a nova arquitetura de Agents para o build, ou build vNext. Esse agent foi aproveitado também para a arquitetura do Release, o substituto do Release Management, disponível agora tanto no VSTS, como no TFS 2015, a partir do Update 2.

Vamos conhecer um pouco mais do processo de setup e configuração deste Agent, para uma infra-estrutura para build e release!

Arquitetura

É interessante que com a integração das features de Release no TFS/VSTS, do produto Release Management, fosse feito um uso racional das ferramentas que estavam sendo construídas, já que tanto o Build como o Release estão fazendo uso intensivo de comando escritos em scripts em Powershell.

Se o Build é a execução de um workflow, build definition, em Powershell em uma máquina por um Agent, por que não reaproveitar essa tecnologia para executar um workflow de deploy de uma Release e também fazê-lo em Powershell?

O Agent do TFS/VSTS torna a máquina na qual é instalada sua “escrava”, adicionando-a aos recursos disponíveis na sua infra de ALM, tanto para Build, quanto para Release e você que definirá o que será executado ali.

Instalação e Configuração

O Setup e config de um Agent é feito, praticamente, ao mesmo tempo, diferentemente do anterior, em que era preciso instalar o “core” do TFS e em seguida abrir o wizard de configuração em um console idêntico ao do App Server do TFS.

Vamos criar então uma infra-estrutura básica para a construção do build do projeto Fabrikam Fiber na VM do Brian Keller.

Build Agent

Baixando o Agent

Você pode fazer o download dos binários do Agent na aba Agent Queues da página administrativa de uma TP Collection.

2016-06-14 02_51_15-Greenshot

 

O pacote compactado contém a instalação do Agent, é só copiá-lo para a máquina que servirá de build machine ou que será um servidor de deploy. Coloque o arquivo Zip na raiz do disco C da VM. Renomeie-o para AgentBuild.zip. Descompacte-o.

Isso é o processo de instalação!

Configurando Queues e Pools

Antes de configurarmos o Agent precisamos criar a infra ao qual ele irá se conectar.

A máquina de build normalmente é criada seguindo um dos padrões: por tecnologia, por time, … Normalmente é a primeira, o que neste caso seria uma máquina para build de aplicações .Net. E já que ela seria cross-team project vamos conectá-la no Pool Default, que está ligado a Queue Default.

Configurando o Agent

Navegue para a pasta do Agent em um console elevado, e execute o arquivo ConfigureAgent.cmd, são apenas 7 perguntas que esse wizard fará:

  1. Nome do Agent, como é um agente de build, e eu divido por tecnologia, eu gosto de nomear Agent-BuilddotNet, por exemplo, como teremos um só Agent-Build
  2. URL para o TFS, não inclui collection
  3. Qual pool este Agent irá pertencer, como visto em De Controllers e Agents para Pools e Queues na nova arquitetura de build vNext um Agent pertence a somente um Pool, e definimos que este de Build seria no Default. Poderíamos ter um Pool de agents de build .Net. O wizard já sugere o Default, então é só dar enter e prosseguir.
  4. Será solicitado um work folder, que é o local onde será feito o download do código para ser usado em uma compilação, por exemplo, e não existe razão para não aceitar novamente a sugestão do Agent.
  5. Configure como serviço caso o Agent não precise executar nada em modo Interactive
  6. Conta que irá rodar o serviço, a já conhecida TFSBuild é a correta, para o exemplo utilizei outra.
  7. Digite o password da conta escolhida.

2016-06-14 03_29_39-

Pronto! O serviço será instalado e para conferirmos a sua disponibilidade é só acessarmos a aba Agent Pools, clicando na Pool Default, é mostrado os Agents registrados e a cor verde na laterial indica que está disponível.

2016-06-14 03_43_37-Greenshot

Na segunda parte vamos configurar os Agents necessários para o Deploy.

 


Ainda sobre os novos agents do TFS / VSTS! – Parte 2

$
0
0

primeira parte dessa sequência de posts foi sobre os novos Agents do TFS e VSTS, e finalizou com um passo a passo de uma instalação e configuração  do Agent responsável pelo Build. Mas para o Fabrikam Fiber estar totalmente na vNext, além do Build, temos que entregar a infra para Release usando o novo Agent.

É o que faremos a seguir…

Arquitetura

Vamos abstrair o fato que estamos usando a mesma VM para os stages nesse exemplo. Para quem se lembra de ter executado o HOL de deploy com o Release Management, a VSALM tem 3 ambientes configurados para o Fabrikam Fiber, em portas diferentes do IIS, na imagem a porta destacada, 10000, é a do stage de Produção.

2016-06-14 17_32_11-Overview - Microsoft Team Foundation Server - Internet Explorer

Em um ambiente real, teríamos ao menos uma máquina para cada stage, espelhando o ambiente de Produção, em alguns casos, este pode estar em um balanceamento de carga, e aí o ambiente de teste poderia reproduzir essa configuração então seria uma máquina para Dev, duas para Teste, duas para Produção, mas para efeito deste exemplo vamos utilizar somente uma VM ao invés de cinco máquinas! 🙂

Então vamos instalar um Agent… não! Vamos instalar três Agents, mas em uma mesma máquina.

Queues e Pools

Vamos separar aqui Queues e Pools para os Agents de deploy, apesar de ser possível utilizar a mesma já criada. Pois é interessante ter uma “infra-estrutura” específica para o pipeline, para isso é preciso criar uma nova Queue, em Agent Queues, no modo de Administração.

2016-06-14 17_51_28-Greenshot

Agora já temos onde ligar os Agents de deploy.

Deploy Agents

Instalação

A instalação é a mesma do anterior, então se você tem o Zip ainda na raiz do C, copie e cole o arquivo três vezes, CTRL + C e CTRL +V, e renomeie-os como abaixo.

2016-06-15 01_09_44-Greenshot

Agora é só extrair as pastas.

Configuração

A configuração é a mesma, porém agora o nome do Agent é o nome da máquina e seu stage, de resto é só seguir os 7 passos anteriores, mas caso esteja com presa e não quer procurar, vou reproduzir aqui:

  1. Nome do Agent, como é um agente de deploy, gosto de nomear com o nome da máquina, o que faz todo o sentido, neste caso: VSALMDev, VSALMQA e VSALMProd;
  2. URL para o TFS, não incluia a collection;
  3. Qual pool este Agent irá pertencer, eu criei um pool da aplicação, então todas as máquinas serão colocadas aqui, que é FabrikanFiber;
  4. Será solicitado um work folder, que é o local onde será feito o download dos binários para ser usado no deploy, de novo, não existe razão para não aceitar a sugestão do Agent.
  5. Configure como serviço caso o Agent não precise executar nada em modo Interactive
  6. Conta que irá rodar o serviço, a já conhecida RMDeploy, se você estiver herdando uma infra do RM, ou crie uma só como Deploy, para o exemplo utilizei outra.
  7. Digite o password da conta escolhida.

2016-06-15 01_19_03-Administrator_ Developer Command Prompt for VS2015

Para verificar se tudo deu certo, você deverá ter no Agents Pools:

2016-06-15 01_30_33-Greenshot

Agora que temos a infra, vamos criar em posts futuros build e deploy vNext.

Arquitetura 2

Como escrito no post anterior, o uso racional de recursos acabou entregando somente um Agent para fazer as duas tarefas… Mas, então, por que não usar apenas um Agent, o da máquina de build, daria certo? Sim!

A ideia dos Agents novos é que o time administre os recursos, por isso você pode atribuir a administração deles para outras pessoas.

2016-06-15 01_39_12-Greenshot

E nessa segunda arquitetura eu proponho ter uma máquina de build/release com um agent, onde seria feito a compilação dos binários, e esse Agent faria a coordenação de deploy entre as máquinas dos stages. Diminuiria setup e até mesmo uma possível manutenção nos stages por conta do agent, porém ao custo de onerar os builds nessa máquina. Ou pode-se fazer ter mais agents em uma máquina centralizadora, build e deploy… As opções comçam a abrir neste momento.

Agora é partir para a definição de build e release… mas antes, temos mais algumas features desses agents que eu quero expor, até a parte 3.

Um pouco mais sobre os novos agents do TFS / VSTS! – Parte 3

$
0
0

Nos dois primeiros posts sobre os novos agents do TFS e VSTS descreveu-se a instalação e configuração como build agent ou deploy agent.

Porém vários pontos ficaram em abertos, por exemplo, se eu reiniciar a VM na qual o agent está instalado, o que acontece? Quando sair uma próxima versão, como eu atualizo tudo?

Esses pontos e outros, serão vistos neste post, continue lendo!

Boot da máquina com Agent

A máquina de build pode ser reiniciada após a instalação de algum novo componente necessário para build, por exemplo, ou o Windows pode sofrer um boot após a instalação de updates. O Agent voltará a ficar on-line?

Se o Agent foi registrado como serviço é preciso verificar no cadastro de Serviços como está configurado, para isso use Win + X, no menu de contexto escolha Computer Management, e no menu lateral esquerdo Services e Applications > Service. Na relação de serviços encontre os com o prefixo “VSO Agent”.

2016-06-16 03_25_44-Greenshot

A coluna Startup Type dos Agents destacados, que são os configurados nos posts anteriores, estão indicando Automatic, ou seja, em um reboot da máquina os serviços vão subir automáticamente.

Deletando um registro de Agent que não existe mais

Aproveitando a janela Computer Management com a relação de serviços, vemos que existe o registro de mais dois Agents, além dos que foram cadastrados anteriormente, e a coluna de Status está em branco.

2016-06-16 03_27_48-Greenshot

São registros de Agents que foram feitos, porém, apagados do TFS, no painel de administração e a pasta com o executável já também deletada. Porém o registro do serviço ainda persiste. Para apagá-lo utilize o comando abaixo no console elevado:

sc delete [Service Name]

2016-06-16 03_37_56-Greenshot

Para pegar facilmente o nome do serviço, clique com o botão direito do mouse no serviço, e no menu de contexto escolha Properties. A janela que abrirá, já trará o Service Name selecionado, só clicar CTRL + C, veja abaixo.

2016-06-16 03_35_54-Greenshot

Depois é só colar no console. Lembre-se de fechar a janela Properties, ou receberá um pequeno alerta de erro quando o serviço for deletado.

Deletando corretamente um Agent

Apagar diretamente a pasta será gerado um erro.

2016-06-16 03_44_57-Greenshot

porém é possível forçar a remoção,

A sequência correta para remover um Agent é:

  1. Parar o serviço do Agent, com o comando
    sc stop [Service Name]

    2016-06-16 03_53_05-Greenshot

  2. Apagar o registro do serviço
    sc delete [Service Name]
  3.  Apagar o registro do Agent no TFS/VSTS2016-06-16 04_03_49-Greenshot
  4. Por fim apagar a pasta em que o Agent havia sido configurado

Update do Agent

No VSTS o update geral do produto é feito a cada entrega de Sprint, no TFS quando é instalado o pacote de Update. Com isso os Agents podem ser atualizados, ou seja, se for feita uma nova instalação, baixe o ZIP que terá a nova versão. Mas e quanto aos Agents já instalados? É preciso removê-los e re-instalar? Não.

Clicando no menu de contexto do Pool ou da Queue, existe a opção Update All Agents. Que irá forçar uma atualização geral.

2016-06-16 04_08_49-Greenshot

Sobre a configuração

Abrindo o arquivo ConfigureAgent.cmd, temos o seguinte código:

@echo off
REM For usage, pass /?
setlocal
if defined VERBOSE_ARG (
 set VERBOSE_ARG='Continue'
) else (
 set VERBOSE_ARG='SilentlyContinue'
)

REM Unblock the files for MEF even if the policy settings don't require it.
REM VsoAgent.exe also performs the unblock, so even if configure is performed
REM using VsoAgent.exe, the unblock will not be missed. It's better to perform
REM the unblock here too in case the policy requires it to run VsoAgent.exe.
powershell.exe -ExecutionPolicy Bypass -Command "$VerbosePreference = %VERBOSE_ARG% ; Get-ChildItem -LiteralPath '%~dp0' | ForEach-Object { Write-Verbose ('Unblock: {0}' -f $_.FullName) ; $_ } | Unblock-File | Out-Null ; Get-ChildItem -Recurse -LiteralPath '%~dp0Agent' | ForEach-Object { Write-Verbose ('Unblock: {0}' -f $_.FullName) ; $_ } | Unblock-File | Out-Null"
"%~dp0Agent\VsoAgent.exe" /configure %*

A principal parte é que será rodado uma chamada ao Powershell que irá executar alguns comandos para pegar path, arquivos, … mas o que importa é o executável VsoAgent.exe, vamos dar uma olhada no seu help:

VsoAgent.exe /?

2016-06-16 04_34_29-Greenshot

Esse executável tem diversos parâmetros, todas as opções que digitamos via configuração podem ser passadas por parâmetro! Diretamente para o ConfigureAgent.cmd, então se temos previamente o Pool, usuário, etc… podemos criar um script e fazer o deploy automatizado de novos Agents de deploy pelo próprio Release do TFS / VSTS!

 

Deem boas vindas ao TFS “15” Preview

$
0
0
Tempo de leitura:3 minuto(s)

Há cerca de um ano e meio atrás, fiz um post aqui no blog apresentando o TFS 2015. Pois bem, passado esse período, o time de produto do TFS/VSTS acabou de lançar o TFS “15” Preview (nome temporário).…

Continue lendo

1 ano de VSTS Sprints

$
0
0
Tempo de leitura:3 minuto(s)

É hora de comemorar 1 ano do canal VSTS Sprints. Uma ideia pensada há exatamente 1 ano atrás surgiu da vontade de entregar conteúdo sobre todas as features do VSTS. Junto com o meu amigo de comunidade Ricardo Serradas idealizamos entregar vídeos que explicassem cada uma das funcionalidades para que todos tivessem acesso à velocidade de entrega do time de produtos.…

Continue lendo

Controle seus projetos legados no TFS

$
0
0
Tempo de leitura:3 minuto(s)

Quem disse que é preciso estar na versão mais nova das linguagens de programação da moda para poder adotar práticas de DevOps e usar uma ferramenta de ALM como o TFS ou o VSTS?

Nesta série de posts, quero mostrar como a manutenção de seus projetos legados pode ser muito mais simples do que você imagina se você se permitir experimentar.

 

Uma vez ouvi falar que o significado de “software legado” era “software que funciona”. Nada mais verdadeiro! As aplicações que comumente chamamos de legado – aquelas que usam tecnologias antigas, por vezes até obsoletas – só estão aí até hoje porque ainda funcionam. Ou seja, frequentemente não há nenhum motivador de negócios que justifique reescrever o sistema numa nova tecnologia, plataforma ou linguagem. Modernizar para quê? Afinal, ele funciona!

O que os times responsáveis por projetos legados acabam esquecendo é que manter seu sistema numa linguagem antiga não significa, necessariamente, continuar usando práticas de desenvolvimento antigas. Longe disso!

Nesta série de posts quero compartilhar algumas dicas de como integrar os projetos legados nas tecnologias que mais temos visto nossos clientes usarem. Na maioria deles, nosso time de Consultores de ALM teve a oportunidade de ajuda-los a adotar as práticas e ferramentas descritas nesta série. Ou seja, mais que conhecimento teórico, é experiência prática!

Parte 1 – Delphi 7

Para os posts sobre Delphi, usarei a versão 7.0, pois é a mais comumente encontrada em projetos legados Delphi em nossos clientes.

  • Controle de versão de projetos legados Delphi 7
  • Automação de build de projetos legados Delphi 7
  • Automação de testes de projetos legados Delphi 7
  • Automação de release de projetos legados Delphi 7

Parte 2 – Visual Basic 6

Não poderíamos deixar o venerável VB6 de fora, né? J

  • Controle de versão de projetos legados VB 6
  • Automação de build de projetos legados VB 6
  • Automação de testes de projetos legados VB 6
  • Automação de release de projetos legados VB 6

Parte 3 – ASP Clássico

Acredite, ainda está cheio de sites ASP por aí…

  • Controle de versão de projetos ASP
  • Automação de build e release de projetos ASP

Parte 4 – Outras ferramentas

  • Controle de versão, build e release para projetos PowerBuilder
  • Controle de versão, build e release para projetos Progress
  • Controle de versão, build e release para projetos Clipper

À medida em que os diversos posts forem sendo publicados, os links serão atualizados nesta página. Não perca!

Ah, tem alguma outra tecnologia legada que você usa em sua empresa e gostaria de ver nesta série de posts? Então deixe um comentário com sua sugestão. Quem sabe não estendemos a série para incluir sua ideia? 😉

Um abraço,
Igor

 

(Cross-post de http://www.tshooter.com.br/2016/08/29/controle-seus-projetos-legados-no-tfs/)

Controle de versão de projetos Delphi 7 no TFS

$
0
0
Tempo de leitura:11 minuto(s)

Veja neste post como colocar seus projetos Delphi 7 sob controle de versão no TFS e/ou VSTS.

(Parte 1 de 13 da série sobre controle de projetos legados no TFS)

O panorama do controle de versão sob o TFS mudou muito desde que foi introduzido o suporte a Git. Ter dois modelos tão distintos – o TFVC com a clássica abordagem centralizada e o Git com o novo mundo da descentralização – naturalmente afeta nossas opções, principalmente na hora de suportar tecnologias e IDEs antigos. O Delphi, como é de se esperar, não é exceção.

Assim, este post vai cobrir os dois cenários – uso de TFVC e uso de Git – para projetos Delphi. Comecemos pelo TFVC.

Integração TFVC e Delphi

O Delphi 7 vem de um tempo onde o “rei” dos controles de versão na plataforma Windows era – acredite se quiser! – o Visual SourceSafe.

(E acaba de me ocorrer que boa parte dos devs da Lambda3 deve nunca ter visto o VSS. Definitivamente estou ficando velho)

Isso significa que o IDE do Delphi 7 está otimizado para o SourceSafe e seu modelo centralizado de lock-modify-unlock (ou seja, o bom e velho “check out & check in”). Dessa forma, o TFVC se encaixa como uma luva na experiência de usuário oferecida pelo IDE do Delphi.

Ambiente e pré-requisitos

Para alinharmos as expectativas, é importante você saber como montei meu ambiente. Afinal, YMMV Smile

  • Windows 7 Ultimate, SP1, x86, 2GB RAM
  • Delphi 7 Enterprise

Agora, vamos falar um pouco sobre os pré-requisitos:

  • Team Explorer 2013: Qualquer integração com o TFS passa necessariamente pelo Team Explorer. Você pode baixá-lo do site da Microsoft (instalação gratuita para usuários licenciados de TFS e/ou VSTS). Se você já tem o Visual Studio 2013 instalado (Professional ou superior) então não é preciso instalar o Team Explorer à parte, pois ele já vem incluído com o VS.
  • Visual Studio Team Foundation Server MSSCCI Provider: O “MSSCCI Provider” (pronuncia-se “miss-kee”) oferece a integração entre o TFS e IDEs antigos que usam a interface MSSCCI (Microsoft Source Code Control Interface), criada para a integração com o SourceSafe. Em outras palavras, o provedor MSSCCI emula a interface criada para o SourceSafe, “enganando” IDEs antigos e fazendo-os acreditar que estão falando com o SourceSafe.
  • EPocalipse SourceConneXion: Plug-in de terceiros (ou seja, $$$ Smile) que faz a integração entre o Delphi e os provedores MSSCCI.

Essa integração toda se dá como no diagrama abaixo:

Diagrama de alto nível com os componentes da integração Delphi-TFS

Configuração dos plug-ins

Eis o processo de instalação dos diversos componentes necessários para habilitarmos a integração. Instale-os na ordem a seguir:

Team Explorer

Comece a instalação pelo Team Explorer (TE). Você pode usar o TE 2012 ou 2013 mas não o 2015. Em outras palavras: você até pode ter o TE (ou o VS) 2015 instalado na sua máquina, mas não será o bastante. Você ainda precisará instalar o TE (ou VS) 2012 ou 2013, pois o TFS MSSCCI Provider não funciona com o TE 2015.

O Team Explorer pode ser obtido de três maneiras diferentes:

  • Através de um download direto do site da Microsoft (2012, 2013);
  • Na mídia do Team Foundation Server de versão correspondente (ou seja, TFS 2012 == TE 2012, TFS 2013 == TE 2013);
  • Ou por meio da instalação do Visual Studio (Professional ou superior) de versão correspondente. Neste caso basta instalar o VS; o TE estará incluído na instalação.

Não há muito além disto. Escolha um dos três meios acima e depois é só next-next-finish.

DICA: Depois da instalação do Team Explorer, é sempre uma boa ideia instalar o Update do Visual Studio correspondente à versão do TE que você instalou, pois ele pode conter correções de bugs.
Instale o Update 5 no TE 2012 ou o Update 5 no 2013.

Visual Studio Team Foundation Server MSSCCI Provider

O que deveria ser uma instalação bem simples pode se tornar um processo um pouco confuso. Isso porque há duas versões do TFS MSSCCI Provider disponíveis no Visual Studio Marketplace:

A diferença entre ambos é a versão do Team Explorer de que cada um depende. Via de regra, use a versão 2010 se você precisar instalar no Windows XP. Para versões mais recentes do Windows (como no nosso caso, em que estamos usando o Windows 7) use a versão 2013&2015 (que funciona tanto com o TE 2013 quanto com o 2015). Baixe a versão correta e depois é só next-next-finish.

DICA: Às vezes pode ser necessário trocar o Provedor MSSCCI padrão no seu computador. Isso é especialmente verdade se você tiver outro provedor MSSCCI (como o SourceSafe) instalado. Para poder usar o TFS, você deve definir o seu provedor MSSCCI como o padrão. O único detalhe é que não há nenhuma forma nativa de fazer isso.
Você pode definir o provedor padrão diretamente no Registry ou então baixar um dentre os diversos utilitários disponíveis para isso. No passado eu já usei o SccSwitch, mas foi descontinuado. Nas minhas pesquisas para este post, encontrei este no CodeProject.
Na dúvida, prefiro ir direto no Registry e editar na mão.

EPocalipse SourceConneXion

Como comentei anteriormente, o SourceConneXion – peça-chave para a integração com o TFS – é pago. A versão para Delphi 7 custa 49 euros. Ah, antes que alguém pergunte: Nem eu nem a Lambda3 temos qualquer tipo de vínculo comercial com a empresa EPocalipse. Estou indicando o plug-in deles simplesmente porque foi a única opção que encontrei para integrar o Delphi com o TFS. O lado bom é que você pode baixar uma versão trial de trinta dias.

Depois de uma instalação padrão next-next-finish, ao abrir o Delphi pela primeira vez após a instalação será exibida a tela de configuração inicial do SourceConneXion:

Tela de configuração inicial do SourceConneXion

Na etapa seguinte o SourceConneXion pergunta qual provedor MSSCCI você vai usar. Selecione o TFS:

Selecionando o provedor MSSCCI integrado ao SourceConneXion

Daí é a hora de configurar opções específicas do provedor MSSCCI em uso. No caso do TFS, ele dá a opção de configurar o modelo padrão de bloqueio de arquivos. O comportamento padrão do TFS é “None” (copy-modify-merge). Se você preferir o modelo de checkout exclusivo do SourceSafe, selecione a opção “Check Out” (lock-modify-unlock).

Configurando o modelo padrão de bloqueio de arquivos do TFS

Lembra que o SourceConneXion permite que você integre o Delphi a qualquer controle de versão que suporte a API MSSCCI, certo? Por isso, um usuário pode ligar o Delphi a diferentes controles de versão que, por sua vez, podem usar nomes distintos para a mesma operação. Imagine, como exemplo, “Check In” no TFVC e “Commit” no Subversion.

Para lidar com essas diferenças, o SourceConneXion permite que você personalize os termos que serão usados na sua interface. Assim, você pode usar a nomenclatura correspondente ao seu sistema de controle de versão. Por uma feliz coincidência, ele usa por padrão os mesmos termos do TFS; portanto, você pode aceitar as sugestões oferecidas.

Personalizando a terminologia do sistema de controle de versão no SourceConneXion

Com isso está concluída a configuração inicial. Repare que agora há um menu chamado Source Control no Delphi, que oferece acesso aos recursos do TFS. É através dele que iremos adicionar nosso projeto a um repositório TFVC:

Adicionando um projeto Delphi pela primeira vez a um repositório TFVC

Agora, indique o servidor (na verdade a Team Project Collection) e então selecione o Team Project onde o projeto será adicionado:

Selecionando o Team Project para adicionar o projeto Delphi

Depois é hora de indicar quais arquivos do seu projeto serão adicionados ao controle de versão. Tipicamente você vai querer adicionar todos:

Indicando quais arquivos de projeto devem ser adicionados ao controle de versão

E finalmente uma tela familiar para quem está acostumado com o TFS. Olha a tela padrão de check-in do TFVC aí! Smile

Caixa de diálogo padrão de check-in do TFS

Nela temos à disposição todos os recursos que o TFVC oferece para nossos projetos: Associação com itens de trabalho, políticas de check-in, notas de check-in… Integração completa!

Confirme o check-in e pronto. Nosso projeto Delphi está sob controle de versão no TFS!

Legal, né? :-)

 

Daqui para a frente, use o menu Source Control para interagir com o TFS a partir do IDE do Delphi:

Menu Source Control com os comandos de integração com o TFS

Uma das coisas bacanas de se ter uma integração nativa com o controle de versão diretamente no IDE é conseguir ter acesso fácil ao histórico de alterações. No menu Source Control, selecione o comando Show Difference para abrir a caixa de diálogo de histórico. Aqui, você pode selecionar dois changesets diferentes para comparar as alterações entre as duas versões:

Caixa de diálogo de histórico de versões, mostrando dois changesets selecionados

Clique com o botão direito sobre um dos changesets selecionados e então clique no comando Compare. Será aberta uma janela do Visual Studio com o diff entre as duas versões do arquivo escolhido:

Visualizando a diferença entre duas versões de um arquivo Delphi

Bacana, né? Agora, pode ser que seu time prefira usar o Git. Nesse caso, vamos ver como ligar o Delphi a um repositório Git do TFS.

Integração Git e Delphi

Agora vamos falar de Git? Smile

Usar o Git do TFS não é diferente de usar o Git do GitHub, GitLab ou qualquer outro serviço/servidor remoto de Git. No fim do dia, todos eles são simplesmente um “remote” com o qual você sincroniza (pull/push) seu clone local.

A primeira providência é instalar o cliente de Git no seu computador. Instale o Git for Windows, que já vem com o Credential Manager da Microsoft (que facilita muito a vida de quem usa TFS e/ou VSTS).

Clonando o repositório

No Git, tudo começa a partir da operação de Clone – ou seja, a “cópia” de um repositório remoto (juntamente com seu histórico) – para o computador local. Para clonar um repositório, é preciso obter seu URL de clone. No TFS, você encontra essa informação na interface Web:

Para obter o URL de clone, navegue até o repositório Git através da opção Code. Então, clique em Clone (1) e copie o URL de clone (2)

Agora, clone o repositório localmente. Abra um prompt de comando, crie uma pasta local e execute o seguinte comando:

git clone http://vsalm:8080/tfs/DefaultCollection/_git/DelphiTP

.gitignore

Umas das coisas mais importantes na configuração do Git para uma determinada linguagem de programação e/ou IDE é o arquivo .gitignore. Ele determina quais arquivos devem ser ignorados pelo Git, de modo a não “sujar” o controle de versão. Arquivos temporários, outputs de compilação etc. variam de linguagem para linguagem e precisam de um gitignore correspondente. Para o Delphi, você pode encontrar um .gitignore aqui. Para “instalar” o arquivo .gitignore, salve-o com o nome .gitignore (assim mesmo, começando com um ponto) na raíz do diretório onde você clonou o repositório Git, adicione-o (git add) e salve-o (git commit) no controle de versão. Na próxima operação de git add, esses arquivos serão ignorados.

E o IDE?

Ainda que o recomendado pela maioria dos usuários de Git seja sempre “use a linha de comando!”, usuários de IDEs RAD como Delphi e Visual Basic preferem ficar no IDE a maior parte do tempo. Para aqueles que preferem a interface gráfica, uma opção é usar o Git SCC Proxy da PushOk. Ele também emula a API MSSCCI e, portanto, integra-se ao IDE através do SourceConneXion:

Caixa de diálogo "Provider Configuration" do SourceConneXion, listando os provedores MSSCCI disponíveis

Tal como acontece com o TFVC, adicionar um plug-in MSSCCI para o Git traz recursos específicos do provedor para dentro do IDE. Por exemplo, veja a janela de histórico do Git SCC:

Caixa de diálogo de histórico de arquivos com o PushOk

Mas eu ainda não sei usar o Git!

Como a internet está repleta de artigos sobre como usar o Git no dia-a-dia de projetos Delphi, acaba sendo um pouco “mais do mesmo” entrar em detalhes aqui. Por isso, sugiro dois materiais de estudo para você usar como ponto de partida:

Conclusão

Viu como integrar o Delphi com o TFS pode ser mais simples do que você imaginava? Sim, o setup inicial dá um certo trabalho mas acredito que o resultado pode ser bem compensador. Experimente!

Ah, e não deixe de compartilhar sua opinião nos comentários do post!

 

Um abraço
Igor

 

(Cross-post de http://www.tshooter.com.br/2016/10/06/controle-de-verso-de-projetos-delphi-7-no-tfs/)

TSC… Team Foundation Server Security as a Code

$
0
0
Tempo de leitura:6 minuto(s)

Se você é administrador do TFS ou do VSTS, já deve ter adicionado novos usuários no TFS, dado permissão, teve que controlar o que grupos podem acessar, etc…

É uma tarefa bem tediosa, dependendo da cultura da organização que está trabalhando. Se ela for mais liberal, o controle será menos rígido, mas, se ela for menos permissiva, ou até mesmo se tiver que seguir regras rígidas, por exemplo, de Governança para empresas listadas na bolsa de valores; daí o processo vai ser mais complexo…

É aí que entra o TSC! E como isso pode acontecer, é o que vou explicar abaixo!

Ah! Apesar do nome, vale para VSTS também. 😀

Gerenciamento de segurança

Até o atual momento , o TFS e o VSTS tem um sistema que pode atingir níveis granulares bem interessantes. É possível negar a permissão a uma branch ou a visualização de builds, por exemplo. O que é excelente para uma organização com uma política de Governança forte que procura atender a SOX, ou Novo Mercado, (BM&F BOVESPA).

Se pensarmos em termos de Separation of duties, podemos dividir várias tarefas, para não deixar na mão de somente uma pessoa, por exemplo: pode-se ter um papel de criador de definições de release, para a automação de deploy, e outro que só informará os grupos ou pessoas responsáveis por aprovações em cada ambiente do pipeline! Assim, garantimos que uma tarefa seja executada “a quatro mãos”, e ninguém fica com todas as chaves ou possibilidades de configuração.

Gerenciamento de segurança no TFS

Se você ainda não leu nada sobre o assunto, recomendo ler esses posts antes de continuar: Administração de usuários e grupos no TFS/VSTS e Administrando usuários, grupos e permissões no console com TFSSecurity, o primeiro post dará uma ideia básica de como funciona o sistema de permissionamento do TFS; o segundo mostra alguns exemplos de como fazer isso via console

Muitas vezes eu faço a criação de um grupo para o papel de Release Manager. As pessoas nesse grupo ficam responsáveis por cuidar do Build, agora do Release, e talvez até de outros assuntos; existe também a figura do Scrum Master, ou Gerente de Projetos, que fazem o controle das Iterações. Do Product Owner, que aprova deploys no ambiente de homologação, por exemplo, enquanto que o time de QA aprova no ambiente de teste e Operações em produção…

Vamos analisar o cenário: Release Manager, em um time ágil, é responsável pela criação da definição de build, de release, das iterações, por causa do lançamento de release após algumas iterações… Ah! Essa pessoa também faz Code Review , e esse processo acontece na integração do código da feature branch com a master, por exemplo; portanto os desenvolvedores não devem ter permissão para mandar código na master.

Vamos configurar tudo isso agora.

Build e Release Definition Administrator

Fácil, no Team Project, nas configurações de segurança (1), criamos o grupo Release Manager (2), selecionamos (3) e colocamos como membro (4) dos grupos Build Administrators e Release Administrators.

2016-11-25-14_54_04-caixa-de-entrada-emmanuel-brandaolambda3-com-br-outlook

Iterations Administer

Aqui já começa a complicar, pois não será na mesma aba que será feita a configuração! A aba Security só é possível configurar algumas permissões. Portanto clique na aba Iterations (1), no backlog clique no menu de contexto (aquela preta na extrema esquerda) (2), clique Add e adicione o grupo Release Manager (3), selecione (4), configure as permissões para administrar as iterações.

2016-11-25-14_59_44-caixa-de-entrada-emmanuel-brandaolambda3-com-br-outlook

Branch master Administrator

Primeiro vamos na aba Version Control (1), mais um lugar diferente, e vamos na branch master (2) do repositório, e no grupo Contributors (3) vamos negar as permissões (4) Contribute, ou seja o desenvolvedor não vai poder fazer push para esta branch, e vamos aproveitar e negar a permissão Rewrite and destroy history (force push), assim previne-se a possibilidade da branch ser apagada.

2016-11-25-16_28_24

Agora que temos os desenvolvedores bloqueados vamos resolver os Release Managers. Na mesma aba (1), na branch master (2), adiciono o grupo Release Manaer (3), seleciono-o (4), e a permissão de Contribute já está OK, pois está sendo herdada, esse conceito foi explicado no post já indicado acima; ela irá permitir que o Release Manager integre o código de uma feature branch na branch master, via Pull Request! A outra permissão eu neguei como segurança, daí quando precisar fazer alguma re-escrita de histórico é só perdir a liberação no grupo e negar novamente.

2016-11-25-16_56_08-itens-excluidos-emmanuel-brandaolambda3-com-br-outlook

Nada disso é difícil, certo? E o processo de configuração é feito uma única vez e não se mexe mais! Mas, se você tem muitos Team Projects ou se você tem muita movimentação estrutural na empresa, começa a ficar um processo chato de ficar alterando…

Mas, e se você fez uma vez e não mexeu mais, como ter certeza que não foi alterado ao longo do tempo? Ainda não temos um processo de auditoria no TFS. Isso significa que você não tem histórico dessas alterações. E é aí que entra o Team Foundation Server Security as a Code

TSC

Esse post é um kick-off do projeto. Você pode encontrá-lo aqui https://github.com/egomesbrandao/tsc, mas calma! Eu disse KICK-OFF, ou seja, ainda não tem código lá. Eu tive a ideia do TSC já tem algum tempo, mas não havia me dedicado a ele, a ideia de escrever sobre ele é me comprometer em desenvolvê-lo e também pedir ajuda da comunidade, seja para mandar PR, ou escrever Issue’s, ou só testar!

O que é TSC

A ideia do TSC é escrever a configuração de código do TFS como código, em uma estrutura Yaml, por exemplo:

 name: "FabrikamFiberCollection"
     url: "http://vsalm:8080/tfs/FabrikamFiberCollection"
     ProjectCollectionAdministrator:
     Members:
      Member:
          user: VSALM\janed
          Permissions:
              Administer build resource permissions: Allow
     Projects:
         Project:
             name: "FabrikamFiber"
                 Groups:
                     Group:
                        Name: "Release Administrators"
                        Members:
                            Member:
                                user: lambda3\andre

Depois de escrito toda a estrutura de configuração, é só “commitar”, e um processo de build vai gerar a estrutura necessária de configuração, para isso será desenvolvido uma task, para ser executada por um deploy em um ambiente, ou seja, na máquina do TFS, pois será utilizado o utilitário de configuração TFSSecurity.exe, por isso a sugestão de leitura do segundo post!

Com isso se ganha rapidez, confiabilidade e um histórico!

Quero comunicar o progresso semanalmente, então toda sexta-feira, durante algum tempo, irei postar sobre o que foi feito durante a semana neste projeto, ou explicando algo.

Espero que mais pessoas se engajem no projeto.

Mande seu PR!


O caminho do TFS para o VSTS

$
0
0
Tempo de leitura:1 minuto(s)

Muitas empresas gostariam de migrar do TFS on-premises para o Visual Studio Team Services e esse era um dos principais pedidos dos usuários. Durante o Connect 2016 a Microsoft apresentou o processo de importação de bases de dados do TFS para o VSTS.…

Continue lendo

Importando repositórios SVN para o GIT

$
0
0
Tempo de leitura:4 minuto(s)

Após o Git ter se tornado uma das principais ferramentas para o versionamento de código fonte, muitas equipes estão procurando migrar para o git de outros sistemas de controle de versão, porém, lidar com todo o histórico de alterações, tags e branchs pode tornar-se uma dor de cabeça.

Hoje vamos falar sobre a migração de repositórios SVN para GIT.

Este post foi inspirado em um trabalho que realizei recentemente, migrando um fonte com mais de 300Mb em SVN para o GIT. Este trabalho foi feito utilizando uma máquina rodando Windows 10, e, por vezes, utilizei o Bash for Windows. Por conta disso, você verá comandos que serão feitos utilizando o bash e outros feitos utilizando o powershell

O git possuí uma ferramenta para a importação de repositórios SVN, incluindo todo o histórico de alterações no código fonte. Se você estiver utilizando uma máquina Windows, não é necessário fazer instalações adicionais para utilizar a ferramenta git svn via linha de comando, porém, em uma máquina utilizando Ubuntu (ou utilizando o bash dentro do Windows) talvez seja necessário instalar alguns pacotes. Faça estas instalações com o comando

sudo apt-get install git-core git-svn

Em meus testes, a utilização do bash provou-se mais rápida que o mesmo comando utilizando o powershell. Portanto, recomendo que continue no bash enquanto executa o comando de clone do repositório:

SECONDS=0 && git svn clone <caminho para o repositório> <Pasta onde será feito o clone> --stdlayout -r2000:HEAD && echo $SECONDS`

O parâmetro r2000:HEAD irá limitar o histórico para a revisão 2000 até a atual. Este comando, em um repositório com 3856 commits levou cerca de 1h10m.

No SVN, uma tag é uma branch, portanto, após o clone do repositório, quando rodamos o comando

git tag -l

não iremos ver nenhuma TAG, porém, se rodarmos o comando

git branch -r

vamos observar que as branchs remotas (que são as tags do SVN) estarão lá. Para criar tags do git, de acordo com as tags do SVN, rode o seguinte comando na pasta de seu repositório (powershell):

git for-each-ref --format="%(refname:short) %(objectname)" refs/remotes/tags | %{$tag = $_ -split "/" -split " "; 
git tag -a -m 'Import tag from svn' $($tag[1]) $($tag[2])}

Aqui estamos iterando em cada branch remota do nosso repositório e criando uma tag apontando para o commit que esta “branch de tag” esta apontando.

Após isso, precisamos criar branchs locais do git que referencie as reais branchs do nosso repositório SVN. O processo para fazer isso é um pouco mais complexo:

$todasBranchs = git for-each-ref refs/remotes;
$branchsTags = git for-each-ref refs/remotes/origin refs/remotes/tags;
$branchs = New-Object System.Collections.ArrayList;
foreach ($b in $todasBranchs) { if ($branchsTags.contains($b) -eq $false) {$branchs.add($b)}};
$branchs | %{$b = $_ -split '/'; git checkout -b $($b[2]) refs/$($b[1])/$($b[2]); git checkout master}

Após este comando, poderemos observar que os comandos

git tag -l

e

git branch -v

irão se comportar da forma esperada. Estes comandos irão transformar todas as branchs atuais do SVN em branchs no seu repositório git. Caso não seja isso que queira fazer, execute o comando

git checkout <nome da branch> refs/remotes/<nome da branch>

somente para as branchs que você quer manter em seu repositório git. Lembre-se sempre das boas práticas para repositórios git e não mantenha branchs que não são necessárias ou estão a muito tempo sem atualizações.

Não se esqueça do arquivo .gitignore

Lembre-se que o git é uma ferramenta de controle de versão que, por sua natureza, não lida bem com arquivos grandes e/ou arquivos binários, portanto, não deixe de incluir o arquivo .gitignore mais apropriado para o seu código fonte. Isso será assunto para outro post, porém, para garantir que o arquivo .gitignore esta fazendo o seu trabalho corretamente, execute os seguintes comandos:

git rm -r --cached .
git add .
git commit -m "Aplicando o arquivo .gitignore"

Com o repositório em ordem, você poderá fazer o push do seu repositório para o repositório remoto:

git remote add origin <url do repositório remoto>
git push origin --all; git push origin --tags #por padrão o comando git push não empurra as tags para o repositório remoto

(Cross-post de http://blog.gersondias.net/Importando-Repositorios-SVN-GIT/)

Como usar NuGet sem escancarar a rede?

$
0
0

Mais um post da série “causos de ALM nos cliente Lambda3“.

De um lado, os desenvolvedores querendo ter acesso irrestrito ao NuGet (www.nuget.org) por razões óbvias. De outro lado, o pessoal responsável por segurança e infraestrutura preocupados com o risco de liberar o acesso irrestrito ao NuGet no firewall.

#comofaz?

O problema

O grande desafio encontrado neste caso – que, aliás, é comum à maioria de nossos clientes – é como equilibrar entre a conveniência para os desenvolvedores e a segurança para a empresa?

Mais especificamente: a política de firewall da empresa em questão prevê, entre outras coisas, whitelisting de IPs que podem ser acessados a partir de sua rede interna. Em outras palavras, é preciso liberar um determinado range de IPs para que eles possam ser acessados.

Entretanto, em tempos de cloud computing e de endereços IPv4 esgotados, está cada vez difícil sustentar esta estratégia. Isso porque é cada vez mais comum que provedores de serviço mudem os IPs de seus serviços com uma certa frequência, contando com os serviços de DNS para notificar os clientes quando tais mudanças acontecem.

No caso do NuGet, isso quer dizer que os IPs dos endpoints de serviço do NuGet podem mudar. Veja o resultado atual (consultado no dia da publicação deste post) do DNS lookup para um dos domínios do NuGet:

C:\> nslookup api.nuget.org

Server:   ***************
Address:  ***.***.***.***

Non-authoritative answer:
Name:    cs9.wpc.v0cdn.net
Addresses:  2606:2800:157:1508:1539:174:1a75:1191
          192.16.48.200
Aliases:  api.nuget.org
          db16.wpc.azureedge.net

Viu como o domínio api.nuget.org é, na verdade, um alias (ou CNAME) para um CDN? Isso quer dizer que não há nenhuma garantia de que o IP retornado por api.nuget.org vai ser sempre 192.16.48.200. Pelo contrário – a natureza dinâmica dos CDN é quase uma certeza de que esse IP vai mudar em algum momento.

Portanto, uma liberação baseada em IPs não resolve. Neste caso, qual a alternativa?

Soluções

Obviamente precisamos de uma alternativa. Principalmente porque, no caso deste cliente, ele nos perguntou explicitamente:

Como outros clientes de você atuam nesta situação?

Bem, deixe-me compartilhar com vocês o que andamos vendo em nossos clientes:

Acesso irrestrito a *.nuget.org

Sim, é claro que esta é uma opção válida – ainda que pouco desejável em muitos de nossos clientes, que ficam desconfortáveis com acesso irrestrito à internet. Entretanto, esta é uma opção relativamente comum, em especial naqueles clientes que não podem (ou não querem) ter o overhead de gerenciar o acesso ao NuGet. Afinal, limitações de acesso aqui podem impactar diretamente na produtividade dos desenvolvedores.

Se você não se quiser liberar todos os domínios abaixo de nuget.org (*.nuget.org), pode liberar apenas estes dois:

  • www.nuget.org (HTTP, HTTPS);
  • api.nuget.org (HTTP, HTTPS).

O maior inconveniente dessa abordagem (segundo alguns de nossos clientes) é que o acesso precisa ser dado para todo mundo: desenvolvedores, agentes de build e release, servidores… Todo mundo pode precisar acessar o NuGet.org.

Será que não tem um meio-termo?

Servidor proxy de NuGet

Sim, há um meio-termo. Com um servidor de proxy de NuGet (usamos o ProGet em alguns de nossos clientes), não há a necessidade de liberar o acesso ao NuGet.org para todo mundo. Apenas o servidor de ProGet precisa ter acesso irrestrito ao NuGet.org.

Quando você configura um servidor ProGet interno, ele é quem baixa os pacotes do NuGet.org para você – por isso é que ele é um “proxy” do NuGet. Isso implica em uma mudança na configuração do NuGet na máquina dos desenvolvedores.

No Visual Studio de cada desenvolvedor, vá em Tools | Options, selecione a página Package Sources da configuração do NuGet e faça duas coisas:

  • Inclua o endereço do feed do seu proxy (http://proget/nuget/default no meu exemplo); e
  • Desabilite os outros feeds de acesso ao NuGet público.

Caixa de diálogo de configuração do Visual Studio, na página "Package Sources", com um feed personalizado apontando para um servidor ProGet interno e os outros feeds desabilitados

Caso você queira evitar de fazer esse processo de configração “na mão”, pode ao invés disso atualizar o arquivo de configuração do NuGet de cada desenvolvedor (por padrão, fica em C:\Users\<nome do usuário>\AppData\Roaming\NuGet\nuget.config), seguindo o exemplo abaixo:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="Package source" value="http://proget/nuget/default" />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
  </packageSources>
  <disabledPackageSources>
    <add key="nuget.org" value="true" />
    <add key="Microsoft and .NET" value="true" />
    <add key="Microsoft Visual Studio Offline Packages" value="true" />
  </disabledPackageSources>
</configuration>

Um benefício adicional, do ponto de vista de segurança, é que o ProGet permite fazer a “curadoria” dos pacotes – ou seja, é possível aprovar/reprovar pacotes que aparecem à disposição dos desenvolvedores. Com isso, as empresas acabam com uma alternativa ainda mais segura: o invés de barrar/liberar o NuGet.org como um todo, podem fazer isso seletivamente – pacote a pacote, se necessário.

Importante

O recurso de proxy de feeds do ProGet não está disponível na versão gratuita. Para mais detalhes, visite http://inedo.com/proget/pricing

Liberação por IP

Bom, se ainda assim nada der certo e você precisar fazer a liberação por IP, resta um problema: Como saber se/quando os IPs do nuget.org mudaram? Uma alternativa é criar um script e executá-lo de tempos em tempos, a fim de verificar se os IPs mudaram ou não (visto que não há um feed oficial com essa finalidade).

Como ponto de partida, você pode dar uma olhada nest Gist. Ele tem uma função chamada Resolve-ServerAddress que recebe um FQDN como parâmetro e retorna seu IP atual, indicando se ele mudou desde a última execução. Em caso positivo, você poderia por exemplo enviar um email para um administrador avisando da mudança, a fim de que ele possa reconfigurar as regras de firewall. Daí, basta agendar sua execução (via Agendador de Tarefas do Windows) e pronto!

Passando a régua

NuGet é algo que veio para resolver um monte de problemas no ecossistema .NET – mas, como qualquer mudança de paradigma, traz seus próprios desafios. Achar o ponto de equilíbrio entre a conveniência desejada pelos desenvolvedores e a segurança necessária para a infraestrutura da empresa não é fácil, mas não dá para empurrar com a barriga. Sem resolver esse tipo de questão, não faz o menor sentido começar a discutir DevOps e assuntos correlatos.

E aí, o que achou? Deixe seus comentários!

Um abraço,
Igor

(Cross-post de http://www.tshooter.com.br/2017/01/27/como-usar-nuget-sem-escancarar-rede/)

Team Projects, Area & Iterations (ou Cade meus WorkItems?)

$
0
0

Em meus trabalhos de implementação do TFS e VSTS em empresas, sempre precisamos discutir sobre como organizar a ferramenta para refletir a organização da empresa. Neste momento, conversamos sobre os conceitos de Team Project Collection, Team Project, Area Path e Iteration Path.…

Continue lendo

Como licencio as ferramentas de teste do TFS e do VSTS?

$
0
0

Imagine, por um momento, que você trabalha como desenvolvedor numa empresa e algumas pessoas lá – membros da sua equipe, fornecedores ou até mesmo usuários – precisam testar os sistemas que você e sua equipe produzem.

Nesse momento, surge o desejo de se “estruturar” o processo de testes, através da adoção de um processo de planejamento, execução e coleta de evidências mais organizado. Por conta disso, alguém pergunta: “alguma ferramenta de testes poderia nos ajudar a simplificar esse processo?

Como em sua empresa vocês usam o TFS/VSTS, você responde de bate-pronto:

Por que não usamos as ferramentas de teste do TFS/VSTS? Tem o Test Manager, tem a interface web do Hub de Testes, tem o plugin do Chrome para Teste Exploratório… Tá tudo lá, integrado ao que a gente usa!

E é lógico que nesse exato instante alguém pergunta “mas quanto custa?” E todo mundo se vira para você, esperando ver como você se sai com essa pergunta à queima-roupa.

E agora, o que você responde?

A resposta, como não poderia deixar de ser, é a óbvia…

Depende…

😉

Perguntas sobre licenciamento nunca são fáceis de responder. Não é por acaso que comecei a escrever um post sobre o assunto!

Entendendo os cenários

Para facilitar o entendimento, vou tentar descrever abaixo alguns cenários de uso e os modelos de licenciamento mais adequados. Imagine que você emende ao seu “depende” a pergunta “o que você quer fazer com a ferramenta?” Eis, a seguir, as respostas que você normalmente poderia ouvir e os modelos de licenciamento correspondentes.

1. “Preciso apenas escrever casos de testes”

Escrever casos de teste, seja no TFS ou no VSTS, pode ser tão simples quanto criar um item de trabalho (“work item“) do tipo Test Case. E como, para criar itens de trabalho, basta um acesso do tipo Stakeholder, podemos dizer que um acesso gratuito (do tipo Stakeholder) é o bastante para criar casos de testes. Custo: Gratuito

Para criar itens de trabalho do tipo Test Case, basta um acesso do tipo Stakeholder

Por outro lado, há ferramentas mais convenientes para a criação de casos de teste. A mais antiga delas é o MTM (Microsoft Test Manager). Custo: CAL + Test Manager

Criando um caso de test no Microsoft Test Manager

Outra opção, mais recente, é o Hub de Teste (Test Hub). É assim que é conhecida a aba “Test” na interface Web do TFS 2013+ e do VSTS, que veio para substituir o MTM.

O Hub de Teste tem um recurso exclusivo: a grade de edição de casos de testes. Com ela, é possível cadastrar seus casos de testes tão facilmente quanto seria digitá-los numa planilha do Excel. Porém, essa conveniência tem um custo: É preciso ter uma licença apropriada para isso. Custo: CAL + Test Manager

Grade de edição de testes na interface web. É, de longe, a mais rápida e conveniente maneira de cadastrar casos de teste!

2. “Preciso apenas executar casos de testes”

Em algumas empresas, os papéis de construção de casos de testes e a sua respectiva execução são separados e ficam a cargo de pessoas diferentes. Ou seja, há pessoas cuja única necessidade é a de executar casos de testes.

Em outras empresas, há por vezes a necessidade de que os próprios usuários dos sistemas possam executar testes construídos para eles por algum analista. Um exemplo típico é quando há o desejo de se orientar o usuário no processo de homologação, provendo-o com os casos de teste que representam as funcionalidades que foram implementadas.

A execução de casos de teste formais (aqueles que contêm o passo-a-passo pré-definido para sua execução) requer o uso ou do MTM ou do Web Test Runner.

O uso do MTM traz um grande benefício – a coleta rica de evidências e dados diagnósticos durante a execução do teste, sem esforço adicional algum por parte de quem testa.

Entretanto, tanto benefício tem um custo. Custo: CAL + Test Manager

Teste sendo executado pelo MTM. Vários dados diagnósticos, como o gravador de tela, a captura das ações (teclado e mouse) e o IntelliTrace, são capturados de modo automático

Se você não precisa da coleta rica de dados diagnósticos do MTM, ou se não deseja instalar um software no computador apenas para poder rodar os testes (o MTM precisa estar instalado no computador), uma alternativa mais interessante pode ser o Web Test Runner.

Neste caso, até mesmo o licenciamento se torna mais barato. Custo: CAL

Execução de testes com o Web Test Runner. Apesar de não contar com coletores avançado de dados (como o IntelliTrace ou o Action Recording), permite a gravação de tela e a captura de screenshots

3. “Preciso criar planos e suítes de testes”

Para planejar e executar adequadamente seus casos de testes, não basta apenas criar work items do tipo Test Case. É preciso agrupá-los em suítes e planos, que permitem a correta organização do processo de testes. Atualmente, tanto o MTM quanto o Web Test Hub permitem a criação de planos e suítes (originalmente, apenas o MTM permitia a criação de planos). Para ter acesso aos recursos de planejamento de testes – suítes e planos – é preciso ter o nível adequado de licenciamento. Custo: CAL + Test Manager

Criação de planos e suítes de testes na interface Web

4. “Preciso executar testes exploratórios”

A grande diferença entre a execução dos casos de testes (que discutimos até agora) e a execução de testes exploratórios é que estes não pressupõem a existência de um caso de teste. Ou seja, sempre que você quiser fazer algum teste sem partir de um caso de teste formal previamente definido, estará fazendo um teste exploratório.

Para testes exploratórios, até algum tempo atrás era preciso usar o MTM. Hoje, podemos usar também o plugin de Test & Feedback.

Com o MTM, é possível usar a coleta rica de dados diagnósticos também durante a execução de testes exploratórios. Muitos times preferem poder tirar proveito desse recurso, dado que ele facilita (e muito) a vida dos desenvolvedores ao tentar reproduzir os erros encontrados. Custo: CAL + Test Manager

Teste exploratório no MTM. É possível fazer um teste exploratório "do zero" (1) ou a partir de um item de requisito/estória (2), selecionado dentre os itens do backlog (3). Neste caso, o resultado do teste é associado automaticamente ao item de trabalho testado

Agora, se o que você procura é a conveniência de fazer os seus testes exploratórios de aplicações Web diretamente a partir do browser, sem precisar instalar nada no computador (além, é claro, da extensão no browser 😃 ), então o novo Test & Feedback é uma ótima opção – além de ser mais em conta! Custo: CAL

Extensão Test & Feedback para o Google Chrome. Com ela é possível executar testes exploratórios diretamente no browser

5. “Preciso fazer acompanhamento de resultados e relatórios de testes”

Para acessar os relatórios de acompanhamento de progresso dos testes nós precisávamos do MTM. Entretanto, agora é possível expor todos os gráficos e relatórios de acompanhamento do progresso dos testes diretamente nos dashboard da interface web do TFS/VSTS, eliminando a necessidade de uma licença de Test Manager. Custo: CAL

Dashboards de acompanhamento de testes no VSTS

6. “Preciso homologar uma aplicação”

Nós já descrevemos o cenário de homologação ao falarmos da execução de casos de testes e dos testes exploratórios. A licença vai depender da ferramenta escolhida e não do papel do usuário.

Se você usar o MTM para testes formais e exploratórios durante a homologação: Custo: CAL + Test Manager

Agora, se você usar o Web Test Runner e extensão Test & Feedback para os mesmos testes formais e exploratórios, o custo é mais baixo. Custo: CAL

Mas e agora? Como licenciar?

Se o seu cenário corresponde a algum dos listados acima que continha a inscrição Custo: CAL + Test Manager, então veja aqui o que isso significa.

CAL (Client Access License)

A CAL, ou Client Access License (“Licença de Acesso de Cliente”), representa um acesso de usuário ao TFS. Já para o VSTS, o equivalente à CAL é chamado de VSTS Basic Subscription.

Isso quer dizer que seu usuário precisa de um acesso mais amplo que aquele provido pelo acesso gratuito de Stakeholders. Esse nível de acesso pode ser adquirido de várias formas:

  • Para usuários de TFS, o acesso pode ser adquirido através de uma das seguintes opções:
    • Compra de licenças de CAL para o TFS; ou
    • Compra de assinaturas VSTS Basic para o TFS no lugar das licenças de CAL (sim, o TFS pode ser licenciado com assinaturas do VSTS!); ou ainda
    • Licenças Visual Studio Professional com MSDN, Visual Studio Test Professional com MSDN ou Visual Studio Enterprise com MSDN;
    • Assinaturas de nuvem Visual Studio Professional (mensal) ou Visual Studio Enterprise (mensal ou anual).
  • Já para usuários do VSTS, não faz sentido falarmos de CALs. O acesso ao serviço se dá por meio de assinaturas e não de licenças. Assim, qualquer uma das opções abaixo seria o equivalente a uma CAL quando estamos falando de VSTS:
    • Compra de assinaturas VSTS Basic;
    • Licenças Visual Studio Professional com MSDN, Visual Studio Test Professional com MSDN ou Visual Studio Enterprise com MSDN;
    • Assinaturas de nuvem Visual Studio Professional (mensal) ou Visual Studio Enterprise (mensal ou anual).

Test Manager

Test Manager, neste contexto, não é um produto nem uma ferramenta – é apenas uma licença. Ou seja, ele não deve ser confundido com o Microsoft Test Manager – este sim, uma ferramenta.

No contexto de licenciamento, Test Manager significa que o usuário precisa de um nível de licenciamento superior àquele provido pela CAL (descrito acima), e que dá acesso às ferramentas de testes do TFS / VSTS (incluindo, agora sim, o Microsoft Test Manager). Atualmente, este nível de licenciamento é comumente obtido através da compra de uma extensão do VSTS chamada Test Manager, daí o nome da licença.

Confuso, né? 😃

  • Assinaturas da extensão Test Manager no Visual Studio Marketplace. Como falamos acima, esta extensão não é uma ferramenta, mas sim um veículo de licenciamento. Ao comprar assinaturas da extensão Test Manager, você está liberando o acesso às ferramentas de teste para as pessoas do seu time que precisam delas; ou
  • Assinaturas Visual Studio Test Professional ou Enterprise (incluindo as antigas Assinaturas MSDN).

IMPORTANTE

Se você optar pela aquisição da extensão Test Manager para licenciar o seu time – ao invés de usar uma licença VS Test Professional ou VS Enterprise – precisará adquirir também uma CAL, como descrito acima.
A extensão, por si só, não inclui o direito de acesso ao TFS/VSTS, diferente de quando você adquire uma assinatura do Visual Studio ou uma licença com MSDN.

Conclusão

As mudanças no modelo de licenciamento do Visual Studio e ferramentas associadas, que estão deixando de ser “licenças” no sentido mais antigo da palavra e estão passando a ser “assinaturas”, mais alinhadas com o modelo de consumo de recursos da nuvem, geram muitas dúvidas. Aliás, era de se esperar, já que estamos bem no meio da transição.

E, como eu disse, licenciamento nunca é um assunto simples. 😃

Este post te ajudou de alguma forma? Restou alguma dúvida? Não hesite em comentar!

Um abraço,
Igor

(Cross-post de http://www.tshooter.com.br/2017/03/13/como-licencio-as-ferramentas-de-teste-do-tfs/)

Notificação no VSTS ou TFS por e-mail? Não… Notifique pelo Slack! (Integration)

$
0
0

É fato, recebemos muito e-mail no trabalho, além dos pessoais; porém muitas vezes esse e-mails ou não importam ou são tantos sobre algo que não é importante que acabamos por ignorá-los.

Com notificações do VSTS ou do TFS não seria diferente. Mesmo assinando somente notificações relevantes acabamos por mandar o e-mail notificando algum acontecimento para alguma pasta de “Notificações”, arquivando e nem olhando o que aconteceu. O que seria algo interessante e totalmente aderente as práticas de comunicação ou mesmo transparência de agilidade ou cultura DevOps, acaba por se transformar em um transtorno.

Mas se o seu time usa uma ferramenta de colaboração por chat, o Slack, por exemplo, é possível enviar várias notificações adicionando apenas uma extenção.

Integração

Não é necessário instalar uma extensão, pois uma integração é feita através de Services Hooks. A Microsoft já deixou preparado no produto a possibilidade de ser integrado com vários serviços conhecidos, por exemplo, no VSTS:

20160410_01

Além dos serviços conhecidos é possível criar a própria integração em um endpoint (1) seu, por exemplo.

Já a lista de integrações do TFS é um pouco menor, mesmo na versão 2017:

20160410_02

Tanto no VSTS quanto no TFS, a janela de configurações acima pode ser acessada pelo menu Settings > Service Hooks, dentro de um Team Project:

20160410_03

Slack

É dífícil não saber sobre o Slack: é uma ferramenta de colaboração de times em formato de chat! Ou seja, comunicação em tempo real. Não é um substituto do e-mail, que está sendo mais direcionado para a consolidação de informações, tais como a ata de uma reunião, ou a formalização de uma requisição. O chat é realmente uma ferramenta mais dinâmica, e se você disponibilizada para uso na empresa, é onde o time de desenvolvimento vai interagir mais.

Criando a integração no Slack

No seu Slack clique para abrir o menu de opções (1) e em seguida no item “App & Integrations”:

20160410_04

Ao clicar será aberto um site com configurações, da mesma maneira que o VSTS e o TSF já tem várias integrações, o Slack também entrega várias prontas, procure na caixa de texto (1) por “Visual Studio Team Services”:

20160410_05

Já é apresentado as integrações existentes, clique no botão “Install” (1):

20160410_06

Em seguida escolha o canal para o qual as notificações serão “postadas” (1), em seguida é só instalar:

20160410_07

O próprio Slack irá fornecer a ajuda para continuar o processo, porém o mais importante desta tela é a informação da URL para a integração, use “Copy URL”, para continuarmos o processo no VSTS.

20160410_08

As customizações existentes são o nome da integração no painel integrações do Slack. Infelizamente não é possível customizar as informações que serão mostradas na postagem da mensagem no canal.

VSTS ou TFS

Acesse o menu de Settings > Service Hooks, se nenhuma integração tiver sido feita nesta conta, estará visível o botão Create Subscription, senão, procure pelo botão com o sinal ‘+’.

20160410_09

Escolha o serviço do VSTS:

20160410_10

Em seguida é preciso escolher o trigger, ou seja, qual a ação que irá gerar uma notificação, neste caso vamos usar o Build Completed (1), e nos filtros, vamos selecionar uma definição de build específica (2), e o status Succeded (3):

20160410_11

Essas configurações são bastante importantes para não cairmos no erro das notificações por e-mail, que é receber demasiadas notificações o que torna cansativo a verificação.

Se pensarmos no conceito de CI e deploy em ambiente de desenvolvimento, talvez o ideial seja receber somente notificações de falha de deploy, nem de build executado com sucesso, pois isso poluiria a timeline do chat!

Seguindo, o último passo irá pedir aquela URL que foi gerada anteriormente, é só colocar no campo Slack Webhook URL:

20160410_12

Clicando no botão Teste, veja o que acontece no canal do time no Slack:

20160410_13

Já executando um build, e o status sendo de sucesso:

20160410_14

No meio de um chat o time pode conferir que um build foi executado, o status é de sucesso, tem o nome, quem solicitou, quanto tempo demorou, … bem informativo.

Na tela de Service Hooks algumas informações importantes para gerenciamento. o status da integração (1) e a quantidade de execuções nos últimos 14 dias:

20160410_15

Talvez você receba um e-mail de alerta de build, mas isso não é da integração com o Slack, e sim uma notificação que você deve desativar no VSTS

O que mais é possível fazer

Além do build completed, você pode notificar no Slack:

  • Code pushed
  • Pull request created
  • Pull request merge commit created
  • Pull request updated
  • Release abandoned
  • Release created
  • Release deployment approval completed
  • Release deployment approval pending
  • Release deployment completed
  • Release deployment started
  • Team room message posted
  • Work item commented on
  • Work item created
  • Work item deleted
  • Work item restored
  • Work item updated

Ou seja, é muita integração informativa e interressante para deixar cair no esquecimento na sua caixa de e-mail! Em determinados momentos, é interessante ligar algumas, para resolver alguma comunicação no time, em outros momentos, deixar somente as que mostram falhas.

Como obter a iteração atual de vários times

$
0
0

Recentemente surgiu a seguinte pergunta no canal de ALM do Slack da Brasil.NET:

amigos
é possível no VSTS realizar queries cross projects utilizando a variável @CurrentIteration, pra trazer a sprint atual de vários projetos no filtro?
tentei de algumas maneiras aqui e não rolou

Minha resposta foi:

Não vai rolar. O problema é que a macro @CurrentIteration depende do contexto do time atual. Por isso, não dá para fazer cross-project.
Uma alternativa seria, via script, obter a iteração padrão de cada time e concatenar numa única query WIQL com OR.

E este post é exatamente sobre como criar o script que faz isso.

TfsCmdlets to the rescue!

Claro que o script vai ser em PowerShell. E como estamos falando de TFS, o TfsCmdlets pode ajudar muito aqui.

Depois de instala-lo (Install-Module TfsCmdlets), a primeira providência é obter uma lista de times e seus GUIDs:

Connect-TfsTeamProjectCollection -Collection http://<url-do-meu-tfs> -Interactive

$teams = Get-TfsTeamProject | Get-TfsTeam | Select Name, @{L='Id'; E={$_.Identity.TeamFoundationId}}

$teams

O resultado vai ser algo parecido com isto aqui:

PS C:\Users\igor.abade> $teams = Get-TfsTeamProject | Get-TfsTeam | Select Name, @{L='Id'; E={$_.Identity.TeamFoundationId}}
PS C:\Users\igor.abade> $teams

Name                  Id
----                  --
NorthwindTraders Team c8c4ec89-b014-4cea-972b-1d80d08d3e8f
TfsSearch Team        6715a4db-66a3-4d23-960f-80fa6b975d83
Database Team         78cde248-c29a-4a1a-88a9-7ac064669c9a
Web Team              0ef068be-c17a-4a95-b2bc-ac77ee81be12
FabrikamFiber Mast... e78f7de9-bfeb-4a49-afd5-af1c120ec3a4
PartsUnlimited Team   b80b113e-aa73-4c35-8bfb-5f7f559e9930
Archive Team          b49ec8aa-3393-44d6-aa79-f881da720fa3
Personal Team         f64cc2e8-2d16-4d55-996e-206534513418
SAC Team              444e07b2-2643-498d-b380-2e823be2a4a3
Tfs Team              7e1ccc5b-b96c-4f22-a351-dc35ee4b257d
TfsRegedit Team       67458414-2a6b-415f-93ed-8df10999437b
OpenSource Team       4cde10ce-fd29-4f70-855b-e495f6a03c97
New team              149edcf0-d6a1-4b7c-a9e5-323127f34faa
NewProject Team       ee0925d1-95ed-472e-a2ba-b56650ec6929
Another team          7a4a27ae-fb08-410b-9847-b5748d0102e5

Agora, para obter a iteração atual, vc precisa da classe TeamSettingsConfigurationService. Por, por padrão, o assembly que contém essa classe não está carregado na memória, precisamos usar primeiro Add-Type e, só então, chamar o método GetTeamConfigurations:

Add-Type -AssemblyName Microsoft.TeamFoundation.ProjectManagement

$guids = [guid[]] ($teams | Select -ExpandProperty Id)

$configSvc = (Get-TfsTeamProjectCollection -Current).GetService([type]'Microsoft.TeamFoundation.ProcessConfiguration.Client.TeamSettingsConfigurationService')

$configs = $configSvc.GetTeamConfigurations($guids)

$teamDefaultIterations = $configs | Select TeamName, @{L='Iteration'; E={$_.TeamSettings.CurrentIterationPath}}

Quase lá. Agora temos os nomes dos times e suas respectivas iterações atuais:

PS C:\Users\igor.abade> $teamDefaultIterations

TeamName                  Iteration
--------                  ---------
NorthwindTraders Team     NorthwindTraders\Release 1\Sprint 1
TfsSearch Team            TfsSearch\Release 1\Sprint 1
Database Team
Web Team
FabrikamFiber Master Team FabrikamFiber\Release 1\Sprint 1
PartsUnlimited Team       PartsUnlimited\Iteration 1
Archive Team              Archive\Release 1\Sprint 1
Personal Team             Personal\Release 1\Sprint 1
SAC Team                  SAC\Release 1\Sprint 1
Tfs Team                  Tfs\Release 1\Sprint 1
TfsRegedit Team
OpenSource Team           OpenSource\Release 1\Sprint 1
New team
NewProject Team           NewProject\Sprint 2
Another team

Neste ponto, você já está com as informações necessárias para montar sua query WIQL.

Vamos supor que você queira pesquisar todas as tasks que estejam “in progress” em todos os times de todos os projetos. Sua query seria montada assim:

$iterations = ([string[]]($teamDefaultIterations | Where Iteration  | % {"[System.IterationPath] = '$($_.Iteration)'"}) -join ' OR ')

$wiql = "SELECT [System.Id], [System.Title], [System.State], [System.AreaPath], [System.IterationPath], [System.AssignedTo] FROM WorkItems Where [System.WorkItemType] = 'Task' AND [System.State] = 'In progress' AND ($iterations)"

Ufa! Agora é só rodar a query 😃

Get-TfsWorkItem -Query $wiql

E voilà!

PS C:\Users\igor.abade> Get-TfsWorkItem -Query $wiql

Id       Rev  Type                 State           Changed              Assigned To               Title
--       ---  ----                 -----           -------              -----------               -----
214      4    Task                 In Progress     22/07/2016 10:38:33  Igor Abade (MSA)          Criar os ícones
215      3    Task                 In Progress     22/07/2016 10:41:14                            Implantar os ícones
284      2    Task                 In Progress     23/03/2017 14:48:36                            Criar tela de cadastro

Conclusão

O PowerShell, em combinação com o TfsCmdlets, permite fazer coisas muito legais ao interagir com o TFS/VSTS. Neste caso em específico, nosso código ficou razoavelmente comprido porque precisamos usar a API do TFS diretamente para obter informações sobre os times que, neste momento, não são expostas pelo TfsCmdlets.

Entretanto, na próxima release, teremos dois cmdlets novos (Get-TfsTeamIteration e Set-TfsTeamIteration) que retornam a informação desejada e eliminariam a necessidade de, neste caso, usar a API do TFS diretamente.

E aí, já usou o TfsCmdlets para resolver algum problema na sua empresa? Compartilhe aqui nos comentários a sua experiência!

Um abraço,
Igor

(Cross-post de http://www.tshooter.com.br/2017/04/13/como-obter-iteracao-atual-de-varios-times/)


Sobre IIS, Web Deploy e WinRM

$
0
0

Se você já precisou implantar um web site ASP.NET a partir do Release Management do TFS/VSTS, é possível que tenha usado a task Web App Deployment da extensão IIS Web App Deployment Using WinRM.

O que não te contaram é que talvez você tenha feito uma péssima escolha…

Que comece a polêmica!

O “problema” todo reside no WinRM – ou, mais especificamente, na decisão dos autores dessa extensão de usar o WinRM para fazer o deployment de um web site no IIS.

E por que o WinRM é um problema? É que ele torna muito complicado algo que podia ser muito mais simples!

Mas, afinal, o que é o WinRM?

Para entender o cerne da questão, precisamos começar entendendo o que é o WinRM, e o tipo de problema que ele se propõe a resolver.

De acordo com a documentação da Microsoft, “Windows Remote Management (WinRM) is the Microsoft implementation of WS-Management Protocol, a standard Simple Object Access Protocol (SOAP)-based, firewall-friendly protocol that allows hardware and operating systems, from different vendors, to interoperate.”

Em outras palavras, o WinRM é um protocolo baseado em SOAP que permite a administração remota de sistemas que implementem o protocolo WS-Management. Dentre as várias coisas que o WinRM permite fazer, a mais comum é a conexão a um terminal remoto, tal como o SSH num sistema Linux. Com isso, é possível conectar num servidor remoto via linha de comando e executar instruções como se estivéssemos diretamente no console do servidor – como eu disse, tal qual uma sessão SSH.

Extensão de deployment via WinRM. Note que é preciso primeiramente usar uma task de cópia de arquivos (1) para transferir o conteúdo do web site para um diretório temporário no servidor remoto antes de fazer a instalação propriamente dita no IIS (2)

A extensão de deployment de IIS que mencionei acima usa o WinRM para iniciar uma sessão remota (a la SSH) e executar o comando msdeploy.exe no servidor IIS para implantar a aplicação. Mas isso é desnecessariamente complicado! Senão, vejamos:

  1. Primeiramente é preciso copiar todos os arquivos do web site (o pacote de Web Deploy gerado durante o build de um site ASP.NET) para dentro do servidor de destino. Isso implica em usar alguma ferramenta de cópia de arquivos a partir do agente de release para o servidor de destino (FTP, Windows File Share ou algo que o valha);
  2. Depois, precisamos garantir que o Web Deploy esteja instalado no servidor de destino, pois a task depende de encontrar o arquivo msdeploy.exe lá no servidor onde está o IIS;
  3. Como se não bastasse, ainda precisamos configurar o WinRM no servidor IIS para aceitar chamadas remotas a partir do agente de release. E, acredite, isso pode dar um baita trabalho. É preciso se preocupar com credenciais, certificados, hosts confiáveis, HTTP vs. HTTPS… Sem contar que a configuração precisa ser feita nas duas pontas (agente e servidor). Ah, e boa sorte se seus servidores não estiverem num mesmo domínio!
  4. Tipicamente, o usuário precisa ter privilégios de administrador para se conectar ao servidor remoto. Ou seja, o agente de release vai ter mais privilégios do que deveria apenas para implantar um web site;
  5. Por fim, mas não menos importante: Você escancarou várias “portas” em seu servidor, que permitem inclusive acesso administrativo completo, quando tudo o que você queria era fazer deployment de um web site. É uma superfície de ataque desnecessariamente grande, principalmente se seu servidor Web estiver numa DMZ.

Ao invés disso, que tal usar um serviço que permita unicamente a implantação remota de uma aplicação Web num servidor IIS, sem o footprint gigante de uma solução baseada em WinRM?

Esse serviço já existe. Aliás, é bem provável que ele já esteja instalado em seu servidor IIS e você nem saiba.

A surpresa, para mim, é: Por que os autores da extensão não usaram este serviço desde o início?!

IIS Web Management Service

O IIS Web Management Service (WMSVC) é um recurso do IIS que permite a administração remota do servidor. O Web Deploy, por sua vez, oferece integração nativa a esse serviço e permite a implantação remota de aplicações Web.

Diagrama de operação do Web Deploy com o WMSVC. Um cliente remoto se conecta ao serviço de gerenciamento remoto do IIS, que por sua vez transfere o controle para o serviço remoto do Web Deploy a fim de implantar a aplicação Web

O primeiro passo é configurar o WMSVC no servidor IIS de destino.

Agora, a partir de um computador remoto (que pode ser a máquina do desenvolvedor ou um agente de build/release) já é possível executar o msdeploy.exe localmente. Este, por sua vez, conecta-se ao WMSVC no servidor de destino, copiando os arquivos e efetuando as configurações necessárias no IIS, sem depender do WinRM para isso.

Para usar esta nova abordagem, é preciso instalar o Web Deploy tanto no agente de build/release quanto no servidor IIS de destino. Agora, uma dica importante:

  1. No agente de build/release, você irá selecionar a opção Typical durante a instalação do Web Deploy;
  2. Já no servidor IIS de destino, selecione a opção Complete.

Por fim, no seu pipeline de release no TFS/VSTS remova as tasks de IIS+WinRM. Nós vamos, ao invés disso, usar o arquivo batch criado durante o processo de empacotamento de uma aplicação Web no build. Sabe quando você coloca no seu build os parâmetros abaixo? Então, ele está empacotando seu site no formato necessário para o Web Deploy.

/p:DeployOnBuild=true /p:WebPublishMethod=Package
/p:SkipInvalidConfigurations=true
/p:PackageLocation=$(build.artifactstagingdirectory)

Por acaso você já reparou que, quando você faz isso, ele gera um arquivo .deploy.cmd junto aos arquivos do seu site? É esse arquivo que usaremos no nosso release.

Build de uma aplicação ASP.NET, com os arquivos de publicação do Web Deploy (em destaque, o script de implantação com a extensão ".deploy.cmd", gerado automaticamente)

Agora, tudo o que nos resta é criar/alterar a definição de release, colocando apenas uma simples task de Batch Script. Nela, iremos chamar o arquivo CMD com os devidos parâmetros para informar detalhes como nome do servidor IIS de destino e credenciais do usuário com permissão para fazer um deploy no servidor:

Task de Batch Script com a chamada ao script de Web Deploy. Note o argumento /M, com a indicação do URL apontando para o Web Deployment Handler no servidor de destino

Conclusão

O WinRM é uma ferramenta extremamente poderosa e, por isso mesmo, pode não ser a melhor opção quando se quer fazer uma simples publicação de um site ASP.NET. Ao invés disso, o Web Deployment Handler do Web Deploy oferece uma solução mais simples, leve e segura de se obter o mesmo resultado.

Um abraço,
Igor

(Cross-post de http://www.tshooter.com.br/2017/08/10/sobre-iis-web-deploy-e-winrm/)