DEV Community: Higor Barbosa

Flyway & Azure DevOps : IaC com ARM Template

Higor Barbosa — Tue, 30 Jun 2020 15:16:21 +0000

E chegamos ao penúltimo artigo dessa serie.

Vamos agora adicionar a criação do nosso banco Azure SQL Database também no Azure DevOps.

E para isso, lembram que um pouco antes de criar o serviço de SQL Database no Azure, tínhamos a opção de baixar o template ARM? Pois bem, utilizaremos ele agora.

Tópicos

IaC e ARM Template
Adicionado ARM Template ao Repos GIT
Adicionando ARM Template no nosso Release Pipeline

IaC e ARM Template

O nosso banco ja esta no nosso pipeline, mas a nossa infraestrutura (o nosso servidor de banco de dados SQL Database) não.

E para isso, precisamos também adicionar a criação do nosso banco de dados ao nosso repositório, versionando e atualizando através de scripts.

E essa tarefa, podemos chamar de IaC, ou simplesmente, Infraestrutura como código.

Temos varias opções no mercado, como Terraform. Mas usarei um recurso do Azure, chamado ARM, Azure Resource Manager.

Adicionado ARM Template ao Repos GIT

Primeiro, vamos descompactar o arquivo que baixamos antes de criação do nosso banco SQL Database no Portal do Azure.

E encontramos esses 2 arquivos: parameters.json e template.json.

Vamos precisar incluir eles no nosso Azure Repos.

Para isso, vamos criar o arquivo parameters.json e adicionar nele o conteúdo do nosso arquivo da pasta descompactada com o mesmo nome.

No parâmetro administratorLoginPassword, voce precisará adicionar a senha a ser aplicada ao banco de dados.

Não é uma boa ideia adicionar senha do seu banco no seu repositório. No próximo artigo dessa serie, iremos substituir a senha por um segredo do Azure Key Vaults.

E podemos commitar ele.

Vamos fazer upload do nosso arquivo template.json.

Portanto, ficaremos com os 2 arquivos na nossa pasta ARM.

Adicionando ARM Template no nosso Release Pipeline

Vamos ir em Pipelines > Releases e editar o nosso pipeline.

E adicionar um novo Stages em Add > New Stage.

E novamente, vamos inserir o o template vazio em Empty Job.

Podemos editar o seu nome para ARM - Create DB.

E vamos editar o agente desse estagio.

Adicionar um nova tarefa. E procurar por ARM.

E será essa que usaremos: ARM Template Deployment.

Precisamos selecionar e autorizar a nossa inscrição no Azure e a nossa inscrição.

A action será Create or update resource group. Precisamos também selecionar o nosso grupo de recursos e a localização que usaremos.

E por fim, precisamos linkar o nosso template com o arquivo dentro da pasta ARM e o mesmo com o arquivo de parâmetros.

Podemos voltar a aba Pipelines e alterar a execucao do estagio Flyway Info & Migrate.

Vamos alterar o gatilho para After stage e selecionar o estágio de ARM - Create DB.

E ficou assim o nosso release pipeline:

Antes de gerar o pipeline, vamos ir no Portal do Azure e excluir o nosso servidor e banco SQL Database.

E para isso, vamos ir no nosso grupo de recursos do Azure, selecionar o nosso SQL database e Sql server e exclui-los.

Vamos confirmar e excluir.

Pronto! Não temos SQL Database no nosso grupo de recursos.

Agora sim, podemos salvar o nosso pipeline e criar um novo release.

E nosso deploy irá iniciar. Primeiro iremos criar o banco SQL Database no Azure, depois passaremos para o estágio do Flyway onde teremos a instalação, a execução do comando de informação e por fim, a migração rodando todos os scripts disponíveis.

E la está. Executou com sucesso como o esperado. ;)

No próximo artigo, iremos adicionar segredo do Azure Key Vaults no nosso Release Pipeline, e assim, iremos atribuir a senha do banco de dados ao serviço do Azure!

Flyway & Azure DevOps : Criando Release Pipeline

Higor Barbosa — Tue, 30 Jun 2020 14:56:05 +0000

E vamos, enfim, criar o nosso Deploy continuo utilizando o Azure DevOps.

Se você não tem uma conta ainda, pode criar acessando esse link

Tópicos

Repositório GIT
Release Pipeline
Extensão do Flyway no Marketplace
Migração pelo Azure DevOps

Repositório GIT

Vamos criar o nosso projeto usando repositório GIT do serviço Repos do Azure DevOps.

E vamos ir em *Repos > Files *.

