RoadMap⚓︎

RoadMap consists of three streams:

• Community
• Architecture
• Building Blocks
• Admin Console
• Documentation

I. Community⚓︎

Goals:

• Innovation Through Collaboration
• Improve OpenSource Adoption
• Build Community around technology solutions EDP is built on

Deliver Operators on OperatorHub⚓︎

OperatorHub is a defacto leading solution which consolidates Kubernetes Community around Operators. EDP follows the best practices of delivering Operators in a quick and reliable way. We want to improve Deployment and Management experience for our Customers by publishing all EDP operators on this HUB.

Another artifact aggregator which is used by EDP - ArtifactHub, that holds description for both components: stable and under-development.

II. Architecture⚓︎

Goals:

• Improve reusability for EDP components
• Integrate Kubernetes Native Deployment solutions
• Introduce abstraction layer for CI/CD components
• Build processes around the GitOps approach
• Introduce secrets management

Kubernetes Multitenancy⚓︎

Multiple instances of EDP are run in a single Kubernetes cluster. One way to achieve this is to use Multitenancy. Initially, Kiosk was selected as tools that provides this capability. An alternative option that EDP Team took into consideration is Capsule. Another tool which goes far beyond multitenancy is vcluster going a good candidate for e2e testing scenarios where one needs simple lightweight kubernetes cluster in CI pipelines.

Microservice Reference Architecture Framework⚓︎

EDP provides basic Application Templates for a number of technology stacks (Java, .Net, NPM, Python) and Helm is used as a deployment tool. The goal is to extend this library and provide: Application Templates which are built on pre-defined architecture patterns (e.g., Microservice, API Gateway, Circuit Breaker, CQRS, Event Driven) and Deployment Approaches: Canary, Blue/Green. This requires additional tools installation on cluster as well.

Policy Enforcement for Kubernetes⚓︎

Running workload in Kubernetes calls for extra effort from Cluster Administrators to ensure those workloads do follow best practices or specific requirements defined on organization level. Those requirements can be formalized in policies and integrated into: CI Pipelines and Kubernetes Cluster (through Admission Controller approach) - to guarantee proper resource management during development and runtime phases. EDP uses Open Policy Agent (from version 2.8.0), since it supports compliance check for more use-cases: Kubernetes Workloads, Terraform and Java code, HTTP APIs and many others. Kyverno is another option being checked in scope of this activity.

Secrets Management⚓︎

EDP should provide secrets management as a part of platform. There are multiple tools providing secrets management capabilities. The aim is to be aligned with GitOps and Operator Pattern approaches so HashiCorp Vault, Banzaicloud Bank Vaults, Bitnami Sealed Secrets are currently used for internal projects and some of them should be made publicly available - as a part of EDP Deployment.

Release Management⚓︎

Conventional Commits and Conventional Changelog are two approaches to be used as part of release process. Today EDP provides only capabilities to manage Release Branches. This activity should address this gap by formalizing and implementing Release Process as a part of EDP. Topics to be covered: Versioning, Tagging, Artifacts Promotion.

Kubernetes Native CI/CD Pipelines⚓︎

EDP has deprecated Jenkins in favour of Tekton. Jenkins is no longer available since EDP v3.4.4.

Advanced EDP Role-based Model⚓︎

EDP has a number of base roles which are used across EDP. In some cases it is necessary to provide more granular permissions for specific users. It is possible to do this using Kubernetes Native approach.

Notifications Framework⚓︎

EDP has a number of components which need to report their statuses: Build/Code Review/Deploy Pipelines, changes in Environments, updates with artifacts. The goal for this activity is to onboard Kubernetes Native approach which provides Notification capabilities with different sources/channels integration (e.g. Email, Slack, MS Teams). Some of these tools are Argo Events, Botkube.

Reconciler Component Retirement⚓︎

Persistent layer, which is based on edp-db (PostgreSQL) and reconciler component should be retired in favour of Kubernetes Custom Resource (CR). The latest features in EDP are implemented using CR approach.

