Automatizando o deploy de aplicações ASP.NET com Octopus Deploy

Em um post anterior mostramos como criar e configurar um ambiente de integração contínua com Jenkis e Git. Neste tutorial faremos o deploy de nossa aplicação ASP.NET e, para isso, utilizaremos a ferramenta de automatização de deploy Octopus Deploy.

O Octopus Deploy permite a realização do deploy de aplicações ASP.NET (Web Forms, MVC e Web API) automatizando uma série de procedimentos durante este processo:

  • Atualização de arquivos de configuração: faz as devidas transformações nos arquivos .config de acordo com o ambiente (homologação, produção, etc).
  • Atualização do IIS: Automaticamente atualiza o website ou application pool do IIS.
  • Execução de scripts powershell: Possibilita que sejam incluídos scripts powershell para execução em diversos estágios do deploy (ex: um script para reinicialização de um serviço windows logo após o deploy). Não utilizaremos nenhum script post deploy neste exemplo.

Antes de começar a configuração do Octopus, vamos rever todo o fluxo que estamos criando:

Instalando o Octopus Server e Configurando o Nuget Feed

O Octopus consiste em dois módulos principais: Octopus Server e Octopus Tentacle. O Octopus Server é utilizado para o gerenciamento de todos os projetos e é onde iremos definir o Nuget Feed (diretório que contém os pacotes Nuget que devem ser descarregados no servidor-alvo). Os arquivos para instalação podem ser obtidos na página de downloads do Octopus.

  1. Instale o Octopus Server: Requer Windows Server 2008 ou superior. A instalação é intuitiva e nela você irá definir a URL para acesso ao painel administrativo e o usuário administrador. Você precisará do thumbprint gerado para identificar esta instância do Octopus Server no Octopus Tentacle (Configuration > Certifications).
  1. Configure o Nuget Feed: O Nuget Feed indica ao Octopus Server qual é o diretório do seu repositório de pacotes Nuget (que contém o conteúdo a ser descarregado no servidor web). No painel administrativo do Octopus Server, clique no menu superior direito em Configuration e, no menu esquerdo, em Nuget. Em seguida, clique em Add Nuget Feed e informe o caminho do diretório (ex: C:\Octopus\NugFeed\MeuProjeto).

Configurando Environment, Machine e Role

Antes de começar a configuração, precisamos conhecer estes três conceitos relacionados à forma como o Octopus Server gerencia os seus projetos.

  • Environment: O Octopus permite a criação de diversos environments – um para cada projeto a ser feito deploy. Cada um destes environments contém um conjunto de máquinas nas quais o deploy deverá ser feito. Você poderia ter em um mesmo environment duas máquinas – um servidor de homologação e um servidor de produção – por exemplo.
  • Machine: Cada máquina do ambiente deverá ter uma instância do Octopus Tentacle rodando (veremos mais adiante neste tutorial).
  • Role: Suponha que um ambiente possua duas máquinas. Como saber qual delas é a que será utilizada para homologação e qual será a de produção? Esta é a tarefa dos roles.

Vamos então criar um novo environment. Mais adiante iremos adicionar a máquina-alvo e configurar seu role.

  1. Adicionar um environment: Ainda no painel de controle do Octopus Server , clique em Environments, Add Environment e informe o nome e a descrição do novo ambiente.

Instalando o Octopus Tentacle

O Octopus Tentacle é um serviço windows que deve ser instalado no servidor onde você pretende fazer o deploy. Este serviço deve estar permanentemente sendo executado pois é ele quem recebe os comandos do Octopus Server e faz o deploy propriamente (assim como as demais tarefas como atualização do IIS e execução de scripts).

  1. Instale o Octopus Tentacle: No servidor onde você pretende fazer o deploy execute o instalador do tentáculo. Novamente, o instalador é bem simples e intuitivo. Assim que o processo for concluído será aberto o Tentacle Manager.

  1. Configurar o Octopus Tentacle: Assim que você clicar em Get Started será necessário completar uma série de etapas. Na figura abaixo vemos a etapa Listening Tentacle onde você pode indicar em qual porta o Octopus Tentacle espera receber as instruções do Octopus Server. É nesta etapa que deve ser informado o Octopus Server Thumbprint que anotamos anteriormente. Desta forma o Octopus Tentacle poderá identificar o Octopus Server quando receber instruções. Depois disso, basta finalizar a instalação.

  1. Anotar o thumbprint do tentáculo: Após a instalação terminar você verá a tela de administração. Nela você deve localizar e anotar o thumbprint gerado.

Adicionar uma nova máquina ao ambiente

Agora que o tentáculo está instalado e rodando no servidor temos de voltar ao gerenciador de environments do Octopus Server e adicionar uma nova máquina ao environment Exemplo.

  1. Adionar uma máquina ao ambiente: No painel de controle, clique em Environments e então em Add Machine para abrir a tela abaixo. Informe um nome para o servidor, a URL (a porta deve ser a mesma que foi configurada no tentáculo). Informe o thumbprint que anotamos durante a instalação do tentáculo. Observe que criamos um role chamado producao para esta máquina (basta escrever o nome do role e pressionar Enter).
  1. Check Health: Para verificar se o Octopus Server consegue se comunicar corretamente com o Octopus Tentacle, clique (no topo da tela de environments) no botão check health. Caso ocorra algum erro verifique as permissões de firewall do serviço Octopus Tentacle e se ambos os thumbprints foram informados corretamente.