Podemos iniciar nosso repositório.

E criar uma nova pasta.

Vamos chamá-la de scripts e vamos criar o arquivo V2__SecoundScript.sql.

E vamos adicionar o script abaixo no arquivo.

INSERT INTO Customers  (name,Priority ) VALUES ('Mr. T', 1);
INSERT INTO Customers  (name,Priority ) VALUES ('Bob', 5);

E podemos commitar na nossa branch master.

E agora, podemos adicionar ao nosso pipeline.

Release Pipeline

Vamos ir em Pipelines > Releases.

E vamos ir em New Pipeline.

Naã vamos selecionar um template. Usaremos o empty job.

Vamos adicionar o nome de Flyway Info no primeiro stage.

E adicionar nosso artefato.

Vamos selecionar a opção Azure Repos GIT, o nosso projeto, repositório, a branch master e adicionar o nosso alias ao artefato.

Podemos agora editar o nosso stage.

Extensão do Flyway no Marketplace

Vamos adicionar uma nova tarefa e procurar por flyway.

E podemos ver a extensão abaixo. Precisamos instalar ela. Vamos ir em Get it free para adicionar ela a nossa organização do Azure DevOps.

E aqui podemos conferir que ainda está em preview. Mas vamos instalar ela. Get it free.

Vamos selecionar a nossa organização e clicar em Install.
Caso você utilize a versão on-premise do Azure DevOps, pode baixar a extensão em download.

Podemos atualizar a nossa lista de tarefas do agent job e vemos 2 tarefas disponíveis: Flyway CLI e Flyway Installer.

Vamos incluir as duas no nosso agente.

Primeiro a tarefa Installer, onde devemos indicar a versão que queremos do nosso Flyway.

E depois, a tarefa CLI, onde vamos selecionar o comando info e vou indicar 3 variáveis a nossa tarefa: JDBC, password e user.

E vamos ir na aba Variables e criar as nossas variáveis.

E estamos prontos para rodar. Vamos alterar o nome do nosso pipeline, salvar e criar o nosso primeiro release.

E vamos aguardar a execução.

E criou o release com sucesso!

Vamos ir em Logs.

E vamos ir no log do flyway info.

o Flyway nos avisou que o primeiro script foi perdido e o segundo esta pendente para execução.

Vamos fechar o log, editar o Release Pipeline e ativar a trigger de Continuous Deployment.

E habilitar a trigger, incluindo a branch master.

Vamos salvar e ir no Repos > Files. Vamos fazer upload do nosso primeiro script na pasta scripts.

E commitar ele.

Vamos ir em Pipelines > Release e veja que o nosso segundo release ja foi iniciado.

Depois de executa-lo, vamos novamente no log e verificar flyway info.

E agora sim. O flyway identificou que o primeiro script rodou e estamos apenas pendente do segundo script.

Vamos editar o nome do nosso estagio.

E também editar o agent job do stage.

Migração pelo Azure DevOps

Podemos clonar a tarefas flyway info e alterar o command para migrate, ficando como a imagem abaixo.

E agora, podemos salvar e gerar mais um release.

E gerou com sucesso. Podemos ir no Log e na tarefa flyway migrate.

E vemos que executou com sucesso o nosso segundo script.

E podemos conferir no Query Editor no nosso Azure SQL Database.

SELECT TOP (1000) * FROM [dbo].[Customers]

E lá está os 2 Customers adicionado no segundo script executado no Flyway diretamente do Release Pipeline do Azure DevOps.

Flyway & Azure DevOps : Rodando Flyway Localmente

Higor Barbosa — Tue, 30 Jun 2020 14:31:41 +0000

Instalamos o Flyway localmente e criamos o nosso banco de dados SQL Database no Azure. Agora, iremos rodar ele.

Tópicos

Connection String
Criando nosso Primeiro Script
Migração

Connection String

E para isso, vamos ir no diretorio do flyway e abrir o arquivo flyway.conf dentro do diretorio conf.

Precisamos retirar o comentário do parâmetro flyway.url e adicionar a nossa conexão. Podemos obter ela no portal do azure, indo no nosso servico do SQL Database e em Settings / Connection String.

E dentro de Connection String, vamos ir na aba JDBC e copiar a conexao disponivel.

Não precisamos colocar todo o conteúdo do JDBC, podemos adicionar ele apenas ate o nome do nosso database, ficando assim:

O flyway.user e flyway.user tambem é opcional.

E podemos novamente rodar o comando flyway info. Ele pedirá nosso usuário e senha e mostrará essa mensagem: No migrations found.

