⚠
Observe que o segundo comando utiliza a flag -legacy. Isso porque utilizei o openssl 3.1.1 via Git Bash e o Mac utiliza o openssl 1.x . Sem essa flag, o arquivo não poderá ser utilizado para assinar mais a frente!
Guarde também a senha utilizada na geração do arquivo `P12`. Ela será necessária mais a frente.
Agora precisamos gerar um `Provisioning Profile`. Basta entrar na [página dos profiles](https://developer.apple.com/account/resources/profiles/list) dentro do painel do desenvolvedor da Apple e criar um. No nosso caso, geramos 1 para desenvolvimento (tipo `iOS App Development`) e um para produção (tipo `App Store`)
![](https://cdn.hashnode.com/res/hashnode/image/upload/v1702688389244/9192635e-2a2e-40ec-b8a5-38cad0c531a8.png align="center")
Logo depois dessa tela, você deverá selecionar as `capabilities` do seu aplicativo. No nosso projeto, foi necessário selecionar o `Push Notification`. Se você gerar um `profile` sem as `capabilities` necessárias, você irá tomar um erro na etapa de geração do IPA que não vai te dizer bem que esse é o problema. Para ver quais são as necessárias, veja [via XCode](https://developer.apple.com/documentation/xcode/adding-capabilities-to-your-app/#Add-a-capability) no projeto.
Concluído o processo, você poderá baixar um arquivo `mobileprovision` .
Todos esses arquivos devem ser enviados para a pipeline do Azure como arquivos seguros, no menu `Pipelines > Library`, na aba `Secure Files` .
Aproveite que está aqui e crie um `Variable Group` e salve as senhas utilizadas para o certificado android e arquivo `p12` iOS. Vamos considerar que o nome desse grupo é `app-vg` e que ele tem as propriedades `androidKeyStorePassword` e `iosP12Password` .
### LogRocket: uma fonte de alívio
Quando começamos a construção, seguimos o modelo proposto no blog da LogRocket para `react-native`: [Continuous deployment of React Native app with Azure DevOps - LogRocket Blog](https://blog.logrocket.com/continuous-deployment-of-react-native-app-with-azure-devops/)
Lendo o artigo, de cara percebemos alguns ajustes a serem feitos:
1. Não vamos manter as pastas `android` e `ios` no repositório Git. Podemos criá-las na execução da pipeline.
2. Vamos controlar a versão programaticamente com o número do build da pipeline Azure, utilizando variáveis de ambiente na hora do build.
3. No link, a pipeline utiliza um único job para fazer a construção do `APK` Android e do `IPA` iOS. Vamos separar o build em 2 `stages`, um para cada OS.
Como no link, nós também estamos utilizando o `App Center` para fazer publicação das versões, mas essa é uma etapa opcional que não vou entrar em detalhes aqui.
### Configurando a versão da aplicação
O formato de versão que vamos utilizar é o recomendado pela Apple, com 3 inteiros, separados por ponto.
No arquivo `app.json`, vamos deixar os dois primeiros números e o terceiro será concatenado com uma variável de ambiente chamada `BUILD_NUMBER`. Para evitar erros durante o desenvolvimento, vamos deixar o valor padrão 1 caso essa variável esteja vazia.
Crie um arquivo `app.config.ts` na raiz da sua aplicação com o seguinte código
```typescript
import type { ConfigContext, ExpoConfig } from '@expo/config'
export default function ConfigExpo({ config }: ConfigContext): ExpoConfig {
if (!config.version) {
throw new Error('No version configured in app.json.')
}
const buildNumber = parseInt(process.env.BUILD_NUMBER ?? '1')
const version = `${config.version}.${buildNumber}`
return {
...config,
version,
android: {
...config.android,
versionCode: buildNumber
},
ios: {
...config.ios,
buildNumber: buildNumber.toString()
},
name: config.name!,
slug: config.slug!
}
}
```