Criar um novo projeto no Octopus Server

Vamos revisar o que temos até agora:

  • O Octopus Server está instalado e com o repositório de pacotes configurado (Nuget Feed).
  • O Octopus Tentacle está instalado no servidor-alvo e está se comunicando corretamente com o Octopus Server.
  • No Octopus Server criamos um environment que contém uma máquina. Esta máquina foi configurada com o thumbprint gerado no seu Octopus Tentacle.
Criaremos agora, no Octopus Server, um novo projeto. Um projeto consiste nos seguintes componentes:

  • Steps: O processo de deploy pode ser subdivido em diversas etapas. Você pode restringir um step para que atue em um determinado environment e ainda criar dependências entre os steps.
  • Variables: São configurações específicas do projeto e da máquina onde pretendemos fazer o deploy (ex: o nome do website no servidor IIS-alvo). Mais informações sobre variáveis podem ser obtidas aqui.
  • Releases: Uma release é o resultado da execução de todos os steps do projeto. O histórico de releases pode ser visto na aba Overview do projeto o que facilita muito quando se precisa retornar rapidamente para um release anterior.
  1. Criar um novo project group: Na tela administrativa do Octopus Server, clique em Projects e em seguida em Add project group. Não esqueça de informar o Environment criado anteriormente.

  1. Criar um novo projeto: Com o project group criado, clique em Add Project para visualizar a tela de criação de um novo projeto. Informe o nome e a descrição e clique em Add.
  1. Criar um novo step: Com o projeto criado, clique nele e em seguida na aba Steps. Clique em Add Step para adicionar. Na lista dropdown da tela seguinte, selecione a opção Deploy a Nuget Package.
  1. Configurar o step: Na tela de configuração informe o nome do step, o repositório de pacotes Nuget (criado anteriormente) e o nome do pacote que o Octopus deve utilizar (ele ainda não existe e será criado posteriormente – neste exemplo, chamei de MinhaAppMVC). Veja também que em Deploy to roles especificamos a role da máquina onde instalamos o Octopus Tentacle. As demais configurações não devem ser modificadas.
  1. Configurar as variáveis do projeto: Nosso projeto precisa apenas de uma variável chamada OctopusWebSiteName. Ela serve para informar ao Octopus qual o nome do web site no servidor IIS que desejamos que este projeto esteja vinculado. No exemplo o website foi criado com o nome Minha App. Veja que especificamos os campos Environment, Role, Machine e Step conforme o que foi criado anteriormente.

De volta ao Jenkins – criar pacote Nuget e executar o deploy

O Octopus Server está pronto para criar novas releases para o nosso projeto. Iremos agora criar um novo job no Jenkins e utilizar um script MSBuild para criar um novo pacote Nuget contendo o resultado do build feito anteriormente (ver este post para criar o job no Jenkins). Em seguida, o script fará uma chamada à API do Octopus para criar a release.

Antes de continuar, será necessário:

  • Fazer o download o Nuget.exe aqui. Ele será utilizado para compactar seu projeto em um .nupkg.
  • Criar um arquivo nuspec no diretório que pretende compactar (raiz da solução). O arquivo Nuspec serve apenas para conter metadados sobre o pacote (versão, autor, etc). Este arquivo deve ter o mesmo nome que foi informado no campo Nuget Package do step do projeto – no nosso caso, MinhaAppMVC.nuspec. Você pode encontrar exemplos de arquivos Nuspec aqui.
  • Obter a extensão do MSBuild MSBuildTasks aqui. Esta extensão permitirá que o MSBuild atualize o arquivo Nuspec a cada novo empacotamento.
  1. Criar novo job no Jenkins: Crie um novo job chamado Meu Projeto – Empacotamento e Deploy. Especifique dois scripts na seção Build – empacotamento.build e deploy.build.
  1. Criar novo script MSBuild chamado empacotamento.build: Este script cria um pacote Nuget (extensão .nupkg) do projeto previamente compilado. Observe as seguintes variáveis no script:
  • ProjectNuspec: caminho para o arquivo Nuspec da solução.
  • OctopusNugetFeed: o pacote Nuget resultante deve ficar no Nuget feed configurado no Octopus anteriormente.
  • Nuget: O caminho do executável Nuget.exe.
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0" DefaultTargets="Start">
  <Import Project="$(MSBuildExtensionsPath)MSBuildCommunityTasksMSBuild.Community.Tasks.Targets"/>

  <PropertyGroup>
    <ProjectNuspec>C:\MinhaApp\MinhaAppMVC.nuspec</ProjectNuspec>
    <OctopusNugetFeed>C:\OctopusNugFeed\MeuProjeto</OctopusNugetFeed>
    <Nuget>C:\Mobiltracker\Nuget\NuGet.exe</Nuget>
  </PropertyGroup>

  <!-- Target principal - executa demais targets na ordem correta -->
  <Target Name="Start">
    <CallTarget Targets="Init"/>
    <CallTarget Targets="Pack"/>
  </Target>

  <!-- Cria o repositorio de pacotes caso ainda nao exista -->
  <Target Name="Init">
    <MakeDir Directories="$(OctopusNugetFeed)" />
  </Target>

  <!-- Atualiza a versao no nuspec, compacta o projeto e envia para a pasta destino -->
  <Target Name="Pack">
    <XmlUpdate
		  Namespace="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd"
		  XmlFileName="$(ProjectNuspec)"
		  XPath="/package/metadata/version"
		  Value="$(VersionNumber)" />

    <Exec Command="$(Nuget) pack $(ProjectNuspec) -OutputDirectory $(OctopusNugetFeed)" />
  </Target>
