Nesta breve postagem, mostrarei como listar os Repositórios do Azure em um Projeto de DevOps do Azure com seus tamanhos em MB usando um script do PowerShell.

Para acompanhar este post, você precisará criar um Token de Acesso Pessoal (PAT) com o permissão de Código (leitura). Você pode ler mais sobre o PAT na documentação oficial.

$DevOpsServerName = "<YOUR AZURE DEVOPS SERVER NAME>"
$ProjectCollection = "<YOUR PROJECT COLLECTION NAME>"
$Project = "<YOUR PROJECT NAME>"
$PAT = "<YOUR PERSONAL ACCESS TOKEN>"

$baseUrl = https://$DevOpsServerName/$ProjectCollection/$Project/_apis/git/repositories?includeLinks={includeLinks}&includeAllUrls={includeAllUrls}&includeHidden={includeHidden}&api-version=6.0
$base64AuthInfo= [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes(":$($PAT)"))
$headers = @{Authorization=("Basic {0}" -f $base64AuthInfo)}
$repositories = Invoke-RestMethod -Uri $baseUrl -Method Get -Headers $headers

foreach ($repo in $repositories.value) {
    $repoName = $repo.name
    $repoSize = [math]::Round(($repo.size / 1MB),2) 
    
    Write-Output "$repoName $repoSize MB"
} 

Aqui está um exemplo da saída desse script:

Tailwind Traders 10.65 MB
TailwindTraders-Backend 28.45 MB
TailwindTraders-Website 14.04 MB 

O script acima usa a API Rest do Azure DevOps para obter os repositórios e seus tamanhos. Você pode ler mais sobre a API na documentação oficial.

Isso é útil para saber o tamanho de seus repositórios no caso de você estar planejando fazer uma migração, ou no caso de você gostaria de saber se você tem arquivos grandes, e para saber se você precisa limpar alguns deles.

Espero ter ajudado!

Introdução​

Muitos dos nossos aplicativos Web hospedados no Azure são criados sobre um serviço PaaS, como o Serviço de Aplicativo do Azure e o SQL Azure. Esses serviços geralmente são cobrados com base na quantidade de recursos que consomem. Quanto mais recursos eles consomem, mais pagamos. No entanto, existem algumas práticas recomendadas que podemos seguir para reduzir a quantidade de recursos consumidos e, portanto, reduzir a quantidade de dinheiro que pagamos. Especialmente se estivermos executando um aplicativo Web que não é usado 24 horas por dia, 7 dias por semana ou apenas usado durante o horário comercial no mesmo fuso horário.

Um dos princípios da computação em nuvem é o elasticidade, o que significa que podemos aumentar ou diminuir os recursos que nosso aplicativo consome com base na demanda ou no cronograma. Esse é um ótimo recurso da nuvem, mas devemos estar cientes das implicações de custo desse recurso. Se ampliarmos nosso aplicativo para lidar com um pico de tráfego, também devemos reduzir os recursos quando o tráfego voltar ao normal.

No Serviço de Aplicativo do Azure, temos duas maneiras de escalar, aumentar ou diminuir a escala e expandir para fora ou para dentro. Aumentar ou diminuir a escala significa que podemos alterar o tamanho da VM em que nosso aplicativo está sendo executado. Expandir ou aumentar significa que podemos adicionar ou remover VMs do nosso aplicativo. Podemos aumentar ou diminuir a escala e reduzir a escala para fora ou para dentro ao mesmo tempo. Por exemplo, podemos aumentar o tamanho das VMs e adicionar mais VMs ao nosso aplicativo.

Portanto, se tivermos um aplicativo Web de produção que não seja usado 24 horas por dia, 7 dias por semana, devemos considerar o seguinte:

• Reduza o aplicativo e o banco de dados para os recursos mínimos necessários fora do horário de pico.
• Dimensione o aplicativo e o banco de dados para os recursos máximos necessários durante o horário de pico. (além disso, devemos habilitar o dimensionamento automático para expandir o aplicativo e adicionar mais instâncias quando necessário, por meio das regras que você define para expandir horizontalmente ou para dentro).

