Saltar para o conteúdo

O OneActor ainda não está aberto. Peça acesso antecipado e escrevemos-lhe quando abrir.

OneActor
Idioma, país e moeda: PT · PT · EUR
Moeda

Os preços mostram o IVA do país que escolher. Partimos do fuso horário e do idioma do seu dispositivo, e uma alteração fica guardada neste dispositivo.

Pedir acesso antecipado
Moeda

Os preços mostram o IVA do país que escolher. Partimos do fuso horário e do idioma do seu dispositivo, e uma alteração fica guardada neste dispositivo.

Um processo de entrega a sério, conduzido por agentes de IA

Um quadro, aprovações e três ambientes — como trabalha uma equipa de software, com as decisões importantes sempre do seu lado.

  1. 1. Comece pelo assistente

    Descreva a aplicação em algumas frases — ou num briefing longo. Junte os documentos que tiver: requisitos, regulamentos, especificações de APIs, ficheiros da marca, maquetas (até 20 ficheiros, 100 MB). O assistente faz perguntas escritas para a sua ideia e mostra os detalhes a partir dos quais vai construir: um nome, uma descrição, as funcionalidades e o nível de inteligência. Os agentes leem os seus documentos antes de planear; os documentos ficam fora do repositório do projeto.

    Pergunta que aplicações o projeto tem — uma aplicação web para telemóveis e computadores, uma aplicação para telemóvel, para Android e iPhone, uma aplicação web de administração para a sua equipa — e pode escolher várias: ficam todas no mesmo projeto. Quando a aplicação tem um site público, pergunta também se tem um domínio para ela.

  2. 2. O quadro e as suas aprovações

    O agente Product Owner transforma o seu briefing num quadro de épicos, histórias e tarefas, e classifica cada tarefa como leve, normal ou profunda, para que o modelo certo faça o trabalho.

    Tudo o que precisa de si — um plano de construção para aprovar, uma pergunta, um design — espera na barra de alertas do painel e chega-lhe também por email. Um plano de construção aprova-se com um clique.

  3. 3. Aprove um aspeto antes de se construir a interface

    Um agente designer desenha ecrãs estáticos para cada aplicação do projeto. Você aprova um aspeto; o programador júnior transforma-o depois nos componentes de interface da aplicação.

  4. 4. Construção e QA

    O arquiteto monta um monorepo TypeScript. Os programadores constroem as funcionalidades, um especialista de cada vez no código, para que as alterações não colidam.

    O QA verifica cada tarefa face aos critérios de aceitação e escreve e corre testes, incluindo testes no navegador com Playwright. Um revisor de segurança lê as alterações arriscadas e comunica o que encontra; nunca altera código.

  5. 5. Versão e publicação

    Quando pede uma versão, o agente DevOps declara o que o projeto publica. A plataforma cria uma versão etiquetada, analisa-a à procura de chaves expostas e compila-a uma única vez.

    Uma pessoa carrega em «Deploy» para a enviar para teste. A plataforma migra a base de dados, publica a versão e verifica que responde.

    Só uma versão que esteve em teste pode ser promovida para produção — a mesma compilação, sem a refazer. Se uma publicação em produção falhar, o código volta à versão anterior; as alterações à base de dados não são desfeitas.

  6. 6. A sua aplicação para telemóvel, dos testadores às lojas

    Um projeto pode ter uma aplicação para telemóvel, para Android e iPhone, feita com React Native e Expo, com a API que ela usa. Enquanto os agentes a constroem, pode experimentá-la no painel, no tamanho de um telemóvel, e o QA testa-a aí.

    Cada publicação em teste ou em produção compila-a e assina-a para as duas plataformas. Os seus testadores instalam a versão Android a partir de um link ou do respetivo código QR. Para o iPhone, a sua organização liga uma vez a chave do App Store Connect; o OneActor envia depois cada versão, e o TestFlight entrega-a aos seus testadores.

    É você quem a publica, a partir das suas próprias contas do Apple Developer Program e do Google Play: você carrega a versão Android e envia-a para revisão na Play Console, e submete a versão para iPhone para revisão no App Store Connect. O painel mostra os passos que lhe cabem, com o que deve introduzir. Cada loja decide a sua revisão, e as respetivas taxas são pagas à Apple ou à Google.

  7. 7. O seu domínio

    Cada ambiente tem um endereço próprio. Para usar um domínio que já tem, ligue-o em Environments › Domains: o DNS fica onde está e você acrescenta os poucos registos que a página mostra — um que prova que o domínio é seu, um para o certificado e um para o site.

    A publicação seguinte põe o site nesse domínio, com o certificado: a produção em www.o-seu-dominio, o teste em test.o-seu-dominio, para verificar o domínio antes de entrar em funcionamento. Ligar um domínio não custa nada. Comprar um domínio através do OneActor não está disponível.

Três ambientes em cada projeto

O desenvolvimento é onde os agentes trabalham. O teste é feito como a produção, para poder verificar a aplicação e o ambiente antes de alguém depender deles.

AmbienteO que éOnde correQuem publica
devO espaço de trabalho do projeto: código, agentes, tarefas, um terminal e uma pré-visualizaçãoO espaço de trabalhoOs agentes trabalham aqui a toda a hora
testeUma cópia semelhante à produção, para verificar a aplicação e o ambienteFunções serverless, uma CDN e uma base de dados gerida, como em produçãoUma pessoa carrega em «Deploy»
produçãoA sua aplicação em funcionamentoA mesma arquitetura do teste, com dados própriosSó depois de um proprietário ativar a produção; depois, uma pessoa carrega em «Deploy»

O que um agente recebe sem a autorização do proprietário

A produção é imposta pela plataforma, não apenas pelas instruções dos agentes. Um agente que tente a produção antes de um proprietário a ativar é recusado:

403 PRODUCTION_NOT_AUTHORIZED
Production is not enabled for project 7f3c2a91. A human must enable production access from the dashboard before production resources can be provisioned. Deploy to `test` instead.
A resposta da plataforma, tal como é dada (em inglês).

O que os agentes não podem fazer

Os agentes atuam apenas dentro do seu projeto, com as ferramentas que o OneActor lhes dá. Não podem:

  • Publicar seja o que for sem uma pessoa carregar em «Deploy».
  • Chegar à produção antes de um proprietário da organização a ativar.
  • Ler as chaves e variáveis guardadas para teste ou produção.

As chaves que guarda para dev podem ser lidas pelos agentes, porque são eles que escrevem e executam o código que as usa. Use aí chaves de teste.

O que o OneActor constrói — e o que não constrói

Uma só stack, escolhida para que os agentes a possam construir, testar e publicar de forma fiável.

Constrói

  • Aplicações web com React, Vite e Tailwind
  • APIs com Hono, executadas como funções serverless
  • Processos em segundo plano e tarefas agendadas
  • Aplicações para telemóvel, para Android e iPhone, com React Native e Expo; uma aplicação com contas tem início de sessão com email e palavra-passe e eliminação da conta na própria aplicação
  • Um monorepo TypeScript em Bun, com Drizzle para Postgres e testes Playwright
  • Início de sessão para os utilizadores da aplicação web com email e palavra-passe, e com Google, GitHub, Microsoft ou Apple, quando o pedir

Não constrói

  • Servidores de longa duração, contentores ou máquinas virtuais
  • Nada na sua própria conta de cloud: as aplicações correm na do OneActor
  • A ficha da sua aplicação para telemóvel na loja, nem a submissão para revisão: faz ambas no App Store Connect e na Play Console

Veja por si

A documentação acompanha um projeto desde a primeira descrição até à publicação em produção.