Active development is performed in feature branches and synchronized into the `dev` branch as it stabilizes. When a sprint completes, the `dev` branch is merged into the `staging` branch. When the release is approved, the `staging` branch will be merged into the `main`
The following branch naming patterns are utilized for different kinds of efforts within the project. All branches should target the `dev` branch, except for `hotfix` branches, which may target both `dev` and `main`.
Please refer to the [readme](packages/acceptance-tests/README.md#community-based-organization-operations-suite-cbo-suite) in `packages/acceptance-tests` for testing instructions.
The application is developed to support multiple locales. Text displayed to the user, either directly on the site or through emails (ex: password reset) will use the locale selected by the user to determine the language. To achieve this, all text displayed to the user must be read from asset files and must not be hardcoded in the application.
There are two places in the application where localized strings exist:
- [GraphQL API](packages/api)
- [Web Application](packages/webapp)
Both of those projects have a locales subfolder (src/locales). In turn, each supported locale will have a subfolder in the locale folder. The text to display is captured in JSON files structured by locale folder. The JSON files are heirarchical key -> value pairs that map keys to their display text values. For example, the following details basic text keys for the page title and account header.
When it comes time to display text to the user, the application will use the specified locale to lookup the text to use by key. The locale will default to en-US if not otherwise specified. Furthermore, if a key does not exist for the specified locale, then the text will be taken from the en-US locale file.
To update the displayed text, it is sufficient to update the locale JSON files. Once these files have been updated and pushed to the appropriate branch, the updated text will be picked up by the application.
The [GitHub Actions CI](.github/workflows/ci.yml) workflow is used to automate the deployment of the app in accordance with the branching strategy described above. The infrastructure required for an instance of the application is:
1. A MongoDB compatible database. We use CosmosDB with MongoDB driver.
2. A NodeJS web-server environment for the [GraphQL API](packages/api).
3. A static website deployment (Azure Blob Storage/S3) for the [web application](packages/webapp). This may be CDN-hosted or self-hosted in static storage.
4. A SendGrid account for sending automated emails (e.g. password reset emails).
5. (_optional_) A Firebase account for In-App Notifications.
The application uses the [config](npm.im/config) package to manage configuration settings per hosted environment. The following environment variables may be defined to override configuration settings:
- API [environment variables](packages/api/config/custom-environment-variables.md)