Create a common strategy for deployments

[genaris]

At the moment, we are managing deployments in separate GitLab repositories per module and environment, which is cumbersome and very hard to maintain.

We need to migrate these to GitHub and define a common structure and/or guidelines to make it easier to understand and as error prone as it can be.

For example, I think that we can do an approach like the one in Verana, where a number of modules are grouped together and different GitHub actions are used to update each. In 2060 I can identify at least three potential repositories:

• 2060-core-deploy: containing deployment scripts for DIDComm mediator, Message Pickup Repository, WebRTC Server for P2P, Indy VDR Proxy, Trust Service Resolver, etc.
• 2060-demos-deploy: Chatbot Demo, generic verifier using phone number credential, and other demos we may want to keep public
• unic.id-deploy: containing Issuer DTS, Verifier DTS, Vision service, matcher, WebRTC server, etc.

It would be good to start with UnicID deployment, since it is not already created and it could be a good example to experiment with.

[lotharking]

📂 Proposed Repository Structure

Proposal

Globally, the following strategy has been proposed for file management:
There are two ways to integrate this solution. We could manage two environments, main and dev, both as protected branches, with each controlling its own deployment. A deployments folder will be created, and each project will have its own files. Each GitHub Actions workflow will validate only the changes made in the specified folder. This ensures that if a redeployment is necessary at any time, it will not cause difficulties or affect all projects globally. We will use Helm for versioning and project deployment, allowing efficient parameterization of manifests and greater control over each deployment.

Deployment Options

1. Direct Deployment via GitHub Actions
   The first option would be an integration similar to what is used in GitLab, where the pipeline handles direct deployment to Kubernetes. In this case, using GitHub Actions, we could deploy the changes, and if everything works correctly, the new images will be deployed. This approach provides a simpler deployment process for each project.
   You can check out this video for more details: Pelado Nerd's video

2. Deployment via Jenkins
   The second option involves using Jenkins for deployment. Since we are restructuring continuous integration, we could explore this solution, which offers several advantages, including greater control over pipelines. Jenkins allows validation of whether the deployed image works correctly and, in blue-green deployment mode, gives the developer a specific time frame to test the new image. If it passes manual testing, the deployment can be approved. This approach helps prevent malfunctions and ensures that we can soon transition our projects to a production environment for client testing.

Architecture

📦 ci-cd-repo
│── 📂 .github
│   ├── 📂 workflows
│   │   ├── projectA.yml  # CI/CD pipeline for individual deployment
│── 📂 deployments
│   ├── 📂 projectA
│   │   ├── Chart.yaml      # Helm Chart definition for Project A
│   │   ├── values.yaml     # Custom values for Project A
│   │   ├── 📂 templates
│   │   │   ├── deployment.yaml  # Single deployment template
│   ├── 📂 projectB
│   │   ├── Chart.yaml
│   │   ├── values.yaml
│   │   ├── 📂 templates
│   │   │   ├── deployment.yaml
│   ├── 📂 projectC
│   │   ├── Chart.yaml
│   │   ├── values.yaml
│   │   ├── 📂 templates
│   │   │   ├── deployment.yaml
│── README.md

🚀 Proposed CI/CD Github

@startuml

title CI/CD Deployment Process

actor Developer
participant "Individual Code Repository" as Repo
participant "DockerHub" as DH
participant "Deployment Repository" as DeployRepo
participant "Jenkins (Blue-Green)" as Jenkins
participant "Kubernetes Cluster" as K8S

== Scenario common: Push to Individual Repo ==
Developer -> Repo : Push Code
Repo -> DH : Build & Push Docker Image
DH -> Developer : Image Published

== Scenario 1: Direct Publication ==
Developer -> DeployRepo : Push Deployment Config
DeployRepo -> Developer : Publication Completed
alt Publication Fails
    DeployRepo -> Developer : GitHub Pipeline Fails
end

== Scenario 2: Deployment with Blue-Green (Jenkins) ==
Developer -> DeployRepo : Push Deployment Config
DeployRepo -> Jenkins : Trigger Blue-Green Deployment
Jenkins -> DH : Fetch Docker Image
Jenkins -> K8S : Deploy to Blue Environment
Jenkins -> K8S : Run Health Check
alt Health Check Fails
    Jenkins -> Developer : Rollback Deployment
else Health Check Passes
    Jenkins -> K8S : Switch Traffic to Blue
    Jenkins -> K8S : Remove Green Environment
end
Jenkins -> Developer : Deployment Completed

@enduml

🖼️ Proposed CI/CD Github - IMG