-
Notifications
You must be signed in to change notification settings - Fork 0
Dev Guide ‐ Project
The Web project is in react.
From that folder we can run all npm commands like normal.
The IDE can set up a run configuration to run npm as well.
Note that we use vite to server front end resources and proxy to the back end.
The backend project is in server, it is a web server for a typical web application.
from the base project folder, we can run gradlew commands like normal.
gradlew :server:bootRun is equivalent to gradlew -p server bootRun
Alternatively, from the server folder, start the server with
../gradlew bootRun or ../gradlew bootTestRun
To build a JAR file that can be deployed and run,
use the command gradlew build from the base project folder.
Run gradlew --scan clean build
You'll see output like
Publishing build scan...
https://gradle.com/s/nabsmftvebtei
Go to that url, enter your email, then the actual report is activated and the link is emailed to you.
Can it be published without email step?
You can check "remember me" when entering your email, but that only lasts 90 days.
To streamline this as part of the regular build you would need to buy the enterprise version.
The activation link redirects to the build link after activation. You could always copy the activation link to the local build report, and it should generally work as long as you look are activating and looking at it on a regular basis.
Run configuration may need to be set to the appropriate version of Java. Also: IntelliJ > Preferences > Build > Build Tools > Gradle > Gradle JVM may need to be set to the appropriate version.
Trunk based development is helpful to implement continuous delivery and continuous deployment. Find out more at https://trunkbaseddevelopment.com/
Generally there will be multiple commits to a feature branch which when ready is merged directly to master.
- Define acceptance criteria for clearly defined scope
- Create branch locally and push to remote
- Must satisfy acceptance criteria
- Must be covered by automated functional tests
- Must be covered by security and validation tests, both positive and negative
- Must pass at least one manual test
- Docs (like README's) are updated
- Create PR (master has a branch protection rule to only allow merge from PR)
- Squash merge to master and automatically delete remote branch on Github
- Delete local branch
- Verify latest was automatically deployed to stage
- UI test on stage as needed
We use Github Actions to build and deploy.
See the .github/workflows folder.
Right now only build and deploy on merge to master. So workflow is develop, merge to master, verify change in stage. This can become more refined once we have a production environment. Eventually would want to verify in a cloud environment before merging to master.
When installing the software into a new environment with a new database, an admin user is automatically created when the database is first initialized with a schema and the password should be changed before the environment is exposed to the public.
With the admin in place more regular users can be created.
This app set up to deploy to Heroku. We use the gradle heroku plugin to deploy from CI instead of using the Procfile or other Heroku integrations. See the GitHub workflow files for the actual command and parameters.
To redeploy a specific older version, use the rollback feature from Heroku. This is on the command line only and can not be done from the Heroku UI. As mentioned in the article: note that this doesn't handle database migrations.