O que é e para que serve uma pipeline no processo de implantação de Cultura DevOps?

Avançar para o conteúdo principal

Não há mais suporte para esse navegador.

Atualize o Microsoft Edge para aproveitar os recursos, o suporte técnico e as atualizações de segurança mais recentes.

• Artigo
• 08/10/2016
• 16 minutos para o fim da leitura

Neste artigo

Agosto de 2016

Volume 31, Número 8

DevOps - Aplicação do DevOps a um projeto de desenvolvimento de software

Por Willy-Peter Schaub, Wouter de de | Agosto de 2016

“O DevOps é a união entre pessoas, processo e produtos para permitir a entrega contínua de valor aos nossos usuários finais”.—Donovan Brown no livro “DevOps on the Microsoft Stack” (Wouter de Kort, 2016).

Cada jornada do DevOps começa com uma ideia que você deseja transformar em solução com base em uma cultura de aprendizagem e entrega contínua de valor. A meta deste artigo é compartilhar o aprendizado que reunimos durante a exploração da implementação de um pipeline de versão automatizada para nosso desenvolvimento, teste de aceitação do usuário e ambientes de produção. Iremos conduzi-lo por um pipeline de versão automatizada, que você pode adotar “como está” ou desenvolver para atender aos seus requisitos.

Então, por que decidimos adotar o DevOps? Conforme nos familiarizávamos intimamente com o “por quê” (meta), o “o quê” (funcionalidades) e o “como” (tecnologia, código) das extensões de construção, precisávamos de uma cultura e um ambiente que nos permitissem compilar, testar, lançar e monitorar a família crescente e de rápida evolução de extensões. A promessa do DevOps nos encorajou a explorar e adotar os processos e ferramentas oferecidos pelo Visual Studio Team Services (Team Services, de forma abreviada). Nossas equipes auto-organizadas e autônomas foram incentivadas a desenvolver uma cultura e um pipeline que reduzissem os tempos de ciclo de liberação de dias caóticos, propensos a erros e manualmente intensivos, para minutos. Uma história e explicação similares do pipeline foram contadas em outro artigo desta edição (“Do código ao cliente: explorando o Mobile DevOps”).

Se não estiver familiarizado com os Rangers, somos uma comunidade de engenheiros internos e externos que trabalham com o grupo de produto para oferecer diretrizes profissionais, experiência prática e soluções de preenchimento de lacunas à comunidade de desenvolvedores. É a última parte—as lacunas—que nos faz sentir estimulados e comprometidos com as extensões.

As extensões fornecem a você uma experiência de integração e extensibilidade para o Team Services e o Team Foundation Server (TFS). Os pontos de extensão incluem o formulário de item de trabalho, tarefas de compilação e versão, widgets de painel, ações de menu, Agile e outros hubs. Eles permitem que você forneça soluções de preenchimento de lacunas, combinação e aprimoramento do produto, experiência de usuário e produtividade.

Uma extensão típica consiste de um conjunto de arquivos JavaScript, HTML e CSS, conforme mostrado em 2015 no blog de Willy P. Schaub, “Extensions 101—Attempting to Visualize the Main Processing Flow” (bit.ly/28Yfj7A). Um ou mais arquivos manifestos JSON descrevem informações básicas, arquivos inclusos e contribuições fornecidas pela extensão. Consulte o exemplo de extensão de Gerenciamento de Pastas de software livre, que permite que você crie uma pasta rapidamente em seus repositórios de origem do Team Services a partir da Web sem clonar o repositório localmente ou instalar ferramentas extras.

Cada extensão é descrita em um manifesto baseado em JSON, denominado vss-extension.json, por padrão. Para manter a consistência, fizemos a escolha de basear todas as extensões futuras em um Modelo de Projeto do Team Services e TypeScript para todo o nosso código JavaScript. O Node Package Manager (NPM) é utilizado para baixar dependências externas, tais como a biblioteca Digitações, exigida pelo TypeScript IntelliSense. Aproveitamos a capacidade do NPM de definir um conjunto básico de scripts para iniciar o ambiente de desenvolvimento. Uma dose de consistência garante que os membros da equipe possam se mover facilmente por entre as equipes e que os problemas possam ser investigados e resolvidos muito mais facilmente. Isso permite tempos de ciclo mais curtos!

