Releases are partially automated in BHIMA. This document is a checklist of things that need to be done before a release and the steps to creating a new release.
The directions below assume you are working in a development environment based on a fork of the main BHIMA repository on github.
- Checkout Bhima 'master' from your fork of https://github.com/IMA-WorldHealth/bhima
- Do
git pull
to make sure it is up-to-date. - Create a new branch called
release-next
(for example) that is based on the upstream repo to do your release with. If one exists on upstream, remove it first. For example, if the main BHIMA githup repo is calledupstream
in your local development setup, do:
git checkout -b release-next upstream/master
- Run
npm install
to ensure you have the latest dependencies. - (Optional, best practice) Test the latest migration script on a production database. (See * below)
- Build the application in production mode to make sure the build works correctly.
NODE_ENV=production npm run build
- Determine the version number for the next version (eg,
v1.X.Y
) - Create a new folder in the
server/models/migrations/
directory to hold the migration file with the formatv1.A.B-v1.X.Y
where1.A.B
is the current version andv1.X.Y
is the next version. - Move the
server/models/migrations/next/migrate.sql
file to the directory created in the previous step. - Create an empty
migrate.sql
file inserver/models/migrations/next/
. You may insert a comment at the top of the file including the name of the new release version. - Commit any updated files (
git commit ...
) - Push your branch to the BHIMA upstream repo:
git push --set-upstream upstream release-next
- In github, convert your branch to a PR in the
IMA-WorldHealth/bhima
repository. - Make sure your personal GITHUB_TOKEN environment variable is defined (assuming you have permissions to update the main BHIMA repository. See Github instructions for this.
- Run
npm run release
and follow the directions. - Verify the release was created and that the binary .tar.gz file is in the assets for the release.
- Via the github interface, merge your
release-next
PR intomaster
(*) Optional, Best Practice: Test the latest database changes on a production database.
- Change your
.env
so the$DB_NAME
variable is the correct one for a production database. - Create your database migration script by running
npm run migrate
. This will create a release migration filemigration-$DB_NAME.sql
. - Append the current migration file into the release migration file:
cat server/models/migrations/next/migrate.sql >> migration-$DB_NAME.sql
.
- Build the migration script targetting your database.
mysql $DB_NAME < migration-$DB_NAME.sql
- If no errors occur, remove the file
migration-$DB_NAME.sql
to prevent it from getting checked into SQL.