</Project>

Veja que atualizamos o arquivo Nuspec com a task XmlUpdate. Na propriedade Value utilizamos uma variável chamada $(VersionNumber) que você não irá encontrar declarada no script. Isto porque trata-se de uma variável de ambiente criada pelo Jenkins e acessível no script (veja abaixo onde ela foi criada na configuração do job).

No campo Version Number Format String utilizamos uma máscara que indica que o valor da variável será gerado dinamicamente a partir da data de criação do projeto (especificado em Project Start Date). Assim, teremos versões do tipo 3.1.20.1 (3 anos, 1 mês, 20 dias, 1º release do dia).

  1. Criar uma nova API Key no painel de controle do Octopus: Faremos uma chamada à API do Octopus a partir do script MSBuild. Para isso, será necessário informar a chave da API que pode ser obtida (no painel do Octopus Server) em My Profile > Generate New API Key

  1. Obter o Octo.exe (Command Line). Esta ferramenta permite que sejam executadas comandos a partir do script. Ela pode ser obtida aqui .
  1. Criar novo script MSBuild chamado deploy.build: Este script é responsável por fazer uma chamada para a API do Octopus para a criação de uma nova release (a partir do pacote gerado no script anterior). Observe as seguintes variáveis no script:
  • OctopusProject: Nome do projeto criado no Octopus Server.
  • Environment: Ambiente criado no Octopus Server que contém a máquina-destino.
  • OctopusNugetFeed: Caminho do repositório de pacotes nuget (onde já deve estar o pacote gerado pelo script empacotamento.build).
  • OctopusAPIEndPoint: URL do Octopus Server
  • OctopusAPIKey: chave gerada no painel do Octopus Server
  • Octopus: Caminho do executável Octo.exe
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0" DefaultTargets="OctopusDeployToDev">
  <Import Project="$(MSBuildExtensionsPath)MSBuildCommunityTasksMSBuild.Community.Tasks.Targets"/>

  <!-- Propriedades globais -->
  <PropertyGroup>
    <OctopusProject>Exemplo</OctopusProject>
    <Environment>Exemplo</Environment
    <OctopusNugetFeed>C:\Octopus\NugFeed\MeuProjeto</OctopusNugetFeed>
    <OctopusAPIEndPoint>http://octopusserver:9090/api</OctopusAPIEndPoint>
    <OctopusAPIKey>XXX</OctopusAPIKey>
    <Octopus>C:\Jenkins\tools\Octo\Octo.exe</Octopus>
  </PropertyGroup>

  <!-- Executa API do Octopus para fazer deploy em ambiente de homologacao -->
  <Target Name="OctopusDeployToDev">
    <Exec Command="$(Octopus) create-release --project=&quot;$(OctopusProject)&quot; --version=$(VersionNumber) --server=$(OctopusAPIEndPoint) --apiKey=$(OctopusAPIKey)" />
    <Exec Command="$(Octopus) deploy-release --project=&quot;$(OctopusProject)&quot; --releaseNumber=$(VersionNumber) --deployto=&quot;$(Environment)&quot; --server=$(OctopusAPIEndPoint) --apiKey=$(OctopusAPIKey) --forcepackagedownload=true --force=true --waitfordeployment" />
  </Target>
</Project>

Se o job do Jenkins foi concluído sem erros um novo release foi gerado pelo Octopus e pode ser visualizado nos detalhes do projeto. Na saída do console do job você verá algo como:

  Finding project: Exemplo
  Handshaking with Octopus server: http://&lt;&lt; IP DO OCTOPUS SERVER &gt;&gt;:9090/api
  Handshake successful. Octopus version: 1.6.1.1718; API version: 2.0.0
  Finding environments...
  Finding steps for project...
  Resolving NuGet package versions...
    - Finding latest NuGet package for step: Deploy
  Release plan for release:    3.2.19.1
  Steps:
    #   Name      Version         Source
    --- --------- --------------- ------------------------------------
    1   Deploy    3.2.19.1        Latest available in NuGet repository

  Creating release...
  Release created successfully!
  C:\Jenkins\tools\Octo\Octo.exe deploy-release --project="Exemplo" --releaseNumber=3.2.19.1 --deployto="Exemplo" --server=http://&lt;&lt; IP DO OCTOPUS SERVER &gt;&gt;:9090/api --apiKey=XXX--forcepackagedownload=true --force=true --waitfordeployment
  Octopus Command Line Tool, version 1.1.17.62

  Finding project: Exemplo
  Handshaking with Octopus server: http://&lt;&lt; IP DO OCTOPUS SERVER &gt;&gt;/api
  Handshake successful. Octopus version: 1.6.1.1718; API version: 2.0.0
  Finding environments...
  Finding release: 3.2.19.1
  Successfully scheduled release 3.2.19.1 for deployment to environment Exemplo

Conclusão

Com os tutoriais mostrados neste post e em Integração Contínua de Projeto .NET com Jenkins você pode criar um sistema de continuous delivery simplificado mas pronto para melhoramentos como:

  • Criação de um pipeline no Jenkins que impeça o deploy caso os testes não passem.
  • Incluir o job de empacotamento e deploy no pipeline de jobs.
  • Criação de avisos por e-mail à equipe de desenvolvimento.
  • Condicionar o deploy à aprovação de um gerente.
  • Geração de relatórios.

