tex-framework/content.tex

\section{Gitlab workflow} \label{sec:glw}
\begin{figure}
	\begin{center}
		\input{img_gitlab.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.
For a proper release configuration it is necessary to configure the ci
build job before creating the release branch (see section \ref{sec:ci_conf})
.
\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{Internal release deployment} \label{sec:ci_int}
For a branch named \texttt{release/...} an internal release is triggered
automatically. The internal release is processing the following steps:\\
\begin{enumerate}
	\item Build project variant specific configuration
	\item Name the release depending on the release naming convention
	\item Deploy the release to the project's internal deploy path
\end{enumerate}
\subsection{External release deployment} \label{sec:ci_ext}
To create an external release the commit to be released must be tagged
using the following naming convention:\\
\texttt{release/<project\_specific\_name>}.\\
The project specific naming convention for Agricola ruby is:\\
\texttt{release/174\_AG*}.\\
\subsection{Configuring the build jobs} \label{sec:ci_conf}
The configuration of gitlab-ci is made in the \texttt{.gitlab-ci.yml} file
in the root directory of the project's repository. The certain build stages
are using variables to customize the build. These variables are defined in
the \texttt{variables} section of the config file.\\\\
\begin{tabular}{l l}
	variable & meaning\\
	PRODUCT\_ID & Id of the product\\
	PRODUCT\_NAME & Short of the product name\\
	PRODUCT\_VARIANT & Short of the product variant\\
	PROJECT\_VERSION & ??\\
	SW\_MAJOR\_INTERNAL & Software major number for internal\\
	 & releases\\
	SW\_MAJOR\_EXTERNAL & Software major number for external\\
	 &  releases\\
	SW\_MINOR\_INTERNAL & Software minor number for internal\\
	 &  releases\\
	SW\_MINOR\_EXTERNAL & Software minor number for external\\
	 & releases\\
	EXEC\_PATH\_INTERNAL & Location of the built executable for\\
	 & internal release\\
	EXEC\_PATH\_EXTERNAL & Location of the built executable for\\
	 & external release\\
	DEPLOY\_PATH\_INTERNAL & Location to deploy internal releases to\\
	DEPLOY\_PATH\_EXTERNAL & Location to deploy external releases to\\\\
\end{tabular}
\newline
In listing \ref{lst:ag_cfg} an example configuration for an Agricola North
America variant release is shown.
\lstsetbash
\begin{lstlisting}[caption=variables configuration, label=lst:ag_cfg]
variables:
  PRODUCT_ID: "174"
  PRODUCT_NAME: "AG"
  PRODUCT_VARIANT: "NA"
  PROJECT_VERSION: "10"
  SW_MAJOR_INTERNAL: "1"
  SW_MAJOR_EXTERNAL: "1"
  SW_MINOR_INTERNAL: "1"
  SW_MINOR_EXTERNAL: "2"
  EXEC_PATH_INTERNAL: "./exec/NAR_release/NAR_release.hex"
  EXEC_PATH_EXTERNAL: "./exec/NAR_release_customer/\
    NAR_release_customer.hex"
  DEPLOY_PATH_INTERNAL: "http://dabsvn01.internal.novero.\
    com/svn/0_31X_P0070_agricola/trunk/development/\
    software/releases/internal"
  DEPLOY_PATH_EXTERNAL: "http://dabsvn01.internal.novero.\
    com/svn/0_31X_P0070_agricola/trunk/development/\
    software/releases/external"
\end{lstlisting}
Remember, it is a good idea to change these values before creating the
release branch, creating (and pushing) the branch triggers the build of an
internal release.

\begin{figure}
	\begin{center}
		\input{img_history.tex}
		\caption{Git commit history}
		\label{fig:git_commit_history}
	\end{center}
\end{figure}