body.tex

\section{Introduction}
The dates in this document are the forecast dates for the proposed rebaseline - as in \figref{fig:fschedule}.
\subsection{Scope}

This document describes the major DM functionality which is expected to be available at major\footnote{ ``level 2''} milestones during the construction project, as described in \citeds{LDM-503}.
In doing so, it is intended to provide guidance to the system integration and verification teams.

\section{Release Management}\label{sect:relman}

All software releases from the DM Subsystem are carried out following the Release Management Policy, \citeds{LDM-672}.
Technical details of the application of this policy are described in \citeds{DMTN-106}.

\subsection{Preparation of Releases}\label{sect:relprep}

DM develops code in GitHub following its developer guidelines and coding standards \footnote{\url{https://developer.lsst.io/}}.
This includes automated testing and continuous integration.
Tested releases are tagged by SQuaRE weekly and major releases are made periodically.

There are specific packages and systems deployed together to form the high level components of DM as depicted in \figref{fig:dmsdeploy}.
The orchestration of deployments on multiple machines is facilitated by the use of containers and machine readable configurations.
DM prepares Docker containers and Puppet configurations for deploying these systems on Kubernetes enabled clusters.
These artifacts are tagged as part of the release.

\begin{figure}[htbp]
        \begin{center}
                \includegraphics[width=0.9\textwidth]{images/DMSDeployment}
                \caption{DM components as deployed during Operations.
                         For details, refer to \citeds{LDM-148}.
                \label{fig:dmsdeploy}}
        \end{center}
\end{figure}

\subsection{Deployment of Releases}\label{sect:reldep}

Although DM will provide ready-to-install products, these will be further tested before being deployed.
Hence, releases will initially be installed on test systems at NCSA and will undergo testing before they are made available in the production environment.
This will serve as an operational validation of the release.

\subsubsection{Levels of Operational Validation}

Certain containers will be used to provide kernels and supporting libraries for the JupyterLab environment.
Multiple versions of these containers can be made available simultaneously --- for example, providing a series of minor releases of the software stack --- with the user selecting which to deploy for their particular use case.
Since they will not be deployed as part of the core operational system, acceptance testing can be relatively minimal.

Some containers will be made available on development systems in support of ongoing development of the code.
Again, these should be made available rapidly, with security checking and validation testing kept to a minimum.

Similarly, during Commissioning, availability of containers on the Commissioning Cluster should be on the order of hours (not days).
The level of smoke testing and the time to availability of a container may need to be compressed in Commissioning.

Containers to be used for prompt or batch processing on operational systems, on the other hand, must be rigorously validated.