Escrito por Rafael Companhoni.

Android Studio + Genymotion + Github – Ferramentas para Desenvolvimento de Software Android de Qualidade

Em dezembro de 2014, foi disponibilizada a IDE oficial da plataforma Android – Android Studio 1.0. Essa primeira versão estável da IDE traz uma série de melhorias em relação a IDE Eclipse (adotada por muitos anos para desenvolvimento Android), dentre as quais destaco o preview instantâneo de múltiplas telas enquanto editando o XML de layout do aplicativo e a geração de múltiplos apk’s (formato do arquivo de aplicativo Android) criados através de um único projeto Android com Gradle.

Contexto de Qualidade de Software (Android)

Em outubro de 2014, assisti uma palestra no TDC Porto Alegre do Edson Yanaga, o qual se autodenomina um artesão de software. Não conhecia o termo artesanato de software até então. Após assistir a palestra e ler mais sobre o assunto, uma frase valorizada pelo Manifesto do Artesanato de Software me chamou bastante a atenção:

Não apenas software em funcionamento, mas software de excelente qualidade

Boa aplicação de metodologias ágeis, boa gestão empresarial, qualidade dos desenvolvedores, boas ferramentas de desenvolvimento, etc, etc, etc… Esses e outros elementos guiam o rumo de um projeto de TI para a produção de software de qualidade. Qualidade não é só importante. É fundamental. Dentre vários possíveis porquês, cito principalmente que o software produzido por uma equipe é o resultado de meses de trabalho, mas o cliente só enxerga o resultado final do produto desenvolvido, ou seja, o software. Logo, ele ser de qualidade (sem bugs, de bom desempenho, com boa experiência de usuário, etc) e isso é primordial. Outro porquê, não menos importante, é a qualidade de software afetar diretamente a motivação de um time de desenvolvimento. Resumindo, um time de desenvolvimento deve ter a sensação de propriedade sobre o software sendo produzido. O time define como o software será construído por ele (com a escolha de ferramentas de seu interesse, inclusive), de modo que a qualidade do software não seja prejudicada pelo uso de ferramental ruim e, por consequência, esse padrão de qualidade não aja negativamente sobre o ânimo do time. Aliás, propriedade do time sobre o software em desenvolvimento é um dos pilares da metodologia de desenvolvimento XP – Extreme Programming (um bom livro sobre o assunto é Programação Extrema (XP) Explicada – Acolha as Mudanças, de Kent Beck).