Publicar uma extensão manualmente

Se você clonar o repositório Gerenciamento de Pastas em sua máquina de desenvolvimento local, poderá empacotar e publicar rapidamente a extensão em sua conta do marketplace manualmente. Veja como:

• Use o Gerenciador do Executor de Scripts NPM (bit.ly/28Qmktu) ou execute os comandos da linha de comando.
• Abra a solução e execute a tarefa de instalação: executar instalação de npm. Isso irá baixar os pacotes NPM, iniciar as Digitações necessárias para o TypeScript e colocar suas dependências externas no local correto.
• Use o Visual Studio para compilar os arquivos TypeScript e gerar a saída do JavaScript.
• Execute o pacote tarefa NPM para criar um arquivo VSIX de saída baseado no manifesto no projeto.
• Carregue o VSIX gerado no Marketplace ou execute npm e execute publicar para empacotar e publicar automaticamente a sua extensão.

Em primeiro lugar, algumas informações básicas. O Team Services é composto de contas isoladas. O Marketplace é global e composto de publicadores e é criado e gerenciado pelo publicador da galeria (você). Uma extensão é publicada como privada e compartilhada explicitamente com as contas do Team Services. Como alternativa, uma extensão pode ser publicada como pública assim que estiver validada, o que a tornará visível para todos. Recomendamos fortemente que você jamais publique essa ou outras extensões de exemplo como pública a fim de evitar uma experiência de usuário confusa e potencialmente ruim.

Para publicar a sua extensão, verifique se o campo publicador no manifesto corresponde ao nome do seu publicador do Marketplace. Se o seu publicador não for verificado pela Microsoft, você só poderá publicar uma extensão como privada. Para publicar sua extensão da linha de comando ou do Executor de Tarefas do NPM, você também precisará de um token de acesso pessoal que conceda permissão para gerenciar seu publicador do Marketplace. Confira o artigo “Publish an Extension to the Marketplace” (bit.ly/28SDsOM) para obter mais informações.

Um pipeline automatizado de compilação e versão

Conforme a família de extensões e revisões cresce, essas etapas manuais aparentemente simples rapidamente se tornarão mais trabalhosas e propensas a erros. Portanto, começamos a trabalhar no pipeline automatizado, utilizando scripts e tarefas de compilação para automatizar as etapas manuais.

Você pode usar o Windows PowerShell e as tarefas de compilação da Linha de Comando para empacotar o manifesto da extensão e revisar o número da versão, conforme mostrado na Figura 1. Isso é descrito com mais detalhes no artigo “Our First Steps of Embracing DevOps When Building Visual Studio Team Services Extensions” (aka.ms/t0wfh6)—simples e eficiente!

Figura 1 - Tarefa de Compilação do Windows PowerShell (topo) e Tarefa de Compilação de Comando (parte inferior)

Como alternativa, você pode usar as Tarefas de Compilação e Versão para Extensões para ajustar seu processo de compilação e versão. O restante deste artigo é baseado nessa extensão.

Vamos explorar como utilizamos as Tarefas de Compilação e Versão para Extensões e implementamos um plano gráfico para todos os outros projetos de extensão. Cada extensão inicia sua jornada em uma conta de Team Services isolada, que é o primeiro estágio de implantação de uma extensão. O Gerenciamento de Versões se refere a esses estágios como ambientes; portanto, estamos chamando-o de ambiente de desenvolvimento (DEV). Depois, ela passa por uma série de validações de design, codificação, recurso, experiência de usuário e desempenho em um ambiente de aceitação de proprietário do produto (BETA) e usuário separados. Semelhante ao ambiente de desenvolvimento, essa é uma conta de Team Services isolada e o segundo estágio da implantação da extensão. Uma vez que a extensão atenda à nossa definição de concluída (bit.ly/28PLYyi), ela é implantada no Marketplace e visível a todos. Você pode reconhecer os estágios DEV → BETA → PROD do pipeline de lançamento tomando forma.

Para preparar o projeto de extensão para o pipeline automatizado, recomendamos as seguintes alterações ao manifesto de extensão, conforme mostrado na Figura 2:

