Os princípios são baseados na metodologia conhecida da heroku , adaptada às realidades do desenvolvimento do ayios (falta de contêineres, revisões que levam vários dias e desaceleram a implantação, o Xcode funciona apenas em uma papoula).
Este artigo é uma breve introdução, a série completa pode ser encontrada no fator iOS , tradução para o russo também está disponível. O projeto de código-fonte aberto para iOS no github está sendo constantemente refinado e recebe novas idéias. Também participei do seu desenvolvimento. O projeto foi fundado por Felix, que é o criador da fastlane .
TL; DR
- Dependências : devem ser especificadas de forma explícita e específica (versão do Xcode, CocoaPods, versão das dependências no podfile). Isso torna possível para um novo desenvolvedor executar a compilação em qualquer Mac. Repita também a montagem usada há 6 meses.
- Configuração : Nenhuma configuração no código, vem com o aplicativo e a capacidade de atualizar por via aérea
- Desenvolvimento de aplicativos / paridade de trabalho : mantenha os ambientes de desenvolvimento, preparo e produção o mais semelhante possível
- Implantação : automatize a implantação para liberá-la de qualquer máquina.
- Local versus Beck : mantenha seu aplicativo iOS universal, para que você possa trabalhar sem back-end sempre que possível
- APIs compatíveis com versões anteriores : não pense que cada usuário está atualizando para a versão mais recente
- Versão do aplicativo : automatize a versão e construa atualizações
- Reversões : montagem de reversão que causa problemas
- Armazenamento de dados : siga as recomendações da Apple para armazenamento de dados
O aplicativo declara todas as suas dependências de maneira completa e precisa, usando o manifesto da declaração de dependência.
Isso inclui uma versão específica do Swift, Xcode, CocoaPods, Carthgae e Fastlane. Além disso, todas as dependências no podfile e cartfile devem especificar uma versão específica.
Uma das vantagens de declarar explicitamente dependências é que facilita a configuração de aplicativos para novos desenvolvedores.
Com a ajuda da especificação de dependências específicas, você pode reproduzir a compilação usada há 6 meses, sabendo que ela será compilada porque a compilação usará a mesma versão do Xcode, CocoaPods e Swift.
Limitação - Como o desenvolvimento do iOS não pode estar contido em um contêiner, pois já é usado para o desenvolvimento da Web, estamos limitados a ferramentas de terceiros que tentam atender a esse requisito até que a Apple forneça uma solução oficial. Existe uma solução comercial (fechada) de terceiros chamada Veertu que permite criar ambientes virtuais do MacOS no hardware da Apple.
O código não depende do ambiente, mas a configuração depende. Portanto, o código deve ser armazenado no repositório e a configuração no ambiente. Verificar se a configuração e o código do aplicativo estão separados corretamente é o fato de que a base de códigos do aplicativo pode estar disponível gratuitamente a qualquer momento, sem comprometer nenhum dado privado.
Existem várias maneiras de inserir valores de configuração no momento da construção.
- Arquivos de configuração (arquivos JSON ou YAML)
- cocoapods-keys para ocultar as chaves e aplicá-las ao seu aplicativo iOS durante a compilação
- Solução personalizada (por exemplo, usando a fase de construção)
Como as implantações na plataforma iOS são significativamente mais lentas que nos servidores, você pode precisar de uma maneira de atualizar a configuração pelo ar (OTA) para responder rapidamente a problemas.
As atualizações de configuração do OTA permitem:
- Execute testes A / B para ativar determinadas funções ou alterações na interface do usuário apenas para uma parte dos usuários ativos.
- Alterar chaves da API
- Atualizar hosts da web ou outros URLs que foram alterados
- Desabilitar remotamente recursos ou ocultar botões
Algumas abordagens em potencial ao implementar atualizações OTA são:
Historicamente, existem diferenças significativas entre o desenvolvimento (o desenvolvedor faz alterações ao vivo na implantação local do aplicativo) e a operação do aplicativo (implantação do aplicativo na App Store com acesso a ele pelos usuários finais).
Essas diferenças aparecem em três áreas:
- Diferença horária
- Diferença de equipe
- Lacuna da ferramenta:
Solução:
- Reduza a diferença de horário: o desenvolvedor pode escrever o código e ele será implantado em algumas horas ou até minutos.
- Reduza as diferenças de equipe: o desenvolvedor que escreveu o código participa ativamente de sua implantação e monitora seu comportamento enquanto o aplicativo está em execução.
- Reduza as diferenças de ferramentas: mantenha o ambiente de trabalho e desenvolvimento do seu aplicativo o mais semelhante possível.
Conforme descrito no princípio Dependências , o repositório de códigos deve incluir todas as dependências necessárias para criar, testar e implantar o aplicativo iOS.
Infelizmente, devido ao fato de o Xcode funcionar no MacOS, não podemos usar contêineres como na web. A execução do macOS em um ambiente virtual está repleta de problemas técnicos e legais.
No momento, a melhor abordagem que os desenvolvedores do iOS podem usar é:
Muitas empresas usam o conceito de trens de liberação: uma programação que libera uma nova versão do seu aplicativo. Todo o código que foi mesclado com sua filial principal (mestre ou versão) no momento em que o trem de liberação "sai" será enviado para a App Store. Essa abordagem é implementada pela maioria dos aplicativos iOS grandes.
Nos últimos anos, algumas equipes de desenvolvimento começaram a usar abordagens que exigem menos esforço de desenvolvimento, diminuindo a qualidade da experiência do usuário, transferindo mais lógica para o back-end e tornando o aplicativo iOS um thin client mostrando os resultados do servidor.
Um aplicativo deve fazer o máximo possível de lógica comercial e de computação no dispositivo por vários motivos:
- Confidencialidade: evite enviar dados para um servidor remoto
- Velocidade: enviar dados para o servidor e aguardar uma resposta leva tempo e pode levar a uma falha (por exemplo, falta de WiFi)
- Uso de dados: os usuários geralmente têm limites de dados mensais
- Escalonamento: se seu aplicativo se tornar popular, você será responsável por escalar os serviços de back-end.
- Vida útil da bateria: o celular é caro
- Confiabilidade: as conexões LTE / 3G ainda são ruins em alguns países
Se seu aplicativo exigir uma conexão com a Internet para todas as funcionalidades (por exemplo, um aplicativo de rede social ou um aplicativo de compartilhamento de viagens), ele ainda funcionará (somente leitura) sem uma conexão com a Internet para acessar dados históricos (por exemplo, recentes viagens, comunicações diretas recentes).
Embora a maioria dos usuários seja atualizada para a versão mais recente dentro de algumas semanas, sempre haverá usuários que não o farão. Isso pode ter vários motivos. Geralmente, isso ocorre devido à versão do iOS usada, que nem sempre é possível atualizar devido à idade do dispositivo.
O conceito básico é que você não está atualizando a API existente, mas adicionando uma nova e permitindo que elas trabalhem em paralelo
https://your-api.com/1.0/drivers.json https://your-api.com/1.1/drivers.json
A versão e o número da compilação são usados juntos para identificar um aplicativo específico no aplicativo.
- Número da versão
(CFBundleShortVersionString) - (CFBundleShortVersionString) como versão no Xcode - Número da compilação
(CFBundleVersion) - (CFBundleVersion) como compilação no Xcode
No desenvolvimento atual do iOS, não há motivo para alterar manualmente esses números. Em vez disso, você precisa de um sistema confiável e automatizado para manter as versões atualizadas.
O Xcode possui uma ferramenta interna chamada agvtool .
A App Store inicialmente não permite reversões; portanto, esta seção descreve como obter resultados semelhantes usando os métodos disponíveis.
Liberações por marcos - Usando liberações por marcos, você pode distribuir lentamente a montagem para o produto, começando com um pequeno número de usuários ativos
No entanto, mesmo no caso de liberações em fases, é impossível recuperar completamente a montagem: depois que a montagem é instalada no dispositivo do usuário, a única maneira de alterar essa montagem é distribuir uma nova versão com um número de versão / compilação atualizado.
Assim como nas versões faseadas, os assemblies da App Store e TestFlight podem ser atualizados apenas seguindo estas etapas:
- Retorne ao seu sistema de controle de versão para o estado que você deseja reverter para
- Aumente a versão e / ou número de compilação do seu projeto
- Crie e assine seu aplicativo
- Distribua seu aplicativo através do serviço beta ou da App Store
- O usuário deve atualizar o aplicativo em seu telefone.
As etapas acima podem ser executadas manualmente, no entanto, é recomendável que o processo seja totalmente automatizado para poder responder rapidamente.
Alternativa: assinar novamente a compilação antiga
- Acesse o assembly antigo (arquivo .ipa) antes da regressão ser introduzida
- Atualize o número da versão / compilação no arquivo Info.plist
- "Assinar novamente" versão antiga
- Distribua-o como uma nova compilação
No entanto, "assinar" aplicativos iOS geralmente cria mais problemas, principalmente porque as ferramentas de linha de comando do Xcode não oferecem uma boa maneira de fazer isso.
O armazenamento de dados e configurações de acordo com as recomendações da Apple é fundamental para o ciclo de vida do seu aplicativo, principalmente quando se trata de sincronização do iCloud, atualização para um novo telefone e restauração do telefone a partir do backup.
Certifique-se de seguir as Diretrizes oficiais de armazenamento de dados da Apple iOS :
Documents : use este diretório para conteúdo personalizado, ele será arquivadoCaches : use este diretório para dados que podem ser recuperados.tmp : use este diretório para arquivos temporários- Use a propriedade
do not back up de arquivos
Nunca armazene informações confidenciais do usuário (como senhas ou sessões) nesses diretórios. Use a API de chaveiro.