Ir para o conteúdo

Distribuição para equipe de suporte (sem fontes)

Processo para desenvolvimento gerar o pacote e suporte técnico instalar em VPS do cliente sem acesso ao monorepo.

Papéis

Papel Responsabilidade
Desenvolvimento Build CTI, empacotar, publicar artefato, checksums
Suporte Extrair pacote, configurar .env, deploy, validação
Cliente VPS, firewall, DNS/SIP (se aplicável)

Artefatos

Arquivo Localização Conteúdo
resources/net9.0.zip Dentro do stack LorentzCTI Release (.NET 9)
resources/supervisor.tar.gz Gerado no build dist Cópia do Supervisor PHP
resources/MANIFEST.json Gerado no build dist Versão, data, SHA256
resources/SHA256SUMS Gerado no build dist Verificação de integridade
dist/lorentz-deploy-*.tar.gz Entrega final Stack + supervisor + zips

O net9.0.zip permanece em lorentz-vps-stack/resources/ — caminho fixo para scripts e documentação.

Desenvolvimento — gerar release

1. Build do LorentzCTI

Requer monorepo com server/LorentzCTI/:

cd lorentz-vps-stack
./scripts/build-lorentz-cti-zip.sh
# → resources/net9.0.zip

2. Pacote completo para suporte

./scripts/build-dist-package.sh
# ou com versão explícita:
./scripts/build-dist-package.sh 1.0.0.109

Saída:

dist/lorentz-deploy-1.0.0.109.tar.gz
dist/lorentz-deploy-1.0.0.109.sha256

3. Publicar para a equipe

Entregar os dois arquivos (.tar.gz + .sha256) por canal interno (SharePoint, S3, ticket).

Opcional: manter histórico em resources/releases/ com nome net9.0-1.0.0.109.zip (cópia manual do zip).

Suporte — instalar no cliente

  1. Validar SHA256 do .tar.gz com o arquivo .sha256
  2. Extrair na VPS
  3. Seguir Instalação completa
cd ~/omnichannel/lorentz-vps-stack
./scripts/prepare-support-install.sh
nano .env
./scripts/check-pre-install.sh
./scripts/deploy-all.sh
./scripts/validate-install.sh --external

Medidas recomendadas (checklist organizacional)

Integridade e rastreio

  • [ ] MANIFEST.json + SHA256SUMS em todo pacote
  • [ ] Versão CTI alinhada ao LorentzCTI.dll / release notes
  • [ ] Arquivo .sha256 separado para validar o .tar.gz antes de extrair
  • [ ] Registro interno: data, responsável, versão entregue, cliente

Segurança

  • [ ] Nunca incluir .env de produção no pacote
  • [ ] Apenas .env.example — suporte cria .env no cliente
  • [ ] Senhas padrão documentadas; exigir troca pós-instalação
  • [ ] Não expor AMI (5038) nem SQL (1433) na internet
  • [ ] Restringir SSH e 8080 ao IP do suporte quando possível

Operacional

  • [ ] VPS mínima documentada (2 vCPU, 4 GB RAM, 40 GB, swap 4 GB)
  • [ ] Scripts check-pre-install.sh e validate-install.sh obrigatórios
  • [ ] Template de coleta: diagnose-all.sh → arquivo para escalonamento
  • [ ] Procedimento de atualização só CTI (substituir net9.0.zip)
  • [ ] Procedimento de restore SQL (.bak do cliente em mídia separada)

Conhecimento da equipe

Licenciamento

  • [ ] SQL Server Developer Edition — apenas homologação/dev (Microsoft)
  • [ ] Componentes Lorentz — uso conforme contrato Megatronix
  • [ ] Issabel — GPL; ISO via SourceForge no deploy

Estrutura após extração na VPS

~/omnichannel/
├── lorentz-vps-stack/
│   ├── resources/
│   │   ├── net9.0.zip              ← Release CTI (distribuído)
│   │   ├── lorentz-cti-publish/    ← extraído pelo script
│   │   ├── MANIFEST.json
│   │   └── SHA256SUMS
│   └── INSTALACAO-SUPORTE.md
└── supervisor/

Lab local (treino sem VPS)

A equipe pode extrair o pacote dist/lorentz-deploy-*.tar.gz em WSL2 Ubuntu + Docker Desktop e subir o stack sem Issabel:

./scripts/prepare-support-install.sh
./scripts/deploy-lab-local.sh
./scripts/deploy-lab-local.sh --all-optional   # webphone + energy + licenca

Guia: 24-lab-local-wsl-docker.md — limitações (sem PABX/SIP), RAM WSL, matriz de testes.

Git e repositório

Arquivos grandes não versionados no git (.gitignore):

  • resources/net9.0.zip
  • resources/supervisor.tar.gz
  • dist/*.tar.gz

Distribuição via artefato de release (dist/), não via clone git, para a equipe de suporte.

Desenvolvimento mantém fontes no monorepo; suporte recebe apenas lorentz-deploy-*.tar.gz.

Atualização de versão (fluxo resumido)

dotnet publish → net9.0.zip → build-dist-package.sh → tar.gz + sha256 → suporte → VPS cliente

Atualização Supervisor (patch PHP)

Para correções somente no Supervisor web, sem novo CTI:

Papel Ação
Dev ./scripts/build-supervisor-package.sh → enviar supervisor.tar.gz
Suporte ./scripts/update-supervisor-web.sh resources/supervisor.tar.gz

Guia completo: 16-atualizacao-supervisor-web.md.

Próximos passos opcionais

Melhoria Benefício
CI (GitHub Actions) gerar dist/ automaticamente Release reprodutível
Git LFS ou registry interno para net9.0.zip Histórico de versões
supervisor/vendor no pacote se Composer for obrigatório Deploy offline PHP
Backup .bak SQL em pacote separado por cliente Restore completo