III. Building Blocks⚓︎

Goals:

• Introduce best practices from Microservice Reference Architecture deployment and observability using Kubernetes Native Tools
• Enable integration with the Centralized Test Reporting Frameworks
• Onboard SAST/DAST tool as a part of CI pipelines and Non-Functional Testing activities

Infrastructure as Code⚓︎

EDP Target tool for Infrastructure as Code (IaC) is Terraform. EDP sees two CI/CD scenarios while working with IaC: Module Development and Live Environment Deployment. Today, EDP provides basic capabilities (CI Pipelines) for Terraform Module Development. At the same time, currently EDP doesn't provide Deployment pipelines for Live Environments and the feature is under development. Terragrunt is an option to use in Live Environment deployment. Another Kubernetes Native approach to provision infrastructure components is Crossplane.

Database Schema Management⚓︎

One of the challenges for Application running in Kubernetes is to manage database schema. There are a number of tools which provides such capabilities, e.g. Liquibase, Flyway. Both tools provide versioning control for database schemas. There are different approaches on how to run migration scripts in Kubernetes: in init container, as separate Job or as a separate CD stage. Purpose of this activity is to provide database schema management solution in Kubernetes as a part of EDP. EDP Team investigates SchemaHero tool and use-cases which suits Kubernetes native approach for database schema migrations.

Open Policy Agent⚓︎

Open Policy Agent is introduced in version 2.8.0. EDP now supports CI for Rego Language, so you can develop your own policies. The next goal is to provide pipeline steps for running compliance policies check for Terraform, Java, Helm Chart as a part of CI process.

Report Portal⚓︎

EDP uses Allure Framework as a Test Report tool. Another option is to integrate Report Portal into EDP ecosystem.

Carrier⚓︎

Carrier provides Non-functional testing capabilities.

Java 17⚓︎

EDP supports two LTS versions of Java: 8 and 11. The goal is to provide Java 17 (LTS) support.

Velero⚓︎

Velero is used as a cluster backup tool and is deployed as a part of Platform. Currently, Multitenancy/On-premise support for backup capabilities is in process.

Istio⚓︎

Istio is to be used as a Service Mesh and to address challenges for Microservice or Distributed Architectures.

Kong⚓︎

Kong is one of tools which is planned to use as an API Gateway solution provider. Another possible candidate for investigation is Ambassador API Gateway

OpenShift 4.X⚓︎

EDP supports the OpenShift 4.9 platform.

IV. Admin Console (UI)⚓︎

Goals:

• Improve UХ for different user types to address their concerns in the delivery model
• Introduce user management capabilities
• Enrich with traceability metrics for products

Users Management⚓︎

EDP uses Keycloak as an Identity and Access provider. EDP roles/groups are managed inside the Keycloak realm, then these changes are propagated across the EDP Tools. We plan to provide this functionality in EDP Portal using the Kubernetes-native approach (Custom Resources).

The Delivery Pipelines Dashboard⚓︎

The CD Pipeline section in EDP Portal provides basic information, such as environments, artifact versions deployed per each environment, and direct links to the namespaces. One option is to enrich this panel with metrics from the Prometheus, custom resources, or events. Another option is to use the existing dashboards and expose EDP metrics to them, for example, plugin for Lens or OpenShift UI Console.

Split Jira and Commit Validation Sections⚓︎

Commit Validate step was designed to be aligned with Jira Integration and cannot be used as single feature. Target state is to ensure features CommitMessage Validation and Jira Integration both can be used independently. We also want to add support for Conventional Commits.

V. Documentation as Code⚓︎

Goals:

• Transparent documentation and clear development guidelines for EDP customization.
• Components that provide Documentation as Code feature should be integrated into EDP.

Consolidate documentation in a single repository edp-install, use mkdocs tool to generate docs and GitHub Pages as a hosting solution.