Versões e publicação

Construir e servir são duas coisas diferentes, e a plataforma separa-as com duas peças: as versões (ramos da app, cada um com o seu desenho e os seus dados) e a publicação (que endereço serve que versão).

A regra que resume tudo: cada host serve UMA versão desta app. Publicar não é "pôr no ar" — é escolher que versão um endereço serve.

#As versões de uma app

Uma versão é um ramo completo da aplicação: os ecrãs, o modelo, as APIs, os scripts, os workflows, os relatórios e os dados. Duas versões não partilham nada — mexer numa não toca na outra.

O menu das versões está no cabeçalho da árvore da app, ao lado do botão de definições. O que ele mostra é a tua versão de trabalho:

Elemento	O que faz
A lista de versões	Clicar numa linha troca a tua versão de trabalho para ela. O visto marca a actual.
⟲ (em cada linha)	Abre o histórico dessa versão — o que mudou, quando e por quem.
🗑 (em cada linha)	Apaga a versão.
Nova versão…	Cria um ramo.
Merge selectivo…	Traz alterações escolhidas de uma versão para outra.

Numa app que nunca teve versões, o menu diz "Esta app ainda não tem histórico.".

#Criar uma versão

1. Abre o menu das versões e clica em Nova versão….
2. Preenche o Nome (por exemplo 1.1) e escolhe A partir de — a versão de origem.
3. Clica em Criar versão.

"Cria um ramo a partir da versão de origem, com os dados copiados. A versão nova não é servida por nenhum host até ser associada a um."

Duas consequências que vale a pena reter:

• Os dados são copiados, não partilhados. A 1.1 nasce com uma cópia do que a main tinha nesse instante; a partir daí, seguem vidas separadas.
• Ninguém a vê, até publicares um endereço a apontar-lhe. Podes trabalhar meses numa versão sem que nenhum utilizador dê por ela.

Assim que a versão é criada, ficas a trabalhar nela ("Versão «1.1» criada — estás a trabalhar nela.").

#Apagar uma versão

O 🗑 de uma linha apaga "o desenho, a base de dados e a história desta versão. As outras versões não são tocadas". Duas protecções:

• a versão main não se apaga;
• a versão em que estás a trabalhar também não — "troca para outra antes de a apagar".

#Publicar

A publicação vive em Definições da app → Geral, na secção Publicação.

Cada linha é um endereço publicado: o host, a versão que ele serve, e o ✕ para Despublicar.

Para publicar um endereço novo:

1. Escreve o host no campo (o exemplo diz ex: mapas.empresa.com) — só o nome, sem https:// nem caminhos.
2. Escolhe a versão que ele passa a servir.
3. Clica em Publicar.

Confirmado, aparece "Host publicado." e a linha nova junta-se à lista.

#Antes de haver endereço nenhum

"Sem hosts publicados — a app responde em /app/{slug} com a versão de trabalho." É o endereço interno de sempre, e é assim que se experimenta uma app antes de lhe dar nome próprio.

Repara na diferença: em /app/{slug} corre a versão de trabalho de quem está a ver; num host publicado corre a versão que o host serve, para toda a gente. É por isso que, em produção, se publica sempre um host — para o que os utilizadores vêem não depender de em que ramo alguém está a trabalhar.

#Despublicar

O ✕ da linha (Despublicar) tira o endereço. A versão não é tocada — deixa apenas de ser servida ali.

Para mudar de versão num endereço já publicado, despublica e publica outra vez com a versão nova. É a operação de "pôr a 1.1 em produção", e demora segundos.

#A app a correr

Um endereço publicado serve a aplicação construída. Quem lá chega não vê a plataforma: vê o ecrã de entrada da app, com o tema dela.

A partir daí, o que cada pessoa consegue fazer depende da conta com que entra e dos papéis dela — matéria da página Utilizadores da app. Os ecrãs de entrada, registo e recuperação são desenháveis, e têm página própria: Ecrãs públicos e registo.

#Um fluxo de trabalho saudável

Uma forma comum de organizar isto numa equipa:

1. main é a versão em produção. O host oficial (crm.empresa.pt) serve a main.
2. Para uma alteração grande, cria-se uma versão (1.1) a partir da main e trabalha-se lá.
3. Para a mostrar a alguém antes do tempo, publica-se um segundo host (crm-teste.empresa.pt) a servir a 1.1.
4. Quando estiver pronta, o host de produção passa a servir a 1.1 — ou traz-se o que interessa para a main com o Merge selectivo….

#O que não viaja com a app

Quando exportas uma app num pacote, o host fica de fora — é desta instalação, e o mesmo pacote instalado noutro sítio vai ter endereços seus. Ficam também de fora o histórico de execuções e as chaves de API. Ver Importar e exportar apps.

#Perguntas frequentes

Troquei de versão e a app parece vazia. Cada versão tem os seus dados. A 1.1 só tem o que existia na origem no momento em que foi criada, mais o que lá foi feito desde então.

Publiquei o host e o browser não encontra nada. Falta o DNS: o nome tem de apontar para esta instalação. Enquanto isso não acontece, usa /app/{slug} para experimentar.

Posso ter dois hosts a servir a mesma versão? Sim. Um host serve uma versão, mas nada impede que várias apontem à mesma — por exemplo, um endereço curto e outro completo.

Apaguei uma versão sem querer. Não há como voltar atrás: apaga o desenho, os dados e a história dela. É a razão para as versões em produção terem sempre um host associado — uma versão servida por um host é uma versão que ninguém apaga por distracção.