Criando nosso Primeiro Script

E vamos ir ate a pasta sql. E é nela que devemos adicionar os nossos scripts SQL.

Podemos renomear o arquivo existente por V1__CreateTables.sql.

E abrindo o arquivo, iremos incluir esse script.

/* Single line comment */
CREATE TABLE Customers (
CustomerId smallint identity(1,1),
Name nvarchar(255),
Priority tinyint
)
CREATE TABLE Sales (
TransactionId smallint identity(1,1),
CustomerId smallint,
[Net Amount] int,
Completed bit
)
GO

E como podemos ver, ele é bem simples. Irá criar 2 tabelas ....

E vamos rodar novamente o comando flyway info.

E veja, agora temos 1 script, pendente de migração.

Migração

E vamos executar a migração.
Faremos ela, com o comando flyway migrate.

E podemos ver que ele migrou com sucesso.

Vamos agora ao Azure, acessando o Query Editor do nosso banco de dados SQL Database. Atualizando as tables, podemos ver que o script foi executado e criou as 2 tabelas.

Além disso, o Flyway criou a tabela dbo.flyway_schema_history. Ele usa esse tabela para manter o histórico de execucação dos Scripts.

SELECT TOP (1000) * FROM [dbo].[flyway_schema_history]

Executando o comando acima, podemos ver dados quanto ao script executado, como a versão, o nome do script, quem executou e quando.

No próximo artigo dessa serie, iremos rodar o Flyway a partir do nosso pipeline de Deploy Continua usando o Azure DevOps.

Flyway & Azure DevOps : Azure SQL Database

Higor Barbosa — Tue, 30 Jun 2020 14:31:28 +0000

Precisamos configurar nosso banco de dados no Flyway e para isso, iremos utilizar o Azure SQL Database, banco relacional na nuvem da Microsoft como Serviço.

Tópicos

Azure SQL Database
Criando o Banco de dados SQL Database no Portal do Azure
Query Editor

Azure SQL Database

O Azure SQL Database é um banco de dados relacional na nuvem do Azure. Ele é um PaaS - plataforma como serviço, totalmente gerenciado e muito parecido com o SQL Server, também da Microsoft. Ele eh um opção de baixo custo, principalmente comparado ao SQL Server e totalmente escalável.

Criando o Banco de dados SQL Database no Portal do Azure

E para criar o nosso banco SQL, vamos ir no portal do Azure e procurar por SQL Database.

Vamos ir em ADD e criar o nosso servidor de banco de dados.

No nosso exemplo, não precisamos usar o Elastic Pool disponível no Azure SQL Database mas precisamos definir o tamanho do nosso servidor de banco de dados. E para isso, vamos ir em Configure Database.

E precisamos definir o tamanho do nosso servidor. Irei selecionar a menor possível, com 100MB de armazenamento.

E podemos ir em Next:Networking >.

E em Networking, precisamos definir como será a conectividade ao nosso banco de dados na nuvem da Microsoft.

Irei habilitar como Public Endpoint e nas regras do firewall, iremos habilitar o acesso aos serviços e recursos do Azure e também ao meu atual IP. Com isso, o Azure DevOps poderá acessar o nosso banco de dados e também a nossa máquina de desenvolvimento.

E vamos avançar para Next: Additional settings >.

Vamos optar por incluir o banco de dados vazio, selecionando a opcao none e também usar o Collation padrão (SQL_Latin1_General_CP1_CI_AS). Podemos avançar para tags e Review + Create para verificar se esta tudo correto.

Precisamos revisar, mas antes de criar o nosso serviço de banco de dados, vamos ir em Download a template for automation.

E vamos ir em Download, e assim baixar o nosso template ARM. Usaremos ele no nosso penúltimo artigo dessa serie.

Podemos fechar e, enfim, criar o nosso SQL Database clicando no botão Create.

O recurso demora alguns minutos para ser criado, mas logo receberá a confirmação da criação do nosso banco de dados Azure SQL Database.

Query Editor

Vamos entrar no recurso, indo em Go to Resource.

E vamos ir em Query Editor, que ainda está em preview.

NO Query Editor, podemos fazer consultas no nosso banco de dados SQL na nuvem. Mas precisamos primeiro inserir o nosso login e senha ou acessar via Active Directory.

E clicando em Tables, podemos ver que ainda não temos tabelas no nosso banco de dados.

Legal! Nosso banco de dados SQL Database está criado no Azure. No próximo artigo dessa serie, vamos rodar o Flyway localmente apontando para ele.

