Software Configuration Management

Overarching Principles

• 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.

Folders under this page