The EMERALD CaaS (Certification-as-a-Service) framework will consist of several components, with different levels of maturity and developed by different teams, which makes it challenging to approach the integration of the framework. Furthermore, on the validation side, the project includes several pilots, each with its particular needs and limitations. Therefore, we have considered that the application of a DevOps Methodology together with CI/CD (Continuous Integration/Continuous Deployment) strategies are the most suitable solutions for the implementation of the framework.

The DevOps Methodology¹ in EMERALD focuses on how the development, integration and validation teams will collaborate to build and evolve the CaaS framework through its three planned releases during the lifecycle of the project. It has the following main characteristics:

• Release based: Three releases are planned in M18, M30 and M24.
• Manage feedback: The project will be tested in 4 real pilot environments.
• Manage the set of components: 12 framework components have been identified so far.
• Keep traceability of requirements: Requirements will be managed in Gitlab.
• Manage the environments: At least two environments (integration and production) will be managed, but additional environments can be managed on demand.
• Integrate as soon as possible: Merge requests from development teams should be promoted into the integration environment as soon as possible.

Figure 1. DevOps Cycle

Figure 1 shows the basic structure of the DevOps cycle adopted in EMERALD, which is commonly presented in publications and includes the following steps:

• Plan: Collect the integration and deployment needs of the project, prioritise them and track them as “Gitlab issues” in the CaaS framework repository.
• Code: Encode the components’ integration with a container orchestration code (aka choreography). In addition, IaC² (Infrastructure as Code) will be developed for the environment and side services.
• Build: Automated process that will take the choreography and will deploy the CaaS framework in the integration environment.
• Test: Focused on the integration testing, including the necessary tests as well as the monitoring mechanism to verify the long-term behaviour of the framework.
• Release: Create a tag in the CaaS framework repository.
• Deploy: Automated process that will take the choreography and deploy the tagged CaaS framework first in the production environment, and then in the pilot environments.
• Operate: Focused on the validation management process that will be carried out by separate teams in the pilot environments.
• Monitor: Adapt the monitoring of the integration environment to cover the production and pilot environments.

The CI/CD Strategy defined in EMERALD describes the technical approaches to be applied in the project to continuously integrate, deploy, and validate the outcomes from the different development teams. On the one hand, the Continuous Integration (CI) strategy deals with the integration of the different components that make up the CaaS framework and the verification of the integrated version so that it is ready for its deployment. The following technological approaches will be applied:

• Components packaged as containers: The Docker ecosystem³ will be used to build and share images. For image building both Docker and Docker Compose will be supported.
• Environment defined with Infrastructure as Code (IaC): The integration environment will be composed of a four-node Kubernetes⁴ cluster -configured by a set of Ansible⁵ playbooks- on a vSphere⁶ platform.
• Progressive verification: A set of automated integration tests will check the health of the components, while more complex tests will be based on developer requests.
• Integration automation: A GitLab Agent for Kubernetes will monitor the CaaS framework repository, and allow new versions of components to be deployed and tested directly.

On the other hand, the Continuous Deployment (CD) strategy deals with the deployment of the integrated version of the CaaS framework both in the production environment and in the pilot environments for validation. The following technological approaches will be applied:

• Releases: A release is generated by copying the content in the integration branch into the production branch. The process starts with the creation of an issue and a merge request, as shown in Figure 2.
• Documentation: The documentation related to the CaaS Framework will be generated as part of the deployment in the production environment
• Environment defined with IaC: The production environment will be deployed using IaC, i.e., the same approach as for the integration environment.
• Deployment automation. Focused in deploying specific releases in specific environments, and updating the monitoring mechanism to measure the long-term health of the CaaS framework.

Figure 2. A Merge Request process to produce a new release in EMERALD

More information:
DevOps methodology and CD/CI strategy for EMERALD-v1

¹ https://en.wikipedia.org/wiki/DevOps
² https://en.wikipedia.org/wiki/Infrastructure_as_code
³ https://docs.docker.com/
⁴ https://kubernetes.io/
⁵ https://www.ansible.com/
⁶ https://www.vmware.com/products/vsphere.html