Que tal armazenar a sua aplicação na nuvem usando o serviço do Windows Azure para controlar o ciclo de vida e a implantação? Agora a Microsoft tem um serviço chamado Visual Studio Online, que é totalmente integrado ao Visual Studio 2013 e que permite controlar o versionamento de códigos, gerenciar os Builds, implementar e controlar o ciclo de vida do desenvolvimento da aplicação no time através de workflow, usar todos os controles de tarefas (work items). Sendo assim, quem usa o famoso Team Foundation Server (TFS), agora tem todas opções online no Azure.
Neste artigo vou mostrar um passo a passo de como criar uma conta e usar o VS Online, como integrar no Windows Azure, usar o Visual Studio 2013 para criar um projeto, fazer o deploy no Azure através do VS Online e explorar as opções disponíveis no site do projeto no Azure para um melhor acompanhamento e gerenciamento. E, é claro, quais as ferramentas disponíveis no VS 2013 para automatizar esta integração.
Os pré-requisitos para este artigo são o Visual Studio 2013 e o Windows Azure SDK, assim como uma conta para ambos. Caso não tenha algum destes, faça o download diretamente do site da Microsoft.
Passo 1. Conta no Visual Studio Online
A primeira coisa a fazer é criar uma conta no VS Online. Acesse o link para obter informações gerais, ou diretamente aqui, para criar a conta e usar. Existem diversos planos, desde o gratuito até os pagos de acordo com o número de usuários. Sendo assim, clique no ícone para criar a sua conta, digite as informações necessárias e pronto. Caso já tenha uma conta vinculada à Microsft, basta logar. Na figura 1 eu já me loguei, mas não tenho nenhuma conta no VS Online. Então, clique na opção “Crie uma conta gratuita agora”.
Veja na figura 2 que é preciso informar a URL de uma conta. O link é pré-definido com https://<suaconta>.visualstudio.com, proporcionando ao usuário criar uma conta personalizada. Isto é ótimo porque você pode ter uma conta para cada projeto.
Como exemplo para o nome da conta, vou colocar o meu nome, mas é claro que você deve colocar o seu nome ou o nome de um projeto. Conforme a figura 3, após digitar a URL da conta, clique no botão Criar Conta e aguarde o processo finalizar.
O próximo passo irá abrir uma janela do Visual Studio Online, solicitando as informações do projeto. Conforme a figura 4, digite em Project name (nome do projeto) o nome do seu projeto – neste exemplo usei ProjetoArtigoMSDN. Em Description escreva um texto descritivo para informar do que se trata este projeto. Em Version control (controle de versão), você pode optar pelo Team Foundation Version Control (é o padrão e deixaremos esta opção selecionada), ou Git, que é um repositório bem comum e usado por vários times. No Process template pode deixar o padrão “Microsoft Visual Studio Scrum 2013.2”, que é o modelo a ser usado. Para finalizar, clique no botão Create project e aguarde a criação.
Após criar o projeto, teremos a mensagem informando que o projeto foi criado e está pronto, conforme a figura 5 – assim como as opções de menu para gerenciamento. No menu Code, você poderá ver todos os códigos – quando eles existirem, é claro. O mais comum para times é o uso do Work, onde se gerenciam os work items, sprints e backlogs. Em Build são mostrados todos os Builds do projeto. Em Test você pode criar um plano de testes para o projeto. No entanto, como nem temos o projeto criado, clique em “Open with Visual Studio to connect” para abrir o Visual Studio 2013. Observe que ter o VS 2013 instalado na máquina é um pré-requisito.
Ao clicar no botão para abrir o VS, será mostrada a janela da figura 6 para permitir a execução. Portanto, clique no botão Permitir.
Excelente! Já temos o VS 2013 aberto e com a janela do Team Explorer mostrando o projeto ProjetoArtigoMSDN, conforme a figura 7.
Agora é preciso configurar o workspace para vincular o local físico ao virtual, e isto é feito apenas na primeira vez. Este é o conceito de mapeamento. Conforme a figura 8, observe que o endereço mapeado está sugerido na caixa. Caso queira mapear para outra pasta, clique no botão Construtor (…) e aponte para o destino. Em seguida, clique no botão Map & Get e aguarde o Team Explorer mapear tudo.
Aguarde a criação do mapeamento e tenha certeza, ao final, que o VS conseguiu mapear. Isto é comprovado pela mensagem “The workspace was mapped successfully”, conforme a figura 9. Aqui já teremos todas as opções de ações para o projeto, como My Work, Pending Changes, Work Items, Source Control Explorer, etc, ou seja, este é o menu principal de ações do projeto. Obviamente não adianta selecionar nenhuma opção porque ainda não temos nenhum projeto criado, apenas o ambiente.
Passo 2. Criar um projeto de Azure Cloud
Até aqui temos a conta e o projeto criado no VS Online. O próximo passo é criar o projeto no Visual Studio 2013 localmente. Portanto, selecione o menu File / New Project, a linguagem será o Visual C#, o template de Cloud – e o único que está disponível é o Windows Azure Cloud Service. O nome (Name) do projeto será Windows Azure1. A pasta você pode escolher uma do seu computador, conforme a figura 10. Clique no botão OK
Logo a seguir é aberta a janela para você selecionar os serviços para esta solução. Portanto, selecione WebRole e WorkerRole, conforme a figura 11. Clique no botão OK.
Como temos um serviço de WebRole, precisamos informar qual tipo de template do ASP.NET usaremos. Dentre as opções disponíveis, conforme a figura 12, selecione MVC, o qual será criado um projeto baseado no template MVC 5. A autenticação você pode deixar como “Individual User Accounts”. Todo projeto de MVC cria uma estrutura de acordo com esta arquitetura, portanto, se você não for familiarizado com MVC, pesquise os diversos artigos que publiquei sobre este assunto no MSDN. Ao final, clique no botão OK e aguarde a criação completa do projeto.
Com o projeto criado, agora é preciso adicionar a solução ao controle de fontes para o versionamento. No Solution Explorer, clique com o botão direito no nome da solução WindowsAzure1, conforme a figura 13, e selecione “Add Solution to Source Control”.
É aberta a janela com duas opções, conforme a figura 14, sendo:
- Team Foundation Version Control: usa um servidor centralizado para repositório onde é permitido pesquisar e armazenar diversas versões dos arquivos. Qualquer alteração local é sempre verificada com o servidor, onde outros desenvolvedores podem pegar as últimas versões.
- Git: é um sistema de controle de versões distribuído que usa um repositório local para pesquisar e versionar os arquivos. Todas as alterações são compartilhadas com outros desenvolvedores através de envios e requisições de alterações remotas no repositório compartilhado.
Neste exemplo, vamos deixar selecionada a opção padrão, Team Foundation Version Control. Clique no botão OK.
Em seguida, é aberta a janela contendo o local indicado para armazenar a solução no TFS e no seu worspace. Conforme a figura 15, pode manter as sugestões padrão e clique no botão OK. Note ainda que é mostrado o nome do servidor, neste caso, renatohaddad.visualstudio.com\DefaultCollection. Caso queira armazenar em outra pasta, clique no botão “Make New Folder” (Criar uma Nova Pasta) e coloque um nome que desejar. Mas isto não é o nosso caso neste artigo.
Abra o Solution Explorer e note que cada arquivo contém um símbolo de marcação + (adição), indicando que estes arquivos ainda não foram para o servidor, conforme a figura 16. Isto é ótimo para que você possa identificar através de símbolos o status dos arquivos. Futuramente, quando enviarmos os arquivos para o servidor, fizermos alterações ou adicionarmos um novo arquivo ao projeto, só o fato de visualizar o símbolo já identificaremos o status.
E como enviar os arquivos ao servidor? É simples, abra o Solution Explorer, clique com o botão direito na solução e selecione Check In, conforme a figura 17.
Será aberta a janela do Team Explorer, mostrando o Pending Changes (alterações pendentes). Em Comment é preciso digitar algum texto para justificar, e em seguida, clique no botão Check In, conforme a figura 18. Exatamente neste momento, como é a primeira vez que está vinculando os arquivos locais a um servidor, aguarde a transferência de todos os arquivos. Neste momento ainda é possível selecionar ou não quais arquivos serão enviados. Na figura 18, observe que o item “Included Changes (318)” nos informa que serão incluídos 318 arquivos na transferência. E, você pode marcar alguns para exclusão do envio. Mas, não é o caso, ainda mais na primeira vez.
Após este processo, por curiosidade, abra o Solution Explorer e note que cada arquivo contém um símbolo de cadeado em azul. Quando um arquivo é alterado e salvo, ficará com o símbolo de confirmado em vermelho. E quando você fizer o Check In, o símbolo ficará como um cadeado em azul.
Aliás, quando quiser enviar apenas um arquivo para o servidor, no Solution Explorer, clique com o botão direito no mesmo e selecione Check In.
Passo 3. Criar um site no Windows Azure
Até agora temos o projeto no VS Online e o projeto MVC 5 local já com o vínculo de versionamento para o servidor TFS. O próximo passo é criar um web site no Windows Azure e vincular o projeto do TFS no VS Online com o Azure.
Pode compilar todo o projeto no VS 2013, pressione CTRL + SHIF + B ou apenas F6. Pode fechar todos os arquivos abertos no VS 2013 para que possamos focar no Azure. Abra a janela do Server Explorer (menu View / Server Explorer), localize e expanda o Windows Azure. Clique com o botão direito em Web Sites e selecione Add New Site, conforme a figura 19.
Dica: Se o Server Explorer não tiver esta opção é porque você não instalou as últimas ferramentas do Windows Azure, portanto, veja no início deste artigo o link para download. Nem preciso dizer que você precisa ter uma conta no Azure. É grátis e simples de se cadastrar; aproveite a oportunidade e se inscreva, caso ainda não tenha a conta.
O mais legal no Server Explorer é que você consegue adminstrar os sites por ali. Em seguida, é aberta a janela conforme a figura 20, solicitando as informações sobre o novo site. Em site name, digite ArtigoVSonline, que será o nome do site. Aguarde alguns segundos até que seja verificado se a URL está disponível. Se estiver, é colocado o símbolo de verificado em verde, indicando que está disponível. Note que a URL completa será <web site>.azurewebsites.net. Em Subscription, selecione a sua conta;’ o Location pode deixar o padrão ou apontar para outro local. Em Database server deixe como “No database”, pois não teremos banco de dados neste projeto. Ao final, clique no botão Create e aguarde a criação do web site.
Agora vamos para o site do Azure. Você pode abrir o portal do Azure, se logar e configurar o site. Ou o atalho é abrir o Server Explorer, selecionar Windows Azure / Web Sites, e na lista de Web Sites, clicar com o botão direito no ArtigoVSonline e selecionar “Open in Management Portal”, conforme a figura 21.
Assim que o portal do Azure é aberto com este Web Site selecionado, você verá uma mensagem indicando que o site foi criado com sucesso. Já estão disponíveis diversas opções de configuração, então localize o item “Integrar o controle de origem” e clique em “Configurar a implantação a partir do controle de origem”, conforme a figura 22.
Será aberta a janela, conforme a figura 23, para você selecionar o provedor do código fonte para este web site. Na lista são mostrados praticamente todos os provedores de repositórios de arquivos disponíveis no mercado. Claro que a lista pode mudar dinamicamente de acordo com o mercado, mas é certo que o Visual Studio Online sempre estará na lista. Sendo assim, selecione esta opção. Em seguida, clique na seta para direita para passar a próxima etapa.
Na URL solicitada você deverá informar a URL gerada no passo do VS Online, aquela que foi criada quando abrimos o VS Online e criamos um projeto. Veja na figura 24 o exemplo da URL.
Logo a frente da URL informada, há o link “Autorizar Agora”, portanto, clique nele e aguarde a autorização. Uma vez autorizado, será mostrada a tela de requisição de conexão, onde temos os botões de Aceitar ou Recusar, conforme a figura 25. Clique em Accept (Aceitar) e aguarde.
Ao final, se tudo foi autorizado, será aberta a janela conforme a figura 26. Aqui serão listados todos os nomes dos repositórios, mas como só temos um, resta-nos selecionar o único na lista.
Enquanto o Azure trabalha nos bastidores para vincular o projeto, você visualiza o status para saber o que está acontecendo. Veja na figura 27 o status do vínculo.
E alguns segundos após, pronto, o projeto está vinculado. Agora é preciso criar e fazer o deploy no Azure. Pode deixar o portal aberto e retorne ao VS 2013. No Team Explorer, clique no nome do projeto e selecione Source Control Explorer, conforme a figura 28.
O Source Control Explorer é uma janela em que constam todos os arquivos do projeto. Caso esteja com a solução fechada ou com outra solução aberta e queira focar na sua solução deste projeto, localize e abra o arquivo de solução WindowsAzure1.sln, conforme a figura 29.
Vamos realziar algumas alterações nas páginas para submeter ao servidor e ver o fluxo de trabalho. Na pasta View / Shared, localize o arquivo _Layout.cshtml, altere algum código HTML e salve. Veja uma sugestão:
HTML
@Html.ActionLink("VSOline", "Index", "Home", null, new { @class = "navbar-brand" })
No Team Explorer, mostre o Pending Changes. Note que automaticamente esta página é listada. Para submeter ao servidor, em Comment digite uma justificativa e clique em Check In para atualizar o repositório de arquivos, conforme a figura 30.
Aguarde o envio do arquivo ao servidor e ainda no Team Explorer, clique no ícone Home para mostrar todas as opções. Clique em Pending Changes, conforme a figura 31 e observe que não há nenhuma pendência (There are no pending changes). Este processo torna-se repetitivo a cada vez que você alterar um arquivo. É claro que não é preciso submeter um a um, você pode alterar todos os arquivos necessários, compilar o projeto, e se tudo estiver 100% compilado e sem erros, aí sim, faz-se o Check In.
Configurar o Build
O próximo passo é configurar o Build, então, no Team Explorer, clique em Home e selecione Builds, conforme a figura 32.
Aqui serão mostrados todos os Builds realizados. Como temos apenas um Build, ele será mostrado na lista, conforme a figura 33. No entanto, este Build contém um erro (Bug), por isto o ícone está com um X vermelho. Se o seu Build não tiver um erro, o ícone ficará em verde.
Um erro de Build não necessariamente é um erro no código e muito provavelmente não será, afinal indico sempre fazer o Check In somente se o projeto for compilado 100% com sucesso. Pode ser um erro de conexão com o server, um erro de login, enfim, você pode dar um duplo clique no Build com erro para abrir a janela de Bug e rastrear o erro, conforme a figura 34.
Para efeito de teste, altere e salve novamente qualquer item do HTML 5 em _Layout.cshtml e faça o Check In novamente. Uma vez iniciado o Check In, ocorre a transferência de arquivos, e isto chamamos de “em progresso”. Durante este processo de Build, caso queira visualizar o status, dê um duplo clique no Build para ver os detalhes, conforme a figura 35. Note que o ícone é uma seta para direita na cor azul.
- Figura 35 – Build em progresso.
Quando o Build estiver finalizado, você verá um ícone verde na lista. Dê um duplo clique nele e veja o resumo do Build realizado com sucesso (Build succeeded), conforme a figura 36. Cabe ressaltar que o ato de se fazer um Build significa que os arquivos pendentes estão sendo transferidos para o repositório de arquivos, neste caso o VS Online, sincronizados com o Windows Azure e compilado no Azure.
E como configurar o Build? Pense da seguinte maneira: a cada Build é preciso realizar a compilação no Azure para disponibilizar imediatamente a nova versão, certo? Perfeito, você está certo, porém isto pode ser configurável conforme a necessidade do projeto e do time.
Para visualizar a definição do Build, no Team Explorer / Builds, clique com o botão direito no Build já realizado e selecione Edit Build Definition, conforme a figura 37.
Na janela aberta, selecione a tab Trigger e observe que o Build está definido a cada Check In. Ou seja, a cada Check In realizado, o Build (compilação) é feito automaticamente, de forma contínua e integrada, conforme a figura 38. Isto é o normal que esperamos, no entanto é possível definir outras configurações de triggers, sendo:
| Manual | Manual – Check-ins do not trigger a new build | O Check In não dispara o build automaticamente |
|---|---|---|
| Continuous Integration | Continuous Integration – Build each check-in | Integração contínua realiza o Build a cada Check In |
| Rolling builds | Rolling builds – accumulate check-ins until the prior build finishes | Acumula check-ins até terminar a compilação anterior |
| Gated Check-In | Gated Check-In – accept check-ins only if the submitted changes merge and build successfully | Aceita os check-ins somente se as alterações enviadas mesclarem e compilarem com sucesso |
| Schedule | Schedule – build every week on the following days | Agenda o Build de acordo com cada dia selecionado na lista |
Veja na tab Process demais configurações como local de deploy “Windows Azure Development Environment”, “Allow Upgrade”, “Do Not Delete”, etc, conforme a figura 39.
Agora que você já domina o Build, retorne ao portal do Azure. Veja o status do Build no menu Implantações, conforme a figura 40. Note que a implantação está ativa na data e hora, o autor, implantado por (em caso de times isto é fundamental).
Complementos aplicáveis
Nesta mesma tela, clique na opção Painel para obter uma visão geral das configurações e opções do site, conforme a figura 41. Há diversos links na direita para obter informações rápidas sobre os complementos aplicáveis, mostrar as strings de conexões com banco de dados (caso tenha), baixar o perfil de publicação, entre outros.
Clique em “Exibir Complementos Aplicáveis” e será mostrada a tela da figura 42, onde você poderá adicionar qualquer um dos complementos à aplicação. Isto é ótimo para adicionar recursos de terceiros, sem a necessidade de escrever nenhuma linha de código.
O melhor de tudo é que é um assistente, ou seja, basta selecionar o complemento, informar as condições de pagamento (caso seja aplicável), e pronto. Por exemplo, selecione o complemento Bing Search, clique na seta para direita para o próximo passo, o qual é exibida uma tela conforme a figura 43. Agora basta selecionar o plano, as configurações e pronto.
Em Painel, há uma opção chamada URL do site com a URL completa a ser usada nos navegadores. Portanto, clique nesta URL e será mostrada a aplicação rodando do navegador, conforme a figura 44.
Simular outro Deploy
Para um melhor entendimento de Builds e Deploys, vamos simular um outro deploy. Abra o arquivo Index.cshtml na pasta View\Home. Como sugestão para alterar qualquer informação no HTML 5, na linha 7, altere o texto para:
HTML
<p class="lead">Veja o funcionamento do deploy no VSOnline + Azure.</p>
No Team Explorer, clique em Pending Changes e note que há uma pendência (Included Changes (1)) para esta página Index. Em Comment escreva um texto qualquer e clique no botão Check In, conforme a figura 45.
Isto irá colocar este Build na fila de Builds, com status “In Progress”, conforme a figura 46. Isto é comum porque pode depender de outros Builds. Em times médios com projetos em desenvolvimento ou manutenção, esta prática faz parte do dia a dia.
Neste momento, se você consultar a opção Implantações no portal do Azure, verá que este Build ainda não foi feito. Conforme a figura 47, note que o Build está com o status “Implantando”. Somente após o Build completo é que aparecerá na lista Builds.
Reimplantar (redeploy)
Uma opção interessante que há nos Builds no portal é o Reimplantar (Rebuild), o qual permite selecionar um Build na lista e clicar no botão Reimplantar no rodapé. Isto fará com que o Build Ativo seja este. Veja na figura 48 que temos dois Builds, o primeiro é o ativo, então, para ativar o outro Build, selecione-o e clique no botão Reimplantar. Isto permite ter uma lista de Builds, todos compilados com sucesso, é claro, no entanto, em certos momentos a aplicação ativa deverá corresponder a um determinado Build anterior, por exemplo.
Métricas do site
Uma vez com o site no ar rodando adequadamente, você pode obter as métricas na opção Painel. É possível aplicar filtros por entrada e saída de dados, erros de HTTP, solicitações e tempo de CPU. Veja na figura 49 todas as opções disponíveis, e para ativar ou não, basta clicar no nome do filtro.
Conclusão
O Visual Studio Online é uma ótima opção para repositório de dados, controle do ciclo de vida do processo de desenvolvimento, atribuição de tarefas, e o melhor de tudo é que está totalmente integrado ao Visual Studio 2013 e ao Azure. Desta forma, uma empresa não precisa comprar o softwares para montar toda esta estrutura em um servidor interno, aplicar updates de correção, alocar espaço em disco, etc. Pense no VS Online como um meio de manter todos os dados na nuvem, 100% disponíveis em qualquer lugar e hora, através de navegadores ou ferramentas como qualquer versão do VS 2013.
Já o processo de integração contínua de Build deve ser implantado para qualquer tamanho de time de desenvolvimento, pois se enquadra perfeitamente no controle de Builds. Com todos estes recursos, vale a pena pagar por um serviço confiável e de fácil uso, conforme o que apresentei neste artigo.
De 0 a 10, o quanto você recomendaria este artigo para um amigo?