solves #60, #61, #62

content/01.abstract.md

@@ -1,4 +1,4 @@
-## Abstract {.page_break_before}
+# Abstract {.page_break_before}
 
 The purpose of this document is to define a set of quality standards,
 procedures and best practices to conform a Software Quality Assurance plan to

content/02.0.copyright-ack.md

@@ -1,9 +1,9 @@
-## Copyright Notice
+# Copyright Notice
 
 Copyright © Members of the INDIGO-DataCloud, DEEP Hybrid-DataCloud eXtreme
 DataCloud and EOSC-Synergy collaborations, 2015-2020.
 
-## Acknowledgements
+# Acknowledgements
 
 The INDIGO-DataCloud, DEEP-Hybrid-DataCloud, eXtreme-DataCloud and
 EOSC-Synergy projects have received funding from the European Union’s

content/02.document-log.md

@@ -1,4 +1,4 @@
-## Document Log
+# Document Log {.page_break_before}
 
 | Issue | Date | Comment |
 |-------|------|---------|

content/03.intro.md

@@ -1,4 +1,4 @@
-## 1. Introduction and Purpose
+# 1. Introduction and Purpose {.page_break_before}
 
 This document has been tailored upon the recommendations and requirements found
 in the Initial Plan for Software Management and Pilot Services deliverable

content/04.goals.md

@@ -1,17 +1,24 @@
-## 2. Goals
+# 2. Goals
 
 1. Set the base of minimum SQA criteria that a software developed within EOSC development project
    MUST fulfill.
