\section{Architecture}
\label{sec:architecture}

Based on the great list of functional requirements desired by Brazilian Federal
Government we decided to select some FOSS systems that already contemplate some
of them and improve these systems. And bringing the idea of community, it is
undoable build a platform to be used by communities, which is a complex
scenario, using just one tool.

At the point of view of the architecture, two main requirements was brought by
the Brazilian Federal Government for the new platform:

\begin{enumerate}
  \item \textit{Integrate existing FOSS systems}, with minimal differences from
    their original versions;
  \item \textit{Provide a consistent user interface} across the different
    systems, as well as centralized authentication.
\end{enumerate}

Adopting existing FOSS systems by the government could bring the benefit of
improvements done by the upstream communities, and the maintenance effort. On
the other hand, integrating different tools with distinct intent, it is not an
easy task and it was important to have a consistent user interface which
justifies the last requirement.

For the first requirement, we identified four main systems that required
specialized teams for work in the integration process. The teams learned how to
develop for their assigned systems and contributed to the  original
communities, so that the version we used were not significantly different from
the original.

At the end of the project, SPB portal was composed of more than ten systems
among them we can highlight: Colab, Noosfero, Mezuro, Gitlab, Mailman, Postfix,
Munin, and so forth. The following sections explained a little bit of Colab,
Noosfero, Mezuro, and Gitlab (the main tools which we contributed). Below, we
described how we integrated those tools and conclude with the deployment.

\subsection{Colab}

Colab integrates web applications as its main goal, the user of this composed
system should not notice the change between the integrated applications. Colab
was designed to use one plugin for each system under its domain, this is
guaranteed by four levels of integration:

\begin{itemize}
  \item Authentication
  \item Visual
  \item Events
  \item Data and search engine
\end{itemize}

The aforementioned integrations levels were possible, because Colab works as a
reverse proxy, therefore all external requests pass through it.

Single Sign-On (SSO) is used to login users throughout all integrated
applications. REMOTE\_USER HTTP header is sent to the applications and we
expect that they know how to handle it, since this is a common authentication
mechanism. The integrated applications should be on a local network to avoid
security issues. With this the user will be able to navigate through the
platform applications and will not be asked for authentication credentials.

As Colab\footnote{\url{https://github.com/colab}} is a reverse proxy, it makes
some HTML transformations in the HTTP response of integrated applications to
provide a unified interface. Allows one to define some default templates to be
used by all applications and overwrite when needed in its plugin. This approach
allowed us to reuse some HTML pages which facilitates maintenance.

A publish-subscribe implementation was used to handle events in the platform.
Thus, if some application want to trigger some action in case that other
application do something is possible. A registration of the desired events and
implementation of the handlers must be done in the plugin of each application.
This bring us many options to innovate in these integrations.

A integrated search engine is provided by Colab. Each plugin specify which data
will be indexed and will became available for the users, just need an simple
implementation of how should perform the collection of data.

Initially, Colab had support for a small set of applications (Trac, GNU
Mailman, and Apache Lucene) and all of them was hard-coded. Our team evolved
Colab so that it can now receive plugins to add support for new applications
with minimal changes to its existing core. We developed plugins to be used in
the SPB platform: Noosfero, GitLab, and Mezuro.

\subsection{Noosfero}

Noosfero\footnote{\url{http://noosfero.org}} is a software for building
social and collaboration networks. Besides the classical social
networking features, it also provides publication features such as blogs
and a general-purpose CMS (Content Management System). Most of the user
interactions with SPB is through Noosfero: user registration, project
home pages and documentation, and contact forms.

\subsection{Gitlab}

GitLab\footnote{\url{http://gitlab.com}} is a web-based Git repository manager
with wiki pages and issue tracking features. On the one hand, Github is the
most famous and used Git repository manager. On the other hand, it is not a
FOSS. Gitlab is a FOSS platform and focuses on delivering a holistic solution
that will see developers from idea to production seamlessly and on a single
platform. Thus, we have worked on it to integrated to Colab.

Moreover, Gitlab has several features working properly than Github that is
interesting in SPB context such as free for private projects, built-in
continuous integration and continuous deployment with best practices, more
control during downtime and upgrade, flexible permissions, Work-in-Progress
protection, move issues between projects, Group-level milestones, Create new
branches from issues, Issue board, Time tracking, as well new features and
improvements every month on the 22nd.

\subsection{Mezuro}

Mezuro\footnote{\url{http://mezuro.org/}} is a platform to collect source code
metric to monitor the internal quality of softwares written in C, C++,
Java, Python, Ruby, and PHP. GNU Mailman is used for mailing lists.

In general, source code metric tools also do not present a friendly way to
interpret its results and, even more, do not follow a standardization between
them. Mezuro brings and presents these results to
the end user, specially, by analyzing source code metric history during its
life cycle.

The Mezuro platform provides a single interface
grouping available tools, allows selection and composition of metrics in a
flexible manner, stores the metrics evolution history, presents
results in a friendly way, as well as, allows users to customize the given
interpretation accordingly to their own context.

\subsection{System unification}

\begin{figure}[hbt]
  \centering
    \includegraphics[width=\linewidth]{figures/arch.png}
  \caption{SPB architecture overview.}
  \label{fig:architecture}
\end{figure}

The conceptual architecture of the platform is presented in Figure
\ref{fig:architecture}. Colab initially handles all user interaction,
directing requests to one of the integrated applications. It
post-processes responses from the applications to apply a consistent
visual appearance, manages authentication, and provides a unified search
functionality: instead of using the redundant restricted search
functionality of each application, a search in the SPB portal might
return content from any of the applications, be it web pages, mailing
list posts, or source code.

% Falar do devops
\subsection{Deploy}

The SPB platform was deployed in 7 virtual machines with different functions,
as we can see in Figure \ref{fig:architecture2}.

\begin{figure*}[hbt]
  \centering
    \includegraphics[width=.8\linewidth]{figures/arch3.png}
  \caption{Instanciation view of the SPB architecture.}
  \label{fig:architecture2}
\end{figure*}

The \textit{reverseproxy} handles the HTTP requests and redirects them to the
\textit{integration}, the \textit{email} sends and receives e-mails on behalf
of the platform and the \textit{monitor} keeps the entire environment tracked.
These three \textit{VMs} mentioned - \textit{reverseproxy}, \textit{email} and
\textit{monitor} - are accessible via Internet and the other ones are only
available in the local network created between them.

\textit{Integration} works as a second layer of proxy beneath
\textit{reverseproxy}, any request to the platform will be handled by it. The
Colab service provides interface, authentication and search engine integration
among all the services. When a request is received to a specific service,
Colab authenticates the user in the target tool, sends the request and makes a
visual transformation in the HTML page which is the content of the response.
Another user-oriented feature is the integrated search engine, when the user
want to find something in the platform Colab will perform the search in the
whole databases. Colab itself provides a web interface for GNU Mailman and we
have two others integrated tools in \textit{integration}: Gitlab and Prezento.
Gitlab provides web interface for Git repositories and issues tracker, and
Prezento is a front-end for source code static analysis.

The source code static analysis is performed by \textit{mezuro}. It runs some
static analysis tools on source code stored in repository and provide this data
to Prezento. A social network and CMS (Content Manager System) is provided by
Noosfero in \textit{social}, and the databases of all tools with a cache
service are in \textit{database}.