Skip to end of banner
Go to start of banner

Software Configuration Management

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Overarching Principles

  • No online software changes while in observation mode.

    • 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, with appropriate tests and the approval of the duty engineer.

  • Notable changes such as hardware or significant software function changes need to be documented and approved.

    • Hardware changes need an associated Hippo and possibly Jira ticket.

    • Significant software changes need a Jira ticket.

    • Changes need to be in the weekly work plan and mentioned at the PoD meeting. 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. Commit and push this version to Bitbucket as a known-good configuration.

    • Hardware changes which break compatibility with previous versions, and non-trivial software changes need a test plan. Once tested and proven, that version becomes the new known-good configuration.

Folders under this page

  • No labels