• Configure a sua versão para 0.0.0 e o seu publicador para uma string vazia (“”)
• Marque a extensão como privada (public: false)
• Remova o atributo galleryFlags

Figura 2 - Extrair arquivo de manifesto

{  "manifestVersion": 1,
  "id": "FolderManagement",
  "version": "0.0.0",
  "publisher": "",
  "name": "Folder Management",
  "description": "Quickly create a folder in your Visual Studio Team
    Services source repositories from the web. No need to clone the
    repository locally or install extra tools.",
  "public": false,
  "icons": {
    "default": "images/VSO-Folder-196x.png"
  },
  "categories": [
    "Code"
  ],
  snipped rest of manifest file ...
}

Esses valores serão atualizados durante a implantação da versão e os padrões garantirão que a extensão não seja implantada ou tornada pública acidentalmente.

 A adoção de uma convenção de nomenclatura consistente simplificará a rastreabilidade por entre os seus vários ambientes. Se, por exemplo, você sufixar a ID com o seu ambiente durante a versão, FolderManagementBeta será a extensão de Gerenciamento de Pastas em execução no ambiente BETA.

A Integração Contínua (CI) é uma prática que permite que você tenha uma compilação pronta para produção do código mais recente em um repositório de controle de origem (bit.ly/28OtZ8K). Isso é feito por compilação automatizada e são executados testes em cada confirmação.

Nossos projetos de extensão são tipicamente armazenados em um repositório de Git hospedado no Team Services ou no GitHub para projetos de software livre, tais como a extensão Gerenciamento de Pastas. O pipeline começa com uma definição de compilação acionada com cada confirmação feita ao repositório, depois compila o pacote de extensão VSIX e aciona a definição de versão para implementá-la nos ambientes DEV, BETA e PROD.

Conforme mostrado na Figura 3, verifique se habilitou a integração contínua e, opcionalmente, mudanças de lote para reduzir o número de compilações em execução.

O leitor astuto deve ter percebido que a nossa Compilação CI produz apenas um pacote VSIX e não copia os arquivos de origem da extensão. O motivo de fazermos isso é um dos princípios fundamentais de um pipeline de entrega: compilar uma vez e apenas uma vez. Ao invés de compilar e empacotar os arquivos de extensão a cada etapa de implantação, nós empacotamos apenas uma vez, no início do pipeline, com diferentes configurações por ambiente. Fazemos isso para ter absoluta certeza de que implantamos exatamente a mesma extensão em cada ambiente diferente. 

O controle de versão da sua extensão e das tarefas de compilação é importante. No Team Services, a versão mais recente ganha. Se você instalar uma versão pública e beta da mesma extensão em uma conta do Team Services, deve estar claro qual versão será ativada.

Quais opções há para o controle de versão? As ferramentas de desenvolvedor do Team Services permitem que você use qualquer número de versão de três dígitos como sua extensão. Em primeiro lugar, pela simplicidade e rastreabilidade clara, decidimos usar o Build.BuildNumber como nosso número de versão, conforme mostrado na Figura 4.

Como alternativa, você pode usar a tarefa Versão de Extensão de Consulta, que oferece maior controle sobre os números de versão publicados ao obter a versão atual do marketplace e incrementar uma parte específica toda vez que a extensão for publicada. Ao reduzir a rastreabilidade entre a versão do marketplace e os artefatos no Team Services, ela fornece uma melhor numeração sequencial para os seus clientes no Marketplace.

E quanto ao autoteste? A Compilação CI também é um bom lugar para executar itens como testes de unidade. A extensão Gerenciamento de Pasta não usa nenhum teste de unidade porque todos os locais lógicos solicitam os APIs REST do Team Services. Outras extensões, como o Widget de Contagem Regressiva (bit.ly/28PTCag), incluem testes de unidade que validam a lógica para o cálculo da diferença de tempo. Esses testes de unidade são executados como parte da compilação. Outros testes automatizados que desejamos adicionar no futuro são os Testes da Web Selenium. Eles permitem que não apenas executemos testes de unidade, mas também testes de IU automatizados.

