Projetos / Slipway github.com/a7t-ai/slipway

  • [autopilot]
  • [architect]

Slipway

Toolkit de auto-publicação para apps iOS.

Eu lanço quatro apps iOS nas horas vagas. Slipway é o toolkit que cuida de tudo entre "feature mergeada na main" e "build entregue no TestFlight com metadata da App Store preparada". A próxima feature recebe o meu tempo; o ritual de release, não.

fastlane/Fastfile.delivery.rb 
1
2
3
4
5
6
7
8
9
10
11
12

lane :deliver_to_testflight do |options|
  scheme = options[:scheme] || ENV["APP_NAME"]
  groups = (options[:groups] || "").split(",").map(&:strip)
  notes  = options[:release_notes]

  build_app(scheme: scheme)
  upload_to_testflight(
    groups: groups,
    changelog: notes,
  )
end
# the only delivery flow I trust on a cron
Slipway

Eu lanço quatro apps iOS nas minhas horas vagas:

  • FareHawk: alertas calmos de tarifas aéreas. Paga uma vez, acompanha para sempre.
  • Kinderuntersuchungsheft: a caderneta amarela alemã da pediatria, agora digital. Cada U-Untersuchung e vacinação STIKO no seu celular.
  • Einbürgerung Pro: o jeito limpo e moderno de se preparar para o teste de cidadania alemã. As 310 perguntas, 11 idiomas de tradução, simulados e repetição espaçada.
  • Reellette: recomendações de filmes e séries com IA para te ajudar a decidir o que assistir hoje.

O Slipway existe por causa do FareHawk e do Reellette. Foram os dois primeiros, cada um cresceu seu próprio pipeline de release em paralelo, e os pipelines acabaram 85% iguais e 15% exatamente o que faltava no outro. Juntar tudo num toolkit só deu menos trabalho do que consertar o mesmo bug duas vezes a cada sexta-feira. Os outros dois apps agora rodam no mesmo template.

O Slipway não é um binário nem um serviço. É um conjunto de workflows do GitHub Actions, lanes do Fastlane e scripts auxiliares que você copia para o seu projeto iOS. O trabalho sai da sua sexta-feira à tarde e vai parar num runner que já tem o seu código, e te devolve o tempo.

O que ele faz, de fato

Um slipway é a rampa que coloca o barco na água. O toolkit faz o mesmo com um build iOS: pega o que acabou de cair na main, bumpa a versão, builda e notariza, faz upload de metadados e screenshots, entrega no TestFlight, atribui aos grupos de beta e escreve as release notes. De git merge a “build disponível” é um workflow de segunda de manhã disparando, sem sessão do Xcode no meio.

O pipeline mora inteiramente no GitHub Actions para orquestração e cron, nas lanes do Fastlane para o trabalho no App Store Connect e os passos de build e notarização, e num punhado de helpers em Bash e Ruby para as tarefas pequenas: geração de ícones, composição de screenshots, interpolação das release notes.

O ciclo de release

Três workflows orquestradores conduzem uma semana inteira. Terça de madrugada, uma cadeia de submissão bumpa a versão, preenche os metadados na App Store, gera as release notes, builda e notariza, sobe para o TestFlight e submete para revisão. Uma hora depois, um segundo workflow taggeia a versão recém-submetida e bumpa o número de marketing para que os commits da nova semana caiam numa versão fresca. A versão fica na fila de revisão da Apple por três a cinco dias. Sexta-feira ao meio-dia, um terceiro workflow encontra o build agora aprovado e ativa o phased release.

Arraste a barra ou clique em play.

O que vale a pena copiar

O compositor de screenshots da App Store. A parte mais difícil de um release não é o binário. É que o App Store Connect quer nove tamanhos de tela diferentes, cada um com texto de marketing sobreposto no lugar certo, cada um com o device frame certo. O compositor do Slipway pega uma pasta de snapshots de UI (gerados pelo seu target de XCUITest) e produz a matriz nove-por-nove por idioma. Se você lança metadados localizados, isso economiza um dia por release.

A lane de release notes lê CHANGES_IN_VERSION.md, puxa os bullets acima do header ### Default Release Notes, manda para a persona de copywriting refinar e faz upload. Se a seção de cima estiver vazia depois de uma semana corrida, a piscina de fallback abaixo do header é amostrada aleatoriamente para que a entrada na App Store nunca saia com release notes vazias.

O version bumper usa calver: YY.MM.PATCH. O Slipway deriva a tag da data, o número do patch da quantidade de releases no mês, e escreve de volta no .xcconfig para o build bater.

O que está deliberadamente fora de escopo

macOS, tvOS, watchOS. Slipway é o pipeline iOS. O mesmo formato funciona para os outros, mas as lanes são diferentes o suficiente para eu não ter puxado para o merge.

Crash reporting e analytics. Questões a nível de app, não de pipeline.

Gerenciamento de beta testers. O Slipway atribui aos grupos existentes do TestFlight; não gerencia quem está dentro.

De onde veio

FareHawk contribuiu com o pipeline de metadados da App Store, o gerador de ícones e o compositor de screenshots: as peças que tocam o App Store Connect.

Reellette contribuiu com a geração de snapshots de UI, o pipeline de unit-test no CI, e a convenção de bump de versão.

Os dois apps agora rodam em cima do Slipway. Slipway é o que eles teriam sido se eu tivesse começado os dois no mesmo dia com o mesmo template.

Como rodar

Repo: https://github.com/a7t-ai/slipway. O README cobre os secrets necessários (chave de API do App Store Connect, certificados do Match, etc.) e as lanes do Fastlane que dá para mapear no seu app existente.

O que eu faria por você

Se você tem um app iOS onde lançar ainda parece um ritual manual (abrir o Xcode, arquivar, fazer upload, trocar para o App Store Connect, colar as release notes), o Slipway tira uns 90% disso da sua mesa numa sessão focada. A parte mais difícil normalmente é convencer o lado da Apple (certificados, chaves de API, roles no App Store Connect); o toolkit cuida do resto.