Flyway & Azure DevOps : Conhecendo o Flyway

Higor Barbosa — Tue, 30 Jun 2020 14:30:36 +0000

Falar sobre DevOps e sua cultura é chover no molhado. Hoje, os times já estão adotando, mesmo que lentamente, a cultura DevOps no seu dia a dia.

Mas e o seu banco de dados? Ele está integrado na sua esteira de entrega continua? O Continuous Delivery envolve o seu banco de dados? Pois, se ainda não está, nesta série quero mostrar para vocês, passo a passo, como podemos adicionar o nosso banco de dados relacional no seu pipeline com a ajuda de 2 poderosas ferramentas: Azure DevOps e Flyway. Vamos lá!?

Tópicos

Requisitos
C.I. / C.D. para seu Banco de Dados
Flyway
Breve Histórico e Versões do Flyway
Como funciona o Flyway
Comandos Flyway
Instalando Flyway Community

Requisitos

Conta no Azure DevOps (podemos utilizar a versão gratuita);
Conta no Azure (usaremos para criar o nosso banco Azure SQL Database);

C.I. / C.D. para seu Banco de Dados

Continuous Delivery, ou simplesmente, Entrega Contínua engloba publicar, de forma automática e usando ferramentas, o nosso código fonte até o destino final. E isso, deve também englobar o nosso banco de dados.

Mas infelizmente, boa parte de projetos não adicionam o banco de dados na sua esteira de deploy. E isso pode gerar transtornos no C.I./C.D. da sua aplicação. No momento em que você não adicionar o script do banco no seu release, e mantem interação humana para atualização do banco, e possibilidade de falha torna-se grande, e grave!

Mas não é surpreendente, pois existem menos ferramentas para oferecer suporte ao DevOps para o banco de dados do que para deploy da sua aplicação.

Mas não significa que essas ferramentas não existam. E nesse artigo, quero falar sobre o Flyway. Com ele, podemos commitar o código do banco de dados para um sistema de controle de versão como GIT, adicionar a Integração Contínua, e claro, realizar a entrega contínua do seus scripts para banco de dados, passando pelos seus ambientes Staging ate chegar em Produção.

Flyway

Flyway DB é uma ferramenta para controle da versão do nosso banco de dados relacional, e apesar de ser bem simples, ela é uma solução robusta e suporta os principais banco de dados baseados em SQL do mercado como Oracle, MySQL, MariaDB, SQL Server, PostgreSQL, DB2, SQLite e muitos outros.

Na nossa demo, iremos usar o Azure SQL Database. Mas o procedimento para a maioria dos outros bancos suportados é o mesmo.

Breve Histórico e Versões do Flyway

O Flyway é uma ferramenta de migração de banco de dados de código aberto e foi adquirido pela empresa Redgate em julho de 2019.
E a partir disso, temos a versão community , PRO e a versão enterprise.

Neste link podemos ver as diferenças entre as versões.

A versão community suporta todas as versões atuais dos bancos de dados relacionais. Mas temos um "porém". Por exemplo, o banco SQL Server 2014 é apenas suportado na versão Enterprise. Fique atento sobre essas restrições na versão Community.

Como funciona o Flyway

SIMPLES, FOCO NA SOLUÇÃO e PODEROSO

Essa é a promessa do Flyway e ela é cumprida com maestria.

Sua utilização é muito simples.

Podemos rodar scrips via Java API, Maven e Gradle.

Além disso, podemos rodar a partir de comandos. E sera assim que iremos executá-lo.

Um único comando e seu script SQL é migrado em segundos.

O primeiro passo é criar um script SQL. E pode usar essa nomenclatura:

V1__MeuPrimeiroScript.sql

V2__MeuSegundoScript.sql

Onde V1__ e V2__ indica a versão crescente de execução do script. Com isso, você controla o que está migrando através do nome dos seus scripts SQL.

Comandos Flyway

flyway info

Usamos esse comando para verificar o status do seus scripts e principalmente, obter informações do que será migrado antes de efetuar a migração.

flyway migrate

Esse é o comando que executa os scripts SQL, por ordem crescendo da versão indicada no nome do arquivo.

flyway clean

Esse comando limpa o nosso banco de dados. Todos os objetos como tabelas, views, procedures e triggers serão droppadas.

Esse comando nunca deve ser executado em produção. Utilize apenas quando você precisar limpar bases de desenvolvimento ou testes.

flyway validate

Esse comando valida se as migrações a serem aplicadas no nosso banco de dados estão de acordo com o que aplicamos no nosso banco local.

