| Version 1 (modified by admin, 8 years ago) (diff) |
|---|
This page describes the software development procedures in place for the development of the Tcs and Camra control systems.
Last updated 2016-11-08
- Development occurs in svn trunk.
- Larger or more complex feature changes requiring intermediate commits that are (partly) non-funcitonal or developments over longer periods of time (spanning a significant fraction of a deployment cycle) should occur in a branch. This branch should be frequently merged from trunk to ensure that it picks up changes by others. It gets merged back to trunk once the features are considered stable.
- We periodically branch from trunk into a deployment branch. This is what is run at the HET for ops. We expect to branch monthly for the time being to be in synch with the dark-time science and bright time engineering cycle.
- Only bugfixes and configuration changes are allowed in the deployment branch. In exceptional cases we will deploy small new features if proven safe and warranted by the science ops or engineering needs. All such changes have to be discussed and agreed upon on hetdex-tcs and het-operations prior to deployment.
- During engineering time, we will be running trunk at night for testing during the first week of engineering, then branch, and run the branch for ~1 week to stabilize it for the coming science run.
- All developers are responsible for keeping the integration test script (orchestrate-trajectory) up to date and functional at all times.
- Prior to any commit to trunk or any branch, we will execute orchestrate-trajectory, running at least all affected subsystems, to ensure that (a) the script still works, (b) configuration is up to data with the changes, (c) basic system integration and integrity is not affected. This test does not preclude the usual thorough testing before committing but augments it with basic integration testing.
- We update the orchestrate-trajectory framework and the associated subsystem simulators to include future systems interfaces and functionality. The absence of simulation capability is not a valid excuse for not testing changes with orchestrate-trajectory. Rather that capability should be added to the simulation packages.
