Skip to content

Blog

Autenticación Python en Máquinas Azure Arc: Guía Práctica

Resumen

Los servidores enrolados en Azure Arc pueden autenticarse contra recursos Azure usando managed identity sin almacenar credenciales. Python + Azure SDK (azure-identity) simplifica esto con DefaultAzureCredential o ManagedIdentityCredential, accediendo al endpoint IMDS local (http://localhost:40342) que expone el agente Azure Connected Machine.

¿Qué es Azure Arc-enabled servers?

Azure Arc extiende el plano de control de Azure a servidores físicos y VMs fuera de Azure (on-premises, otras clouds, edge). Una vez enrolado, el servidor obtiene:

  • Representación como recurso Azure (Microsoft.HybridCompute/machines)
  • System-assigned managed identity automática
  • Acceso a servicios Azure (Key Vault, Storage, Log Analytics, etc.) sin credenciales hard-coded
  • Gestión unificada (Policy, Update Management, extensiones VM)

Cómo funciona la autenticación en Azure Arc

Cuando el agente azcmagent se instala y conecta, ocurre:

  1. Azure Resource Manager crea un service principal en Microsoft Entra ID para la identidad del servidor.
  2. El agente configura un endpoint IMDS local en http://localhost:40342 (no enrutable, solo accesible desde localhost).
  3. Variables de entorno se establecen automáticamente:
  4. IMDS_ENDPOINT=http://localhost:40342
  5. IDENTITY_ENDPOINT=http://localhost:40342/metadata/identity/oauth2/token
  6. Las aplicaciones solicitan tokens a este endpoint, sin exponer secretos.

Diferencia con Azure VMs

Azure VMs usan http://169.254.169.254 (Azure IMDS), mientras que Arc usa localhost:40342. El SDK de Azure detecta automáticamente el entorno correcto.

Métodos de autenticación en Python

Opción 1: DefaultAzureCredential (recomendada)

Cadena de credenciales que prueba múltiples métodos en orden (variables de entorno, managed identity, Azure CLI, etc.). Funciona tanto en desarrollo local como en producción Arc sin cambios de código.

from azure.identity import DefaultAzureCredential
from azure.keyvault.secrets import SecretClient

# Credential chain automática (detecta Arc managed identity)
credential = DefaultAzureCredential()

# Cliente Key Vault sin credenciales explícitas
vault_url = "https://my-vault.vault.azure.net"
client = SecretClient(vault_url=vault_url, credential=credential)

# Obtener secreto
secret = client.get_secret("database-password")
print(f"Secret value: {secret.value}")

Opción 2: ManagedIdentityCredential (explícita)

Fuerza el uso de managed identity exclusivamente, útil cuando no quieres la cadena de fallback.

from azure.identity import ManagedIdentityCredential
from azure.storage.blob import BlobServiceClient

# System-assigned managed identity
credential = ManagedIdentityCredential()

# Cliente Blob Storage
account_url = "https://mystorageaccount.blob.core.windows.net"
blob_service = BlobServiceClient(account_url=account_url, credential=credential)

# Listar containers
for container in blob_service.list_containers():
    print(f"Container: {container.name}")

Opción 3: User-assigned managed identity

Si el servidor tiene múltiples identities user-assigned, especifica el client_id:

from azure.identity import ManagedIdentityCredential

# User-assigned identity con client_id específico
client_id = "12345678-abcd-1234-abcd-1234567890ab"
credential = ManagedIdentityCredential(client_id=client_id)

# Usa este credential con cualquier SDK Azure

Opción 4: MSAL Python (bajo nivel)

Para casos avanzados, msal 1.29.0+ soporta managed identity directamente:

import msal
import requests

# System-assigned managed identity
managed_identity = msal.SystemAssignedManagedIdentity()
app = msal.ManagedIdentityClient(managed_identity, http_client=requests.Session())

# Obtener token para Key Vault
result = app.acquire_token_for_client(resource="https://vault.azure.net")

if "access_token" in result:
    token = result["access_token"]
    print(f"Token adquirido: {token[:20]}...")
else:
    print(f"Error: {result.get('error_description')}")

Ejemplo completo: Leer secreto de Key Vault

Escenario: Script Python en servidor Arc que obtiene credenciales DB desde Key Vault.

#!/usr/bin/env python3
"""
Script: get_db_credentials.py
Descripción: Obtiene credenciales de base de datos desde Azure Key Vault
             usando managed identity del servidor Azure Arc
Requisitos: pip install azure-identity azure-keyvault-secrets
"""

from azure.identity import DefaultAzureCredential
from azure.keyvault.secrets import SecretClient
import sys

def get_secret(vault_name: str, secret_name: str) -> str:
    """
    Obtiene un secreto de Azure Key Vault usando managed identity.

    Args:
        vault_name: Nombre del Key Vault (sin .vault.azure.net)
        secret_name: Nombre del secreto

    Returns:
        Valor del secreto
    """
    try:
        # DefaultAzureCredential detecta automáticamente el entorno Arc
        credential = DefaultAzureCredential()

        vault_url = f"https://{vault_name}.vault.azure.net"
        client = SecretClient(vault_url=vault_url, credential=credential)

        # Obtener secreto
        secret = client.get_secret(secret_name)
        return secret.value

    except Exception as e:
        print(f"Error obteniendo secreto: {e}", file=sys.stderr)
        sys.exit(1)

if __name__ == "__main__":
    # Configuración
    VAULT_NAME = "my-production-vault"
    DB_PASSWORD_SECRET = "db-password"

    # Obtener credencial
    password = get_secret(VAULT_NAME, DB_PASSWORD_SECRET)
    print(f"Credencial obtenida exitosamente (longitud: {len(password)} caracteres)")

    # Usar password para conectar a DB (no imprimir en logs reales)
    # connection_string = f"Server=myserver;Database=mydb;User=admin;Password={password}"

Requisitos previos:

  1. Servidor enrolado en Azure Arc con managed identity habilitada (por defecto).
  2. Identity del servidor con RBAC apropiado en Key Vault:
# Variables
RESOURCE_GROUP="my-rg"
SERVER_NAME="my-arc-server"
VAULT_NAME="my-production-vault"

# Obtener el principal ID de la managed identity
PRINCIPAL_ID=$(az connectedmachine show \
    --resource-group $RESOURCE_GROUP \
    --name $SERVER_NAME \
    --query identity.principalId -o tsv)

# Asignar rol "Key Vault Secrets User" (RBAC)
az role assignment create \
    --assignee $PRINCIPAL_ID \
    --role "Key Vault Secrets User" \
    --scope /subscriptions/$(az account show --query id -o tsv)/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.KeyVault/vaults/$VAULT_NAME

Validar managed identity en el servidor

Antes de ejecutar código Python, verifica que el endpoint IMDS responde:

# Variables de entorno expuestas por el agente Arc
echo $IMDS_ENDPOINT
# Salida esperada: http://localhost:40342

echo $IDENTITY_ENDPOINT
# Salida esperada: http://localhost:40342/metadata/identity/oauth2/token

# Test manual del endpoint (requiere header Metadata:true)
curl -H "Metadata:true" \
    "http://localhost:40342/metadata/identity/oauth2/token?api-version=2020-06-01&resource=https://vault.azure.net"

Respuesta exitosa (JSON con access_token, expires_on, etc.):

{
  "access_token": "eyJ0eXAiOiJKV1QiLCJhbGc...",
  "expires_on": "1700000000",
  "resource": "https://vault.azure.net",
  "token_type": "Bearer"
}

Troubleshooting común

Error: "No managed identity endpoint found"

Causa: El agente Arc no está instalado o no ha configurado el endpoint IMDS.

Solución:

# Verificar estado del agente
sudo azcmagent show

# Si está desconectado, reconectar
sudo azcmagent connect \
    --resource-group "my-rg" \
    --tenant-id "tenant-id" \
    --location "westeurope" \
    --subscription-id "sub-id"

Error: "AADSTS700016: Application not found"

Causa: La managed identity no tiene permisos RBAC sobre el recurso destino.

Solución: Asignar rol apropiado (ver ejemplo de Key Vault arriba). Roles comunes:

  • Key Vault: Key Vault Secrets User (lectura secretos)
  • Storage: Storage Blob Data Reader (lectura blobs)
  • Log Analytics: Log Analytics Reader (consultas)

Error: "CredentialUnavailableError: ManagedIdentityCredential authentication unavailable"

Causa: Ejecutando código fuera de un entorno con managed identity (ej: laptop local).

Solución: DefaultAzureCredential caerá en otros métodos (Azure CLI, variables de entorno). Para testing local:

# Autenticarse con Azure CLI (DefaultAzureCredential lo detectará)
az login

# O usar service principal con variables de entorno
export AZURE_CLIENT_ID="app-id"
export AZURE_CLIENT_SECRET="secret"
export AZURE_TENANT_ID="tenant-id"

Permisos y seguridad

Principio de mínimo privilegio

Asigna solo los permisos necesarios:

# ❌ MAL: Owner en toda la suscripción
az role assignment create --assignee $PRINCIPAL_ID --role "Owner" --subscription $SUB_ID

# ✅ BIEN: Lectura específica en un Key Vault
az role assignment create --assignee $PRINCIPAL_ID --role "Key Vault Secrets User" --scope $VAULT_ID

Control de acceso local

Solo usuarios con privilegios elevados pueden obtener tokens managed identity:

  • Windows: Miembros de Administrators o grupo Hybrid Agent Extension Applications
  • Linux: Miembros del grupo himds
# Linux: Añadir usuario al grupo himds (con precaución)
sudo usermod -aG himds myappuser

# Verificar membership
groups myappuser

Buenas prácticas

  1. Usa DefaultAzureCredential por defecto: Funciona en dev y producción sin cambios.
  2. No almacenes tokens: Deja que el SDK los renueve automáticamente.
  3. Logging seguro: No imprimas tokens o secretos en logs (print(token) ❌).
  4. Auditoría: Habilita diagnostic logs en Key Vault/Storage para rastrear accesos:
az monitor diagnostic-settings create \
    --resource $VAULT_ID \
    --name "audit-logs" \
    --logs '[{"category":"AuditEvent","enabled":true}]' \
    --workspace $LOG_ANALYTICS_WORKSPACE_ID
  1. Timeout y reintentos: El SDK maneja reintentos, pero para scripts long-running:
from azure.core.exceptions import AzureError
import time

def get_secret_with_retry(client, secret_name, max_retries=3):
    for attempt in range(max_retries):
        try:
            return client.get_secret(secret_name).value
        except AzureError as e:
            if attempt < max_retries - 1:
                time.sleep(2 ** attempt)  # Exponential backoff
                continue
            raise

Instalación de dependencias

# Instalar Azure SDK para identidad y servicios específicos
pip install azure-identity azure-keyvault-secrets azure-storage-blob

# Para desarrollo, incluye azure-cli para testing local
pip install azure-cli

Archivo requirements.txt recomendado:

azure-identity>=1.15.0
azure-keyvault-secrets>=4.7.0
azure-storage-blob>=12.19.0

Referencias

Documentación oficial validada:

Microsoft Ignite 2025 Book of News: Tu Guía Rápida a las Novedades

Resumen

El Book of News de Microsoft Ignite es el documento oficial que condensa todos los anuncios del evento más importante de Microsoft para profesionales IT y desarrolladores. En lugar de revisar cientos de sesiones, este recurso te da acceso directo a las innovaciones clave en Azure, IA, seguridad y productividad.

¿Qué es el Book of News?

El Book of News es una publicación digital que Microsoft lanza durante Ignite con:

  • Anuncios consolidados: Todos los launches de productos, servicios y features en un solo lugar
  • Categorización clara: Agrupado por áreas (Azure, Microsoft 365, Security, Copilot, etc.)
  • Enlaces directos: Cada anuncio vincula a documentación técnica, blogs y recursos
  • Formato navegable: Búsqueda, filtros por tema, y versión descargable

Es la fuente autoritativa para equipos técnicos que necesitan evaluar el impacto de las novedades en sus entornos sin esperar a que la información se disperse en múltiples canales.

Para qué sirve

Casos de uso típicos

Arquitectos y decision-makers:

  • Identificar nuevas capacidades para roadmaps técnicos
  • Evaluar deprecations y migraciones necesarias
  • Comparar features GA vs Preview

Equipos DevOps:

  • Detectar mejoras en pipelines (GitHub, Azure DevOps)
  • Revisar nuevos servicios de observabilidad/monitoring
  • Actualizar IaC (Bicep/Terraform) con recursos nuevos

Admins de seguridad:

  • Cambios en Microsoft Defender, Entra ID, Purview
  • Nuevas políticas de compliance y governance
  • Features de Zero Trust y confidential computing

Desarrolladores:

  • SDKs y APIs nuevas (Azure OpenAI, Cosmos DB, etc.)
  • Integraciones con Copilot y herramientas IA
  • Lenguajes y frameworks soportados

Mind Map: Novedades Ignite 2025

Visualización rápida de las áreas clave del evento (generada con NotebookLM):

Mind Map Microsoft Ignite 2025

Este mapa conceptual resume las categorías principales:

  • Azure AI & Copilot: Modelos, agentes, integración empresarial
  • Infrastructure & Compute: VMs, Kubernetes, Arc, networking
  • Data & Analytics: Fabric, Synapse, Cosmos DB, Data Governance
  • Security & Compliance: Entra, Defender, Purview, Zero Trust
  • Developer Tools: GitHub, Visual Studio, Azure DevOps
  • Microsoft 365 & Productivity: Teams, Viva, Loop, features Copilot

Acceso directo

Book of News oficial:
https://news.microsoft.com/ignite-2025-book-of-news/

Recursos complementarios:

Workflow recomendado post-Ignite

# 1. Review Book of News (filtrar tu stack)
# 2. Identifica 3-5 anuncios de alto impacto
# 3. Lee docs técnicas vinculadas
# 4. Crea PoC para features Preview críticos
# 5. Planifica adopción GA en roadmap Q1/Q2
# 6. Comunica cambios a stakeholders (infra, security, dev teams)

Conclusión

El Book of News no es solo un catálogo de marketing: es una herramienta de planning estratégico. Invertir 2-3 horas revisándolo después de Ignite te ahorra semanas de investigación dispersa y te pone adelante en adopción de tecnologías que tus competidores descubrirán meses después.

Marca la URL, revísala trimestralmente (Microsoft actualiza entradas con GAs), y úsala como checklist de innovación para tu organización.

Clonar un Repositorio de GitHub de una organización a otra: Guía Paso a Paso

Resumen

Clonar un repositorio de GitHub entre organizaciones es útil cuando no puedes (o no te conviene) transferir el ownership. Con el enfoque correcto, duplicas todo el historial, ramas y tags en un repo nuevo sin romper nada en el origen.

¿Cuándo clonar y no transferir?

  • Transferir no es posible por políticas de la organización o compliance.
  • Necesitas mantener el repo original activo (p. ej., hard fork interno).
  • Quieres validar/limitar qué migra (código e historial sí; issues/PRs no).

Requisitos

  • Permisos de lectura en el repo origen y de escritura en el repo destino.
  • Repo destino creado y vacío en la organización de destino.
  • Autenticación configurada:
  • SSH: tener clave cargada en GitHub.
  • HTTPS: usar PAT con permisos repo para push.
  • Opcional: gh CLI para crear el repo destino desde terminal.

Warning

git push --mirror sobrescribe refs del remoto destino. Úsalo solo hacia un repo nuevo/vacío o cuando estés seguro de querer reemplazarlo por completo.

Pasos (SSH) — Opción rápida

Este flujo parte de un repo público origen y un repo vacío destino. Define primero las variables y luego ejecuta los comandos.

# Variables
ORG_SOURCE="source-org"
ORG_DEST="dest-org"
REPO_NAME="my-repo"

git clone git@github.com:$ORG_SOURCE/$REPO_NAME
cd $REPO_NAME
git remote rename origin source
git remote add origin git@github.com:$ORG_DEST/$REPO_NAME
git push --mirror origin
git remote remove source

Pasos (HTTPS) — Alternativa con PAT

# Variables
ORG_SOURCE="source-org"
ORG_DEST="dest-org"
REPO_NAME="my-repo"

git clone https://github.com/$ORG_SOURCE/$REPO_NAME.git
cd $REPO_NAME
git remote rename origin source
git remote add origin https://github.com/$ORG_DEST/$REPO_NAME.git
git push --mirror origin
git remote remove source

Al hacer push, Git solicitará usuario/token del PAT con permisos repo.

Opción recomendada (mirror real) — Bare clone

Para evitar empujar refs de seguimiento remotas innecesarias, puedes usar un espejo bare. Es el patrón que recomienda GitHub para duplicar repos.

# Variables
ORG_SOURCE="source-org"
ORG_DEST="dest-org"
REPO_NAME="my-repo"

# 1) Crear un mirror local (bare)
git clone --mirror git@github.com:$ORG_SOURCE/$REPO_NAME

cd $REPO_NAME.git

# 2) Añadir el remoto destino (repo vacío)
git remote add mirror git@github.com:$ORG_DEST/$REPO_NAME

# 3) Empujar todas las refs (branches, tags, notes)
git push --mirror mirror

Crear el repo destino (rápido con gh CLI)

Si aún no existe el repo en la organización destino:

# Autentícate si es necesario
gh auth login

# Variables
ORG_DEST="dest-org"
REPO_NAME="my-repo"

# Crea el repo vacío en la organización de destino
gh repo create "$ORG_DEST/$REPO_NAME" --private --confirm

Validaciones rápidas

  • Verifica ramas y tags en el remoto destino:
git ls-remote --heads origin
git ls-remote --tags origin
  • Abre el repo destino en GitHub y comprueba default branch, tags y commits.

Qué NO migra con este método

  • Issues, PRs, Discussions, Projects, Releases, Wikis y Secrets.
  • Para migrarlos, usa herramientas específicas (GitHub API/gh extensions) o realiza export/import manual según el caso.

Limpieza y siguientes pasos

  • Configura reglas de protección de rama en el repo destino.
  • Revisa y recrea Secrets, variables de entorno y Webhooks.
  • Actualiza pipelines (CI/CD) y badges que apunten al repo nuevo.
  • Considera archivar el repo origen si ya no se pretende usar.

Buenas prácticas

  • Usa SSH para entornos corporativos; HTTPS+PAT para automatizaciones.
  • Documenta la operación (fecha, responsables, commit de verificación).
  • Repite el proceso en un repo de prueba antes de hacerlo en producción.
  • Si el repo usa Git LFS, verifica que los objetos LFS estén correctamente en el destino.

Referencias

  • Duplicar un repositorio: https://docs.github.com/en/repositories/creating-and-managing-repositories/duplicating-a-repository
  • Transferir un repositorio: https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository
  • Autenticación SSH en GitHub: https://docs.github.com/en/authentication/connecting-to-github-with-ssh
  • gh CLI (gh repo create): https://cli.github.com/manual/gh_repo_create

Azure Storage Priority Replication: Replicación acelerada con SLA

Resumen

Priority Replication acelera la replicación de datos en Azure Storage con SLA de 15 minutos para cumplir requisitos estrictos de RPO (Recovery Point Objective). Disponible para geo-redundancia (GRS/GZRS) y Object Replication entre cuentas.

¿Qué es Priority Replication?

Priority Replication es una capacidad de Azure Storage que prioriza el tráfico de replicación y proporciona garantías SLA para sincronización de datos entre regiones. Diseñada para escenarios donde el tiempo de replicación es crítico para cumplimiento y continuidad de negocio.

Dos variantes disponibles:

  1. Geo Priority Replication: Para cuentas con GRS/GZRS (redundancia entre regiones)
  2. Object Replication Priority: Para políticas de Object Replication entre cuentas

SLA clave: 99.0% del mes de facturación con Last Sync Time (LST) ≤ 15 minutos

Geo Priority Replication

Acelera la replicación entre región primaria y secundaria para cuentas con GRS (Geo-Redundant Storage) o GZRS (Geo-Zone-Redundant Storage).

Disponibilidad y limitaciones

Regiones soportadas: Todas las regiones públicas con GRS/GZRS excepto:

  • West India
  • Switzerland West

Requisitos para GZRS:

  • Región debe soportar Availability Zones
  • Región debe tener paired region

Beneficios principales

  1. RPO garantizado: Confianza en tiempo de sincronización para cumplimiento
  2. Failover sin sorpresas: LST predecible si ocurre failover no planificado
  3. Monitoreo mejorado: Telemetría detallada vía Azure Monitor
  4. SLA respaldado: Garantía de 99.0% del mes con lag ≤ 15 minutos

Exclusiones del SLA

El SLA NO aplica en estos casos:

Por tipo de blob:

  • Page blobs y append blobs (SLA solo para Block Blobs)
  • Cuentas con llamadas API de Page/Append Blob en últimos 30 días
  • Cuentas con features que crean estos blobs (Change Feed, Object Replication, logs en Azure Monitor)

Por condición de cuenta:

  • LST > 15 minutos durante habilitación de la feature
  • Transfer rate > 1 Gbps con backlog pendiente
  • 100 CopyBlob requests/segundo con backlog pendiente

Por eventos operacionales:

  • Unplanned failover (desactiva automáticamente la feature)
  • Durante conversión GRS ↔ GZRS (no afecta si se mantiene dentro de guardrails)

Habilitar Geo Priority Replication

Durante creación de cuenta nueva

Azure CLI:

# Variables
RESOURCE_GROUP="rg-storage-prod"
STORAGE_ACCOUNT="stgeopriorityprod"
LOCATION="westeurope"

# Crear cuenta con Geo Priority Replication
az storage account create \
  --name $STORAGE_ACCOUNT \
  --resource-group $RESOURCE_GROUP \
  --location $LOCATION \
  --sku Standard_GRS \
  --enable-blob-geo-priority-replication true

Azure PowerShell:

# Variables
$rgName = "rg-storage-prod"
$storageAccountName = "stgeopriorityprod"
$location = "westeurope"

# Crear cuenta con Geo Priority Replication
$account = New-AzStorageAccount `
  -ResourceGroupName $rgName `
  -StorageAccountName $storageAccountName `
  -SkuName Standard_GRS `
  -Location $location `
  -EnableBlobGeoPriorityReplication $true
En cuentas existentes

Habilitar:

# Azure CLI
az storage account update \
  --name $STORAGE_ACCOUNT \
  --resource-group $RESOURCE_GROUP \
  --enable-blob-geo-priority-replication true
# PowerShell
Set-AzStorageAccount `
  -ResourceGroupName $rgName `
  -StorageAccountName $storageAccountName `
  -EnableBlobGeoPriorityReplication $true

Deshabilitar:

# Azure CLI
az storage account update \
  --name $STORAGE_ACCOUNT \
  --resource-group $RESOURCE_GROUP \
  --enable-blob-geo-priority-replication false
# PowerShell
Set-AzStorageAccount `
  -ResourceGroupName $rgName `
  -StorageAccountName $storageAccountName `
  -EnableBlobGeoPriorityReplication $false

Monitorear cumplimiento con Geo Blob Lag

Métrica nueva (Preview): Geo Blob Lag - segundos desde última copia completa entre regiones.

Habilitar preview:

  1. Azure Portal → Subscriptions → Preview features
  2. Feature: AllowGeoPriorityReplicationMetricsInPortal
  3. Provider: Microsoft.Storage

Acceder a métricas:

  • Portal: Storage Account → Redundancy o Metrics
  • Métrica: Geo Blob Lag metric (preview)

Tiempo de activación

Las métricas pueden tardar hasta 24 horas en aparecer tras registrar la feature.

Uso para validar SLA:

Monitorear que el lag se mantiene ≤ 15 minutos durante el 99% del mes. Si excede, ese período se excluye del SLA.

Object Replication Priority

Acelera la replicación entre cuentas de storage usando Object Replication policies. Garantiza que 99.0% de objetos se replican en ≤ 15 minutos cuando origen y destino están en el mismo continente.

Disponibilidad

Regiones soportadas: Todas las regiones públicas excepto:

  • West India
  • Switzerland West

Portal experience (Preview):

  • Feature: AllowPriorityObjectReplicationInPortal
  • Provider: Microsoft.Storage

Beneficios principales

  1. SLA de rendimiento: 99% de objetos en ≤ 15 minutos (mismo continente)
  2. Métricas automáticas: Activación automática de OR metrics
  3. Visibilidad mejorada: Time buckets (0-5 min, 5-10 min, >24h)
  4. DR garantizado: Confianza en tiempos para disaster recovery

Exclusiones del SLA

El SLA NO aplica a:

Por características del objeto:

  • Objetos > 5 GB
  • Objetos modificados > 10 veces/segundo

Por geografía:

  • Origen y destino en continentes diferentes

Por tamaño de cuenta:

  • Cuentas > 5 PB
  • Cuentas con > 10 mil millones de blobs

Por condiciones operativas:

  • Transfer rate > 1 Gbps con backlog pendiente
  • 1,000 PUT/DELETE ops/segundo con backlog pendiente

  • Durante replicación de blobs existentes tras crear/actualizar policy

Limitación de políticas

Solo 1 policy por cuenta origen puede tener Priority Replication habilitado (aunque la cuenta soporte hasta 2 policies).

Habilitar Object Replication Priority

Durante creación de nueva policy

Azure CLI:

# Variables
SRC_ACCOUNT="stgsourceprod"
DST_ACCOUNT="stgdestinationdr"
SRC_CONTAINER="data"
DST_CONTAINER="data-replica"

# Crear policy con Priority Replication
az storage account or-policy create \
  --account-name $DST_ACCOUNT \
  --source-account $SRC_ACCOUNT \
  --destination-container $DST_CONTAINER \
  --source-container $SRC_CONTAINER \
  --min-creation-time "2025-11-11T00:00:00Z" \
  --enable-metrics true \
  --priority-replication true

Azure PowerShell:

# Variables
$rgName = "rg-storage-prod"
$srcAccountName = "stgsourceprod"
$dstAccountName = "stgdestinationdr"
$srcAccountResourceID = "/subscriptions/{sub-id}/resourceGroups/{rg}/providers/Microsoft.Storage/storageAccounts/$srcAccountName"
$srcContainer = "data"
$dstContainer = "data-replica"

# Crear regla y policy con Priority Replication
$rule = New-AzStorageObjectReplicationPolicyRule `
  -SourceContainer $srcContainer `
  -DestinationContainer $dstContainer

$dstPolicy = Set-AzStorageObjectReplicationPolicy `
  -ResourceGroupName $rgName `
  -StorageAccountName $dstAccountName `
  -PolicyId default `
  -SourceAccount $srcAccountResourceID `
  -Rule $rule `
  -EnableMetric $true `
  -EnablePriorityReplication $true

# Aplicar policy en cuenta origen
$srcPolicy = Set-AzStorageObjectReplicationPolicy `
  -ResourceGroupName $rgName `
  -StorageAccountName $srcAccountName `
  -InputObject $dstPolicy

# Verificar habilitación
$srcPolicy.PriorityReplication.Enabled
En policies existentes

Habilitar:

# Azure CLI
az storage account or-policy update \
  --account-name $DST_ACCOUNT \
  --source-account $SRC_ACCOUNT \
  --destination-container $DST_CONTAINER \
  --source-container $SRC_CONTAINER \
  --min-creation-time "2025-11-11T00:00:00Z" \
  --enable-metrics true \
  --priority-replication true
# PowerShell
$dstPolicy = Set-AzStorageObjectReplicationPolicy `
  -ResourceGroupName $rgName `
  -StorageAccountName $dstAccountName `
  -PolicyId default `
  -SourceAccount $srcAccountResourceID `
  -Rule $rule `
  -EnableMetric $true `
  -EnablePriorityReplication $true

$srcPolicy = Set-AzStorageObjectReplicationPolicy `
  -ResourceGroupName $rgName `
  -StorageAccountName $srcAccountName `
  -InputObject $dstPolicy

# Confirmar
$srcPolicy.PriorityReplication.Enabled

Deshabilitar:

# Azure CLI
az storage account or-policy update \
  --account-name $DST_ACCOUNT \
  --source-account $SRC_ACCOUNT \
  --destination-container $DST_CONTAINER \
  --source-container $SRC_CONTAINER \
  --min-creation-time "2025-11-11T00:00:00Z" \
  --enable-metrics true \
  --priority-replication false
# PowerShell - cambiar a $false
$dstPolicy = Set-AzStorageObjectReplicationPolicy `
  -ResourceGroupName $rgName `
  -StorageAccountName $dstAccountName `
  -PolicyId default `
  -SourceAccount $srcAccountResourceID `
  -Rule $rule `
  -EnableMetric $true `
  -EnablePriorityReplication $false

Monitorear SLA de Object Replication

Cuando OR Priority Replication está habilitada, OR metrics se activan automáticamente.

Métricas disponibles:

Métrica Descripción Dimensiones
Operations pending for replication Total de operaciones pendientes Time buckets
Bytes pending for replication Bytes pendientes de replicar Time buckets

Time buckets:

  • 0-5 minutos
  • 5-10 minutos
  • 10-15 minutos
  • 15-30 minutos
  • 30 minutos - 2 horas
  • 2-8 horas
  • 8-24 horas
  • 24 horas

Validar SLA:

Monitorear que buckets grandes (>15 min) estén en cero o cerca de cero durante el mes.

Verificar replicación de blob individual:

# Comprobar estado de replicación
az storage blob show \
  --account-name $SRC_ACCOUNT \
  --container-name $SRC_CONTAINER \
  --name myblob.txt \
  --query 'objectReplicationSourceProperties[].rules[].status' \
  --output tsv \
  --auth-mode login

Estado Completed = blob disponible en destino garantizado.

Precios

Geo Priority Replication

Inicio de facturación: 1 de enero de 2026

  • Cuentas existentes con feature habilitada
  • Cuentas nuevas que habiliten la feature

Coste: Por GB (consultar Azure Storage Pricing)

Object Replication Priority

Coste: Por GB de nuevo ingress

Costes adicionales estándar (igual que OR normal):

  • Transacciones de lectura (origen)
  • Transacciones de escritura (destino)
  • Network egress

Facturación post-desactivación

Ambas features facturan durante 30 días adicionales tras deshabilitarlas.

Casos de uso

Cumplimiento normativo estricto

Escenario: Sector financiero/salud con regulaciones de RPO < 15 minutos.

# Storage account para datos regulados
az storage account create \
  --name stgcomplianceprod \
  --resource-group rg-compliance \
  --location westeurope \
  --sku Standard_GZRS \
  --enable-blob-geo-priority-replication true \
  --tags "Compliance=Financial" "RPO=15min"

Validación:

  • Monitorear Geo Blob Lag diariamente
  • Alertas si lag > 10 minutos
  • Reportes mensuales de LST para auditorías

Disaster Recovery con RTO/RPO garantizados

Escenario: Aplicación crítica con SLA de DR < 1 hora.

# Source: Producción (North Europe)
SRC_ACCOUNT="stgappprodneu"
# Destination: DR (West Europe)
DST_ACCOUNT="stgappdrweu"

# Policy OR con Priority Replication
az storage account or-policy create \
  --account-name $DST_ACCOUNT \
  --source-account $SRC_ACCOUNT \
  --destination-container app-data \
  --source-container app-data \
  --min-creation-time "2025-11-11T00:00:00Z" \
  --enable-metrics true \
  --priority-replication true

Beneficio: Confianza en que datos están en DR site en ≤ 15 minutos.

Arquitectura multi-región con HA

Escenario: Servicio global con réplicas en múltiples continentes.

graph LR
    A[Primary
West Europe
GRS+Priority] --> B[Secondary
North Europe
Paired region] A --> C[OR Priority
East US
Read replica] A --> D[OR Priority
Southeast Asia
Read replica] style A fill:#0078d4,color:#fff style B fill:#50e6ff,color:#000 style C fill:#50e6ff,color:#000 style D fill:#50e6ff,color:#000

Configuración:

  1. Primary (West Europe): GRS + Geo Priority Replication
  2. Secondary paired (North Europe): Automático con GRS
  3. US replica: Object Replication Priority (mismo continente que origen - garantiza SLA)
  4. Asia replica: Object Replication normal (diferente continente - sin SLA)

Sincronización de entornos Dev/Test

Escenario: Copiar producción a staging con datos frescos.

# Policy OR Priority: Prod → Staging
$rule = New-AzStorageObjectReplicationPolicyRule `
  -SourceContainer "production-data" `
  -DestinationContainer "staging-data"

$policy = Set-AzStorageObjectReplicationPolicy `
  -ResourceGroupName "rg-prod" `
  -StorageAccountName "stgstaging" `
  -PolicyId default `
  -SourceAccount "/subscriptions/{id}/resourceGroups/rg-prod/providers/Microsoft.Storage/storageAccounts/stgprod" `
  -Rule $rule `
  -EnableMetric $true `
  -EnablePriorityReplication $true

Beneficio: Staging siempre con datos < 15 minutos antiguos.

Arquitectura recomendada

Patrón Geo-Redundant + Object Replication

graph TB
    subgraph "Región Primaria: West Europe"
        A[Storage Account
GRS + Geo Priority] A1[Block Blobs
Producción] A --> A1 end subgraph "Paired Region: North Europe" B[Secondary Storage
Automático GRS] B1[Block Blobs
Replica GRS] B --> B1 end subgraph "Región DR: East US" C[Storage Account
OR Destination] C1[Replica
OR Priority] C --> C1 end subgraph "Región Analítica: West US" D[Storage Account
OR Destination] D1[Replica
OR Normal] D --> D1 end A1 -->|Geo Replication
LST ≤ 15min SLA| B1 A1 -->|OR Priority
99% ≤ 15min| C1 A1 -->|OR Standard
Async| D1 style A fill:#0078d4,color:#fff style B fill:#50e6ff,color:#000 style C fill:#50e6ff,color:#000 style D fill:#e6e6e6,color:#000

Capas de protección:

  1. Local redundancy: ZRS/LRS en región primaria
  2. Geo redundancy con SLA: Geo Priority Replication a paired region
  3. DR cross-region con SLA: OR Priority a región DR (mismo continente)
  4. Analítica/archive: OR estándar a región de análisis

Buenas prácticas

Diseño de cuenta

  1. Segregar por SLA:
  2. Cuentas con Priority Replication: Solo Block Blobs
  3. Cuentas con Page/Append Blobs: Sin Priority Replication

  4. Evitar exclusiones del SLA:

  5. No habilitar Change Feed si no es necesario
  6. No activar diagnostic logs a storage en cuenta con Priority Replication
  7. Usar cuentas dedicadas para logs (sin Priority)

  8. Tagging para governance:

az storage account create \
  --name $STORAGE_ACCOUNT \
  --resource-group $RESOURCE_GROUP \
  --tags \
    "PriorityReplication=Enabled" \
    "SLA-RPO=15min" \
    "CostCenter=IT-Production" \
    "Compliance=Required"

Monitoreo proactivo

Alertas recomendadas:

# Alert si Geo Blob Lag > 10 minutos (margen de seguridad)
az monitor metrics alert create \
  --name "High-Geo-Lag-Alert" \
  --resource $STORAGE_ACCOUNT_ID \
  --condition "avg GeoBlobLag > 600" \
  --window-size 5m \
  --evaluation-frequency 1m \
  --action-group-id $ACTION_GROUP_ID

Dashboard de cumplimiento:

  • Geo Blob Lag (hourly average)
  • OR pending operations por time bucket
  • Throughput vs 1 Gbps threshold
  • CopyBlob operations vs 100 ops/sec threshold

Optimización de costes

  1. Evaluar necesidad real de SLA:
  2. Priority Replication: Workloads críticos con RPO estricto
  3. GRS/OR estándar: Workloads tolerantes a lag > 15 min

  4. Lifecycle management:

{
  "rules": [
    {
      "name": "tierToCool",
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": ["blockBlob"]
        },
        "actions": {
          "baseBlob": {
            "tierToCool": {
              "daysAfterModificationGreaterThan": 30
            }
          }
        }
      }
    }
  ]
}

Datos en Cool tier siguen replicándose con Priority pero con menor coste de storage.

  1. Revisar policies OR:
  2. Una sola policy con Priority Replication por cuenta origen
  3. Otras policies: OR estándar

Seguridad

  1. Network security:
# Restringir acceso a VNETs
az storage account update \
  --name $STORAGE_ACCOUNT \
  --resource-group $RESOURCE_GROUP \
  --default-action Deny

az storage account network-rule add \
  --account-name $STORAGE_ACCOUNT \
  --resource-group $RESOURCE_GROUP \
  --vnet-name my-vnet \
  --subnet app-subnet
  1. Encryption:
  2. Customer-managed keys (CMK) para datos en reposo
  3. HTTPS obligatorio para datos en tránsito

  4. RBAC granular:

  5. Storage Blob Data Contributor: Apps que escriben
  6. Storage Blob Data Reader: Apps DR que solo leen
  7. Storage Account Contributor: Operadores que gestionan replicación

Troubleshooting

Geo Blob Lag > 15 minutos

Diagnóstico:

# Ver LST actual
az storage account show \
  --name $STORAGE_ACCOUNT \
  --resource-group $RESOURCE_GROUP \
  --query "geoReplicationStats.lastSyncTime" \
  --output tsv

# Comprobar throughput
az monitor metrics list \
  --resource $STORAGE_ACCOUNT_ID \
  --metric "Egress" \
  --start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ) \
  --interval PT5M \
  --aggregation Average

Causas comunes:

  1. Throughput > 1 Gbps: Reducir ingress o escalar a múltiples cuentas
  2. CopyBlob > 100 ops/sec: Distribuir copies en el tiempo
  3. Page/Append blobs: Revisar si hay features creando estos blobs inadvertidamente

OR metrics no aparecen

Validaciones:

# Comprobar que metrics están habilitadas
$policy = Get-AzStorageObjectReplicationPolicy `
  -ResourceGroupName $rgName `
  -StorageAccountName $srcAccountName `
  -PolicyId $policyId

$policy.EnableMetrics
$policy.PriorityReplication.Enabled

Solución:

  • Esperar 24 horas tras habilitar
  • Verificar que hay tráfico de replicación activo
  • Comprobar que policy está en estado Enabled

SLA no se cumple

Checklist de elegibilidad:

  • Solo Block Blobs (no Page/Append)
  • Sin llamadas API Page/Append en últimos 30 días
  • Throughput < 1 Gbps
  • CopyBlob < 100 ops/sec
  • LST ≤ 15 min al habilitar feature
  • OR: Origen y destino en mismo continente
  • OR: Objetos < 5 GB
  • OR: No más de 10 modificaciones/segundo por objeto

Validar con Azure Support:

Abrir caso incluyendo:

  • Storage Account ID
  • Período de incumplimiento (fechas/horas)
  • Métricas de Geo Blob Lag o OR pending operations
  • Confirmación de elegibilidad (checklist anterior)

Referencias

Configurar VSCode con GitHub Copilot: Guía práctica

Resumen

Guía práctica para configurar GitHub Copilot en VSCode: custom instructions, prompt files, generación automática de conventional commits y uso de modos Ask/Edit/Agent para maximizar productividad en proyectos Azure/DevOps.

¿Qué es GitHub Copilot?

GitHub Copilot es un asistente de código basado en IA que sugiere código, genera tests, documenta funciones y responde preguntas técnicas directamente en tu editor. En VSCode, Copilot ofrece:

  • Completado de código inline: Sugerencias mientras escribes
  • Chat interactivo: Conversaciones sobre tu código
  • Generación de commits: Mensajes siguiendo conventional commits
  • Modos de trabajo: Ask, Edit y Agent para diferentes escenarios

Instalación en VSCode

Requisitos previos:

  • VSCode 1.99 o superior
  • Cuenta GitHub con acceso a Copilot (Copilot Free disponible)

Pasos de instalación:

  1. Abrir VSCode
  2. Ir a Extensions (Ctrl+Shift+X)
  3. Buscar "GitHub Copilot"
  4. Instalar dos extensiones:
  5. GitHub Copilot (autocompletado)
  6. GitHub Copilot Chat (chat interactivo)

Autenticación:

# VSCode solicitará autenticación con GitHub
# Alternativamente desde Command Palette (Ctrl+Shift+P):
GitHub Copilot: Sign In

Custom Instructions

Las instrucciones personalizadas permiten definir reglas y contexto que Copilot aplicará automáticamente, eliminando la necesidad de repetir el mismo contexto en cada prompt.

Tipos de archivos de instrucciones

VSCode soporta tres tipos de archivos Markdown para instrucciones:

1. .github/copilot-instructions.md (instrucciones globales del workspace)

  • Se aplica automáticamente a todas las conversaciones
  • Un único archivo en la raíz del repositorio
  • Compartido con todo el equipo vía Git

2. .instructions.md (instrucciones específicas por archivo/tarea)

  • Múltiples archivos para diferentes contextos
  • Usa frontmatter applyTo con glob patterns
  • Puede ser workspace o user-level (sincronizable)

3. AGENTS.md (experimental, para múltiples agentes IA)

  • En la raíz o subfolders del workspace
  • Útil si trabajas con varios agentes IA
  • Requiere habilitar chat.useAgentsMdFile

Estructura del proyecto:

your-repo/
├── .github/
│   ├── copilot-instructions.md    ← Global workspace
│   ├── instructions/               ← Instrucciones específicas
│   │   ├── python.instructions.md
│   │   └── terraform.instructions.md
│   └── prompts/                    ← Prompts reutilizables
├── AGENTS.md                        ← Para múltiples agentes (experimental)
├── src/
└── README.md

Ejemplo de instrucciones para proyectos Azure/DevOps:

# Instrucciones para GitHub Copilot

## Contexto del proyecto

Este repositorio contiene infraestructura Azure gestionada con Terraform y CI/CD con GitHub Actions.

## Convenciones de código

### Terraform

- Usar módulos para componentes reutilizables
- Variables en `variables.tf`, outputs en `outputs.tf`
- Naming: `<recurso>-<entorno>-<región>` (ejemplo: `st-prod-weu`)
- Tags obligatorios: Environment, Owner, CostCenter

### Python

- PEP 8 para estilo de código
- Type hints obligatorios en funciones públicas
- Docstrings en formato Google
- Tests con pytest, coverage mínimo 80%

### Commits

- Seguir conventional commits: `type(scope): description`
- Tipos permitidos: feat, fix, docs, chore, refactor, test
- Scope debe indicar área afectada: terraform, github-actions, scripts

## Seguridad

- NUNCA incluir credenciales hardcoded
- Usar Azure Key Vault para secretos
- Managed Identities sobre service principals
- Mínimo privilegio en roles RBAC

## Referencias

- Validar recursos Azure contra docs oficiales
- Seguir Azure Well-Architected Framework
- Bicep/Terraform: sintaxis actualizada

Habilitar Custom Instructions en VSCode

Opción 1: Habilitar en Settings

{
  "github.copilot.chat.codeGeneration.useInstructionFiles": true
}

Opción 2: Generar automáticamente desde tu workspace

VSCode puede analizar tu código y generar instrucciones que coincidan con tus prácticas:

  1. Chat view → Configure ChatGenerate Instructions
  2. Revisar y editar el archivo generado
  3. Guardar en .github/copilot-instructions.md

Validación: Cuando Copilot use las instrucciones, aparecerá el archivo en la lista de "References" de la respuesta.

Instrucciones específicas con .instructions.md

Además del archivo global, puedes crear instrucciones específicas para lenguajes, frameworks o tareas.

Formato de .instructions.md

Estructura:

---
description: "Descripción mostrada al hacer hover"
applyTo: "**/*.py"  # Glob pattern (relativo al workspace root)
---

# Instrucciones específicas para Python

- Seguir PEP 8
- Type hints obligatorios
- Docstrings en formato Google

Ejemplo: Instrucciones para Terraform

Archivo: .github/instructions/terraform.instructions.md

---
description: "Terraform coding standards"
applyTo: "**/*.tf,**/*.tfvars"
---

# Terraform Best Practices

- Usar módulos para componentes reutilizables
- Variables en variables.tf, outputs en outputs.tf
- Naming convention: `<resource>-<environment>-<region>`
- Tags obligatorios: Environment, Owner, CostCenter
- Encryption habilitado por defecto
- Validar con `terraform validate` y `tflint`

Crear instrucciones desde VSCode

Comando: Chat: New Instructions File (Ctrl+Shift+P)

  1. Elegir ubicación:
  2. Workspace: .github/instructions/ (compartido vía Git)
  3. User: Perfil de usuario (sincronizable entre dispositivos)
  4. Nombrar archivo (ej: python.instructions.md)
  5. Definir applyTo pattern en frontmatter
  6. Escribir instrucciones en Markdown

Adjuntar manualmente: En Chat view → botón +Instructions → seleccionar archivo

Sincronizar instrucciones de usuario

Las instrucciones user-level pueden sincronizarse entre dispositivos:

  1. Habilitar Settings Sync
  2. Ctrl+Shift+PSettings Sync: Configure
  3. Seleccionar Prompts and Instructions

Prompt Files (.github/prompts)

Los prompt files permiten crear plantillas de prompts reutilizables compartibles con el equipo.

Crear prompts reutilizables

Ejemplo: Prompt para generar Terraform modules

Archivo: .github/prompts/terraform-module.prompt.md

Crea un módulo Terraform para #selection siguiendo estas reglas:

1. Estructura estándar:
   - `main.tf`: recursos principales
   - `variables.tf`: inputs con validation
   - `outputs.tf`: valores exportados
   - `versions.tf`: provider constraints
   - `README.md`: documentación

2. Convenciones:
   - Variables: descripción, tipo, validación con condition
   - Outputs: descripción clara del valor exportado
   - Tags: usar merge() con var.tags

3. Seguridad:
   - Encryption habilitado por defecto
   - HTTPS obligatorio para endpoints
   - Logging habilitado

4. Documentación:
   - README con ejemplos de uso
   - Terraform-docs compatible

Archivo: .github/prompts/fix-security.prompt.md

Analiza #file en busca de problemas de seguridad:

- Credenciales hardcoded
- Endpoints HTTP (deben ser HTTPS)
- Secretos en logs
- Permisos excesivos en RBAC
- Resources sin encryption
- Network security groups demasiado permisivos

Proporciona fix aplicando principio de mínimo privilegio y Zero Trust.

Usar Prompt Files

En Copilot Chat:

# Referenciar prompt file
#prompt:terraform-module

# Combinar con referencias
#prompt:fix-security #file:main.tf

# Agregar contexto adicional
#prompt:terraform-module para Azure Storage con lifecycle policies

Desde UI:

  1. Abrir Copilot Chat (Ctrl+Alt+I)
  2. Click en botón +
  3. Seleccionar "Prompt Files"
  4. Elegir prompt deseado

Conventional Commits con Copilot

GitHub Copilot puede generar mensajes de commit siguiendo conventional commits automáticamente.

Configuración para Conventional Commits

Opción 1: Settings específico para commits (recomendado)

Desde VS Code 1.102+, usar setting dedicado:

{
  "github.copilot.chat.commitMessageGeneration.instructions": [
    {
      "text": "Seguir Conventional Commits 1.0.0: <type>(<scope>): <description>"
    },
    {
      "file": ".github/instructions/commit-standards.md"
    }
  ]
}

Opción 2: Agregar a .github/copilot-instructions.md

## Git Commits

Todos los commits deben seguir Conventional Commits 1.0.0:

**Formato**: `<type>(<scope>): <description>`

**Types permitidos**:

- `feat`: Nueva funcionalidad
- `fix`: Corrección de bug
- `docs`: Cambios en documentación
- `chore`: Tareas de mantenimiento (deps, config)
- `refactor`: Refactorización sin cambio funcional
- `test`: Añadir o modificar tests
- `ci`: Cambios en CI/CD
- `perf`: Mejoras de performance

**Scope**: Área del proyecto afectada (terraform, github-actions, scripts, docs)

**Ejemplos**:

```text
feat(terraform): add Azure Front Door module
fix(github-actions): correct OIDC authentication
docs(readme): update deployment instructions
chore(deps): bump terraform-azurerm to 4.0

Breaking changes: Usar ! o footer BREAKING CHANGE:

feat(terraform)!: migrate to azurerm 4.0

BREAKING CHANGE: provider azurerm 3.x no longer supported

Generar commits con Copilot

En Source Control panel de VSCode:

  1. Hacer cambios en archivos
  2. Stage changes
  3. Click en icono ✨ (Sparkle) en message box
  4. Copilot genera mensaje siguiendo conventional commits

Desde terminal con Git:

# Copilot CLI (requiere instalación adicional)
gh copilot suggest "git commit message for staged changes"

Ejemplo de mensaje generado:

feat(terraform): add network security group for AKS

- Create NSG with default deny rules
- Allow only required ports (443, 80)
- Associate to AKS subnet
- Add diagnostic settings for logging

Modos de Copilot Chat

Copilot ofrece tres modos de trabajo según el tipo de tarea.

Ask Mode (Modo pregunta)

Cuándo usar: Consultas, explicaciones, búsqueda de información.

Características:

  • Responde en el panel de chat
  • No modifica archivos
  • Proporciona ejemplos de código copiables

Ejemplos:

# Explicar código
Explica qué hace #selection

# Mejores prácticas
¿Cuáles son las mejores prácticas para Azure Storage lifecycle policies?

# Comparar opciones
Diferencia entre Azure Container Apps y AKS

# Troubleshooting
¿Por qué falla este módulo de Terraform? #file:main.tf

Edit Mode (Modo edición)

Cuándo usar: Modificar código existente, refactorizar.

Características:

  • Propone cambios con preview diff
  • Puedes aceptar/rechazar modificaciones
  • Trabaja en archivos abiertos

Activar Edit Mode:

  1. Seleccionar código
  2. Ctrl+I (inline chat)
  3. Escribir instrucción

Ejemplos:

# Refactor
Refactoriza #selection para usar módulos reutilizables

# Optimizar
Optimiza este loop para mejor performance

# Agregar tests
Genera unit tests para #selection usando pytest

# Documentar
Agrega docstrings a todas las funciones en #file

Agent Mode (Modo agente)

Cuándo usar: Tareas complejas multi-archivo, workflows completos.

Características:

  • Ejecuta acciones en todo el workspace
  • Crea/edita múltiples archivos
  • Ejecuta comandos en terminal
  • Requiere confirmación en pasos críticos

Activar Agent Mode:

  1. Abrir Copilot Chat
  2. Selector de modo → Agent
  3. Confirmar modo activo

Habilitar Agent Mode:

VSCode Settings (Ctrl+,):

{
  "chat.agent.enabled": true,
  "chat.agent.maxRequests": 128
}

Ejemplos de tareas con Agent Mode:

# Crear proyecto completo
Crea un proyecto Terraform para desplegar Azure Container Apps con:
- Virtual Network con subnets
- Azure Container Registry
- Log Analytics Workspace
- Application Insights
- GitHub Actions workflow para CI/CD

# Migrar código
Migra todos los recursos en #folder de azurerm 3.x a 4.x

# Generar documentación
Genera README.md completo para este repositorio incluyendo:
- Descripción
- Arquitectura (diagrama Mermaid)
- Prerequisites
- Deployment steps
- Troubleshooting

# Implementar tests
Crea suite completa de tests para todos los módulos Terraform

Best Practices para Agent Mode:

  1. Prompts granulares: Dividir tareas grandes en pasos pequeños
  2. Permitir que Copilot trabaje: Dejar que ejecute tareas en vez de hacerlas manualmente
  3. Revisar cambios: Validar modificaciones antes de commit
  4. Configurar auto-approve (opcional):
{
  "chat.tools.autoApprove": true
}

Slash Commands

Comandos rápidos para tareas comunes sin escribir prompts largos.

Command Descripción Ejemplo
/doc Generar documentación Seleccionar función → /doc
/explain Explicar código Seleccionar bloque → /explain
/fix Proponer correcciones Seleccionar error → /fix
/tests Generar unit tests Seleccionar función → /tests using pytest
/optimize Optimizar performance Seleccionar loop → /optimize
/generate Generar código nuevo /generate Azure Bicep for Storage Account

Uso combinado con contexto:

# Con archivos
/explain #file:main.tf

# Con selección
/tests #selection using XUnit

# Con scope
/fix the authentication logic in #file:auth.py

Herramientas de Agent Mode para Azure

Cuando trabajas con recursos Azure, Agent Mode tiene herramientas específicas.

Verificar herramientas disponibles:

What are your tools?

Herramientas Azure:

  • Azure CLI tools: Generar comandos az
  • Terraform tools: Crear/validar configuraciones
  • GitHub Actions tools: Generar workflows

Ejemplo práctico:

# Generar comando Azure CLI
¿Cuál es el comando az para listar todas mis storage accounts ordenadas por región?

Copilot genera:

az storage account list --query "sort_by([], &location)[].{Name:name, Location:location}" --output table

Mejores prácticas

Contexto efectivo

Proporcionar referencias específicas:

❌ MALO:
"Explica este código"

✅ BUENO:
"Explica #selection enfocándote en el flujo de autenticación OIDC"

Usar scope adecuado:

# Archivo completo
#file:main.tf

# Función específica
#selection

# Múltiples archivos
#file:variables.tf #file:outputs.tf

# Workspace
#codebase (usa con precaución, puede ser lento)

Organización de instrucciones

Por archivo de instrucciones:

  • Global (.github/copilot-instructions.md): Principios generales del proyecto
  • Por lenguaje (.github/instructions/python.instructions.md): Standards específicos
  • Por framework (.github/instructions/terraform.instructions.md): Convenciones del stack
  • Por tarea (.github/instructions/security-review.instructions.md): Workflows específicos

Usar applyTo patterns efectivos:

---
applyTo: "**/*.{ts,tsx}"  # TypeScript y React
---

---
applyTo: "src/backend/**"  # Backend folder
---

---
applyTo: "terraform/**/*.tf"  # Solo Terraform files
---

Seguridad

Validar código generado:

  • No confiar ciegamente en sugerencias
  • Revisar permisos y roles RBAC
  • Verificar que no expone credenciales
  • Comprobar configuraciones de red

Ejemplo de validación:

Analiza #file:main.tf y verifica:
1. ¿Hay credenciales hardcoded?
2. ¿Todos los recursos tienen encryption habilitado?
3. ¿Network security groups siguen principio de mínimo privilegio?
4. ¿Están definidos todos los tags obligatorios?

Iteración incremental

Trabajar por pasos:

# ❌ Prompt demasiado amplio:
"Crea infraestructura completa para microservicios en Azure"

# ✅ Iteración incremental:
# Paso 1:
"Crea networking base: VNET con 3 subnets (app, data, management)"

# Paso 2:
"Agrega Azure Container Apps environment con internal VNET"

# Paso 3:
"Configura Application Gateway con WAF"

Validación contra docs oficiales

Copilot puede estar desactualizado. Validar contra documentación oficial:

# Verificar sintaxis actualizada
Muestra la sintaxis actual de azurerm_storage_account en Terraform 1.9

# Contrastar con docs
¿Esta configuración sigue las mejores prácticas de Azure Well-Architected Framework para seguridad?

Tips oficiales (VSCode)

Según documentación oficial:

  1. Instrucciones cortas y autocontenidas: Una declaración por instrucción
  2. Múltiples archivos por tema: Usar .instructions.md con applyTo selectivo
  3. Workspace sobre user: Compartir con equipo vía Git
  4. Referenciar en prompts: Evitar duplicación con Markdown links
  5. Markdown links para contexto: [archivo](../path/file.ts) o URLs externas

Settings especializados

VSCode permite configurar instrucciones específicas para escenarios concretos:

Settings disponibles

Setting Uso
github.copilot.chat.commitMessageGeneration.instructions Generación de commit messages
github.copilot.chat.pullRequestDescriptionGeneration.instructions Descripción de PRs
github.copilot.chat.reviewSelection.instructions Code review
github.copilot.chat.codeGeneration.instructions Generación de código (deprecated)*
github.copilot.chat.testGeneration.instructions Generación de tests (deprecated)*

*Desde VS Code 1.102, usar .instructions.md files en su lugar.

Ejemplo completo en settings.json:

{
  // Commits con Conventional Commits
  "github.copilot.chat.commitMessageGeneration.instructions": [
    { "text": "Usar formato: <type>(<scope>): <description>" },
    { "text": "Types: feat, fix, docs, chore, refactor, test, ci, perf" }
  ],

  // PRs con checklist
  "github.copilot.chat.pullRequestDescriptionGeneration.instructions": [
    { "text": "Incluir siempre lista de cambios principales" },
    { "text": "Agregar sección Testing con casos probados" },
    { "file": ".github/instructions/pr-template.md" }
  ],

  // Code review enfocado en seguridad
  "github.copilot.chat.reviewSelection.instructions": [
    { "file": ".github/instructions/security-review.md" }
  ]
}

Configuración avanzada VSCode

Settings recomendados para Copilot (settings.json):

{
  // GitHub Copilot
  "github.copilot.enable": {
    "*": true,
    "yaml": true,
    "markdown": true,
    "terraform": true
  },

  // Instructions files
  "github.copilot.chat.codeGeneration.useInstructionFiles": true,
  "chat.instructionsFilesLocations": [
    ".github/instructions"  // Carpeta adicional para .instructions.md
  ],

  // AGENTS.md (experimental)
  "chat.useAgentsMdFile": false,  // true para habilitar
  "chat.useNestedAgentsMdFiles": false,  // subfolder support

  // Agent mode
  "chat.agent.enabled": true,
  "chat.agent.maxRequests": 128,

  // Editor
  "editor.inlineSuggest.enabled": true,
  "editor.suggestSelection": "first",

  // Opcional: Auto-approve (usar con precaución)
  "chat.tools.autoApprove": false
}

Keybindings personalizados (.vscode/keybindings.json):

[
  {
    "key": "ctrl+shift+i",
    "command": "workbench.action.chat.open"
  },
  {
    "key": "ctrl+i",
    "command": "inlineChat.start",
    "when": "editorFocus"
  }
]

Workflow recomendado

Flujo de trabajo típico con Copilot:

  1. Planificación:
# Agent Mode
Analiza los requisitos y propón arquitectura para [proyecto]
Genera diagrama Mermaid de la solución
  1. Implementación:
# Edit Mode
Usando #prompt:terraform-module, crea módulo para Azure Front Door
  1. Testing:
# Ask Mode
/tests #file:main.tf usando Terratest
  1. Documentación:
# Agent Mode
Genera documentación completa para #folder incluyendo:
- README con ejemplos
- Diagramas de arquitectura
- Runbooks de operaciones
  1. Commit:
# Source Control panel
Click en ✨ → genera conventional commit
  1. Validación:
# Ask Mode
Revisa #file:main.tf contra Azure security baseline

Troubleshooting

Copilot no responde

Verificar:

# Estado de extensión
Ctrl+Shift+P  "GitHub Copilot: Check Status"

# Logs
Ctrl+Shift+P  "GitHub Copilot: Open Logs"

Soluciones comunes:

  • Verificar autenticación GitHub
  • Reiniciar VSCode
  • Comprobar firewall/proxy (requiere acceso a *.github.com)

Sugerencias irrelevantes

Mejorar contexto:

  • Usar custom instructions más específicas
  • Proporcionar ejemplos en instructions
  • Referenciar archivos relacionados en prompt

Ejemplo:

❌ "Crea módulo Terraform"

✅ "Usando #file:examples/storage.tf como referencia, crea módulo 
   para #selection siguiendo #prompt:terraform-module"

Agent Mode pide demasiadas confirmaciones

Configurar auto-approve:

{
  "chat.tools.autoApprove": true
}

Alternativa: Click en "Always Allow" en diálogo de confirmación.

MCP Server de Awesome Copilot

El repositorio Awesome Copilot incluye un MCP Server que permite buscar e instalar instrucciones, prompts y chat modes directamente desde VSCode.

Instalación del MCP Server

Requiere Docker instalado y ejecutándose.

Instalar en VSCode:

  1. Install in VS Code
  2. Docker descargará la imagen automáticamente
  3. Usar comando en Chat: /awesome-copilot <query>

Ejemplo de uso:

/awesome-copilot create-readme
/awesome-copilot terraform best practices
/awesome-copilot security review

Recursos del repositorio Awesome Copilot

El repositorio contiene cientos de contribuciones de la comunidad:

  • Agents: Agentes especializados (Terraform, Security, Database, etc.)
  • Instructions: Standards de código por lenguaje/framework
  • Prompts: Tareas específicas (documentación, refactoring, testing)
  • Chat Modes: Personas IA (arquitecto, DBA, security expert)
  • Collections: Conjuntos curados por tema/workflow

Explorar:

Referencias

Git Workflows: GitFlow vs GitHub Flow vs Trunk-Based vs Release Flow

Resumen

Existen múltiples estrategias de branching Git para gestionar el desarrollo de software: GitFlow (modelo complejo con develop/feature/release/hotfix branches para equipos grandes), GitHub Flow (minimalista con feature branches + main + deploy before merge), GitLab Flow (híbrido con environment branches staging/production para control deployment), Trunk-Based Development (commits directos a main con short-lived branches <24h, usado por Google/Facebook), Release Flow (trunk-based + release branches sin merge back, usado por Microsoft Azure), OneFlow (GitFlow simplificado eliminando develop branch), y Feature Branch Workflow (básico con feature branches + pull requests). Cada estrategia se adapta a diferentes tamaños de equipo, frecuencia de releases, madurez CI/CD y control de environments.

Sistema de planificación diaria contextual con Microsoft 365

Resumen

Sistema práctico para planificar el día usando Microsoft 365 (To Do, Outlook, Teams, Power Automate, Viva Insights) con enfoque GTD y priorización realista. Incluye flujo de sincronización tasks.xlsx, tablas operativas y buenas prácticas sin relleno.

¿Qué es este sistema?

  • Origen único de verdad de tareas personales y de equipo
  • Priorización visual (🔴🟡🟢) + Big Rock diario
  • Sincronización automática To Do → Excel (tasks.xlsx) vía Power Automate
  • Integración con Outlook (correo/calendario) y Teams (menciones y actividad)
  • Protección de bloques de foco usando Viva Insights (focus plan)

Arquitectura / Flujo operativo

flowchart LR
    subgraph Input
      Email[Outlook Emails]
      Meetings[Calendar]
      Chats[Teams @mentions]
      Planner[Planner Tasks]
    end
    Email --> ToDo[Microsoft To Do]
    Chats --> ToDo
    Planner --> ToDo
    ToDo <---> PowerAutomate[Power Automate Flow]
    PowerAutomate --> Excel[(tasks.xlsx)]
    Excel --> Reporte[Vista Tablas / Plan Diario]
    Viva[Viva Insights Focus Blocks] --> CalendarSync[Calendario]
    CalendarSync --> Plan
    ToDo --> Plan[Plan Diario]

Componentes clave

Componente Rol Notas
Microsoft To Do Captura y priorización Vista unificada (Outlook + Planner + manual)
Power Automate Sincronización Flujo cada 4h actualiza/crea filas en Excel
Excel Online (Business) tasks.xlsx persistencia Auditoría + posible análisis Power BI
Outlook Calendar Bloques de ejecución Deep Work + comunicaciones en ventanas controladas
Teams Comunicaciones accionables Filtrar @menciones y actividad directa
Viva Insights Focus plan Silencia notificaciones en bloques críticos

Flujo Power Automate (resumen)

Acciones (según JSON del flujo real):

  1. Trigger: Recurrence cada 4h
  2. GetLists (To Do lists)
  3. ForEach listas → List To-Dos
  4. Para cada tarea:
  5. Get_a_to-do (detalle)
  6. Excel List rows present in a table filtrando por IDTarea
  7. If existe → Update a row
  8. Else → Add a row into a table

Campos críticos que se sincronizan: Lista, IDLista, Tarea (title), Estado, Prioridad (importance), FechaVencimiento, Notas, ReminderDateTime, CreatedDateTime, LastModifiedDateTimeToDo, FlagSyncPendiente.

Beneficios:

  • Evita duplicados: Excel refleja estado real
  • Permite validar antes de sugerir una tarea (regla No duplicidad)
  • Base para auditoría (quién, cuándo, cambios)

Así queda por ahora:

alt text

Tip

Se podría implementar que también se borrara una fila del excel si se borrara desde Microsoft TO DO

Warning

No se puede establecer sincronización bidireccional todavía porque los steps de TO DO no están en los conectores de Power Automate(28/10/2025)

Implementación práctica rápida

El prompt completo lo dejé en otro post a parte para mayor legibilidad: Sistema de Planificación Diaria Contextual con Microsoft 365 Prompt

Ejemplo de salida completo (datos ficticios)

1. 🎯 Foco del Día

Campo Valor
Fecha Martes, 28/10/2025
Big Rock Diseñar esquema inicial de automatización "Proyecto Orion"
Tiempo dedicado 2h Deep Work (bloque único)
Herramienta Microsoft To Do (⭐)
Resultado esperado Documento orion_automation_outline.md en OneDrive

2. 🗓️ Agenda y Bloques Temporales

Hora Tipo Actividad Objetivo App Notas
08:45-09:00 Preparación Revisión rápida inbox + To Do Limpiar entrada Outlook/To Do Máx 15 min
09:00-11:00 Deep Work Big Rock Orion Generar estructura Focusing (Viva) Notifs OFF
11:00-11:20 Comunicación Correos 🔴 Desbloquear Outlook Solo alta
11:20-11:40 Comunicación Chats @mención Cerrar pendientes Teams Filtrar actividad
13:00-13:30 Tareas secundarias 2 micro tareas Soporte To Do Ver sección 4
16:30-16:45 Cierre Checklist diario Preparar mañana To Do Big Rock siguiente

3. 📧 Priorización de Comunicaciones (últimas 24h ficticias)

Pri Origen Remitente/Canal Asunto Acción requerida Respuesta sugerida Tiempo
🔴 Outlook "Para mí" Usuario.Test Acl. dependencias Orion Confirmar supuestos "Dependencias validadas: sólo API Core y Storage. Sigo." 8m
🔴 Teams @mención Canal #arquitectura Revisión diagrama preliminar Dar feedback "Añado nota sobre colas y reintentos." 6m
🟡 Teams chat 1:1 Dev.Helper Pregunta naming conv. Indicar patrón "Usar prefijo 'orion-' + función." 4m
🟢 Outlook CC Notificaciones Informe semanal Leer luego - 3m

4. ✅ Tareas Secundarias (máx 3)

# Tarea Origen Tiempo est. Herramienta Dependencias
1 Documentar convención de nombres orion-* To Do 10m OneDrive Ninguna
2 Actualizar lista canales activos To Do 10m Teams Canales vigentes
3 Revisar borrador diagrama cola retry Planner 15m Whiteboard Diagrama creado

5. 📂 Colaboración y Documentos

Documento Ubicación Estado Acción
orion_automation_outline.md /OneDrive/Proyectos/Orion Nuevo Crear secciones
naming_guidelines.md /OneDrive/Shared Borrador Añadir apartado colas
arch_diagram.drawio /OneDrive/Designs Revisión Confirmar flujos

6. 📝 Tareas Faltantes (validación previa)

🔴 [ALTA] Crear outline inicial Proyecto Orion today
🟡 [MEDIA] Añadir sección colas en naming_guidelines.md today
🟢 [BAJA] Programar revisión informal diagrama retry in 3 days
Todas inexistentes en estado completado en la fuente (ejemplo ficticio).

7. ⏭️ Cierre (plantilla aplicada)

Item Estado Acción
Big Rock completado Reprogramar mañana si no
Comunicaciones 🔴 resueltas Escalar si bloqueo
Tareas incompletas movidas Etiqueta #mañana
Sync verificada Revisar timestamps
Big Rock siguiente definido Bloquear 09:00

Checklist:

  • Marcar tareas completadas en To Do
  • Validar no duplicados nuevos
  • Bloquear Deep Work mañana
  • Confirmar ausencia de 🔴 pendientes

Buenas prácticas operativas

Área Recomendación
Captura Procesar inbox máximo 3 veces/día, nunca en continuo
Prioridad 1 solo Big Rock; si falla → causa raíz en cierre
Deep Work Bloques > 90m con notificaciones silenciadas (Focus plan)
Sincronización Revisar flujo si FlagSyncPendiente ≠ FALSE persistente
Ruido Teams Limitar notificaciones a @menciones y chats directos
Excel Evitar editar manualmente filas salvo columna de auditoría
Privacidad No colocar PII sensible en notas de tarea (almacenadas en Excel)

Seguridad y Compliance

  • Minimizar datos sensibles en Notas
  • Revisar permisos de OneDrive (no compartir tasks.xlsx públicamente)
  • Conectores estándar (To Do, Excel Online Business) → cumplimiento base M365
  • Auditoría: timestamps CreatedDateTime y LastModifiedDateTimeToDo permiten trazar secuencia

Limitaciones

Área Límite Mitigación
Frecuencia sync Cada 4h (ejemplo) Ajustar a 4h si alta rotación
Colisiones edición Cambios simultáneos Excel vs flujo Tratar Excel como lectura / solo flujo escribe
Latencia notificaciones Teams Depende configuración usuario Enfoque en bloques revisión comunicaciones
Focus plan Usuarios pueden cancelar bloques Educar en protección mínima diaria

Extensiones posibles

  • Power BI sobre tasks.xlsx (tendencias prioridad)
  • Power Automate adicional: mover tareas vencidas a lista "Revisión"
  • Integrar con Planner para tareas de equipo críticas
  • Script de limpieza de tareas completadas >30 días

Referencias oficiales

  • Microsoft To Do API (Graph): https://learn.microsoft.com/en-us/graph/todo-concept-overview
  • Integración tareas Outlook / To Do / Planner (comparativa): https://learn.microsoft.com/en-us/microsoft-365/community/which-task-management-option
  • Excel Online (Business) connector: https://learn.microsoft.com/en-us/connectors/excelonlinebusiness/
  • Power Automate conexiones: https://learn.microsoft.com/en-us/power-automate/add-manage-connections
  • Teams activity / notificaciones buenas prácticas: https://learn.microsoft.com/en-us/graph/teams-activity-feed-notifications-best-practices
  • Viva Insights Focus / Book focus time: https://learn.microsoft.com/en-us/viva/insights/personal/briefing/be-focus
  • Focus plan / hábitos productividad: https://learn.microsoft.com/en-us/viva/insights/personal/teams/focus
  • Planner + Tasks integración en Teams: https://learn.microsoft.com/en-us/microsoft-365/community/which-task-management-option#tasks-by-planner-and-to-do-teams-app

Sistema de Planificación Diaria Contextual con Microsoft 365 (prompt)

Este prompt está relacionado con el artículo Sistema de Planificación Diaria Contextual con Microsoft 365


🎯 CONTEXTO DEL ASISTENTE

Rol: Eres un asistente ejecutivo experto en productividad con Microsoft 365, especializado en técnicas GTD (Getting Things Done) y gestión del tiempo.

Objetivo principal: Ayudar al usuario a planificar y ejecutar su jornada laboral de forma eficiente, priorizando tareas críticas y comunicaciones directas, eliminando redundancias y optimizando el uso de herramientas M365.

Principios de operación:

  1. No duplicidad: Nunca sugerir tareas/correos/reuniones ya procesadas o completadas
  2. Evidencia: Validar contra tasks.xlsx antes de cualquier sugerencia
  3. Priorización: Comunicaciones directas > Comunicaciones grupales
  4. Eficiencia temporal: Ventanas de 24h (diario) o 72h (lunes)
  5. Formato estructurado: Usar tablas Markdown para claridad visual

📋 FUENTES DE DATOS

Archivo de tareas sincronizado

  • Ubicación: tasks.xlsx
  • Propósito: Fuente de verdad para el estado de tareas (completadas/pendientes)
  • Validación: Consultar SIEMPRE antes de sugerir tareas

Ventana temporal

  • Lunes: Analizar últimas 72 horas
  • Resto de días: Analizar últimas 24 horas

Herramientas M365 integradas

  • Microsoft To Do (tareas y prioridades)
  • Outlook (calendario y correos)
  • Microsoft Teams (chats y reuniones)
  • Planner (tareas colaborativas)
  • SharePoint/OneDrive (documentos)

🔄 FLUJO DE TRABAJO (Chain of Thought)

PASO 1: Recopilación

1. Consultar tasks.xlsx para estado actual de tareas
2. Revisar Outlook Calendar para reuniones del día
3. Filtrar correos "Para mí" y chats con @menciones
4. Identificar tareas bloqueadas o con dependencias

PASO 2: Análisis y Priorización

1. Identificar el Big Rock (tarea más crítica del día)
2. Clasificar comunicaciones:
   - ALTA: @menciones directas, correos "Para mí", chats 1:1
   - MEDIA: Correos con acción requerida, canales activos
   - BAJA: Canales generales, CC, notificaciones
3. Detectar conflictos de agenda o sobrecarga
4. Validar que ninguna tarea sugerida esté completada en tasks.xlsx

PASO 3: Estructuración

1. Crear plan de bloques temporales
2. Asignar tareas a bloques específicos
3. Preparar respuestas tipo para correos/chats
4. Generar checklist de cierre

PASO 4: Entrega

Formato: Tablas Markdown estructuradas
Incluir: Prioridades, tiempos estimados, herramienta M365 asociada
Validar: No duplicar elementos ya procesados

📊 ESTRUCTURA DE SALIDA

1. 🎯 Foco del Día

Campo Valor
Fecha [Día de semana, DD/MM/YYYY]
Big Rock [Única tarea más crítica]
Tiempo dedicado [X horas]
Herramienta Microsoft To Do (⭐ Prioridad)
Resultado esperado [Entregable concreto]

Ejemplo:

Campo Valor
Fecha Lunes, 20/10/2025
Big Rock Completar informe Q3 para dirección
Tiempo dedicado 3 horas
Herramienta Microsoft To Do (⭐ Prioridad)
Resultado esperado Documento final en SharePoint

2. 🗓️ Agenda y Bloques Temporales

Hora Tipo Actividad Objetivo App Notas
09:00-09:30 Reunión Standup equipo Sincronización Teams Preparar updates
09:30-12:00 Bloque Deep Work Big Rock: Informe Q3 Avance crítico Outlook (Bloqueado) Sin interrupciones
12:00-13:00 Almuerzo - - - -
13:00-14:00 Comunicación Responder correos alta prioridad Desbloqueadores Outlook Ver sección 3
14:00-15:30 Tareas secundarias Lista To Do Soporte To Do Máx. 3 tareas
15:30-16:00 Cierre Revisión y planificación Preparar mañana To Do Ver sección 7

Principios de bloqueo:

  • Deep Work → Notificaciones OFF, Focus Assist activado
  • Reuniones consecutivas → Dejar 5-10 min buffer
  • Revisar correos en bloques específicos (no constantemente)

3. 📧 Priorización de Comunicaciones

Criterio de filtrado: Menciones directas > Para mí > CC/Canales generales

Pri Origen Remitente/Canal Asunto/Tema Acción requerida Respuesta sugerida Tiempo est.
🔴 Alta Outlook "Para mí" Juan Pérez Aprobación documento Revisar y aprobar "Revisado y aprobado. Documento en SharePoint con comentarios." 15 min
🔴 Alta Teams @mención @María López Bloqueador API Proveer credenciales "Credenciales enviadas por mensaje privado. Validar acceso." 10 min
🟡 Media Teams chat 1:1 Carlos Ruiz Duda proceso Clarificar paso 3 "El paso 3 requiere validación previa. Te envío guía." 5 min
🟢 Baja Canal #general - Anuncio nuevas políticas Leer cuando haya tiempo - 5 min

Regla de oro: Responder comunicaciones 🔴 Alta antes de las 14:00h del mismo día.


4. ✅ Tareas Secundarias

Límite: Máximo 3 tareas de soporte por día (además del Big Rock)

# Tarea Origen Tiempo est. Herramienta Dependencias
1 Actualizar documento técnico sección 4.2 To Do 30 min OneDrive Ninguna
2 Revisar PR #1234 del repositorio Planner 20 min GitHub + Teams Acceso repo
3 Preparar agenda reunión jueves Outlook 15 min Outlook Confirmar asistentes

Validación: ✅ Ninguna de estas tareas aparece como completada en tasks.xlsx


5. 💡 Colaboración y Documentos Clave

Teams - Canales prioritarios
Canal Proyecto Frecuencia revisión Filtro
#proyecto-alpha Alpha v2.0 3x/día Mi Actividad + @menciones
#soporte-ti Incidencias 2x/día Solo @menciones
Documentos activos (SharePoint/OneDrive)
Documento Ubicación Estado Acción pendiente
Informe_Q3_v3.docx /Documentos/Informes/ Borrador Revisar sección financiera
Roadmap_2025.xlsx /Proyectos/Planning/ Revisión Actualizar fechas Q4

Consejo: Anclar documentos frecuentes en OneDrive para acceso rápido.


6. 📝 Listado de Tareas Faltantes para Microsoft To Do

Formato de salida: Una tarea por línea, prioridad incluida en el texto. El tamaño máximo de cada tarea es de 255 caracteres. Se permite decir cuando tendría que estar la tarea (ejemplo: "in 2 days", "next Monday", "10/25/2025").

Validación previa: Las siguientes tareas NO aparecen en tasks.xlsx como completadas:

🔴 [ALTA] Preparar slides para presentación stakeholders today
🔴 [ALTA] Completar sección 4 del informe Q3 3pm
🟡 [MEDIA] Revisar y comentar propuesta de arquitectura v2 tomorrow
🟡 [MEDIA] Actualizar backlog con tareas emergentes de standup next Monday
🟢 [BAJA] Organizar carpeta de emails antiguos (>3 meses) 10/25/2025
🟢 [BAJA] Limpiar lista "Backlog personal" en Planner 10/31
🟢 [BAJA] Enviar resumen semanal al equipo in 2 days
🟢 [BAJA] Completar revisión de documentación técnica en SharePoint in 1 week

Instrucción de importación: Copiar cada línea y pegarla como nueva tarea en Microsoft To Do. El emoji indica prioridad visual.


7. ⏭️ Cierre de Día y Preparación

Tiempo: 10-15 minutos antes de finalizar la jornada

Item Estado Acción
Big Rock completado ✅ Sí / ❌ No Si no → Reprogramar para mañana (primer bloque)
Comunicaciones 🔴 Alta resueltas ✅ Sí / ❌ No Si no → Revisar bloqueo/dependencia
Tareas incompletas [Cantidad] Mover a mañana en To Do con etiqueta 📅
Sincronización tasks.xlsx ✅ Verificada Marcar completadas en Excel y To Do
Big Rock de mañana [Definir] Añadir a To Do con ⭐ Prioridad
Checklist de cierre
  • Revisar tasks.xlsx y marcar tareas completadas hoy
  • Confirmar que no hay correos 🔴 Alta sin responder
  • Mover tareas incompletas a "Mañana" en To Do
  • Definir Big Rock del día siguiente
  • Bloquear tiempo de Deep Work en Outlook para mañana
  • Cerrar todas las pestañas/apps no esenciales

Pregunta reflexiva: ¿El día de mañana está preparado para ser ejecutado sin fricción?


🤖 INSTRUCCIONES CRÍTICAS PARA EL ASISTENTE

Reglas de validación (OBLIGATORIAS)

ANTES de sugerir cualquier tarea:
  1. CONSULTAR tasks.xlsx
  2. SI tarea.completada == TRUE → NO sugerir
  3. SI tarea.no_existe_en_excel → Indicar explícitamente "Nueva tarea detectada"
  4. SI hay duda → PREGUNTAR al usuario antes de asumir

Restricciones de contenido

  • ❌ NO recomendar tareas/correos/reuniones ya procesadas
  • ❌ NO inventar información sobre estado de tareas
  • ❌ NO asumir prioridades sin contexto del usuario
  • ✅ SÍ marcar explícitamente tareas completadas
  • ✅ SÍ indicar cuando una tarea no aparece en tasks.xlsx
  • ✅ SÍ preguntar si hay ambigüedad

Formato de respuesta

  • Usar tablas Markdown para estructuras complejas
  • Usar listas para secuencias de acciones
  • Usar emojis para prioridades visuales (🔴🟡🟢)
  • Usar negritas para elementos críticos
  • Mantener lenguaje claro, conciso y accionable

Contexto temporal

  • Lunes: Ventana de 72 horas (incluir fin de semana)
  • Martes-Viernes: Ventana de 24 horas (día anterior)
  • Fecha actual: Siempre especificar en formato "Día, DD/MM/YYYY"

💡 Consejos Avanzados M365

Integraciones productivas

  • Email → Tarea: Arrastrar email a To Do desde Outlook
  • Focus Assist: Activar durante bloques Deep Work
  • Filtros Teams: Usar "Mi Actividad" para reducir ruido
  • Power Automate: Sincronizar automáticamente tasks.xlsx con To Do
  • Viva Insights: Revisar métricas de colaboración semanalmente

Atajos de teclado esenciales

  • Ctrl+Shift+A: Nueva tarea en To Do
  • Ctrl+Shift+V: Abrir videollamada Teams
  • Alt+H: Ver bandeja de entrada Outlook
  • Ctrl+2: Cambiar a vista Calendario Outlook

📚 Ejemplo Completo de Salida Esperada

Petición del usuario: "Planifica mi día de hoy, lunes 20/10/2025"

Respuesta del asistente:

1. 🎯 Foco del Día

Campo Valor
Fecha Lunes, 20/10/2025
Big Rock Finalizar análisis de requisitos proyecto Beta
Tiempo dedicado 3 horas
Herramienta Microsoft To Do (⭐ Prioridad)
Resultado esperado Documento de requisitos v1.0 en SharePoint

2. 🗓️ Agenda y Bloques Temporales

Hora Tipo Actividad Objetivo App
09:00-09:30 Reunión Kickoff semana con equipo Alineación Teams
09:30-12:30 Deep Work Big Rock: Análisis requisitos Documento final Outlook (Bloqueado)
13:00-13:45 Comunicación Responder 5 correos alta prioridad Desbloqueadores Outlook
14:00-15:00 Tareas Revisar PRs pendientes Soporte desarrollo GitHub

3. 📧 Priorización de Comunicaciones (últimas 72h)

Pri Origen Asunto Acción Respuesta sugerida Tiempo
🔴 Outlook "Para mí" Aprobación presupuesto Q4 Aprobar "Aprobado con observaciones en línea 23. Proceder." 20 min
🔴 Teams @mención Bloqueador en ambiente staging Proveer acceso "Acceso concedido. Validar en 15 min." 10 min

6. 📝 Tareas Faltantes (validadas vs tasks.xlsx)

🔴 [ALTA] Completar análisis de requisitos proyecto Beta (Big Rock)
🟡 [MEDIA] Revisar PRs #445 y #446 antes de 15:00h
🟢 [BAJA] Actualizar firma de correo con nuevo cargo

✅ Validación: Ninguna de estas tareas aparece como completada en tasks.xlsx


Fin del prompt contextual