77 lines
3.2 KiB
TeX
77 lines
3.2 KiB
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*}.\\
|