O processo para aumentar e diminuir a escala pode ser desativado manualmente a partir do portal, conforme mostrado na imagem.

No entanto, esse processo pode ser tedioso e propenso a erros. Podemos automatizar o processo para aumentar e diminuir a escala do Web App e do banco de dados durante a noite e os fins de semana. Isso reduzirá a quantidade de recursos consumidos e, portanto, reduzirá a quantidade de dinheiro que pagamos.

Solução​

Nós podemos usar Automação do Azure para agendar um script do PowerShell para reduzir o Aplicativo Web e o Banco de Dados durante a noite e os fins de semana. Também podemos agendar outro script do PowerShell para ampliar o Aplicativo Web e o Banco de Dados antes do horário comercial.

Você precisará configurar uma identidade atribuída pelo sistema à conta de automação do Azure para se conectar aos recursos do Azure. Você pode seguir as etapas neste artigo.

Vamos explorar os scripts do PowerShell que podemos usar:

Aumentar ou diminuir a escala do aplicativo Web​

$resourceGroupName = '<Your Resource Group>'
$appServicePlanName = '<Your App Service>'
$tier = '<Tier you would like to scale down - For example: Basic>'
try
{
    filter timestamp {"[$(Get-Date -Format G)]: $_"}
    Write-Output "Script started." | timestamp
    Write-Verbose "Logging in to Azure..." -Verbose
    Connect-AzAccount -Identity
    Write-Verbose "Login sucessful. Proceding to update service plan..." -Verbose
    Set-AzAppServicePlan -ResourceGroupName $resourceGroupName -Name $appServicePlanName -tier $tier
    Write-Verbose "Service plan updated. Getting information about the update..." -Verbose
    $appPlanService = Get-AzAppServicePlan -ResourceGroupName $resourceGroupName -Name $appServicePlanName
    Write-Output "App Service Plan name: $($appPlanService.Name)" | timestamp
    Write-Output "Current App Service Plan status: $($appPlanService.Status), tier: $($appPlanService.Sku.Name)" | timestamp
    Write-Output "Script finished."
}
catch {
    Write-Verbose "Error... '$_.Exception'" -Verbose
    Write-Error -Message $_.Exception
    throw $_.Exception
}

Aumentar ou diminuir a escala do SQL Azure​

$resourceGroupName = '<Your Resource Group>'
$SqlServerName = '<Your SQL Azure Server Name>'
$DatabaseName = '<Your SQL Azure DB Name>'
$Edition = '<Tier you would like to scale down - For example: Basic>'
$PerfLevel = '<Tier you would like to scale down - For example: Basic>'
try{
    filter timestamp {"[$(Get-Date -Format G)]: $_"}
    Write-Output "Script started." | timestamp
    Write-Verbose "Logging in to Azure..." -Verbose
    Connect-AzAccount -Identity  
    Write-Verbose "Login sucessful. Proceding to update SQL Server plan..." -Verbose
    Set-AzSqlDatabase -ResourceGroupName $resourceGroupName -DatabaseName $DatabaseName -ServerName $SqlServerName -Edition $Edition -RequestedServiceObjectiveName $PerfLevel 
    Write-Verbose "SQL Server plan updated. Getting information about the update..." -Verbose
    $sqlServerPlan = Get-AzSqlDatabase -ResourceGroupName $resourceGroupName -DatabaseName $DatabaseName -ServerName $SqlServerName
    Write-Output "SQL Server Edition: $($sqlServerPlan.Edition)" | timestamp
    Write-Output "Current SQL Server Plan status: $($sqlServerPlan.Status)" | timestamp
    Write-Output "Script finished."
}
catch{
    Write-Verbose "Error... '$_.Exception'" -Verbose
    Write-Error -Message $_.Exception
    throw $_.Exception
}

Depois de criar os Runbooks na Automação do Azure, você pode criar as agendas e vincular os Runbooks às agendas.

Conclusão​

Vimos como podemos usar a Automação do Azure e o PowerShell para agendar o dimensionamento para cima ou para baixo do Aplicativo Web e do SQL Azure. Isso nos ajudará a economizar dinheiro e também a evitar o tempo de inatividade durante o horário comercial, adicionando os recursos que não usamos à noite.

