Authors: Panos Matzakos
Organization: Netcompany-Intrasoft
CI/CD stands for Continuous Integration and Continuous Delivery or Continuous Deployment. It’s a set of best practices and methodologies in software development, aiming to deliver code changes more frequently and reliably and shorten the development cycles, using automation extensively.
Continuous Integration (CI) involves developers frequently merging their code changes into a central repository. Each code update triggers automated builds and various tests—such as unit, functional, and integration tests— through the CI server to ensure that the application remains stable as new changes are merged into the main repository branch. This workflow also includes packaging software components into Docker container images, storing them in a container image registry, and deploying them as containerized applications within a dedicated development/testing environment, specifically under the central NANCY Kubernetes cluster (Figure 1). The primary aim of CI is to accelerate the release cycle by identifying and resolving bugs early, thereby streamlining the development process and minimizing the need for extensive rework. In this context, this approach allows teams to concentrate more on development and integration activities.
Figure 1 Continuous Integration workflow
As shown in Figure 1, the following tools comprise the CI framework of NANCY:
· Github code repository[1] featuring version control, access management, and issue tracking.
- Jenkins CI server[2] to handle automated build, testing, and deployment pipelines, triggered by software updates. Role Based Access Control (RBAC) policies are applied to ensure that each developer/component provider has access only to dedicated workspaces (Figure 2) where she/he is authorized.
[1] https://github.com/
[2] https://www.jenkins.io/
Figure 2 NANCY component-specific workspaces in Jenkins server
- Harbor private registry[3] to store and distribute software artifacts, such as container images and Kubernetes helm charts. Similarly to the Jenkins CI server, RBAC is applied, and different workspaces have been created for the different NANCY component providers in the Harbor registry (Figure 3).
[3] https://goharbor.io/
Figure 3 NANCY component specific workspaces in Harbor container registry
- Kubernetes[4] is an open-source, cloud-native platform that automates the deployment, scaling, and management of containerized applications. Within the NANCY project, the main Kubernetes cluster facilitates hosting for development/testing and staging environments.
- Utilities for logging, notifications, and health monitoring are implemented at various stages of the CI/CD workflows.
Continuous Delivery (CD) acts as the next phase, following Continuous Integration in the software release pipeline. It enables the deployment to production environments in a manual manner, once all relevant CI workflows have been successfully validated. This stage focuses on preparing the software artifact for distribution to the end-users in the NANCY testbeds and demonstration environments. It is crucial to maintain this phase in a ‘healthy’ state, indicating that the artifact is consistently ready for deployment. It ensures that the code can be deployed to production at any time but requires human approval, as opposed to Continuous Deployment where the deployment to production environments is fully automated.
In the context of NANCY, a Continuous Delivery approach is followed for the deployments across the different (Kubernetes-based) testbeds and demonstrators (Figure 4). In this framework, the connection of the CI/CD system with NANCY service and resource orchestrators is also envisioned, to efficiently manage large-scale service order deployments towards the different demonstrator-specific Kubernetes clusters.
[4] https://kubernetes.io/
