Como criar uma página de changelog: entradas, tags, RSS e "novidades"

Uma página de changelog é uma lista datada do que mudou no seu produto, da mais recente para a mais antiga, escrita para quem usa o produto. Para criar uma, você precisa de entradas com data, um título claro, uma explicação curta e uma tag (Novo, Melhorado, Corrigido), uma página que as liste, uma URL separada para cada entrada e, idealmente, um feed RSS e uma forma de avisar o usuário de que algo é novo. É uma das coisas mais simples que você pode construir, e a principal decisão é onde as entradas vivem: como arquivos no seu site ou em um banco de dados com uma página administrativa.

Por que vale ter um changelog

Um changelog mostra a clientes e possíveis clientes que o produto é mantido. Dá ao suporte e às vendas um link para enviar quando alguém pergunta "isso já faz X?". Também é um lugar para fechar o ciclo do feedback: quando um recurso pedido é lançado, a entrada do changelog é para onde você direciona as pessoas. Se você mantém um portal de feedback de clientes, linke os pedidos lançados diretamente para as suas entradas.

Um changelog não é o histórico interno de commits. "Refatoramos o serviço de cobrança" não significa nada para um usuário. "As faturas agora mostram o número de IVA da sua empresa" significa.

O que a página precisa

Conteúdo de cada entrada

Páginas

• Índice do changelog: do mais recente para o mais antigo, com filtros por tag e paginação simples ou "carregar mais".
• Página da entrada: uma entrada por URL, para que possa ser linkada e compartilhada.
• Feed RSS ou Atom: permite que as pessoas e as ferramentas acompanhem as atualizações sem e-mail.
• Página administrativa (só na versão com banco de dados): escrever, pré-visualizar, agendar e publicar entradas.

Extras no app

• Selo de "novidades": um ponto em um item do menu quando há entradas que o usuário ainda não viu. Guarde a data da última entrada que ele abriu, por usuário ou no navegador.
• Resumo por e-mail: um resumo enviado a quem optar por recebê-lo. Isso exige um provedor de envio; veja como enviar e-mails pelo seu app.

A decisão principal: arquivos ou banco de dados

Entradas como arquivos no site

Cada entrada é um arquivo Markdown no projeto. Publicar uma entrada significa adicionar um arquivo e fazer um novo deploy. É a abordagem mais simples e robusta: sem banco de dados, sem login administrativo, nada para proteger, e as páginas podem ser pré-renderizadas, então carregam rápido e são fáceis de ler para os mecanismos de busca.

Ela serve para equipes em que quem escreve as entradas se sente confortável em pedir a um criador com IA ou em editar um arquivo.

Entradas em um banco de dados com página administrativa

As entradas ficam em uma tabela, e uma página administrativa privada permite que qualquer pessoa da equipe escreva, pré-visualize, agende e publique. Serve para equipes em que marketing ou suporte escrevem as atualizações, ou quando você quer publicação agendada ou entradas por público (por exemplo, mostrar recursos empresariais apenas para clientes empresariais).

O custo é mais trabalho para construir e manter: um login administrativo, envio de imagens e garantir que as páginas públicas continuem legíveis pelos mecanismos de busca, o que uma página que só carrega as entradas no navegador pode não permitir.

Escrevendo entradas que as pessoas leem

• Comece pelo benefício. "Exporte relatórios para o Excel" vence "Novo módulo de exportação".
• Diga quem tem acesso. Todos os planos, só no Pro, disponível gradualmente esta semana.
• Mostre. Uma captura de tela ou um pequeno vídeo.
• Agrupe as correções pequenas. Uma entrada semanal de "Correções e melhorias" com tópicos evita que a página fique inundada.
• Seja honesto sobre remoções. Se algo vai sair, diga quando e o que usar no lugar.

Um primeiro prompt que funciona

Adicione um changelog público ao nosso site em /changelog. Cada entrada é um arquivo Markdown com título, data, tag (Novo, Melhorado ou Corrigido), imagem de capa opcional e corpo. A página de índice lista as entradas da mais recente para a mais antiga, com data, tag e o primeiro parágrafo, tem botões de filtro por tag e mostra 10 entradas por página. Cada entrada tem sua própria página em /changelog/<slug>, com título e descrição adequados para os mecanismos de busca. Adicione um feed RSS em /changelog/rss.xml. Crie três entradas de exemplo. Siga o design atual do site, mantenha a leitura confortável em celulares e pré-renderize as páginas para que carreguem rápido.

Para a versão com banco de dados, troque a primeira frase por "Guarde as entradas em um banco de dados com status de rascunho/publicado e uma data de publicação, e adicione uma página administrativa protegida por senha para escrever, pré-visualizar e publicar."

Etapas de construção

1. Decida entre arquivos ou banco de dados usando a tabela acima.
2. Construa as páginas de índice e de entrada com algumas entradas de exemplo.
3. Adicione tags e filtros.
4. Adicione o feed RSS e linke-o a partir da página.
5. Adicione títulos de página, descrições e uma entrada no sitemap para cada entrada. Nosso guia de SEO para sites criados com IA cobre o básico.
6. Página administrativa e login, se você escolheu o caminho do banco de dados.
7. Selo de "novidades" no seu app.
8. Escreva entradas reais dos últimos meses para que a página não seja lançada vazia.

Erros comuns

• Copiar mensagens de commit. Escreva para usuários, não para desenvolvedores.
• Uma página gigante, sem URLs por entrada. Ninguém consegue linkar uma mudança específica, e os mecanismos de busca veem uma página em vez de muitas.
• As atualizações param depois de um mês. Um changelog atualizado pela última vez há um ano sugere um produto abandonado. Defina um ritmo que você consiga manter.
• Carregar as entradas só no navegador. Mecanismos de busca e pré-visualizações de links podem ver uma página vazia. Pré-renderize ou renderize no servidor.
• Misturar incidentes. Quedas de serviço pertencem a uma página de status, não ao changelog.

Quando uma ferramenta de changelog hospedada é a escolha melhor

Existem ferramentas hospedadas de changelog e de atualizações de produto, e algumas vêm incluídas com quadros de feedback ou widgets no app. Elas valem a pena se você quer um pop-up dentro do app, segmentação de público e análises sem construí-los, ou se a sua equipe já paga por uma ferramenta que inclui um. O seu software de blog ou de central de ajuda também pode ter um formato adequado já pronto.

Criar o seu próprio faz sentido quando você quer o changelog no seu próprio domínio, no seu próprio design e totalmente indexável, o que, para uma lista simples de publicações datadas, não dá muito trabalho.

Criando com o Mythex

No Mythex, você pode pedir ao agente para adicionar um changelog a um projeto existente ou construí-lo como um pequeno site próprio, e ver o resultado na pré-visualização ao vivo enquanto ele é construído. A versão baseada em arquivos não precisa de banco de dados. Se você escolher a versão administrativa, o agente adiciona um banco de dados Postgres dedicado quando as entradas precisarem ser salvas (ou digite /database), e as capturas de tela ficam no armazenamento de arquivos do projeto. O login administrativo é algo que você adiciona com a sua própria abordagem de autenticação (receita de login).

Apps novos do Mythex costumam ser aplicações de página única renderizadas no cliente, que a receita de SEO indica como mais fracas para busca; então peça páginas de changelog estáticas ou pré-renderizadas se quiser que as entradas sejam encontradas na busca. A mesma receita cobre títulos, descrições e sitemaps. Para um ponto de partida com um changelog integrado, veja o modelo central de conhecimento do produto.

Perguntas