Introdução​

O teste de carga é uma técnica que se concentra em avaliar o desempenho de um aplicativo em condições de carga normais ou esperadas. O objetivo é determinar como o aplicativo se comporta quando está sujeito aos níveis esperados de uso e tráfego. O teste de carga é frequentemente usado para verificar se um sistema pode lidar com o número esperado de usuários e transações e para identificar quaisquer gargalos de desempenho ou problemas que possam afetar a experiência do usuário.

O Microsoft Azure oferece um novo serviço (na visualização), chamado Teste de Carga do Azure. Um dos principais benefícios de usar esse serviço é que ele permite que você teste o desempenho do seu aplicativo em uma escala sem ter que investir em hardware e infraestrutura caros. Além disso, ele é altamente configurável e pode ser usado para testar aplicativos hospedados em uma variedade de plataformas, incluindo o Azure, servidores locais e provedores de nuvem de terceiros.

Do que precisamos?​

Além de uma Assinatura do Azure e uma conta do GitHub, precisaremos de uma Apache JMeter script, que normalmente consiste em uma série de elementos de teste, incluindo grupos de threads, samplers, ouvintes e asserções. Os grupos de threads definem o número e o tipo de usuários virtuais que serão simulados, enquanto os samplers definem as ações ou solicitações específicas que serão executadas pelos usuários virtuais. Os ouvintes capturam os dados de desempenho gerados pelo teste, e as asserções definem os resultados esperados do teste e verificam se os resultados reais correspondem às expectativas.

Aqui você pode encontrar o script que eu criei como parte desta demonstração

Primeiros passos​

No exemplo a seguir, usaremos o Teste de Carga do Azure em nosso fluxo de trabalho das Ações do GitHub para detectar quando nosso aplicativo Web atingiu um problema de desempenho. Vamos definir um cenário de teste de carga com um número e tipo específico de usuários virtuais que serão simulados, bem como a duração do teste e o tipo de carga de trabalho a ser simulada, que neste caso é apenas uma Solicitação HTTP. Além disso, você também pode usar o Visual Studio ou o Portal do Azure para criar e configurar seu cenário de teste de carga.

Uma vez definido o cenário de teste de carga, podemos revisar os resultados e os dados de monitoramento, o que inclui métricas como tempo de resposta, uso da CPU e tráfego de rede, bem como contadores de desempenho personalizados que podemos definir. Com esses dados, identificamos gargalos e otimizamos o desempenho do aplicativo.

O cenário​

Desenvolvi um simples Aplicativo Web criado com ASP.NET Core usando o .NET 7 que se conecta a um Azure Cosmos DB e adiciona um registro de cada visita à página e recupera os dados de todas as visitas.

O ambiente​

Este aplicativo Web está sendo executado em um Serviço de Aplicativo Básico e ele tem o Applications Insights para monitorar o desempenho do aplicativo. O Cosmos DB é definido com o nível gratuito (1000 RU/s e 25 GB). Quero descobrir se o aplicativo em execução nesse ambiente pode oferecer suporte a até 100 usuários simultâneos.

O repositório​

Você pode conferir o Repositório do GitHub aqui. Lá você pode bifurcar o repositório, use o Modelo ARM.

Observação: O Microsoft Azure só permite que você crie um recurso de Camada Gratuita do Cosmos DB por assinatura, você pode receber um erro se já tiver uma Camada Gratuita do Cosmos DB em sua assinatura.

Este repositório tem um Ação do GitHub que Compile e Implante o aplicativo e execute o Teste de Carga no Teste de Carga do Azure.

A ação do GitHub​

O fluxo de trabalho consiste em três etapas (Compilação, Implantação e Teste de Carga) e é executado em cada push. O trabalho de teste de carga usa os seguintes arquivos na pasta raiz:

• LoadTestingScript.jmx
• LoadTestingConfig.yaml

O logon do Azure é necessário para se comunicar com o serviço de Teste de Carga do Azure para enviar o script JMeter e a configuração para o teste. Nesta configuração podemos definir o número de Motores queremos executar o teste e os critérios de falha, neste caso temos um tempo médio de resposta inferior a 5 segundos e uma percentagem de erro inferior a 20%.

