From cae2d573bc605d0f957190884eee2bc13eab97db Mon Sep 17 00:00:00 2001 From: Jonathan Niles Date: Wed, 19 May 2021 09:45:28 +0100 Subject: [PATCH] docs: add RELEASES.md Adds RELEASES.md file with checklist before doing a release. --- .gitignore | 1 + README.md | 27 ++++++++++--------- RELEASES.md | 24 +++++++++++++++++ .../migrations/v1.18.0-v1.19.0/migrate.sql | 1 + 4 files changed, 41 insertions(+), 12 deletions(-) create mode 100644 RELEASES.md diff --git a/.gitignore b/.gitignore index 0273aee472..d9897d5093 100644 --- a/.gitignore +++ b/.gitignore @@ -52,5 +52,6 @@ docs/.sass-cache/ client/upload/ +migration-*.sql yarn-error.log *.log diff --git a/README.md b/README.md index 78854ae18f..3f8001dd0c 100644 --- a/README.md +++ b/README.md @@ -1,9 +1,7 @@ BHIMA ================= -[![Build Status](https://travis-ci.org/IMA-WorldHealth/bhima.svg)](https://travis-ci.org/IMA-WorldHealth/bhima) - -Bhima is a free, open source accounting and hospital information management system +BHIMA is a free, open source accounting and hospital information management system (HIMS) tailored for rural hospitals in Africa. We are an international team based in the Democratic Republic of the Congo. @@ -19,27 +17,32 @@ inventory and pricing, and purchasing. Additionally, BHIMA bundles reports and optional reporting plugins to aid hospital administrators, aid organisations, and governmental/non-governmental -agencies access up to date utilization data. +agencies access up to date utilization data. It targets insitutions that must conform +to the [OHADA](https://en.wikipedia.org/wiki/OHADA) reporting standards in western +and central Africa. Finally, the entire project is designed to scale from a single, low cost device in a clinic, to a large multi-hundred bed institution with tens of users accessing the server simultaneously. +Technology +--------------- + +The client-side is written in AngularJS and the server in NodeJS. Session management +is enabled by Redis, and the backend is a MySQL database. + Contributing --------------- All contributions are welcome! If you want to get started hacking on BHIMA, the [developer wiki](https://github.com/IMA-WorldHealth/bhima/wiki) contains notes -on our designs and testing infrastructure. If you have any questions or need help -getting started, please [open an issue](https://github.com/IMA-WorldHealth/bhima/issues/new) - -chances are you are not the only one! +on our designs and testing infrastructure. We also have a dedicated documentation +website https://docs.bhi.ma. If you have any questions or need help getting started, +please [open an issue](https://github.com/IMA-WorldHealth/bhima/issues/new) - chances +are you are not the only one! If you just want to jump into to messing with the software, check out [Getting Up And Running](https://github.com/IMA-WorldHealth/bhima/wiki/Getting-Up-and-Running). -If you are new to git/Github check out our [Getting Started Guide](https://github.com/IMA-WorldHealth/bhima/wiki/Getting-Started:-Contributing-on-Github). - -Want to jump straight into code? The [First Time Contributor](https://github.com/IMA-WorldHealth/bhima/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22) -issues are a decent place to start. - +If you are new to Github, they have an [excellent guide](https://docs.github.com/en/github/getting-started-with-github). Installation ------------------- diff --git a/RELEASES.md b/RELEASES.md new file mode 100644 index 0000000000..e833d9c589 --- /dev/null +++ b/RELEASES.md @@ -0,0 +1,24 @@ +RELEASES +-------- + +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. + +1. Make a new branch called `release-next` that is based on `upstream/master` to do your release on. If one exists on upstream, remove it first. +2. Run `yarn` to ensure you have the latest dependencies. +3. (Optional, best practice) Test the latest migration script on a production database. (*) +4. (Optional, best practice) Build the application in production mode with `NODE_ENV=production yarn build`. +5. Determine the version number for the next version. (v1.X.Y) +6. Create a new folder in the `server/models/migrations/` directory to hold the migration file with the format `v1.A.B-v1.X.Y` where `1.A.B` is the current version and `v1.X.Y` is the next version. +7. Move the `server/models/migrations/next/migrate.sql` file to the directory created in the above step. +8. Create a blank `migrate.sql` file in `server/models/migrations/next/`. +9. Run `yarn release` and follow the options. + + +(*) Optional, Best Practice: Test the latest database changes on a production database. + +1. Change your `.env` so the `$DB_NAME` variable is the correct one for a production database. +2. Create your database migration script by running `yarn migrate`. This will create a file `migration-$DB_NAME.sql`. +3. Catenate the latest release file into the output `cat server/models/migrations/next/migrate.sql >> migration-$DB_NAME.sql`. +4. Build the migration script targetting your database. `mysql $DB_NAME < migration-$DB_NAME.sql` +5. If no errors occur, remove the file `migration-$DB_NAME.sql` to prevent it from getting checked into SQL. diff --git a/server/models/migrations/v1.18.0-v1.19.0/migrate.sql b/server/models/migrations/v1.18.0-v1.19.0/migrate.sql index 4ce6333865..e0fb1a5e1c 100644 --- a/server/models/migrations/v1.18.0-v1.19.0/migrate.sql +++ b/server/models/migrations/v1.18.0-v1.19.0/migrate.sql @@ -1,4 +1,5 @@ /* migrate v1.18.* to v1.19.0 */ + /** * @author: mbayopanda * @date: 2021-03-5