Development Processes
Development and Deployment Model
The CASA pipeline has a single release per year. There are several reasons for this model:
- Time is required after each release to evaluate the performance of the pipeline against data and formulate new requirements.
- The ALMA project would prefer to have a single pipeline version throughout an observing cycle.
- The amount of time required by the scientific staff of both telescopes to validate and document a new pipeline version make more frequent releases prohibitive.
The figure below shows the deployment banches created by the pipeline and the approximate timescales. The production pipeline branch in created in the late summer to be deployed with the Fall release of CASA. The trunk of the pipeline at that point is available for development intended for delivery the following year. Bugs that are descovered in production can be fixed on the production branch, and put into deployment. In the Spring a "compatability" branch will be created from the production branch, any interface changes or backwords incompatabilities for the pipeline relative to the upcoming release version of CASA will be corrected on this branch and this variant of the pipeline will be delivered as part of the Spring CASA release. Finally as we return to late summer the next release of the pipeline will be prepared, and the production branch produced.
The yearly calendar is summarized below, this schedule may need to be adjusted from year to year based on the exact timing of other events at the observatory.
| Time Period | Development Team | Science Operations |
| Sept. 15 | CASA and Production Pipeline Release |
|
| Oct.- Nov. |
Bug fixes for production pipeline Infrastructure development decrease technical debt |
Heuristics definition for following release |
| Dec. 1 | Deadline for feature and heuristics definition for next yearly release. | |
| Dec. - Mar. | Development of new features and heuristics | |
| Mar. 1 | Initial release (R1) of functionality to Science Operations for feedback, heuristic clarification, and initial verification. |
|
| Mar. - April | Responding to bugs found in testing of R1, addressing bugs and additional features. | Verification of R1 functionality, development of punchlist items |
| May 1 | Final deadline for release requirements (Initial punchlist, clarification) | |
| May - Jun. | Improvements to R1, addressing items on punchlist. | |
| July 1. | Second release (R2) to Science Operations | |
| July | Respond to issues identified in testing | Final verificiation testing, initial validation testing |
| Aug 1 | Final punchlist from verification testing complete | |
| Aug - Sept. | Final bug fixes, release preparation | End to end testing, validation testing |
| Sept. 15 | CASA and Production Pipeline Release | |
Version Control System
The pipeline subsystem uses Git as it's version control system. The pipeline should be included in the continuous integration process in two seperate ways, to accomodate two distinct use cases.
- Use a released and well tested version of the pipeline to monitor the evolution of the CASA packages and identify any changes that affect the pipeline at the earliest possible point. This use case also provides significant regression testing for the CASA package.
- Use a selected version of the CASA package with the latest updates from the pipeline development team for testing of the pipeline development. The goal is to isolate the pipeline development from changes in the underlying CASA implementation.
The CASA pipeline is maintained as a submodel of the CASA tree in Git, allowing independent development with a simple path to publish new versions of the pipeline as part of standard CASA artifiacts. Below are recipies for many of the most common tasks that a developer or pipeline lead needs to do.