-
Notifications
You must be signed in to change notification settings - Fork 2
Deploy Process (WIP)
Reference: https://github.com/OHIF/Viewers/issues/1924
- Make changes in OHIF/Viewers
- Bring changes to IDC fork sandbox branch
- Open PR to update IDC fork master from IDC fork sandbox branch with a description of incoming changes and task numbers
- Merge changes to IDC fork master branch
- Slack message to @general on IDC Slack
- This gets deployed to IDC portal dev and ultimately to testing and production by ISB team
- idc-sandbox environment can be updated manually when Slack message arrives (@pieper)
-
The IDC fork master branch should be updated when there's something we need to test. I can update the idc-sandbox from there and Bill can selectively introduce it to IDC dev, test, and then prod for successive testing layers. Bill and I should get a Slack message so they go into idc-sandbox and IDC/dev environments at the same time.
-
The sandbox environment/branch is used internally to have features readily available to be tested without any dependency on ISB team
-
The IDC WebApp team deploys OHIF in a google cloud bucket and we want to have a clear process for introducing fixes and features into production, currently, the head of the master branch is used when an update is needed.
-
Some changes in the works will eventually go into OHIF master so we will want an IDC-release branch to pin down and maintain.
We pick a version and branch from there, and it can be updated to the master or commits can be cherry-picked as appropriate.
Other people might have a similar need to incrementally switch to the new OHIF until it stabilizes and they will also want a way to maintain it while the master is being debugged. They could possibly use the same one IDC uses.
Our other option would be to fork OHIF and implement this process, but it probably makes more sense to do this within the OHIF repository.