This is a REST-API build on top of sprint-boot framework. This catering set of end-points for Pittsburgh Buddhist Center. This is using by mobile app and web app to deliver few of functionalities to devotes.
- Java 24
- Heroku CLI
- Kotlin -- v2.2.0
- Gradle -- v8.14.3
- Sprint-Boot -- 4.0.0-M1
- Firebase - FireStore
After any developer close the code from Github. They can run setup.sh script for setting up the local environment. This will configure followings
- Configure STAGING & PROD heroku remotes into the project.
- Add
local.propertiesfile for local debugging with required fields. (Developer need to configure relevant values)
$ ./setup.sh
Build the code by running following command.
$ ./gradlew clean --no-build-cache build
In this application development, we are trying to follow trunk-base approach for branching. Therefore, if there is any new development or bug-fx or hot-fix
available, our development branch will be main branch.
Primary deployment is in Heroku dyno. For this application has two environments. One is for staging and other one is for production. Both environments are in Heroku. To do the deployments, developer need to be a contributor of heroku accounts related with staging / production. Once developer get the access to heroku environments, they can use deploy.sh script to do the deployments.
For the application functionality with firebase integration, Before we deploy, make sure in the heroku application, set the following environmental variables
GOOGLE_CREDENTIALS-> Google Firebasegoogle-service-account.jsonfile contentPBC_ENV-> According to the deployment environment, set the value asstagingoprod.
Note
This values already set in the existing heroku application. So no need to worry about that. But in case of new deployment, need to make sure these set-up correctly.
If we need to deploy a change to staging server (QA) without merging to develop branch as a release, use following command to deploy feature branch to staging server.
git push heroku-staging <feature-development>:master
Application is following pattern to name the releases. It built with release year, major or feature drop version, minor or bug-fix.
Pattern : <release-year>.<major/feature-drop>.<minor/bug-fx>
Example : 2025.1.0
This deploy.sh script is created for make the deployment process easy to all developers. Currently, developer can execute the deploy.sh script as follows.
./deploy.sh <env-name-to-deploy>
This env-name-to-deploy is an argument while execute the script. From that script will identify which environment that developer want to deploy the new app.
Following are the available options developer can pass as environment.
| option (env) | Description |
|---|---|
| local | This is to run the application in local system. |
| staging | This is to deploy the application into staging heroku application |
| prod | This is to deploy the application into production heroku application |
- Bash/Unix environment (Mac/Linux)
- Access to
pbc-app-secretsrepository. - Heroku CLI installed in the system
- Need to add the
heroku-staging&heroku-prodremotes to the local git repository.
- All tool version is configured in
pbc-app-api/gradle/version-catalog/libs.versions.toml. - To Change Java version, make sure to change it in
libs.versions.toml&settings.properties. By changing inlibs.versions.tomlwill apply changes to gradle and the build configurations and by changing insettings.propertieswill define version to Heroku.- In libs.versions.toml
[versions] ... jvmTarget = "24" ... - In settings.properties
# Java Runtime version definition for Heroku java.runtime.version=24
- In libs.versions.toml
- Before attached debugger in IntelliJ, open the
AppProperties.ktfile and hardcode the values toappEnv="staging". While debugging, it failed to read the properties.