Estratégia de deployment

A spec LTI 1.3 permite que um mesmo tool seja registrado uma vez por LMS e deployado várias vezes, com deployment_id distinto por unidade administrativa (escola, campus, departamento). Essa decisão acontece do lado do LMS e impacta diretamente como a Árvore organiza os dados.

Como a Árvore mapeia LTI para entidades

Cada (issuer, client_id, deployment_id) registrado na Árvore vira uma escola no nosso modelo. Toda turma vinda dessa plataforma fica como filha dessa escola.

deployment LTI ──► 1 escola Árvore
                    ├── turma A (LTI context A)
                    ├── turma B (LTI context B)
                    └── turma C (LTI context C)

Cenários comuns

Uma escola só (cliente individual)

O LMS gerencia apenas uma escola. Basta um deployment.

LMS único → 1 deployment_id → 1 escola na Árvore → várias turmas

Sem nada especial pra fazer. Funciona out of the box.

Rede de escolas com 1 LMS único (multi-tenant)

Uma rede educacional roda um único LMS que atende várias escolas filhas. Aqui a decisão importa:

Opção A — 1 deployment por escola (recomendado)

O admin do LMS cria um deployment_id por escola dentro da mesma instalação. Nesse caso, a Árvore registra um lti_platforms por deployment, e cada um vira uma escola distinta com suas próprias turmas e relatórios.

LMS único → deployment 1 (Escola Recife) → 1 escola na Árvore
         → deployment 2 (Escola SP)     → outra escola na Árvore
         → deployment 3 (Escola Curitiba) → outra escola na Árvore

Isso é o padrão suportado por Blackboard, Canvas, Moodle e D2L. Vantagens:

• Hierarquia natural no painel do educador (cada escola tem suas turmas)
• Relatórios por escola fazem sentido
• Permissão de admin de escola fica restrita à escola correta

Opção B — 1 deployment só pra todas as escolas

Tecnicamente funciona, mas todas as turmas da rede acabam embaixo de uma escola única na Árvore (geralmente nomeada com o nome da rede). Trade-offs:

• Painel do educador agrupa tudo embaixo de uma “escola virtual”
• Relatórios por escola perdem granularidade
• Permissão de admin de escola vira permissão de admin da rede toda

Use a Opção B apenas quando o LMS realmente não suporta múltiplos deployments ou quando a rede é tratada como uma escola única.

LMS separado por escola

Cada escola tem um LMS distinto (issuer diferente). Cada LMS é registrado como uma plataforma separada na Árvore — equivale à Opção A acima, com a diferença de que cada plataforma também tem issuer próprio.

Como decidir

A escolha entre as opções é responsabilidade do admin do LMS, não do tool. Se você precisa de granularidade por escola (relatórios, painel, permissões), peça ao admin do LMS para criar deployments separados. Quase todos os LMSs comerciais suportam isso nativamente:

Conclusão

Sempre que houver mais de uma escola compartilhando o mesmo LMS, prefira deployments separados. A Árvore vai criar uma escola distinta por deployment automaticamente no primeiro launch, e a partir daí cada escola opera de forma isolada.