flyway undo

Podemos adicionar tags nas nossas migrações. E através delas, podemos reverter scripts incorporados posteriormente.

flyway repair

Esse comando corrige problemas que podemos ter na nossa tabela de histórico do schema (flyway_schema_history).

flyway baseline

Usamos esse comando em banco de dados existentes, atualizando com uma versão especifica.

Instalando Flyway Community

Podemos instalar o Flyway no Windows, Linux e MacOs sem problemas. Irei mostrar passo a passo como instalar no Windows 10, mas nesse link, você pode ver como é simples a instalação também no Linux e MacOs.

E primeiro, precisamos acessar esse link

E vamos baixar! Atualmente esta na versão 6.5.0 e esta com o tamanho de 87.7MB.

Depois de finalizado o download, vamos descomprimir o arquivo no diretório de sua escolhe. Por exemplo, na raiz do C:/.

Podemos inclusive ter 2 ou mais versões do Flyway na mesma máquina, conforme imagem abaixo.

Dentro do Flyway, temos essas pastas e arquivos:

Para o flyway.cmd, iremos enviar os nossos comandos desejados.
Na pasta conf, temos o arquivo flyway.conf.

Abrindo ele, vemos diversas de configurações.

Os principais parâmetros para configuração:

flyway.url: devemos indicar o JDBC que queremos conectar. Temos uma lista de exemplos no arquivo, como SQL Server, MySQL, Oraclee MariaDB.
flyway.user e flyway.passwork: usuário e senha do nosso banco de dados.
flyway.table: nome da tabela que será criada para controle das versões (histórico) de scripts executados no banco. Se não for preenchido, assumirá o valor padrão que é flyway_schema_history.

Por enquanto, não iremos alterar nada.

Vamos abrir o command do Windows, navegar até a pasta onde instalamos o flyway e executar o comando flyway info.

E ele nos avisa que não foi possível conectar ao banco porque não configuramos a URL do nosso JDBC, usuário e senha. E isso faremos no próximo post dessa serie.

Azure DevOps - Integração Continua e Entrega Contínua de relatórios Power BI

Higor Barbosa — Sun, 16 Feb 2020 23:59:32 +0000

No último artigo mostrei como conectar o Azure DevOps através do Analytics Views do Boards.

Agora, quero mostrar passo a passo como adicionar o relatório que criamos na integração contínua e entrega contínua utilizando o Azure DevOps através do serviço Azure Pipeline.

Vamos lá!?

Requisitos:

Licença Power BI Pro (versão trial 60 dias);
Conta no Azure DevOps (podemos utilizar a versão gratuita);
Conta no Azure (não utilizaremos de créditos);

Azure Repos

Primeiro precisamos adicionar o nosso relatório ao repositório. Usaremos o próprio gerenciador de repositório do Azure DevOps, serviço chamado de Azure Repos.

Quando criamos o projeto no Azure DevOps, selecionamos o GIT como tipo de repositório. E continuaremos com essa opção.

Vamos ir no Repos > Files.

E vamos inicializar com arquivo README.

Vamos ir nos 3 pontos e selecionar a opção Upload File.

Selecionar o novo arquivo, adicionar comentário. Iremos usar a branch master e podemos ainda vincular esse commit a um dos work items que temos.

E lá está o nosso arquivo com extensão .pbix.

Azure Pipeline - Build

Agora que nosso relatório do Power BI foi versionado, podemos adicionar ele no nosso pipeline.

E para isso, vamos ir em Pipelines > Pipelines.

E vamos criar o Pipeline!

Como pode ser sua primeira experiência com pipeline no Azure DevOps, vamos optar pelo editor clássico.

Aqui, precisamos selecionar o gerenciador de repositório. No nosso caso, estamos usando o Azure Repos Git. Selecionar o nosso repositório e a branch, no nosso caso será a Master e continuar.

Temos alguns templates disponíveis. No nosso caso, iremos criar sem template, e para isso, vamos ir em Empty job.

E nessa tela, podemos adicionar tasks relacionadas ao nosso build. Não entrarei em detalhes, mas caso queria saber mais sobre Azure DevOps e Azure Pipeline, pode entrar em contato que lhe envio um cupom do meu treinamento.

Vamos adicionar uma nova tarefa indo no botão "+" na direita do nosso Agent job.

Vamos procurar por copy e adicionar a tarefa Copy files.

Com isso, podemos configurar a tarefa que irá copiar os arquivos do repositório. Em Contents, podemos adicionar a expressão *.pbix, e assim, filtraremos por apenas por arquivos gerados pelo Power BI neste repositório.

