Guía de Desarrollo del Sistema A3¶

Guía de desarrollo para el equipo de TI de A Terceros Inmobiliaria y desarrolladores externos contratados.

Prerrequisitos de Acceso¶

Antes de comenzar a desarrollar, necesitas:

Aprobación del departamento de TI
Firma de acuerdos de confidencialidad (NDA)
Autorización de acceso al repositorio
Acceso al repositorio privado en GitHub
Solicitar a: [Tech Lead] o [email de TI]
Tiempo estimado: 1-2 días hábiles
Requiere cuenta GitHub corporativa o personal verificada
Accesos a servicios
Ver guía de accesos para detalles completos
Heroku, AWS, Base de Datos, etc.
Entorno configurado
Seguir guía de instalación
Python 3.11+, PostgreSQL 12.3+, virtualenv

Workflow de Desarrollo¶

1. Clonar el Repositorio¶

Como miembro del equipo, trabajas directamente en el repositorio principal (no necesitas hacer fork):

git clone https://github.com/A-Terceros-Inmobiliaria/sistema-a3.git
cd sistema-a3

Nota: Si no tienes acceso, solicítalo según la sección de prerrequisitos.

2. Configurar Entorno Local¶

# Crear virtualenv
python -m venv venv
source venv/bin/activate  # En Windows: venv\Scripts\activate

# Instalar dependencias
pip install -r requirements.txt

# Configurar variables de entorno
cp .env.example .env
# Editar .env con tus credenciales locales

Ver guía de configuración para detalles.

3. Asignación de Tareas¶

Las tareas se asignan a través de [sistema de tracking - Jira/Trello/etc.]:

Prioridades:
P0: Crítico - Sistema caído, afecta producción
P1: Alto - Feature principal afectada
P2: Medio - Funcionalidad secundaria
P3: Bajo - Nice-to-have, backlog
Estimación: Story points (escala Fibonacci: 1, 2, 3, 5, 8, 13)
Sprint: Ciclos de 2 semanas
Planning: Reuniones bi-semanales con Product Owner

4. Crear Rama de Desarrollo¶

Usa la convención de nombres del equipo:

# Features
git checkout -b feature/TICKET-123-nombre-descriptivo

# Bugs
git checkout -b bugfix/TICKET-456-corregir-error

# Hotfixes (producción)
git checkout -b hotfix/TICKET-789-error-critico

Importante: Incluye el número de ticket para trazabilidad.

5. Desarrollo¶

Estándares a Seguir¶

Código:
Sigue estándares de código
Usa black para formateo
Usa isort para imports
Respeta convenciones Django
Testing:
Escribe tests para funcionalidad nueva (guía de testing)
Asegura que tests existentes pasen
Cobertura mínima: 70%
Documentación:
Actualiza docstrings
Actualiza esta documentación si cambia funcionalidad
Agrega comentarios para lógica compleja
Seguridad:
NO commitees secretos, API keys, contraseñas
NO uses datos de producción en local sin anonimizar
Valida inputs de usuario
Revisa OWASP Top 10

6. Commits¶

Sigue el formato de conventional commits:

git add .
git commit -m "feat(modulo): descripción breve del cambio

Descripción más detallada explicando:
- Qué se cambió
- Por qué se cambió
- Impacto del cambio

Refs: TICKET-123"

Prefijos de commit: - feat: Nueva funcionalidad - fix: Corrección de bug - docs: Cambios en documentación - style: Formato, sin cambios de lógica - refactor: Refactorización de código - perf: Mejoras de performance - test: Agregar o modificar tests - chore: Mantenimiento, dependencias

Ejemplo:

git commit -m "fix(apartados): corregir cálculo de comisiones

El cálculo de comisiones no consideraba descuentos especiales
aplicados en ventas C90. Se ajustó la fórmula para incluir
estos casos especiales.

Refs: TICKET-456"

7. Push y Pull Request¶

git push origin feature/TICKET-123-nombre-descriptivo

Luego crea un Pull Request en GitHub siguiendo la guía de PRs.

Pull Request - Checklist¶

Antes de crear tu PR, verifica:

[ ] Código compila sin errores
[ ] Tests pasan localmente (pytest)
[ ] Cobertura cumple mínimo (70%)
[ ] Documentación actualizada si aplica
[ ] No hay secretos en el código
[ ] Estándares aplicados (black, isort)
[ ] Migraciones creadas si hay cambios de BD
[ ] Descripción clara en el PR
[ ] Screenshots si hay cambios visuales
[ ] Revisión propia del código antes de solicitar review

