...
No online software changes during active observation.
Peer review of excepted changes is strongly encouraged if possible.
Exception: Emergency fix, with approval of the duty engineer.
Exception: Low-risk changes may be collected offline during observing and possibly implemented online on a snow clean day or during weather, etc. downtime, with appropriate tests and the approval of the duty engineer.
Notable changes such as hardware (more than simple spare replacement) or significant software function changes need to be documented and approved.
Informal peer review and formal design review are probably appropriate. Changes which influence how an output is actuated or which require deleting a safety signature must be reviewed.
Hardware changes need an associated Hippo and possibly Jira ticket.
Significant software changes (those which influence how an output is controlled) need a Jira ticket.
Changes need to be in the weekly work plan and mentioned at the PoD meeting (drawing attention to the test period--may be a different day). Emergency exceptions can be made with the approval of the PoD lead or duty engineer.
Maintain a recent rollback version for disaster recovery. The Main/Master branch in Bitbucket (git) is to be maintained as our known-good copy. Other branches may be used for development.
Upload program from controller (where possible) on last day of an observing period and after a few uneventful days at the beginning of observation. This is primarily for the EMCS and GIS. Commit and push this version to Bitbucket as a known-good configuration. Also add a tag relating to the specific observing period, e.g., OCP2.6_End.
Hardware changes which break compatibility with previous versions, and non-trivial software changes (those which affect behavior of outputs) need a test plan as per Code Testing. Once tested and proven, that version becomes the new known-good configuration.
...