Quatro passos até produção. Nenhum deles no console da AWS.
Do primeiro login ao release em produção, quem constrói trabalha no console do Dev Factory e no próprio Git. Por baixo, o control plane cria, nomeia, isola e mede cada recurso na conta AWS da empresa, com as regras que a TI definiu.
O caminho inteiro, em quatro passos.
Cada passo tem dois lados: o que o desenvolvedor vê no console e o que a plataforma faz por baixo, na conta AWS do cliente. Nenhum deles depende de chamado.
Login corporativo
Microsoft Entra ID ou Google. A mesma identidade do resto da empresa.
Cria o projeto
Um repositório por aplicação, no GitHub ou no GitLab, a partir de um template.
Provisiona do catálogo
Armazenamento, bancos, filas, imagens e bases de conhecimento de IA, sem fila.
Publica pela tela de Releases
A mesma imagem de dev a qa e a prod, com aprovação para produção.
Entra com a identidade que a empresa já usa.
Microsoft Entra ID ou Google, configurado no Dev Factory Setup. Não existe usuário local para criar, senha nova para lembrar nem acesso à conta AWS para pedir.
Os projetos de que participa, e nada além.
- Login com a conta corporativa, sem cadastro à parte.
- Os projetos em que é membro, com o seu papel em cada um.
- As ações do console liberadas conforme o papel: owner, admin, editor ou viewer.
- O próprio consumo de IA, por período e por modelo.
Identidade da empresa, autorização da plataforma.
- Autentica no provedor corporativo, via OIDC.
- Resolve os papéis em dois escopos: a plataforma e cada projeto.
- Emite chaves de IA individuais, com validade, revogação e modelos permitidos.
- Registra a atividade na trilha da plataforma, com pessoa e projeto.
Um formulário no lugar de um chamado.
O projeto é a unidade de isolamento, de permissão e de custo da fábrica. Tudo o que nasce depois, de repositórios a recursos e releases, pertence a ele.
Escolhas, não configurações.
- Nome e tags da taxonomia da empresa, com valores sugeridos pelo administrador.
- O template de cada aplicação: React, Vue, .NET, Node ou Python; frontend, backend, service ou worker.
- Os repositórios no GitHub ou no GitLab da empresa, um por aplicação.
- Quem participa: o Owner do projeto gerencia membros e papéis depois, pelo catálogo de acesso da plataforma.
Tudo que o projeto precisa nasce junto.
- Cria os repositórios a partir do template, com a CI configurada e autenticada na AWS por OIDC, sem segredo estático.
- Registra a aplicação no provedor de identidade e cria os grupos por ambiente.
- Separa dev, qa e prod, com namespace, bucket, banco e chaves isolados.
- Aplica nomenclatura e tags da empresa, a base da alocação de custo.
Recurso pronto em segundos, já com dono e custo.
S3, ECR, DynamoDB, bancos, filas e bases de conhecimento de IA, escolhidos de um catálogo que a TI governa. Um bucket fica ativo em menos de cinco segundos.
O recurso e o jeito de usá-lo.
- O catálogo de recursos da plataforma, por ambiente.
- O recurso ativo no ambiente escolhido, sem esperar a infraestrutura.
- O kit de conexão atualizado: URLs, autenticação e exemplos, em JSON e em Markdown.
- Os dados de cada ambiente no Data Explorer, sem acesso direto ao banco.
Cria do jeito da empresa, e mede.
- Provisiona na conta AWS do cliente, com a identidade da plataforma.
- Nomeia e etiqueta cada recurso com projeto, ambiente e dono.
- Isola por projeto × ambiente: um projeto nunca endereça os dados de outro.
- Começa a medir o custo, por projeto e por ambiente.
- Remoção por solicitação: com o controle ativado, um operador aprova.
A aplicação usa os recursos pelos serviços de plataforma, por HTTPS, e nunca recebe credencial AWS. Entenda o contrato.
Build once, deploy many.
A tela de Releases mostra cada versão da aplicação e em que ambiente ela está. Promover é levar a mesma imagem ao próximo degrau. Produção exige aprovação.
- TemplateO ponto de partida escolhido no passo 2: estrutura, build, deploy e observabilidade já ligados.
- BuildA CI no GitHub ou no GitLab, autenticada por OIDC, constrói a imagem uma única vez e a publica no Amazon ECR do cliente, versionada por tag.
- devA versão nova chega ao ambiente de desenvolvimento do projeto, com os recursos de dev.
- qaPromovida para homologação sem rebuild: a mesma imagem, com os recursos de qa.
- prodPublicada com aprovação de administrador, em cluster separado, identificada pelo digest da imagem.
Cada versão, e onde ela está.
- As versões da aplicação, com tag e status do pipeline.
- O ambiente em que cada versão está publicada.
- A promoção para o próximo ambiente.
- A publicação em produção, sujeita à aprovação.
Uma imagem, três ambientes.
- Promove a imagem identificada por digest, sem reconstruir.
- Exige aprovação de administrador para produção.
- Publica produção em cluster separado de dev e qa.
- Rastreia o release: quem publicou, o quê e quando.
O scan de segurança vive no mesmo portal do projeto.
Em qualquer versão, o Code Security Review analisa o código na conta do cliente e devolve os achados no portal, mapeados a OWASP, CWE e MITRE ATT&CK. A correção volta como merge request e segue pela mesma esteira até a próxima release.
- SolicitarUm operador dispara o scan de uma aplicação ou do projeto inteiro, em profundidade Rápida ou Completa.
- ExecutarO motor roda na conta AWS do cliente, sobre Amazon Bedrock, na versão atual de cada repositório. O código não sai do ambiente.
- VisualizarOs membros do projeto leem severidade, evidência e remediação, e acompanham a evolução de versão em versão.
- CorrigirPrompt de correção para o agente de IA do time, ou correção autônoma entregue como merge request, revisada antes de publicar.
O consumo de IA de cada scan entra no mesmo painel de custo do projeto. Ver o Code Security Review.
Cada passo deixa rastro de governança e de custo.
Como todo recurso nasce pelo control plane, o Platform Admin enxerga o que os quatro passos produziram: quem acessa o quê, como o portfólio se organiza e quanto custa cada projeto, ambiente, pessoa e modelo.
- Controle de acessoOs papéis resolvidos no login e atribuídos nos projetos, nos dois escopos.
- Taxonomia de tagsAs tags escolhidas na criação do projeto viram filtro, visão salva e eixo de custo.
- Uso e custoOs recursos provisionados do catálogo, com o custo estimado por projeto e por ambiente.
- Consumo de IATokens das chaves individuais e do gateway de IA, por pessoa, projeto e modelo.
- ObservabilidadeA telemetria das aplicações publicadas, agregada entre projetos e ambientes.
- ConfiguraçõesParâmetros da plataforma ajustados em tempo de execução, sem redeploy.
Todas as telas do Platform Admin exigem o papel de administrador da plataforma. Ver a administração.
Do requisito ao software. Em dias.
Agende uma sessão de trabalho com a sua TI e duas áreas de negócio: 2–3 casos e os primeiros 90 dias.