A Figura 5 mostra as etapas de compilação. As dependências do NPM são instaladas com a instalação npm (1) e o script de configuração processado com as tarefas de execução do npm. Como alternativa, você pode usar o NuGet e a atividade de restauração do NuGet. A tarefa de compilação do Visual Studio (2), então, compila a solução, seguida pela tarefa de Extensão do Pacote (3), que produz o pacote de extensão VSIX.

Opcionalmente, você pode configurar as IDs e tags do publicador e da extensão e nomeá-las para substituir os valores manifestos. O pipeline configura apenas o número da versão (4) como parte da compilação, configurando-a para o número da compilação para garantir que cada instância do pipeline possa ser identificada e rastreada exclusivamente.

Para que serve a tarefa de script do PowerShell? No momento da escrita deste artigo, o script a seguir foi necessário para extrair a informação da versão (versões futuras das ferramentas do desenvolvedor da extensão—tarefas de compilação [bit.ly/28R0oMh] tornarão o script obsoleto):

$bldVerD =("$env:BUILD_BUILDNUMBER").replace("$env:BUILD_DEFINITIONNAME","").Trim();
Write-Verbose "Extracted buildVersion $bldVer";
Write-Host "##vso[task.setvariable variable=ExtensionVersion;]$bldVer"

A Entrega Contínua é a habilidade de usar o resultado do CI para compilar e implantar a nova boa compilação conhecida a um ou mais ambientes automaticamente. (bit.ly/28PWsfk). Há uma diferença sutil entre a Entrega Contínua e a Implantação Contínua. A última é para um ambiente único. Uma equipe pequena pode implementar apenas a Implantação Contínua porque cada alteração vai direto à produção. A Entrega Contínua movimenta o código por diversos ambientes e termina, por fim, na produção, que pode incluir uma IU automatizada, testes de carga e desempenho e aprovações ao longo do caminho.

A implantação no ambiente DEV é totalmente automatizada e ocorre frequentemente. Isso significa que cada compilação de CI bem-sucedida é implantada no DEV sem etapas manuais. Conforme mostrado na Figura 6, após o sucesso do DEV, é solicitada uma pré-aprovação antes de implantá-lo no ambiente BETA. Esse estágio é aprovado pelo líder do projeto ou pelo gerente do programa. Por fim, há uma etapa de pré-aprovação para o lançamento público para produção. Isso precisa ser aprovado tanto pelo líder do projeto quanto pelo gerente do programa. Para simplificar, escolhemos usar apenas etapas pré-aprovadas e automatizar a etapa pós-aprovação porque não há motivo para aprovarmos uma etapa pós-implantação e, depois, não implantá-la no próximo ambiente.

A Figura 7 mostra a definição da versão, que implanta o pacote de extensão VSIX em três ambientes. O primeiro ambiente, DEV (1), pertence e é gerenciado pela equipe que compila a extensão. A extensão é implantada como privada e é compartilhada com uma conta de área restrita de desenvolvimento.

Quando a versão for testada e aprovada, a implantação continuará no segundo ambiente, o BETA (2). A extensão ainda é implantada como privada e é compartilhada com uma conta de área restrita de aceitação do usuário.

Quando o teste de aceitação do usuário estiver concluído e aprovado, a implantação continuará alterando o publicador, configurando a visibilidade como pública e implantando a extensão no marketplace.(3).

A tarefa Publicar Extensão (4) é o ponto central do processo de implantação e o ingrediente secreto do pipeline. Essa tarefa atualiza o arquivo VSIX ao descompactar o conteúdo, atualizar os valores de configuração e compactar todos os arquivos. Depois, a tarefa o implanta na conta do publicador do Marketplace configurada, como o publicador alm-rangers configurado para o ambiente Beta, conforme mostrado.

A tag de ID da extensão (5) e o nome são substituídos para garantir que tenhamos uma instância exclusiva da extensão em execução em cada ambiente, que as extensões Dev e Beta sejam compartilhadas automaticamente com as contas do Team Services de aceitação de desenvolvimento e usuário e que os lançamentos de DEV e BETA sejam privados.

É necessário um Token de Acesso Pessoal (6) para publicar uma extensão utilizando a tarefa Publicar Extensão ou a Linha de Comando. Para armazenar com segurança o token, você pode criar uma conexão de serviço do Team Services com o Marketplace. A conexão define um par chave/valor em que a chave é o nome da sua conexão e o valor é o token de acesso.