Proceso de Code Review¶

Revisores¶

Los PRs requieren mínimo 1 aprobación de:

Features de Ventas/Inventario: [nombre del reviewer]
Features de RH: [nombre del reviewer]
Features de Finanzas: [nombre del reviewer]
Cambios de Arquitectura: Requiere aprobación de Tech Lead
Cambios en BD: Requiere aprobación de DBA/DevOps

SLA de Review¶

Estándar: 24 horas hábiles
Urgente (hotfix): 2-4 horas
Bloqueado (más de 48h sin review): Escalar a Tech Lead

Responder a Feedback¶

Lee comentarios cuidadosamente
Haz cambios solicitados en la misma rama
Responde a comentarios cuando hayas hecho los cambios
Re-solicita review cuando esté listo
Mantén comunicación profesional

Módulos en Desarrollo Activo¶

Áreas con desarrollo continuo y oportunidades de contribución:

Módulo	Contacto	Prioridad Actual
Inventario	`[nombre]`	Alta - Integración SAP
Apartados	`[nombre]`	Media - Mejoras UX
Tickets	`[nombre]`	Alta - Campos dinámicos
Comprobaciones	`[nombre]`	Media - Automatización
Dashboard	`[nombre]`	Baja - Nuevos KPIs
Reportes	`[nombre]`	Alta - Exportación Excel mejorada

Nota: Las tareas se asignan en reuniones de planning, no de forma voluntaria.

Deployment¶

Ambientes¶

Local: Tu máquina de desarrollo
Staging: [URL staging] - Para QA y pruebas internas
Producción: [URL producción] - Ambiente live

Proceso de Deploy¶

Merge a master: Requiere aprobación de PR
CI/CD automático: GitHub Actions ejecuta tests
Deploy a Staging: Automático después de merge
QA en Staging: [Equipo de QA] prueba funcionalidad
Deploy a Producción: Manual, ejecutado por DevOps

Responsable de Deploys: [DevOps Lead - nombre]

Horarios de Deploy a Producción: - Lunes a Jueves: 10:00 AM - 4:00 PM - Viernes: Solo hotfixes críticos - Evitar deploys antes de fines de semana largos

Rollback¶

En caso de problemas post-deploy:

Notificar en #sistema-a3-urgente
Contactar a DevOps: [contacto]
Evaluar rollback vs hotfix
Documentar incidente en postmortem

Comunicación del Equipo¶

Canales de Slack¶

#dev-sistema-a3: Desarrollo general, dudas técnicas, coordinación
#sistema-a3-urgente: Incidencias críticas de producción (usar con moderación)
#sistema-a3-deploys: Notificaciones automáticas de deployments

Reuniones¶

Daily Standup: Lunes, Miércoles, Viernes a las 9:00 AM (15 min)
Sprint Planning: Cada 2 semanas, Lunes a las 10:00 AM (1 hora)
Retrospectiva: Cada 2 semanas, Viernes a las 3:00 PM (30 min)
Tech Sync: Martes a las 2:00 PM (30 min) - Solo equipo técnico

Reportar Problemas¶

Bug encontrado en desarrollo: Crear issue en GitHub
Bug en producción: Ticket en [sistema de tickets] + notificar en Slack
Duda técnica: Preguntar en #dev-sistema-a3
Duda de negocio: Contactar al stakeholder del módulo
Decisión arquitectónica: Escalar a Tech Lead

Proponer Nuevas Features¶

Discutir idea con Product Owner antes de implementar
Si es cambio arquitectónico grande: Crear RFC (Request for Comments)
Presentar en reunión de planning
Obtener aprobación antes de comenzar desarrollo

Onboarding de Nuevos Desarrolladores¶

Si eres nuevo en el equipo:

Completa proceso de onboarding
Lee arquitectura del sistema
Configura entorno local
Haz tu primer PR (puede ser fix menor o actualización de docs)
Participa en code reviews de otros
Haz pair programming con desarrollador senior

Mentor asignado: Se te asignará un mentor durante las primeras 4 semanas.

Recursos Adicionales¶

Documentación Interna¶

Recursos Externos¶

Contactos del Equipo¶

Tech Lead: [nombre] - [email]
Product Owner: [nombre] - [email]
DevOps: [nombre] - [email]
QA Lead: [nombre] - [email]

Nota Importante: El Sistema A3 es software propietario de A Terceros Inmobiliaria. Todo el código, documentación y conocimiento adquirido es confidencial y está protegido por acuerdos de NDA.