O desenvolvedor de software mobile francês Cyril Mottier, reconhecido pelo Google como um “Google Developer Expert” (http://cyrilmottier.com/), defende a ideia que “Great applications come from great development environment”. Logo, reforçando a posição de Cyril Mottier e, como incentivo à produção de software Android de qualidade, serão explorados, em seguida, alguns contextos de uso tanto da IDE Android Studio, como também de ferramentas complementares que auxiliam o desenvolvedor na produção de bons aplicativos Android, dentre elas Genymotion e Github.

Instalando Android Studio

Esta seção, mostra a criação de um projeto-exemplo do qual será gerado um aplicativo Android através da IDE Android Studio e, em seguida, executado. Para o uso da IDE é realizado o download dela através do seguinte link:

http://developer.android.com/sdk/index.html

O instalador do Android Studio é executado. A seguinte tela de componentes a serem instalados é apresentada:

O primeiro componente é o SDK (Software Development Kit) Android. O segundo é um Android Virtual Device (AVD). Com esse componente selecionado, é pré-configurado um dispositivo virtual Android para que ele seja usado para testar aplicativos Android construídos em um emulador. Já o terceiro componente é formalmente conhecido como um “hardware-assisted virtualization engine”. Popularmente, mais conhecido por desenvolvedores Android como o “plugin da Intel”. A inicialização completa de um emulador Android é um processo muito lento (levando mais de um minuto, facilmente). O “plugin da Intel”, essencialmente, torna o processo de inicialização do emulador cerca de três vezes mais rápido. Porém, nem todos os computadores suportam esse plugin. O link abaixo apresenta uma descrição completa dos requisitos necessários para suporte ao plugin:

https://software.intel.com/en-us/android/articles/installation-instructions-for-intel-hardware-accelerated-execution-manager-windows

Em suma, geralmente, as máquinas com suporte ao “plugin da Intel” devem conter processadores Intel e terem desempenho acima de um Intel Core i5. Devido ao fato de muitas máquinas com desempenho abaixo do requerido para uso do “plugin da Intel” ainda serem usadas para desenvolvimento de soluções Android, será apresentado, em seguida, o Genymotion. O uso dele provém um “emulador” com desempenho acima do disponibilizado no SDK Android e não requer configurações de hardware avançadas para seu funcionamento.

Dando continuidade ao processo de instalação do Android Studio, a seguinte tela, solicita um diretório para instalação do Android Studio e outro diretório para instalação do SDK Android:

Passos depois, a instalação é finalizada. Então, ao ser iniciado o Android Studio, será mostrada a seguinte tela:

Genymotion no Android Studio

Genymotion é uma ferramenta que cria uma espécie de máquina virtual capaz de “emular” o sistema operacional Android.

Através de um plugin, é possível integrar Genymotion ao Android Studio de forma a possibilitar ao desenvolvedor uma melhor experiência de desenvolvimento para a plataforma Android. Para realizar o download da ferramenta Genymotion, em primeiro lugar, é necessário registrar-se no seguinte link:

https://www.genymotion.com

Em seguida, após realizar o download, é executado o instalador da ferramenta:

Será solicitado um diretório para instalar a ferramenta, como mostrado na ilustração acima.

Após concluir a instalação, Genymotion pode ser integrado a IDE Android Studio. Para isso, devem ser realizados os passos (após iniciar Android Studio), conforme explicitados nas ilustrações abaixo:

Botão direito do mouse sobre Genymotion, conforme mostrado abaixo:

Uma vez instalado, Android Studio deve ser reiniciado de forma que a instalação do plugin esteja completa.

Projeto-Exemplo no Android Studio

De forma a demonstrar as ferramentas abordadas neste post, será criado um projeto-exemplo. A sequência de passos para a criação do projeto é mostrada abaixo:

Uma vez o projeto criado, ele já está com todas as condições mínimas para ser executado no emulador (no caso, o Genymotion). Antes disso, é necessário finalizar a configuração do plugin do Genymotion referenciando o diretório onde ele foi instalado para o Android Studio. Para isso, é necessário clicar no ícone do Genymotion, conforme a ilustração abaixo:

Será solicitado o local onde o Genymotion foi instalado (por padrão, ele é instalado no diretório C:\Program Files\Genymobile\Genymotion).

Um dispositivo virtual, então, deve ser criado. Uma série de dispositivos virtuais já são definidos pelo Genymotion (inclusive, de dispositivos reais tais como Samsung Galaxy S3, por exemplo). Assim, é selecionado o mesmo ícone de Genymotion (da mesma forma como a imagem acima) e criado o dispositivo virtual conforme às ilustrações abaixo:

Uma vez criado o dispositivo virtual, ele é iniciado:

Após iniciado o dispositivo virtual Genymotion, é executada a aplicação:

Comitando Projeto para o Github com Android Studio

Github é um serviço de hospedagem compartilhado de projetos que usa sistema de controle de versionamento Git, usado por inúmeras empresas de TI no mundo.

De forma a explorar essa ferramenta através de Android Studio, será usado o projeto-exemplo criado na seção anterior comitando-o para o Github, conforme mostrado nas figuras abaixo (é assumido que o desenvolvedor já tenha criado uma conta no Github):

Conclusão

Esse post teve como objetivo mostrar brevemente o Android Studio 1.0, primeira versão estável dessa IDE. Além disso, apresentou a ferramenta Genymotion que “emula” o sistema Android com um desempenho acima do emulador disponibilizado pelo SDK Android. Por fim, também brevemente, mostrou o Github e sua integração com Android Studio.

Principalmente, esse post teve como objetivo explicitar a importância da escolha de boas ferramentas para produção de soluções para a plataforma Android e de que forma essa escolha afeta a motivação e produtividade de um time de desenvolvimento. As ferramentas abordadas foram escolhidas com base em pesquisa e em minha experiência acumulada como sendo as mais “confortáveis” e produtivas para desenvolvimento de aplicações Android. Porém, outro ferramental pode ser o melhor para outro desenvolvedor ou time de desenvolvimento. O importante é que as ferramentas não sejam um impedimento para a boa qualidade do software produzido para a plataforma Android.

Escrito por Roger Silva

Introdução ao Knockout.js

O Knockout.js é uma biblioteca JavaScript open source desenvolvida e mantida por Steve Sanderson, colaborador da Microsoft, cujo principal objetivo é oferecer suporte para criação de interfaces dinâmicas baseadas no padrão MVVM. A biblioteca auxilia na implementação de interfaces que precisam ser modificadas dinamicamente, como por exemplo, com atualizações dependentes da ação do usuário.

De acordo com a página oficial, os principais conceitos que compõe o Knockout são:

  • Bindings declarativos: sintaxe concisa para associar os elementos DOM ao modelo de dados;
  • Atualização automática da interface: a interface é atualizada automaticamente cada vez que o modelo de dados é modificado;
  • Rastreamento de dependências: criação de relacionamentos entre os dados do modelo de maneira implícita;
  • Templates: replicação de estruturas HTML através de templates.


Model-View-View Model

O MVVM, do inglês Model-View-View Model, é um padrão para desenvolvimento de interface que divide a implementação em três partes: view, model, view-model.

  • Model: camada que representa os dados da aplicação e as operações sobre esses dados;
  • View: camada responsável por apresentar os dados para o usuário;
  • View-model: camada que implementa a comunicação entre a model e a view.

Utilizando Knockout, a view é a página HTML com bindings que se conectam na view-model, enquanto a view-model é implementada em JavaScript. As operações de leitura e escrita na model são geralmente feitas através de chamadas Ajax ao servidor.

Benefícios

Alguns dos benefícios do Knockout são:

  • Biblioteca leve – 54kb minificada;
  • Sem dependências;
  • Suporta os principais browsers – IE, Chrome, Firefox, Opera, Safari;
  • Atualização automática da view quando a model é modificada e vice-versa;
  • JavaScript puro, funcionando com qualquer framework web.

Na prática

Vamos mostrar um pequeno exemplo utilizando Knockout. Primeiro, precisamos adicionar o JavaScript da biblioteca, conforme segue.

<script src="scripts/knockout-3.2.0.js"/>

Em seguida, criamos a view, que é o HTML da página com os bindings necessários. O usuário entra seu nome, que é atualizado no modelo com o valor da textbox. Dependendo se a checkbox é marcada ou não, o valor de checked no modelo é atualizado e utilizado para decidir se o próximo parágrafo é exibido ou não.

<p>Digite seu nome: <input type="text" data-bind="value: name"></p>

<p><input type="checkbox" data-bind="checked: checked">
    Marque para mostrar a mensagem.
</p>

<p data-bind="visible: checked">
    Hello, <span data-bind="text: name()"/>
</p>

Por fim, criamos a view-model, onde inserimos dois observables para os campos do modelo.

<script>
    function ViewModel() {
         var self = this;
         self.name = ko.observable("");
         self.checked = ko.observable(false);
    };
</script>

Além disso, deve-se utilizar o comando do Knockout para aplicar os bindings ao carregar a página.

<script>
    ko.applyBindings(new ViewModel());
</script>

O resultado é exibido na imagem abaixo.

Com esse pequeno exemplo, nosso objetivo é introduzir a utilização do Knockout.js para criação de uma página web baseada no padrão MVVM. Já é possível perceber seu principal benefício, que é a atualização da interface de maneira dinâmica. Também podemos perceber outras vantagens, como a simplicidade do código e o fato de que não é necessária nenhuma dependência para que a biblioteca funcione.

Escrito por Paula Burguêz.

Integração Contínua de Projeto .NET com Jenkins

Integração contínua é uma prática das metodologias ágeis onde o trabalho desenvolvido pelos membros de um time são integrados com frequência. Em um único dia, pode haver múltiplas integrações. O objetivo é detectar erros de integração o mais rápido possível. Para implementar essa prática existem muitas ferramentas disponíveis atualmente, e Jenkins, sem dúvida, é uma das mais populares.

Neste post, vamos demonstrar a criação de um sistema de integração contínua de um projeto Web ASP.NET usando Jenkins. Simulamos um cenário em que o código fonte do projeto fica armazenado em um repositório Git.

Instalando o Jenkins

A forma mais fácil de instalar o Jenkins é como um serviço do Windows. Basta baixar o arquivo zip do instalador no site oficial do Jenkins, descompactá-lo e executar o arquivo “setup.exe”. Concluída a instalação, o Jenkins estará disponível no endereço http://localhost:8080 (certifique-se de que a porta 8080 não esteja sendo utilizada por outro processo). A versão utilizada no momento da escrita deste post é a 1.598.

Instalando e Configurando Plugins

Precisamos instalar e configurar alguns plugins antes de criarmos o nosso job de integração. Na página inicial do Jenkins, no menu à esquerda, clique em “Gerenciar Jenkins” (configure o seu browser para que o idioma preferido seja o português brasileiro) e, em seguida, clique em “Gerenciar plugins”.

Vamos instalar três plugins: Git Plugin, MSBuild Plugin e MSTest Plugin. O primeiro permite usar o Git como sistema de controle de versão. O segundo facilita o uso do MSBuild como sistema de build (o mesmo que é utilizado pelo Visual Studio) no Jenkins, e o último converte o formato TRX dos relatórios de teste no formato JUnit XML, tornando possível a análise dos resultados pelo Jenkins.

No Gerenciador de plugins, clique na aba “Disponíveis”. Digite “Git Plugin” no campo “Filtrar” acima e à direita para facilitar a busca pelo Git Plugin. Marque-o.

Gerenciador de pluginsEm seguida, repita o processo para os outros plugins. Marcados os três plugins, clique no botão “Baixar agora, instalar e depois reiniciar”.

Instalação dos pluginsMarque a caixa “Reinicie o Jenkins quando a instalação estiver completa…” para reiniciar o Jenkins após o download. Nota: o plugin Git Client Plugin é instalado automaticamente pelo Jenkins pois é uma dependência do Git Plugin.

Os plugins Git Plugin e MSBuild Plugin necessitam de configuração. Clique novamente em “Gerenciar Jenkins” e, em seguida, em “Configurar o sistema”. Na seção “Git”, preencha o campo “Path to Git executable” com o caminho do executável do Git. É possível também adicioná-lo no PATH do sistema e digitar apenas “git” nesse campo.

Configuração do Git PluginNa seção “MSBuild”, clique em “Adicionar MSBuild”. Preencha o campo “Name” com um nome para identificar a instalação do MSBuild. Uma sugestão é preenchê-lo com a versão (por exemplo, “v12.0″). Em “Path to MSBuild”, informe o caminho absoluto do executável do MSBuild. A partir do Visual Studio 2013, é recomendado que se use o executável localizado em “C:\Program Files (x86)\MSBuild\12.0\Bin\MSBuild.exe” (instalação padrão).

Configuração do MSBuild PluginClique no botão “Salvar” para finalizar a configuração. Agora estamos prontos para a criação do job de integração.

Criando o Job de Integração

O job é composto de vários passos: baixar o código fonte do repositório, fazer o build do projeto e executar os testes. Para ilustrar melhor o processo de integração contínua, criamos um projeto ASP.NET Web Application em C# com o template MVC, incluindo a criação do projeto de testes unitários, no Visual Studio 2013 e o armazenamos em um repositório Git online.

No painel principal do Jenkins, clique em “Novo job”. Escolha um nome para o seu job (“WebApp-Testes”, por exemplo) e escolha a opção “Construir um projeto de software free-style”. Clique no botão “OK”.

Criação do jobNa seção “Gerenciamento de código fonte”, selecione “Git”. Em “Repository URL”, informe a URL do seu repositório, a mesma URL usada no comando `git clone`.

Configuração do repositório GitUsando-se um repositório privado no Bitbucket, por exemplo, é preciso adicionar também as informações de usuário e senha. Em “Credentials”, clique no botão “Add” e informe seu usuário e senha do Bitbucket. Inclua uma descrição no campo “Description” se desejar.

Inclusão de usuário e senhaAs credenciais (globais) recém criadas podem ser gerenciadas no menu “Credentials” a partir do painel principal do Jenkins.

Arquivo MSBuild

Para a execução do build, criamos um arquivo MSBuild manualmente. Neste único arquivo, compilamos o código e os testes, e executamos os testes compilados. Segue abaixo o conteúdo do arquivo:

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Test">
  <ItemGroup>
    <SolutionFile Include="WebApp.sln" />
    <TestResultsDir Include="TestResults" />
  </ItemGroup>

  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Release</Configuration>
    <BuildPlatform Condition=" '$(BuildPlatform)' == '' ">Any CPU</BuildPlatform>
    <TestRunnerExePath>C:Program Files (x86)Microsoft Visual Studio 12.0Common7IDECommonExtensionsMicrosoftTestWindowvstest.console.exe</TestRunnerExePath>
  </PropertyGroup>

  <Target Name="Clean">
    <RemoveDir Directories="@(TestResultsDir)" />
  </Target>

  <Target Name="Compile" DependsOnTargets="Clean">
    <MSBuild Projects="@(SolutionFile)"
             Targets="Rebuild"
             Properties="Configuration=$(Configuration);Platform=$(BuildPlatform)" />
  </Target>

  <Target Name="Test" DependsOnTargets="Compile">
    <ItemGroup>
      <TestAssemblies Include="**bin$(Configuration)*.Tests.dll" />
    </ItemGroup>

    <PropertyGroup>
      <TestRunnerCommand>"$(TestRunnerExePath)" @(TestAssemblies->'"%(FullPath)"', ' ') /Logger:trx"</TestRunnerCommand>
    </PropertyGroup>

    <Exec Command="$(TestRunnerCommand)" />
  </Target>
</Project>

Salvamos esse arquivo no mesmo diretório em que está o arquivo da solution (“WebApp.sln” no exemplo), que no nosso caso se encontra na raiz do repositório Git. O código possui alguns comentários que ajudam a entendê-lo e onde é possível alterá-lo de acordo com o seu projeto. Para mais detalhes sobre a sintaxe do arquivo MSBuild, veja a documentação do MSBuild.

Criado o arquivo MSBuild, vamos configurar o Jenkins para executá-lo. Ainda na página de configuração do job, na seção “Build”, clique em “Adicionar passo no build” e na opção “Build a Visual Studio project or solution using MSBuild”. Em “MSBuild Version”, selecione a instalação do MSBuild que foi criada na configuração do MSBuild Plugin (“v12.0″, por exemplo). No campo “MSBuild File”, informe o caminho do arquivo MSBuild criado. Esse caminho é relativo à raiz do repositório Git.

Configuração do buildPor fim, em “Ações de pós-build”, clique em “Adicionar ação de pós-build” e selecione a opção “Publicar relatório de testes do MSTest”. Preencha o campo “Arquivo TRX com resultado dos testes” com o padrão “TestResults/**/*.trx” (sem aspas). Quando usamos o VSTest.Console para executar os testes, não é possível especificar o caminho e o nome do arquivo TRX resultante. A ajuda do MSTest Plugin recomenda, nesse caso, que esse padrão seja usado para selecionar o arquivo de resultado de teste. O caminho para o arquivo é relativo à raiz do workspace do Jenkins e, consequentemente, à raiz do repositório Git.

Configuração do MSTestClique no botão “Salvar” para finalizar a criação do job.

Executando o Build

Para verificar que está tudo funcionando, clique no menu “Construir agora” na página do projeto recém criado. É possível ver os detalhes de cada build no “Histórico de builds” localizado abaixo do menu da página do projeto.

Detalhes do buildCaso o build tenha falhado, a melhor maneira de verificar a causa da falha é no menu “Saída do console”. As saídas da execução do Git, do MSBuild e da execução dos testes são todas exibidas nesse console.

Em “Resultado de testes” podemos ver os detalhes da execução de cada teste, quantos passaram, quantos falharam e suas respectivas durações.

Resultados dos testesApós alguns builds, um gráfico com a tendência de resultados de teste aparece na página do projeto, dando uma visão geral da evolução dos testes.

Disparando o Build Automaticamente

Para que não seja necessário acessar disparar o build manualmente toda vez que um membro do time fizer um push no repositório, precisamos adicionar mais uma configuração no nosso job. Há várias formas de dispararmos o build automaticamente. Uma delas é configurar o Jenkins para verificar periodicamente se há alguma mudança no nosso repositório. Na página do projeto, clique em no menu “Configurar”. Na seção “Trigger de builds”, marque “Consultar periodicamente o SCM”. Consulte a ajuda próxima do campo “Agenda” para compreender como preenchê-lo. Ele usa a sintaxe do cron com algumas diferenças. Se quisermos que o Jenkins consulte o repositório a cada uma hora, por exemplo, devemos preencher esse campo com “H * * * *” (sem as aspas).

Agendamento do buildClique no botão “Salvar”. Agora, a cada 5 minutos o Jenkins verifica se o nosso repositório Git possui alguma mudança. Se possuir, ele dispara o build das novas modificações.

Uma forma mais eficaz é fazer com que a cada push no repositório o Jenkins seja notificado. A wiki do Git Plugin explica com mais detalhes como realizar essa configuração.

Finalizamos, assim, a configuração do nosso sistema de integração contínua com o Jenkins. O que mostramos aqui foi apenas uma das várias formas de montar esse sistema para o cenário específico de um projeto ASP.NET. Se você não usa Git para o controle de versão, não tem problema. É muito provável que exista um plugin para integrar o seu sistema com o Jenkins (existem plugins equivalentes para Mercurial e TFS, por exemplo). Além disso, é sempre possível criar um passo de build para executar comandos do Windows, caso não exista um plugin para facilitar o trabalho.

Em um post futuro, vamos mostrar como estender nosso sistema de integração contínua para fazer deploy automaticamente em um servidor Web.

Escrito por Cassiano Kuplich

Conhecendo e aplicando gestão visual em projetos ágeis

Gestão visual é uma técnica de gerenciamento em que a informação é passada de forma visual, ao invés de textual. O principal objetivo é promover um entendimento rápido da informação, contribuindo para a eficiência e redução de falhas na comunicação. A ideia é compartilhar informações facilmente, com qualquer pessoa que entre no ambiente do trabalho, desde o presidente até os membros da equipe.

Uma das principais vantagens da gestão visual é

o feedback imediato sobre o andamento do projeto, incluindo a identificação de impedimentos. Se algo está atrasando o trabalho, é possível perceber de maneira mais rápida e agir logo para eliminar o problema. Outra vantagem é a transparência das informações. Quando as pessoas não tem acesso a informação, elas começam a interpretar as situações de diversas maneiras, podendo gerar mal-entendidos.

Existem diversas maneiras de passar informações visualmente, como placas, murais, gráficos, luzes, entre outros. Entre os diferentes tipos de gestão visual, está aquele que apenas retrata dados, como quadro de indicadores da empresa. Outro tipo é aquele que é usado para informar padrões ou regras, como as placas de trânsito e sinaleiras. Também pode-se utilizar gestão visual para representar a estrutura organizacional, analisar problemas, acompanhar o fluxo das tarefas, entre outros.

    

Vantagens:

De maneira resumida, os principais benefícios da gestão visual são:

  • Contribui para o planejamento, controle e melhoria contínua dos processos;

  • Transmite informações complexas de maneira simples, como quais itens devem ser priorizados;

  • Aumenta a eficiência na resolução de impedimentos, já que é possível identificar gargalos assim que eles aparecem;

  • Reduz a necessidade de repetir a informação, já que ela está exposta para todos;

  • Promove colaboração entre a equipe, já que todos podem ver no que os demais estão trabalhando;

  • Reduz as falhas de comunicação e ambiguidades, transmitindo informações mais precisas.

Gestão visual e os métodos ágeis:

Os métodos ágeis enfatizam a comunicação em tempo real, preferencialmente cara a cara, ao invés de documentos escritos. Nesse sentido, a gestão visual facilita a comunicação, o compartilhamento de informações, a remoção de impedimentos e a tomada de decisões.

O formato mais adotado de gestão visual em projetos de software é o Kanban, termo de origem japonesa que significa “cartão” ou “sinalização”. Tem seu conceito relacionado com a utilização de cartões (post-it), com o objetivo de indicar o andamento dos fluxos das tarefas. Um Kanban permite o controle detalhado de tarefas com diversas informações sobre a mesma.

Além da gestão visual dentro de cada projeto utilizando metodologias ágeis, quadros, post-its e qualquer outro formato de trabalho visual podem ser integrados com muita facilidade em outras atividades, como eventos internos. Utilização de quadros em eventos vem sendo uma prática adotada em empresas com frequência. Com este formato, podemos facilitar a integração entre participantes, gerar pauta de assuntos e um feedback rápido diversos aspectos do evento.

Gestão visual auxilia no micro gerenciamento:

A gestão visual pode facilitar o micro gerenciamento, de acordo com o que Mike Cohn escreveu no seu blog durante o ano de 2009. A reunião diária, por exemplo, auxilia nessa micro-gestão do trabalho da equipe, que serve para verificar dia a dia o que todos estão fazendo, e quais os impedimentos que estão atrasando o andamento das tarefas. A integração contínua é aplicada de tal forma que no momento que algum desenvolvedor quebra alguma compilação, todos ficam sabendo. Sendo assim, a própria equipe executa o micro gerenciamento.

Se a equipe executa sua própria micro-gestão, a utilização do Kanban, onde todas as atividades estão visíveis para todos na parede, facilita para que todos os integrantes possam saber o que está acontecendo no seu projeto e qual o objetivo da equipe.

Enfim, gestão visual não é uma técnica nova, sendo utilizada há muito tempo em inúmeras situações, como foi possível ver. O compartilhamento de informações com várias pessoas ao mesmo tempo, a redução de falhas na comunicação e a melhoria na resolução de impedimentos são alguns dos seus benefícios. Na empresa, com a adoção dos métodos ágeis, algumas equipes passaram a utilizar o Kanban físico, que é constantemente personalizado de acordo com as necessidades dos projetos e dos membros do grupo. A ideia foi bem recebida pelas equipes e tem contribuído bastante para a colaboração entre os seus integrantes, deixando os benefícios da gestão visual cada vez mais evidentes.

Escrito por Marcel Guinther e Paula Burguez