Algumas das outras tarefas que você deve explorar incluem:

• Versão de extensão da consulta: Verifica o número da versão de uma extensão publicada do Marketplace. A versão pode ser armazenada em uma variável e utilizada pelo pipeline para criar uma nova versão, como incrementar o número de versão principal, secundário ou de patch.
• Instalar extensão: Implanta uma extensão no Marketplace sem instalá-lo em uma conta.
• Compartilhar extensões: Compartilha uma extensão privada com as contas especificadas.

Nesse ponto, o pipeline compila, empacota e atualiza a extensão consistentemente e, o mais importante, protege os ambientes de falhas comuns. São exemplos de falhas de compilação quando há erros no código TypeScript ou se houver arquivos ausentes. A implantação falha quando o VSIX é inválido, se o acesso aos ambientes for restrito ou se um dos aprovadores rejeitar a liberação.

Conclusão

Agora que você tem um pipeline de compilação e versão automatizado, pode acelerar seu processo de desenvolvimento, reduzir erros criados por intervenção humana e, o mais importante, desenvolver suas soluções e também melhorar continuamente por meio da reflexão, medidas e aprendizagem contínuas.

No entanto, esse é um assunto para outro dia.

O pipeline CI e CD automatizado reduziu nosso processo de compilação e versão de extensões manual e propenso a erros de dias para minutos. É uma experiência revigorante e permite que nossa equipe de desenvolvimento concentre seu tempo e esforços no que é realmente importante.

As práticas de DevOps ilustradas aqui também podem ser aplicadas aos seus próprios projetos. O Team Services habilita o DevOps para qualquer linguagem direcionada a qualquer plataforma, incluindo local, nuvem, nuvem híbrida e móvel. Com recursos que permitem que você planeje, controle a versão, compile, implante e monitore o seu aplicativo, o Team Services tem tudo o que você precisa para transformar uma ideia em um software de trabalho. De posse dessa informação, estamos animados para ver as extensões que a comunidade cria para aprimorar os recursos do Team Services enquanto você embarca na sua jornada do DevOps.

Recursos do DevOps

• Tarefas de compilação e versão para extensões aka.ms/tasksforext
• Extensão de gerenciamento de pasta também disponível como código de exemplo no GitHub aka.ms/foldermanagement
• Biblioteca de ferramentas e soluções de orientação aka.ms/vsarsolutions
• Visão geral das extensões para o Visual Studio Team Services bit.ly/293YEOm
• O Visual Studio Marketplace é um local para encontrar extensões, ferramentas, produtos e serviços para o Visual Studio, o Visual Studio Team Services, o Visual Studio Code e o Team Foundation Server marketplace.visualstudio.com
• O modelo de projeto do Visual Studio Team Services contém tudo o que você precisa para criar uma extensão do Visual Studio Team Services ou uma tarefa de compilação/versão personalizada.aka.ms/extensiontemplate
• O que é o DevOps?aka.ms/whatisdevops

Willy-Peter Schaub é gerente de programas sênior da equipe Visual Studio ALM Rangers do Microsoft Canada Excellence Centre. Ele mantém um blog em blogs.msdn.com/b/willy-peter_schaub e você também pode acompanhá-lo no Twitter: twitter.com/wpschaub.

Wouter de Kort é o principal consultor da Microsoft na Ordina, Holanda, onde ajuda as empresas a se inteirar do que há de mais recente no desenvolvimento de software. Ele mantém um blog em wouterdekort.com. Você pode segui-lo no Twitter: @wouterdekort.

Mattias Sköld  é treinador de DevOps/ALM na Sogeti Suécia e ajuda os clientes a melhorar suas práticas de software e conduzir a adoção das práticas de ALM/DevOps internamente na Sogeti. Ele mantém um blog em mskold.blogspot.com e você pode segui-lo no Twitter: @mattiasskold.

Agradecemos aos seguintes especialistas técnicos da Microsoft pela revisão deste artigo: Donovan Brown, Jess Houwing e Will Smythe

Recursos adicionais

Recursos adicionais

Neste artigo

O que são pipelines em DevOps?

O que é e para que serve uma pipeline?

O que é um pipeline de implantação?

Para que serve pipeline GIT?