+
 2. Enhance the visibility, accessibility and distribution of the produced source code through the
    alignment to the Open Source Definition [@https://opensource.org/osd].
+
 3. Promote code style standards to deliver good quality source code emphasizing its readability and
    reusability.
+
 4. Improve the quality and reliability of software by covering different
    testing methods at development and pre-production stages.
+
 5. Propose a change-based driven scenario where all new updates in the source code are continuously
    validated by the automated execution of the relevant tests.
+
 6. Adopt an agile approach to effectively produce timely and audience-specific documentation.
+
 7. Lower the barriers of software adoption by delivering quality documentation and the utilization
    of automated deployment solutions.
+
 8. Encourage secure coding practices and security static analysis at the development phase while
    providing recommendations on external security assessment.

content/05.notational_conventions.md

@@ -1,4 +1,4 @@
-## 3. Notational Conventions
+# 3. Notational Conventions
 
 The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”,
 “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be

content/06.quality_criteria.md

@@ -1,4 +1,4 @@
-## 4. Quality Criteria
+# 4. Quality Criteria {.page_break_before}
 
 The following sections describe the quality conventions and best practices that
 apply to the development phase of a software component within the EOSC
@@ -14,6 +14,8 @@ validate them before being added to the software component code base.
 Consequently, software components are more eligible for being deployed in
 production infrastructures, reducing the likelihood of service disruption.
 
+## Manual Criteria
+
 ### 4.1. Code Accessibility [QC.Acc]
 
 * **[QC.Acc01]** Following the open-source model, the source code being produced MUST be open
@@ -107,6 +109,8 @@ A change-based approach is accomplished with a branching model.
     description SHOULD make reference to the identifiers of the issues it is fixing
     (to eventually close them, either manually or automatically).
 
+## Continuous Integration (CI)
+
 ### 4.5. Code Style [QC.Sty]
 
 Code style requirements pursue the correct maintenance of the source code by
@@ -383,22 +387,37 @@ the required set of change-based tests.
 * **[QC.Rev05]** Code reviews SHOULD assess the inherent security risk of the changes,
   ensuring that the security model has not been downgraded or compromised by the changes.
 
-### 4.14. Automated Deployment [QC.Aud]
+## Continuous Delivery, Continuous Deployment (CD)
+
+### 4.14. Automated Delivery [QC.Del]
+
+Automated delivery comprises the build of Software into an artifact, its upload/registration into
+a public repository of such artifacts and notification of successful process.
+
+* **[QC.Del01]** Production-ready code SHALL be built as an artifact that can be executed on a system.
+
+* **[QC.Del02]** The builded artifact SHALL be uploaded and registered into a public repository of
+  such artifacts.
+
+* **[QC.Del03]** Upon success of the previous (**QC.Del02**) process, a notification SHALL be sent
+  to pre-defined parties such as the main developer or team.
+
+### 4.15. Automated Deployment [QC.Dep]
 
-* **[QC.Aud01]** Production-ready code SHALL be deployed as a workable system with the minimal user
+* **[QC.Dep01]** Production-ready code SHALL be deployed as a workable system with the minimal user
 or system administrator interaction leveraging software configuration management (SCM) tools.
 
-* **[QC.Aud02]** A SCM module is treated as code.
-  * **[QC.Aud02.1]** Version controlled, it SHOULD reside in a different repository than the
+* **[QC.Dep02]** A SCM module is treated as code.
+  * **[QC.Dep02.1]** Version controlled, it SHOULD reside in a different repository than the
     source code to facilitate the distribution.
 
-* **[QC.Aud03]** It is RECOMMENDED that all software components delivered by the same project
+* **[QC.Dep03]** It is RECOMMENDED that all software components delivered by the same project
   agree on a common SCM tool.
-  * **[QC.Aud03.1]** However, software products are not restricted to provide a unique
+  * **[QC.Dep03.1]** However, software products are not restricted to provide a unique
     solution for the automated deployment.
 
-* **[QC.Aud04]** Any change affecting the application’s deployment or operation MUST be
+* **[QC.Dep04]** Any change affecting the application’s deployment or operation MUST be
   subsequently reflected in the relevant SCM modules.
 
-* **[QC.Aud05]** Official repositories provided by the manufacturer SHOULD be used to host
+* **[QC.Dep05]** Official repositories provided by the manufacturer SHOULD be used to host
   the SCM modules, thus augmenting the visibility and promote external collaboration.

content/08.annex.md

@@ -15,21 +15,23 @@ Quality Criteria detailed in this document.
 
 | Service/Tool | Usage              | Criteria   | Comment |
 |:------------:|:------------------:|:----------:|:-------:|
-| Github       | VCS                | **QC.Acc** | Source code repository |
-|              | License            | **QC.Lic** | File present in VCS repository |
-|              | Code Workflow      | **QC.Wor** | |
+| Github       | VCS                | **QC.Acc** | Source code repository - git |
+|              | Code Workflow      | **QC.Wor** | git branching management and version tagging |
 |              | Issue tracker      | **QC.Man** | Track issues, bugs, new features, etc. |
-|              | Pull Requests (PR) | **QC.Man**, **QC.Rev** | Code review |
-|              | Code metadata      | **QC.Met** | JSON metadata file present in VCS repository |
+|              | Pull Requests (PR) | **QC.Man**, **QC.Rev** | Code review through PRs |
 |              | Documentation      | **QC.Doc** | Documentation present in VCS repository (markdown) |
-| Jenkins CI   | Pipelines of tests | **QC.Uni**, **QC.Int**, **QC.Fun**, **QC.Sec** | Service to manage CI tests |
-|              | Check style        | **QC.Sty** | pylint, checkstyle |
 | Docker, Dockerhub | Jenkins CI nodes | | Containers to execute CI tests |
 | Ansible, Galaxy   | Installation, Configuration | **QC.Aud** | Automated deployment and configuration |
 
 Table: Tools and services used to implement the QA criteria, also shown the criteria
 where applicable. {#tbl:services}
 
+| Service/Tool | Usage              | Criteria   | Comment |
+|:------------:|:------------------:|:----------:|:-------:|
+|              | License            | **QC.Lic** | File present in VCS repository |
+|              | Code metadata      | **QC.Met** | JSON metadata file present in VCS repository |
+| Jenkins CI   | Pipelines of tests | **QC.Lic**, **QC.Met**, **QC.Sty**, **QC.Uni**, **QC.Int**, **QC.Fun**, **QC.Sec**, **QC.Tdd** | Service to manage CI tests |
+
 ### A1.2. Code workflow
 
 This section describes the code workflow shown in Figure @fig:workflow