En esta breve publicación, les mostraré cómo listar los repositorios de Azure en un proyecto de Azure DevOps con sus tamaños en MB mediante un script de PowerShell.

Para seguir esta publicación, deberás crear un token de acceso personal (PAT) con el permiso de Código (lectura). Puede leer más sobre PAT en la documentación 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"
} 

Aquí hay un ejemplo de la salida de ese script:

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

El script anterior usa la API de REST de Azure DevOps para obtener los repositorios y sus tamaños. Puede leer más sobre la API en la documentación oficial.

Esto es útil para saber el tamaño de sus repositorios en caso de que esté planeando hacer una migración, o en caso de que desee saber si tiene archivos grandes y saber si necesita limpiar algunos de ellos.

¡Espero que esto ayude!

Introducción​

Muchas de nuestras aplicaciones web hospedadas en Azure se crean sobre un servicio PaaS, como Azure App Service y SQL Azure. Estos servicios generalmente se facturan en función de la cantidad de recursos que consumen. Cuantos más recursos consumen, más pagamos. Sin embargo, hay algunas mejores prácticas que podemos seguir para reducir la cantidad de recursos consumidos y, por lo tanto, reducir la cantidad de dinero que pagamos. Especialmente si estamos ejecutando una aplicación web que no se usa 24/7 o solo se usa durante el horario comercial en la misma zona horaria.

Uno de los principios de la computación en la nube es el elasticidad, lo que significa que podemos escalar hacia arriba o hacia abajo los recursos que consume nuestra aplicación en función de la demanda o el horario. Esta es una gran característica de la nube, pero debemos ser conscientes de las implicaciones de costos de esta característica. Si ampliamos nuestra aplicación para manejar un pico de tráfico, también debemos reducir los recursos cuando el tráfico vuelva a la normalidad.

En el Servicio de aplicaciones de Azure tenemos dos formas de escalar verticalmente, verticalmente o abajo y escalar horizontalmente o entrar. Escalar hacia arriba o hacia abajo significa que podemos cambiar el tamaño de la máquina virtual en la que se ejecuta nuestra aplicación. Escalar horizontalmente o en significa que podemos agregar o quitar máquinas virtuales de nuestra aplicación. Podemos escalar hacia arriba o hacia abajo y escalar hacia afuera o hacia adentro al mismo tiempo. Por ejemplo, podemos escalar verticalmente el tamaño de las máquinas virtuales y agregar más máquinas virtuales a nuestra aplicación.

Así que si tenemos una Web App de producción que no se utiliza 24/7, debemos considerar lo siguiente:

• Reduzca la aplicación y la base de datos a los recursos mínimos necesarios durante las horas de menor actividad.
• Escale verticalmente la aplicación y la base de datos a los recursos máximos necesarios durante las horas punta. (Además, debemos habilitar el escalado automático para escalar horizontalmente la aplicación y agregar más instancias cuando sea necesario, a través de las reglas que defina para escalar horizontalmente o en).

El proceso de escalado vertical y vertical se puede reducir manualmente desde el portal, como se muestra en la imagen.

Sin embargo, este proceso puede ser tedioso y propenso a errores. Podemos automatizar el proceso para escalar hacia arriba y hacia abajo la aplicación web y la base de datos durante la noche y los fines de semana. Esto reducirá la cantidad de recursos consumidos y, por lo tanto, reducirá la cantidad de dinero que pagamos.

Solución​

Podemos utilizar Automatización de Azure para programar un script de PowerShell para reducir la escala de la aplicación web y la base de datos durante la noche y los fines de semana. También podemos programar otro script de PowerShell para escalar verticalmente la aplicación web y la base de datos antes del horario comercial.

Deberá configurar una identidad asignada por el sistema a la cuenta de Azure Automation para conectarse con los recursos de Azure. Puede seguir los pasos de este artículo.

Exploremos los scripts de PowerShell que podemos usar:

Escalar verticalmente o reducir verticalmente la aplicación 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
}

Escalar verticalmente o reducir el 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
}

Una vez creados los Runbooks en Automatización de Azure, puede crear las programaciones y vincularlas a las programaciones.

Conclusión​

Hemos visto cómo podemos usar Azure Automation y PowerShell para programar el escalado vertical o vertical de la aplicación web y SQL Azure. Esto nos ayudará a ahorrar dinero y también a evitar el tiempo de inactividad durante el horario comercial al agregar los recursos que no usamos por la noche.

