Os desafios na construção do Changelog
Changelogs, notas de versão, release notes, novidade, são importantes em diversos graus, como pude explicar na minha história com changelogs, postagem que saiu na última semana, recomendo a leitura. Porém, o que levou a gente a começar a não se importar tanto com eles, e estar utilizando versões bem padronizadas e sem graça. Hoje é raro aplicativos sendo lançados com changelogs.
O problema
A importância foi diminuindo, e agora não temos quase nada. Algo como:
O nosso roxo ficou mais roxo. O simples ficou mais simples. Nosso time de engenharia trabalhou essa semana corrigindo bugs.
Textos que podem ser feitos para os próximos 5 anos que nada vai mudar, é tão atemporal, só não importa mais o que está sendo atualizado. O marketing já pode deixar pronto.
Tanto é que já tem realmente 2 meses que está sendo a mesma mensagem, apesar de atualizações diretas (incluindo tema escuro, nova navegação pela aplicação). Uma das poucas exceções foi ao falar da nova moeda do Nubank.
E assim, o print anexado nesta postagem é do ano passado.
Mas vamos falar sobre o texto na mensagem, me vem a pergunta, TODOS os bugs mesmo corrigidos? Não tinha falado isso semana passada? Eu até pensei em trocar as palavras e ocultar o logo pra que ninguém descobrisse de qual app eu estava falando, mas que vocês já iriam reconhecer na hora. Ele é bem famosinho por isso.
Eu faço agora o exercício de entender o motivo não conseguem colocar o que foi feito no aplicativo.
Problemática #01: DevOps
Já tentaram fazer alguns serviços, pacotes ou metodologias que resolvessem isso. Algumas são terríveis e outras dão nojo. Mas pelo menos estão tentando. Fazer algo para DevOps é um desafio, especialmente para integrar com as lojas de aplicativos um texto que deve ser sempre revisado por times que não são de pessoas desenvolvedoras.
Conventional Commits
Mas ainda estamos caminhando lentamente nesta direção, e uma das maneiras de fazer isso é através de padronizar como commits são escritos. O famoso Conventional Commits.
Como funciona? Basicamente na mensagem do commit você adiciona algumas coisas que dizem o que foi feito no código.
Se adiconar um
feat! para informar que é uma feature que tem quebra de contratos ou, em inglês, breaking changes.
Ou se adicionar um feat(lang) pra informar que foi adicionado um novo idioma.Tem várias regrinhas de como utilizar, não é tão simples como eu estou expondo aqui, mas é só entrar em conventionalcommits.org que tá lá!
E aí por manter o padrão bonitinho é possível ter ferramentas que sabem ler, trabalhar e automatizar o processo com isso. É bem interessante a proposta, porém pouco útil se você deseja fazer marketing. Pelo menos ajuda na criação de documentação do seu código.
É tão séria essa brincadeira que fizeram um lint – um lint! – pra isso. Se você não sabe o que é lint ou acha que ele é seu amigo, terapia ajuda. Terapia ajuda. Brincadeira, mas é possível forçar que seu time de desenvolvimento utilize o Conventional Commits, usando o lint a mensagem do commit que não está nos padrões é bloqueado.
Semantic Releases
Aí vem um tal de Semantic Releases que permite que você utilize qualquer coisa – e eu digo isso pois tem vários plugins por aí, e ainda você pode fazer o seu – para ler ou transformar o que você digitou lá mensagem do commit durante o seu processo de Build em um Pipeline.
Inclusive plugins que podem escrever notas de versão de forma automática! Ok, meu trabalho agora está feito aqui. Obrigado por lerem esta postagem, até a próxima.
Problemática #02: Feature Flags ou Betas
Brincadeira! Ainda temos uma segunda problemática, pois se fosse só DevOps talvez nossas vidas seriam mais fáceis.
Hora de falar de um queridinho dos PMs, dos Designers, e odiado por vários devs: o feature flag. Aquele ifzinho que tem no código pra saber se o aquele usuário específico terá essa função ou não. Qual que é o problema disto para nosso changelog? Simples! Se uma pessoa tem acesso e nem todo mundo tem acesso, então não pode-se colocar no changelog né?
Daí não tem muita ferramenta pra auxiliar nisso não, só três possíveis manobras.
Ser sincero
Ser sincero e dizer: “Olha... Estamos lançando isso para alguns usuários, você talvez receba na próxima onda”.
Talvez não seja a melhor forma de mostrar para o usuário o que está acontecendo, mas se você está rodando um programa em beta – que é público – ou seu produto ou serviço é algo gratuito, talvez, só talvez, seja mais fácil implementar isso. Eu sempre vou preferir ir pela sinceridade, mas nem sempre é possível.
Quem faz isso e o faz muito bem é o Windows Insider, que sempre ao exibir uma nova versão do Windows para seus testadores, avisa que algumas funções podem não estar disponíveis por estarem sendo realizados testes. Mas o release notes está lá.
Omita
Ou Omita! Esconda! Não fale nada! Silêncio, o que você está olhando aqui? Não tem nada aqui.
Trabalhar com funções que ainda não estão disponíveis para o público em geral é frustrante pra quem precisa documentar e criar changelogs. Inclusive, lembrei aqui que estou há paragrafos de intimidade com você e não falei que changelogs fazem parte da documentação. Só pra deixar claro, caso alguém ache que não.
Você sabia que o git salva só as alterações de códigos entre um commit e outro, né? Se fizer um changelog interessante, ele funciona de uma forma bem semelhante.
Mas é um exercício que tenho feito ultimamente, maior parte do tempo do meu antigo time era criar documentações para produtos que ainda não estão disponíveis para todos, então como podemos no final de uma sprint sentar e falar “Ah, vamos escrever as nossas notas de versão”? Simples! Por mais que você esteja trabalhando em funções novas, sempre vai existir – e eu disse SEMPRE vai existir – um bug. Alguma coisa que você vai trabalhar que de fato é disponível pra todos. Ou aquela sua feature que tava oculta há tanto tempo, em algum momento ela vai sair.
Não acho justo que um aplicativo seja atualizado sem que NADA tenha sido feito na versão que está rodando no meu celular. É fazer eu gastar meus dados atoa. Talvez já tenhamos nos acostumado a realidade como pessoas desenvolvedoras e privilegiadas, e não lembramos que num país tão grande como o nosso – ou o mundo (pq afinal, viajamos e não devemos pensar só em brasileiros usando nossos aplicativos) – nem todo mundo tem a capacidade de ficar baixando as vezes 50mb só pra não ter alteração nenhuma. Se nada vai acontecer com o seu aplicativo, não atualize. Uma base específica precisa? Bem, já ouviu falar de microfrontends? Não force teu usuário a baixar algo que é inútil pra ele. Ponto!
Espere a próxima atualização pra levar pra frente essa feature flag.
Bobagem essa história de toda semana tem que ter atualizações do app! Tem que ter atualizações quando realmente tiver atualizações no seu app.
Problemática #03: lojas de aplicativos
Enviar essas notas de versão pras lojas pode ser um pain in the ass, então tem uma solução mais simples: o seu changelog não precisa estar atrelado ao aplicativo.
Um blog, um Tweet, uma maneira de falar o que está acontecendo, quem tem interesse vai atrás. Não é como “ah vamo deixar na mão do usuário ir atrás dessa informação” é do tipo “o usuário busca por essas informações”, encaminhar ele dentro do aplicativo ou nas notas de versão que vai na loja de aplicativos já é suficientemente bom.
E se o marketing for bem feito, ele primeiro vai ver as mudanças para então correr atrás da App Store ou da Google Play e pedir pra atualizar o app.
E quando você se desprende dessa, você consegue apelar pra algo que não está atrelado ao código do seu app.
Como eu tenho feito? Tenho escrito meu markdown bonitinho, salvo ele num repositório do GitHub e deixado pra esse projeto Formula.Releases fazer todo o resto.
É um projeto com licença aberta e que precisa de ajuda.
A proposta do projeto é que rodando no Azure, ele lê o que está num repositório do GitHub e transforma em um endpoint para receber informações baseado nos arquivos markedown que está no repositório.
Com isso foi possível incorporar as notas de versão no meu blog, no wordpress, e no meu aplicativo, enquanto a escrita e o fonte dessa informação é algo familiar aos tech writers: um simples markedown.
É só um início da conversa
A proposta aqui, nessas duas postagens, não foi falar que deve ser feito de tal jeito ou de outro, e sim de chamar a atenção para uma das coisas que foram se perdendo com o tempo na nossa área e que precisamos retomar e dar a importância digna a ela.
É realmente pra ser um início de uma conversa, para se atentar nestes detalhes, para chamar o time de marketing, de tech writer, de devops e conversar em como pode ser diferente. Quem sabe uma solução não venha a partir disso?