In Figure we depict the project's software lifecycle management services and
activities and their interdependencies:
\begin{itemize}
\item Version Control System (VCS) - Source Code is made available through public VCS
repositories, hosted externally in GitHub repositories, guaranteeing in this
way the software openness and visibility, simplifying the exploitation beyond the
project lifetime. The INDIGO-DataCloud software is released under the Apache 2.0
software license and can be deployed on both public and private Cloud infrastructures.
\item Software quality assurence criteria and control activities and services to enable them:
\begin{itemize}
\item Continuous Integration service using {\bf Jenkins}: Service to automate the building,
packaging (where applicable) and execution of unit and functional tests of software components.
\item Code review service using GitHub: Code review of software source code is one integral part of the SQA\@. This service facilitates the code review proces. It records the
comments and allows the reviewer to verify the software modification.
\item Code metrics services using {\bf Grimoire}: To collect and visualize several metrics about the software components.
\end{itemize}
\item Software release and maintenance activities, services and supporting infrastructures
After the delivery of the first draft of the strategy and recommendations done in
2017 and begining of 2018, four data interoperability demonstrators have been
proposed to test components of the strategy:
\begin{itemize}
\item A project management service using {\bf openproject.org} is made available by the
project: It provides tools such as an issue tracker, wiki, a placeholder for documents and a project management timeline.
\item Artifacts repositories for RPM and Debian packages, and Docker Hub for containers:
In INDIGO-DataCloud there are two types of artifacts, packaged software and virtual images.
The software can be downloaded from our public repository\footnote{http://repo.indigo-datacloud.eu}.
\item Release notes, installation and configuration guides, user and development manuals are made
available on {\bf GitBook}\footnote{https://indigo-dc.gitbooks.io/indigo-datacloud-releases}.
\item Bug trackers using GitHub issues tracker: Services to track issues and bugs of INDIGO-DataCloud software components.
\item Integration infrastructure: this infrastructure is composed of computing resources to support directly
the Continuous Integration service. It's the place where building and packaging of software
occurs as well as the execution of unit and functional tests. These resources are provided by INDIGO partners.
\item Testing infrastructure: this infrastructure aims to provide several types of environment. A stable environment
for users where they can preview the software and services developed by INDIGO-DataCloud, prior to its public release.
\item Preview infrastructure: where the released artifacts are deployed and made available for testing and validation by the use-cases.
\item Evaluation of the EDMI (EOSC Datasets Minimum Information) metadata guidelines to find and access datasets
\item Discovery of compliant data resources and metadata catalogues
\item Research schemas for exposing dataset metadata
\item Description and guidelines per metadata property
\end{itemize}
Our role during 2018 was to:
\begin{itemize}
\item Facilitate & Support through
\begin{itemize}
\item Integration of the feedback from demonstrators into the
EOSCpilot data interoperability strategy
\item Organization of phone calls, F2F meetings and other events to help delivering the proposed tasks
\item Track the outcomes produced by the data interoperability demonstrators
\item Promote the activities and results of the demonstrators and work on
ways to recognise the contribution of the demonstrator participants.
\end{itemize}
\end{itemize}
\section{Other activities}
The first INDIGO-DataCloud major release (codename {\tt MidnightBlue}) was released 1st of August 2016 (see table~\ref{tab:1} for the fact sheet). The
second INDIGO-DataCloud major release (codename {\tt ElectricIndigo}) was made publicly available on April 14th 2017 (see table~\ref{tab:2} for the fact sheet).
\section{DevOps approach in INDIGO}
Progressive levels of automation were adopted throughout the different phases of
the INDIGO-DataCloud project software development and delivery processes.
\subsection{Services for continuous integration and SQA}
The INDIGO-DataCloud CI process is schematically shown
in Figure~\ref{fig:3}. The process, in its different steps, reflects some of
the main and important achievements of the software integration team, such as:
During 2018 we contributed also to the writing of two of the project deliverables
summarizing the activities done:
\begin{itemize}
\item New features are developed independently from the
production version in \textit{feature branches}. The creation of
a pull request for a specific feature branch marks the start of
the automated validation process through the execution of the
SQA jobs.
\item The SQA jobs perform the code style verification and calculate unit
and functional test coverage.
\begin{itemize}
\item The tools necessary for tackling these tests are packaged in
Docker images, available in DockerHub.
\item Each test then initiates a new container that provides a
clean environment for its execution.
\item This is an innovative approach that provides the flexibility
needed to cope with the INDIGO-DataCloud software diversity.
\end{itemize}
\item The results of the several SQA jobs are made available in the Jenkins
service which notifies back to GitHub their exit status.
\begin{itemize}
\item Only if the tests have succeeded, the source code is
validated and is ready to be merged into the production branch.
\end{itemize}
\item The last step in the workflow is the code review, where a human
review of the change is performed. After code review the source code
can be merged and becomes ready for integration and later release.
the status of all Science Demonstrators testbeds and activities, most of them
in line with what planned initially, some of them requiring extensions in order
to finalise the work.
\item{\bf D6.7: Revised Requirements of the Interoperability Testbeds} - providing
an updated picture of the different actors involved in the EOSCpilot project,
that, through their activities, aim in shaping the EOSC environment,
improving the services and e-infrastructures it consists of, and also provide
requirements and recommendations, based on the experiences they gained during
the project, to help in the prioritization of the new features of the existing
services and of the development of new services that are aligned with the needs
and expectations of researchers.
\end{itemize}
As a general rule, the described CI process must be followed by all the PTs
contributing code to INDIGO-DataCloud. However there are exceptions to this rule that fall into two main categories:
\subsection{Continuous delivery}
Continuous delivery adds, on top of the software development chain, a seamless
manufacturing of software packages ready to be deployed into production
services. Therefore, fast, frequent and small releases can be taken over thus
promoting the reliability of the software.
\subsection{DevOps adoption from user communities}
The experience gathered throughout the project with regards to the adoption of different DevOps
practices is not only useful and suitable for the software related to the core services in the
INDIGO-DataCloud solution, but also applicable to the development and distribution of the applications coming from the user communities.
\section{Conclusions}
Thanks to the new common solutions developed by the INDIGO project, teams of first-line
researchers in Europe are using public and private Cloud resources to get new results in Physics, Biology, Astronomy, Medicine, Humanities and other disciplines.
After the collection of the initial requirements on the interoperability testbeds,
reported in deliverable D6.4, at th end of 2017, the activities continued on
supporting the projects Science Demonstrators and an interim report on the
status of the testbeds was provided in the D6.5 deliverable. In the second part
of the project after the first round of selected Science Demonstrators were almost
at the end of their activities, while the second round was at the beginning, an
updated list of requirements regarding interoperability aspects was provided in
the deliverable D6.7.
The activities of the Interoperabiliy Pilots task will be concluded during the first part of 2019
by providing the validation of the e-infrastructures and services deployed. For this
final assessment we will take into considerations the ools/services developed as
part of other EC projects to implement the interoperability aspects, e.g. the
Interoperability (IOP) Quick Assessment Toolkit (add reference), developed in the
context of Action 2.1 of the Interoperability Solutions for European Public
Administrations (ISA) Programme (add reference)
\section*{Acknowledgments}
EOSCpilot has been funded by the European Commision H2020 research and innovation program under grant agreement RIA XXXXXXX.
EOSCpilot has been funded by the European Commision H2020 research and innovation
