Environment
The project environment consists of three parts:
-
The
envfolder that contains a basic definition of environment variables inenv/default, and the environment folders cloned from the environments repository. As a recommendation, one per environment, e.g.:dev,staging,prod. -
The
tenantfolder cloned from the tenants repository, which contains configuration environment variables, specific resources, and style specifications. -
The source code distributed in the
desktop,mobile, andfenicefolders.
Separately, none of the three parts is functional. For the complete project to be functional, it is necessary to run a script that collects data from the first two parts and "implements" them in the third.
This happens by running the script yarn create_env {env-name}.
Env
Environment variables that will be used to establish the project configuration are defined in the env folder.
The env/default folder contains basic environment variables that can be redefined by each tenant's environment configuration. This way, each time we need to add a new environment variable, it is recommended to add it to the default environment so it doesn't fail due to not being defined in the tenants' environment configurations.
The "customized" environment folders are composed of a base tenant configuration obtained from the previously mentioned repository, and a submodule to the fenice tenants repository fenice-env which has three branches (dev, prod, staging). Changing the branch that the submodule points to changes the environment of the variables.
This separation is because there is a lot of common configuration among tenants, and we centralize it in fenice-env. And everything that is tenant-specific, especially credentials, firebase ids, apk signing keys, etc., are defined in the tenant's environment variables repository.
Environment Variables Structure
env/ # Environment variables
├── default/ # Basic project environment variables
│ ├── backend/ # Backend environment variables (never used, can be deprecated)
│ ├── client/
│ │ ├── app.env * # Client environment variables
│ │ └── sentry.properties # Example sentry config file
│ └── config.env * # Common environment variables between backend and client
└── staging/ # Environment variables cloned from external repository
├── backend/ # Backend environment variables (never used, can be deprecated)
├── client/
│ ├── app.env * # Client environment variables
│ ├── google-services.json # Firebase config file for Android
│ ├── GoogleService-Info.plist # Firebase config file for iOS
| ├── {tenant-name}.keystore # Android signing file
│ └── sentry.properties # Sentry config file
├── fenice-env/ # Fenice environments repository submodule
│ ├── backend/ # Backend environment variables (never used, can be deprecated)
│ ├── client/
│ │ ├── app.env * # Client environment variables
│ │ ├── google-services.json # Firebase config file for Android
│ │ ├── GoogleService-Info.plist # Firebase config file for iOS
│ │ ├── publicala.keystore # Android signing file
│ │ └── sentry.properties # Example sentry config file
│ └── config.env * # Common environment variables between backend and client
└── config.env * # Common environment variables between backend and client
- Files that can be unified to simplify structure
Tenant
The next structure shows the main directories and files required for a tenant setup, including:
- Android resources for icons and splash screens
- iOS assets for app icons and splash screens
- Configuration files
- Theme customization
- Translation files
- Asset files including fonts and images
Tenant Folder Structure
tenant/
├── android
│ └── res # Android resources
│ ├── drawable-*
│ │ ├── ic_notification.png # Notification icon
│ │ └── splash.png # Splash resource(s)
│ ├── layout
│ │ └── launch_screen.xml # Splash definition
│ └── mipmap-anydpi-v26/
│ ├── ic_launcher_round.xml # Round app icon layer definition
│ └── ic_launcher.xml # App icon layer definition
│ └── mipmap-*
│ ├── ic_launcher_background.png # App icon solid background
│ ├── ic_launcher_foreground.png # App icon png without background
│ ├── ic_launcher_monochrome.png # App icon png without background
│ ├── ic_launcher_round.png # App icon resource with round cropped background
│ └── ic_launcher.png # App icon resource with square cropped background
├── assets
│ ├── fonts
│ │ └── [TenantFonts] # Specific fonts
│ ├── assets.json # Resource re-definition
│ └── [Resources] # UI resources
├── config
│ ├── system # Environment variables with tenant-specific configuration independent of environment (dev, prod, or staging)
│ │ ├── base.env *
│ │ └── client.env *
│ └── templates
│ └── ios-fonts.template # iOS-specific font definition
├── ios
│ ├── Images.xcassets
│ │ ├── AppIcon.appiconset # App icon resources
│ │ └── SplashScreen.imageset # Splash resources
│ │ ├── splash.png
│ │ ├── splash@2x.png
│ │ └── splash@3x.png
│ └── LaunchScreen.storyboard # Splash definition
├── theme
│ └── index.js # Colors and styles definition
└── translations
└── locales
│ ├── es.json
│ ├── en.json
│ └── pt.json
└── index.js # Translations definition
The asterisk (*) in paths like drawable-* and mipmap-* indicates multiple resolution folders (e.g., hdpi, mdpi, xhdpi, etc.).
Environment files marked with asterisk (*) can be unified to simplify the structure.
Result
Running the script yarn create_env {env-name} takes everything defined previously and "creates" a structure that makes the project functional.
Defined in steps, the script does the following:
-
Creates an
.envfile with all environment variables in the corresponding order so that tenant-specific definitions take precedence over the rest. -
Loads the environment variables from the file generated in step 1.
-
Creates a configuration file where environment variable values are exposed so they can be used by React at runtime.
-
Resource files are copied to the mobile platforms, and each platform's files (android and iOS) are updated, specifying name, version, signing file, firebase configuration files, and everything each platform needs to have a completely functional project.
-
Same as the previous step for desktop.
-
The reader package is obtained from gitlab using the defined version and tags created in the volpe mirror repository.
All these changes resulting from the script SHOULD NOT BE COMMITTED. The base project should not be functional, to avoid configuration problems or environment setup errors for each tenant.