tex-framework/content.tex

\section{Gitlab workflow} \label{sec:glw}
\begin{figure}
	\begin{center}
		\input{img_gitlab_rel.tex}
		\caption{Gitlab workflow}
		\label{fig:gitlab_workflow}
	\end{center}
\end{figure}
Figure \ref{fig:gitlab_workflow} gives an overview of the gitlab workflow.
The workflow is splitted in different phases:\\
\begin{itemize}
	\item Implementation phase
	\item Code freeze
	\item Release phase
\end{itemize}
For these different phases The continuous integration/delivery system
triggers different build stages. For further details please refer to
section \ref{sec:ci}.
\subsection{Implementation phase}
While in implementation phase every implementation for the next release is
done. Every implementation has to be done on a seperate branch. After
finishing an implementation the branch it was made on has to be merged back
to the master branch. As defined an implementation could be one of:\\
\begin{itemize}
	\item Feature
	\item Fix
\end{itemize}
\subsubsection{Feature implementation}
A feature is a a new piece of code that implements new functionality into
the system.
\subsubsection{Fix implementation}
If in any testing phase an issue is detected these issue can be fixed with
a fix implementation.
\subsubsection{Further kinds of implementation}
Beside these defined implementations any other kind of implementation is
possible but has to be made also on a seperate branch.
\subsection{Code freeze}
The transition between implementation phase and release phase is called
code freeze. Code freeze means each for the upcoming release planned
feature is implemented and merged to the main branch (normally master) of
the project's git repository (see figure \ref{fig:gitlab_workflow}). For
the upcoming release a "\texttt{release/...}" named branch is created.
\subsection{Release phase}
Any release relevant issue that is detected while release phase has to be
fixed at the release branch. The release phase is splitted into different
stages:
\begin{itemize}
	\item Internal release(s)
	\item External release
\end{itemize}
\subsubsection{Internal release(s)}
Each push to a release branch triggers the creation of an internal release.
Only internal releases must be used to system test the release branch. For
details please refer to section \ref{sec:ci_int}.
\subsubsection{External release}
If no further release relevant issues could be found (or are accepted as
known issues) an external release is created by tagging the commit which
should be delivered to the customer. For details please refer to section
\ref{sec:ci_ext}.
\section{Continuous integration/delivery} \label{sec:ci}
As continuous integration system the gitlab built in ci-system
\textit{gitlab-ci} is used. Beside the most important task of ci, ensure
constant high code quality, the ci system is used for various tasks:
\begin{itemize}
	\item Automated static code analysis (not implemented yet)
	\item Automated build
	\item Automated test (not implemented yet)
	\item Internal release deployment
	\item External release deployment
\end{itemize}

%\subsection{External release deployment} \label{sec:ci_ext}
%An external release must be tagged with following naming convention:\\
%\texttt{release/<project\_specific\_name>}.\\
%The project specific naming convention for Agricola ruby is:\\
%\texttt{release/174\_AG*}.\\