Também precisamos adicionar o Target Folder. E para isso, vamos utilizar a expressão $(Build.ArtifactStagingDirectory). Essa é uma das diversas variáveis pré definidas do Azure DevOps. Para ver a lista completa, acesse esse link.

E vamos adicionar nossa segunda e últimas tarefas. Ela será responsável pela publicação do nosso artefato, utilizando o Publish build artifacts.

E não precisamos alterar suas configurações. Ela precisa estar apontando o Path to Publish para a pasta que copiamos o *.pbix na tarefa anterior e o nome do artefato será drop.

Agora podemos editar o nome, salvá-lo e rodar manualmente, clicando na opção Save & queue.

Podemos adicionar um comentário e Save and run.

Ele inicia o build e logo receberá uma mensagem de sucesso.

Podemos clicar no Agent Job e assim que finalizado, conseguimos identificar que geramos um artefato.

Clicando no artefato identificamos a pasta, que na verdade é um arquivo zipado, contendo o nosso arquivo com extensão *.pbix.

Power BI Pro

Legal, nosso relatório do Power BI já está no repositório e no nosso pipeline. Mas isso é apenas o inicio. Agora liberar acesso no Power BI a APIs.

Primeiro, precisamos ativar a licença PRO no nosso Power BI. Sem isso, infelizmente não conseguimos consumir as APIs e realizar o deploy via Azure DevOps e apenas em contas Pro, podemos criar Workspaces. Mas nem tudo está acabado. Você pode optar pela conta trial e prosseguir nesse passo a passo.

Para ativar a versão Pro, podemos ir em Workspaces > Criar um workspace.

E somos indicados a utilizar a versão experimental do Pro.

Temos 60 dias para aproveitar essa experiência.

Agora, vamos criar nosso Workspace no Power BI.

Mas, precisamos também adicionar nosso usuário como administrador. Para isso, vamos ir no em workspace > nosso workspace criado > Acesso ao workspace.

E vamos adicionar o nosso usuário como administrador desse workspace. Por padrão, ao criá-lo, você fica como membro apenas.

Agora, vamos ir em workspace > nosso workspace criado > Configurações de workspace.

E aqui, podemos adicionar o nosso usuário ou um grupo de usuários do Active Directory.

E ainda, você ou o administrador do Power BI precisam liberar o acesso a APIs e podemos fazer isso no Portal do administrador > Configurações.

Vamos ir em Configurações de locatário > Configurações de Desenvolvedor e habilitar o uso de API.

Essa configuração pode levar até 15 minutos para ficar disponível. Enquanto isso, podemos criar a nossa aplicação que irá consumir a API.

Power BI - Registro da Aplicação

E nossa missão está mais simples a alguns meses. Podemos acessar esse link e cadastrar a nossa aplicação.

Precisamos entrar com nossas credenciais do Power BI e adicionar um nome a nossa aplicação.

A aplicação será do tipo Server-side web application (for web apps or web APIs), inserir a URL da sua organização e URL de redirecionamento.

Irei conceder acesso total a essa aplicação, e registrá-lo.

Com isso, temos o nosso Application ID e Application Secret. Vamos copiar o Application ID, usaremos apenas ele.

Azure - Conceder Permissão no Active Directory

Ao criar nossa conta no Power BI, ativamos também o acesso a nuvem da Microsoft.

E para finalizar essa parte, precisamos acessar o portal do Azure.

E no Portal do Azure, vamos ir em Todos os serviços e procurar por active directory.

No Active Diretory, precisamos ir em Registros de Aplicativos.

E aqui vemos o aplicativo que criamos. Vamos entrar nele.

Em Autenticação, precisamos adicionar o aplicativo como cliente público.

E em Permissões de API, precisamos adicionar permissão de aplicativo para o Power BI Service.

E também conceder permissão ao nosso domínio.

Em Proprietários, precisamos adicionar o nosso usuário.

E no Portal do Azure, era isso! Tudo configurado para o Azure DevOps acessar o portal do Power BI.

Release

Legal, nosso relatório do Power BI já está no repositório e no nosso pipeline e fizemos a configurações necessárias no Active Diretory do Azure e no Portal do Power BI. E agora precisamos adicionar ele no release.

E para isso, iremos contar com uma ajuda: Extensões do Marketplace.

Extensão Power BI Actions

Extensões do Marketplace nos ajudam e complementam os serviços disponíveis no Azure DevOps.

