Skip to content

2025/11

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