Xelops Technology

Dans tout projet client, nous sommes amenés à gérer plus qu’un environnement. Chacun d’eux est lié à une configuration unique et spécifique. La mise en place de cette configuration est une phase importante à appliquer minutieusement pour en tirer profit d’une manière automatisée:

En premier lieu, ceci permettra l’utilisation des mêmes noms de variables globales (exemple: SERVER_URL, …) dans le projet en entier.

Ensuite, ces variables globales auront des valeurs constantes dans chaque fichier de configuration (Info.plist…) mais variantes par environnement.

Enfin, pointer sur un autre environnement se fera facilement en passant d’un target du projet à un autre puisque chacun d’eux encapsule tout ce que cet environnement requiert comme configuration.

Nous allons donc découvrir dans ce tutoriel comment mettre en place un mécanisme structuré permettant la bonne gestion des environnements dans un projet iOS (Swift) tout en évitant des erreurs probables lors des livraisons.

Les environnements que nous allons gérer sont les suivants:

Puisque le même processus se répète pour les trois, la majorité des exemples ci-dessous seront avec un focus “Environnement de Développement”.

1. Duplication du target

Après la création du projet dans l’éditeur Xcode, on y trouve par défaut un seul target. La première des choses à faire est la duplication de ce dernier. Pour ce faire, il faut sélectionner le target existant, faire un clic avec les 2 doigts puis choisir l’option “Duplicate” comme le montre l’image ci-dessous:

Duplication des targets

Ceci engendre la création d’un target ayant le même nom que l’ancien mais avec keyword “copy” en plus.

Résultat de la duplication des targets

Il faut à présent le renommer en remplaçant “copy” par “Dev”. Ensuite, il faut changer le nom dans les “schemes” en cliquant sur le target en haut puis sur “Manage Schemes”.

Accès au Manage schemes

Une fenêtre s’affiche indiquant les différents “schemes” du projet. De même, il faut renommer le nouveau target en remplaçant “copy” par “Dev” en sélectionnant le “scheme”, puis en cliquant sur la touche “Return” pour avoir le mode edit.

Changement du nom d’un scheme sur Xcode

2. Gestion des fichiers Info.plist :

Suite à la duplication, un nouveau fichier Info.plist est créé. De même que pour le target et le “scheme”, ce fichier doit être renommé pour avoir un nom faisant référence à son environnement. Nous allons le renommer “Dev-Info.plist”.

Afin de bien organiser le projet, il est recommandé de créer un dossier dans lequel il faut grouper les Info.plist et les fichiers GoogleService-Info.plist de Firebase (si il y en a) dans des dossiers d’environnement. L’idée est de placer chaque fichier dans son propre dossier. De plus, il faut changer le chemin des plist depuis le Build Setting comme le montre l’image ci-dessous :

Changement du chemin du fichier Info.Plist

Remarque: si après ce changement le build ne passe pas suite à une erreur indiquant que le Dev-Info.plist est introuvable, il suffit de sélectionner ce plist et faire un “show in finder”. Il est fort probable que le fichier soit encore dans son ancien emplacement, il faut donc le glisser et le mettre dans son nouveau dossier. A checker aussi sa “Location”, normalement elle doit être mise à la valeur “Relative to group” et non à “Absolute path” dans le menu à droite “Identity and type”.

3. Gestion des serveurs URL

Nous allons associer à chaque fichier Info.plist une constante “SERVER_URL” de type “String” ayant comme valeur l’URL du serveur de l’environnement adéquat comme l’indique les images suivantes:

Pour s’assurer que chaque plist est pris en considération et que la constante “SERVER_URL” est accessible, il est possible de faire un “print” lorsque chaque target est sélectionné/lancé:

Print du SEREVR_URL PROD dans le ViewController

A noter qu’il est possible d’ajouter d’autres constantes (par environnement) dans le même fichier Info.plist et d’y accéder de la même manière.

4. Display Name et Signing & capabilities:

En suivant le même processus pour les environnements à gérer, on se trouve avec autant de target que d’environnement. Certes, à ce niveau chaque target a ses propres configurations mais, pour un testeur, il est possible d’avoir une confusion. Ainsi, il est préférable de mentionner le nom de l’environnement (à l’exception de la PROD) dans le “Display name” de chaque target voir même lui affecter un logo spécifique.

De plus, avec cette gestion, chaque environnement (surtout celui de la PROD) aura sa propre “Signing & capabilities” à configurer une seule fois (Bundle ID, Team, etc.).

5. Gestion des Pods :

Puisque nous avons désormais plus que le target créé par défaut, et dans le cas où le projet supporte les pods avant la mise en place de cette gestion des environnements (voir même dans le cas d’un projet en cours), il faut noter que les autres targets n’auront pas accès aux Pods puisqu’ils ne sont pas mentionnés dans le fichier Podfile.

Afin d’y remédier, il faut ajouter les noms des nouveaux targets dans ce fichier mais pas n’importe comment. D’après la documentation officielle de CocoaPods, il existe plusieurs façon selon le besoin (utilisation d’un pod dans un target et pas dans les autres, utilisation des même pods…).

Ci-dessous un exemple:

abstract_target ‘MyProject’ do
# Comment the next line if you’re not using Swift and don’t want to use dynamic frameworksuse_frameworks!

# ignore all warnings from all pods

inhibit_all_warnings!

# List of all Pods

target ‘MyProject’ do

end

target ‘MyProject PP’ do

end

target ‘MyProject VABF’ do

end

target ‘MyProject Dev’ do

end

target ‘MyProjectTests’ do

inherit! :search_paths

# Pods for testing

end

target ‘MyProjectUITests’ do

inherit! :search_paths
 # Pods for testing  
 
 end
 
end

Avec ce format, il est possible d’utiliser les mêmes pods pour tous les targets sans avoir à écrire/dupliquer la même liste pour chacun d’eux.

Conclusion:

En suivant cette démarche de gestion des environnements, chacun de ces derniers aura sa propre configuration (les url serveurs, les fichiers Google-Info.plist, les bundle ID, etc.) sans avoir à la modifier lors de chaque passage d’un environnement à un autre.

Ainsi, le risque de passer un fichier d’une console Firebase dans le mauvais environnement ou de se tromper dans les URL serveurs lors des tests/livraisons sera moindre puisqu’il suffira uniquement de se positionner dans le bon target.