196 lines
6.7 KiB
TeX
196 lines
6.7 KiB
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
|
|
\item Automated build
|
|
\item Automated test (not implemented yet)
|
|
\item Internal release deployment
|
|
\item External release deployment
|
|
\item Automated release note generation (not implemented yet)
|
|
\end{itemize}
|
|
|
|
\subsection{Internal release deployment} \label{sec:ci_int}
|
|
|
|
\begin{figure}
|
|
\begin{center}
|
|
\input{img_deploy.tex}
|
|
\caption{Deployment of release candidats and releases}
|
|
\label{fig:deployment}
|
|
\end{center}
|
|
\end{figure}
|
|
|
|
For a branch named \texttt{release/...} the creation of a release candidate
|
|
is triggered automatically. Figure \ref{fig:deployment} illustrates the
|
|
deployment process. The internal release is processing the following steps:
|
|
\\
|
|
|
|
\begin{enumerate}
|
|
\item Build project variant specific configuration
|
|
\item Static code analysis of project variant specific configuration
|
|
\item Name the release depending on the release naming convention
|
|
\item Build release notes for the release candidate
|
|
\item Deploy the release to the project's release candidate deploy
|
|
location
|
|
\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*}.\\
|
|
|
|
\begin{enumerate}
|
|
\item Build project variant specific configuration
|
|
\item Static code analysis of project variant specific configuration
|
|
\item Name the release depending on the release naming convention
|
|
\item Build release notes for the release
|
|
\item Deploy the release to the project's release deploy location
|
|
\end{enumerate}
|
|
|
|
\subsection{Release note generation} \label{sec:rel_note}
|
|
|
|
\begin{figure}
|
|
\begin{center}
|
|
\input{img_history.tex}
|
|
\caption{Git commit history}
|
|
\label{fig:git_commit_history}
|
|
\end{center}
|
|
\end{figure}
|
|
|
|
To generate release notes by commit messages special tagged commit messages
|
|
are used. Release notes are generated for release candidats and releases.
|
|
For release candidats (internal releases) more tags are analyzed. The
|
|
definition of the commit tag rules are somewhere in the Polarion :) Because
|
|
the release notes content is taken from the log history of a release branch
|
|
each commit in it's history has to use tagged commits. As long as the
|
|
release branch is branched off the master only it's own commits and the
|
|
master's commits has to be tagged. Figure \ref{fig:git_commit_history}
|
|
illustrates the flow of the log history of the release branch shown in
|
|
figure \ref{fig:gitlab_workflow}.
|
|
|
|
\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. Table \ref{tab:conf_var}
|
|
and listing \ref{lst:ag_cfg} gives an overview about customizing a release
|
|
phase.
|
|
|
|
\captionof{table}{Variables to customize a release phase}
|
|
\label{tab:conf_var}
|
|
\begin{tabular}{l l l}
|
|
\cellcolor{black}\color{white}variable & \cellcolor{black}\color{white}meaning & \cellcolor{black}\color{white}example\\
|
|
PRODUCT\_NAME & Short of the product name & AG\\
|
|
PRODUCT\_VARIANT & Short of the product variant & NA\\
|
|
PROJECT\_VERSION & ?? & 10\\
|
|
SW\_MAJOR & Software major number & 1\\
|
|
SW\_MINOR & Software minor number & 2\\\\
|
|
\end{tabular}
|
|
\newline
|
|
|
|
\lstsetbash
|
|
\begin{lstlisting}[caption=variables configuration, label=lst:ag_cfg]
|
|
variables:
|
|
PRODUCT_NAME: "AG"
|
|
PRODUCT_VARIANT: "NA"
|
|
PROJECT_VERSION: "10"
|
|
SW_MAJOR: "1"
|
|
SW_MINOR: "2"
|
|
\end{lstlisting}
|
|
|
|
\textbf{Remember}, it is a good idea to change these values before creating
|
|
the release branch, creating (and pushing) the branch triggers the build of
|
|
a release candidate.
|