Os resultados​

Como você pode ver na imagem acima, o Teste de Carga Falhou Como o tempo médio de resposta foi maior que o limite (5 segundos), podemos obter mais detalhes sobre a execução do teste no Portal do Azure. Você pode baixar os resultados aqui.

No Serviço de Aplicativo do Azure, podemos ver as métricas com os tempos de resposta (superiores a 5 segundos) e o número de solicitações com os Dados de entrada e saída de dados.

Além disso, adicionei o Application Insights para monitorar o aplicativo Web, no Portal do Azure podemos ver os problemas e falhas de desempenho.

Na imagem acima, você pode ver de onde vieram as solicitações, neste caso, estou executando o Teste de Carga do Azure na região Leste dos EUA (Virgínia).

Conclusões​

O teste de carga não deve ser em execução em um ambiente de produção, experimente-o em um QA ou Pré-Produção. Mesmo que você esteja executando em slots de implantação, lembre-se de que o aplicativo ainda será executado no mesmo Plano de Serviço de Aplicativo, e isso pode afetar seu ambiente de produção ou causar um Ataque de negação de serviço.

Se você quiser saber mais sobre o Teste de Carga do Azure, recomendo que você revise o documentação do serviço.

Estou muito feliz em compartilhar que acabei de ganhar as três Certificações de Parceiros do GitHub.

As Certificações de Partners do GitHub são um conjunto de três exames que cobrem a plataforma GitHub e seu ecossistema. Os exames são projetados para testar seu conhecimento do GitHub.

Os três exames são:

• Ações do GitHub
• Administrador do GitHub
• Segurança Avançada do GitHub

Coleções do Microsoft Learn me ajudou muito a me preparar para os exames. Eu recomendo que você os verifique.

Estou ansioso para continuar aprendendo e compartilhando meu conhecimento com a comunidade.

Hoje tive a oportunidade de apresentar um webinar sobre GHAS, pode assistir aqui.

Você pode obter a Apresentação do PowerPoint aqui.

Hoje estou muito feliz para começar meu novo trabalho como Consultor Azure & DevOps em xpirit | Parte de Xebia. Vou me juntar a equipe de Esteban Garcia como o sexto empregado nos EUA.

Xpirit é um Microsoft Gold Partner & GitHub Partner Verificado que começou em 2014 na Holanda e estendeu as operações na Bélgica, Alemanha e em 2022 nos EUA.

Estou entusiasmado em começar com a equipe de consultores altamente experientes, especialistas em transformação de nuvem usando o Microsoft Azure, construindo equipes de TI de alto desempenho usando DevOps e criando Software Nativo em Nuvem. Xpirit continua crescendo, vem se juntar a nós, confira as vagas abertas aqui.

Depois de quase 7 anos, hoje é meu último dia na Microsoft. Tem sido ótimo, não posso agradecer o suficiente a todos os companheiros de equipe, gerentes e mentores que tive ao longo dos anos que me ajudaram a crescer e aproveitar a jornada.

Estarei eternamente grato à Microsoft por todas as oportunidades, experiências, aprendizados, todo o apoio que recebi e especialmente por todas as pessoas incríveis que conheci e tive a oportunidade de trabalhar.

Enquanto é meu último dia na Microsoft, minha missão continuará. Amanhã, começarei uma nova aventura como consultor da Azure & DevOps para continuar ajudando as pessoas a construir as soluções mais inovadoras com tecnologia.

Hoje eu estou relançando meu site com base em Docusarious do Facebook. Estou executando-o em Azure Static WebApps e GitHub Pages.

Um destaque deste gerador de site estático é a funcionalidade de localização, como você pode ver, este site suporta inglês, espanhol e português.

Outra coisa que me gostou é o suporte de React, TypeScript e Markdown (incluindo MDX).

Neste blog vou compartilhar dicas sobre tecnologia e desenvolvimento profissional de carreira.

Se você tiver algum feedback ou suggestion para conteúdo, não hesitante para entrar em contato.

Obrigado por ler!