Introducción​

Las pruebas de carga son una técnica que se centra en evaluar el rendimiento de una aplicación en condiciones de carga normales o esperadas. El objetivo es determinar cómo se comporta la aplicación cuando está sujeta a los niveles esperados de uso y tráfico. Las pruebas de carga se utilizan a menudo para comprobar que un sistema puede controlar el número esperado de usuarios y transacciones, y para identificar cualquier cuello de botella o problema de rendimiento que pueda afectar a la experiencia del usuario.

Microsoft Azure ofrece un nuevo servicio (en versión preliminar), llamado Pruebas de carga de Azure. Uno de los beneficios clave de usar este servicio es que le permite probar el rendimiento de su aplicación a una escala sin tener que invertir en hardware e infraestructura costosos. Además, es altamente configurable y se puede usar para probar aplicaciones hospedadas en una variedad de plataformas, como Azure, servidores locales y proveedores de nube de terceros.

¿Qué necesitamos?​

Además de una suscripción de Azure y una cuenta de GitHub, necesitaremos un Apache JMeter script, que normalmente consta de una serie de elementos de prueba, incluidos grupos de subprocesos, samplers, oyentes y aserciones. Los grupos de subprocesos definen el número y el tipo de usuarios virtuales que se simularán, mientras que los muestreadores definen las acciones o solicitudes específicas que realizarán los usuarios virtuales. Los oyentes capturan los datos de rendimiento generados por la prueba, y las aserciones definen los resultados esperados de la prueba y verifican que los resultados reales coincidan con las expectativas.

Aquí puedes encontrar el script que creé como parte de esta demo

Empezando​

En el siguiente ejemplo, vamos a usar Azure Load Testing en nuestro flujo de trabajo desde GitHub Actions para detectar cuándo nuestra aplicación web ha alcanzado un problema de rendimiento. Vamos a definir un escenario de prueba de carga con un número y tipo específico de usuarios virtuales que se simularán, así como la duración de la prueba y el tipo de carga de trabajo a simular, que en este caso es solo una solicitud HTTP. Además, también puede usar Visual Studio o el Portal de Azure para crear y configurar el escenario de prueba de carga.

Una vez definido el escenario de prueba de carga, podemos revisar los resultados y los datos de supervisión, que incluyen métricas como el tiempo de respuesta, el uso de CPU y el tráfico de red, así como contadores de rendimiento personalizados que podemos definir. Con estos datos identificamos cuellos de botella y optimizamos el rendimiento de la aplicación.

El escenario​

Desarrollé un simple Aplicación Web compilado con ASP.NET Core con .NET 7 que se conecta a Azure Cosmos DB y agrega un registro de cada visita a la página y recupera los datos de todas las visitas.

El entorno​