E para essa nossa solução de adicionar os relatórios do Power BI no C.I e C.D., vamos usar essa extensão: Power BI Actions.

Vamos acessá-la e Get if free!

Selecionar a nossa organização e instalar.

Caso você esteja utilizando o Azure DevOps Server, tens a opção de baixar e adicionar na sua organização.

Release - Adicionado Artefato e Tarefas

E vamos ir ao nosso Release. Vamos acessá-lo em *Pipelines > Releases *.

E vamos criar o nosso New Pipeline.

Não precisamos selecionar template. Vamos ir em Empty Job.

E o nosso release, é dividido em 2 partes:

Artifacts, onde indicamos qual a fonte do nosso release, no nosso caso nosso repositório do Azure Repos.
Stages, onde adicionamos os steps que teremos na entrega dos nossos artefatos.

Primeiro, vamos ir em Artifacts e vamos indicar o nosso repositório e nossa branch master.

E em Stages, já temos 1 job, vamos clicar nele.

Temos o nosso agente e precisamos adicionar tarefas. Na verdade, iremos adicionar apenas uma. Vamos ir no botão "+".

Vamos pesquisar por Power BI, e já vemos a tarefa da extensão que instalamos a pouco.

E agora temos diversas configurações a fazer.

Usaremos o tipo de autenticação como User.

Mas, precisamos criar essa autenticação. E para isso, vamos ir em Manager.

E vamos criar uma nova conexão, e vai ser do tipo Power BI - User.

Lembram do Application ID que copiamos a pouco? Usaremos ela no campo Client Id.

Também precisamos adicionar nosso usuário e senha e adicionar nome da conexão.

E podemos voltar ao Releases. Precisamos selecionar a conexão que criamos.

Em Action, temos algumas opções, como por exemplo, Upload PowerBI Report, e é ela que usaremos.

Precisamos também selecionar o nosso workpace que criamos no Power BI e o Source File, selecionando a pasta drop do nosso artefato.

Podemos alterar o nome do Release, salvar e criar o nosso release.

Vamos criar nosso release manualmente e vamos rodá-lo.

E terminou com Sucesso!

Podemos entrar no job e ver detalhes da execução.

E acessando workspace, lá está o nosso relatório.

Integração Contínua e Entrega Contínua

Podemos sempre que o arquivo do Power BI for commitado, iniciar automaticamente a execução do pipeline. Para isso, vamos ir em * Pipelines > Pipelines*.

Selecionar o nosso build, editá-lo e navegar até a aba Triggers.

Marcar a opção Enable continuous integration e selecionar a nossa branch.

E depois da integração contínua, podemos também habilitar a entrega contínua.

Para isso, vamos ir em Pipelines > Releases. Editar nosso release e clicar no ícone do Continuous Deployment trigger e habitá-lo.

E está lá! Agora nossos relatórios do Power BI estão versionados e assim que commitados, irão diretamente para o nosso workspaces no portal do Power BI.

Podemos também criar mais um workspace e adicionar mais um step e aprovações. Deixando assim um workspace como ambiente de homologação e outro como produção, ficando assim:

E assim, finalizamos o C.I./C.D. dos nossos relatórios Power BI!

Azure DevOps - Integrando Boards com Relatórios do Power BI

Higor Barbosa — Sat, 15 Feb 2020 21:27:41 +0000

Boards, o serviço de gerenciamento e planejamento de projetos do Azure DevOps é uma ferramenta fantástica.

Mas, nem sempre o que esta disponível na feature de Queries contempla tudo o que necessitamos.

E para suprir isso, podemos conectá-lo ao Microsoft Power BI.

E nesse artigo, quero demonstrar passo a passo como faremos isso.

Vamos lá?

Requisitos:

Conta no Azure DevOps
Instalação do Power BI Desktop

Māos a obra!

Azure DevOps

Primeiro, você vai precisar ter uma conta do Azure DevOps.

E você poderá cria-la, acessando aqui.

A conta Basic Plan já será suficiente para essa demonstração e totalmente gratuita para até 5 usuários.

Projeto no Azure DevOps

Iremos trabalhar com o Work Item Process Basic e esse projeto está público, caso queira consulta-lo.

O Azure DevOps dividido em serviços. Boards, Repos, Pipelines, Test Plans e Artificats. Cada um com seu proposito.

O Boards eh o serviço responsável pelo planejamento dos nossos projetos. E nele, podemos criar nossos epics, features, US, tarefas e bugs, gerenciando assim o desenvolvimento do nosso projeto. E temos 4 modelos de processos, cada um com suas caracteristicas e premissas: Basic, Scrum, Agile e CMMI.

Iremos utilizar o Basic, modelo mais simplificado.

Vamos acessar a nossa lista de Work Items, através do menu Boards > Work Items.

Podemos criar Epics, Issues e Tasks através da opçāo New Work Item.

Mas, vamos simplificar. Vamos ir na opçāo * Import Work Items*.

E vamos selecionar esse arquivo.

Salvar clicando em Save Items.

E esta lá! Temos Issues e Tasks no nosso projeto de exemplo.

No Azure DevOps, temos uma sessão para novas features, que ainda estão em uma versão preview.

E entre essas features, temos a opçāo Analytics Views. Podemos habilitá-la, para o usuário e para a organização.

E com isso, em Overview temos a opção Analytics view.

E acessando essa opção, vamos a lista de visões analíticas.

Na lista de visões, temos Issues, Tasks, Bugs e Work Items em geral, podendo visualizar pelo histórico ou presente.

Podemos também criar novas visões, clicando em New view.

E vamos criar nossa visão.

Em General, vamos criar uma visão compartilhada.

Em Work Items, podemos selecionar pelo filtro por time, selecionar times, incluir filtros por backlogs, work items e também por critérios.

Em Fields, vamos incluir os seguintes campos:

Work item Id
Title
Area Path
Assigned To
Iteration Path
State
Work Item Type
Priority
Effort
Tags
Remaing Work

Em History, podemos filtrar por datas mas iremos simplesmente filtrar apenas pelo estado atual.

Temos ainda a aba Verification. Nela, verificamos se nossa visão se tudo está ok.

E vamos salvá-lo.

Clicando na nossa visão criada, vemos o seu resumo.

E o que queremos agora? Vamos criar relatórios no Power BI, utilizando essas informações que importamos.

Microsoft Power BI Desktop

Precisamos instalar o Power BI Desktop. E podemos instalar através desse link

Ele é gratuito, mas não eh bem assim. Precisamos ter uma conta comercial, não podemos usar, por exemplo, nossa conta do gmail ou outlook.

E a instalação e feita através do Microsoft Store.

Abrindo o Power BI Desktop, criamos a conta e fazemos login com e-mail comercial.

Com ele aberto, podemos precisamos conectar o Power BI Desktop ao Azure DevOps.

E pra isso, vamos ir em Get Data e na opção More.

Aqui, temos os conectores disponíveis. O Power BI em si, não trabalha como um banco de dados, mas sim como um visualizador de dados. Você conecta o seu repositório e assim, poderá criar painéis, inclusive, relacionando fontes de dados.

Vamos procurar por Azure DevOps e temos 2 opções.

Azure DevOps (Beta)
Azure DevOps Server (Beta)

Ou seja, temos conectores disponíveis para a versão Service e versão On-Premise, ambos em versão Beta, não recomendado para uso em produção, ainda!

Devemos optar pela primeira opção, Azure DevOps (Beta).

Informar Organização e Projeto.

E logar na nossa conta do Azure DevOps.

Abriu a tela com as nossas visões. Todas visões criadas automaticamente e a nossa visão criada a pouco.

Vamos selecionar a nossa visão e carregá-la.

Na esquerda, temos 3 opções:

Report, onde criamos o nosso painel;

Data, onde podemos visualizar os dados conectados;

Model, onde temos o modelo relacional;

Vamos ir em Report, e selecionar a visualização do tipo Table.

Selecionamos os campos:

Effort
Priorty
Remaing work
Tags
Title
Work Item Type

Vamos inserir também o gráfico Donut. Adicionar Effort em Values e Tags em Legends.

E também inserir gráfico "Pie", selecionando Tags em Legends e Remaining Work em Values.

Podemos organizar melhor a pagina do nosso relatório, e adicionar imagem e texto, opções encontradas no menu do topo do Power BI Desktop.

E o nosso relatório ficou assim:

Listamos os work items e também temos 2 gráficos: Esforço por Tags e Trabalho Restante por Tag. Selecionando o work item ou a tag nos gráficos, conseguimos ver detalhes.

Podemos salvar. E para compartilhar com integrantes da nossa organização, podemos ir em Publish, no menu do topo.

Vamos selecionar o nosso workspace.

E assim, ele publica o nosso relatório nesse repositorio. Vamos acessa-lo.

E na opção Relatórios, podemos acessar a nossa pagina criada no Power BI Desktop.

E lá está! Nosso relatório pronto para ser compartilhado e distribuído para o resto da nossa organização.