Esta aplicación web se ejecuta en un Servicio de aplicaciones Básico y tiene Applications Insights para supervisar el rendimiento de la aplicación. Cosmos DB se establece con el comando Nivel gratuito (1000 RU/s y 25 GB). Quiero averiguar si la aplicación que se ejecuta en este entorno puede admitir hasta 100 usuarios simultáneos. (https://loadtestingweb.azurewebsites.net)

El repositorio​

Puedes consultar el Repositorio de GitHub aquí. Allí puede bifurcar el repositorio, use el botón Plantilla de ARM.

Nota: Microsoft Azure solo le permite crear un recurso de capa gratuita de Cosmos DB por suscripción, es posible que reciba un error si ya tiene una capa gratuita de Cosmos DB en su suscripción.

Este repositorio tiene un Acción de GitHub que compilan e implementan la aplicación y ejecutan la prueba de carga en Azure Load Testing.

La acción de GitHub​

El Flujo de trabajo consta de tres pasos (compilación, implementación y pruebas de carga) y se ejecuta en cada inserción. El trabajo de prueba de carga utiliza los siguientes archivos en la carpeta raíz:

• LoadTestingScript.jmx
• LoadTestingConfig.yaml

El inicio de sesión de Azure es necesario para comunicarse con el servicio Azure Load Testing para enviar el script de JMeter y la configuración de la prueba. En esta configuración podemos definir el número de motores Queremos ejecutar la prueba y los criterios de fallo, en este caso tenemos un tiempo de respuesta promedio inferior a 5 segundos y un porcentaje de error inferior al 20%.

Los resultados​

Como puedes ver en la imagen de arriba, la prueba de carga fracasado dado que el tiempo de respuesta promedio fue superior al umbral (5 segundos), podemos obtener más detalles sobre la ejecución de la prueba en el Portal de Azure. Puedes descargar los resultados aquí.

En el Servicio de aplicaciones de Azure, podemos ver las métricas con los tiempos de respuesta (superiores a 5 segundos) y el número de solicitudes con los datos de entrada y salida.

Además, agregué Application Insights para monitorear la aplicación web, en el Portal de Azure podemos ver los problemas y errores de rendimiento.

En la imagen de arriba puede ver de dónde provienen las solicitudes, en este caso estoy ejecutando Azure Load Testing en la región Este de EE. UU. (Virginia).

Conclusiones​

Las pruebas de carga no debe ser ejecutándose en un entorno de producción, pruébelo en un control de calidad o preproducción. Incluso si se ejecuta en ranuras de implementación, recuerde que la aplicación seguirá ejecutándose en el mismo plan del Servicio de aplicaciones, lo que podría afectar al entorno de producción o provocar un Ataque de denegación de servicio.

Si desea obtener más información sobre Azure Load Testing, le recomiendo que revise el Documentación de servicio.

Hoy tuve la oportunidad de presentar un webinar sobre GHAS, puedes verlo aquí.

Puede obtener la presentación de PowerPoint aquí.

Estoy emocionado de compartir que acabo de obtener las tres certificaciones de socios de GitHub.

Las certificaciones de socios de GitHub son un conjunto de tres exámenes que cubren la plataforma GitHub y su ecosistema. Los exámenes están diseñados para poner a prueba su conocimiento de GitHub.

Los tres exámenes son:

• Acciones de GitHub
• Administrador de GitHub
• Seguridad Avanzada de GitHub

Las colecciones de Microsoft Learn me ayudaron mucho a prepararme para los exámenes. Te recomiendo que los revises.

Tengo muchas ganas de seguir aprendiendo y compartiendo mis conocimientos con la comunidad.

Hoy estoy muy emocionado de comenzar mi nuevo trabajo como Consultor de Azure y DevOps en Xpirit | Parte de Xebia. Me estoy uniendo al equipo de Esteban García como el sexto empleado en los Estados Unidos.

Xpirit es un Microsoft Gold Partner y GitHub Verified Partner que comenzó en 2014 en Holanda y amplió las operaciones en Bélgica, Alemania y en 2022 en los Estados Unidos.

Estoy de unirme a este equipo de consultores altamente experimentados, expertos en transformación de la nube utilizando Microsoft Azure, creando equipos de TI de alto rendimiento utilizando DevOps y creando software nativo en la nube. Xpirit sigue creciendo, acompáñanos, echa un vistazo a las posiciones abiertas aquí.

Después de casi 7 años, hoy es mi último día en Microsoft. Ha sido genial, no hay palabras de agradecimiento a todos los compañeros de equipo, gerentes y mentores que he tenido a lo largo de los años que me han ayudado a crecer y disfrutar de esta aventura.

Estaré eternamente agradecido con Microsoft por todas las oportunidades, experiencias, aprendizajes, todo el apoyo que recibí y especialmente por todas las personas increíbles que conocí y con las que tuve la oportunidad de trabajar.

Mientras dejo de trabajar en Microsoft, mi misión continuará. Mañana, comenzaré una nueva aventura como consultor de Azure y DevOps para continuar ayudando a las personas a crear las soluciones más innovadoras con tecnología.

Hoy estoy relanzando mi sitio web basado en Docusarious de Facebook. Lo estoy ejecutando en Azure Static Web Apps y GitHub Pages.

Un punto a resaltar de este generador de sitios estáticos es la funcionalidad de localización, como pueden ver, estos sitios web soporta inglés, español y portugués.

Otra cosa que me gustó es el soporte de React, TypeScript y Markdown (incluido MDX).

En este blog compartiré consejos sobre tecnología y, desarrollo profesional.

Si tiene algún comentario o suggetion para el contenido, no dude en comunicarse conmigo.

¡Gracias por leer!