Understanding DevOps and the RDMS (R&D Management Platform) Implementation

DevOps has become popular in software development, enabling teams to achieve agile development, regular code releases, automated deployment, and continuous integration/delivery, ultimately boosting productivity and rapid delivery.

1. Understanding DevOps

DevOps concept overview.

DevOps aims to increase productivity and accelerate delivery.

2. Background for Introducing DevOps

2.1 Technology Stack Overview

Backend frameworks: .NET Core (C#) and Java Spring Cloud, with some Python and Go projects.

Frontend frameworks: Vue, React.

Service deployment: Frontend sites on ECS with Nginx, backend services on Kubernetes.

Code repository: GitLab.

Environments: Development, Test, Stress, Integration, PRE, Production (six total).

2.2 Backend CI/CD Status

Each code push triggers a GitLab CI/CD pipeline defined in gitlab.yml, which runs unit tests, builds Docker images, deploys pods to Kubernetes, and starts automated API tests.

Missing elements?

Initial deployment steps to Kubernetes.

Location of service ConfigMaps.

Maintenance of differing gitlab.yml files per service.

Domain name resolution for applications.

Six environments are managed: development, test, integration, stress, PRE, and production. Test environments are maintained by testers, while PRE and production are handled by operations, creating a high learning curve for newcomers and significant communication overhead via ticketing systems.

2.3 Frontend CI/CD Status

Frontend CI/CD process overview.

Developers push code to GitLab; testers pull the latest code via Jenkins, which transfers files to the target server and triggers UI automation jobs. However, new site deployments still require Nginx configuration and manual ticketing for PRE and production changes.

2.4 Pain Points Identified

2.4.1 Security Governance Gaps

Code security: All team members have GitLab accounts, but no strict access controls.

Production security: Deployments are triggered directly from GitLab CI/CD without approval workflows.

2.4.2 Management Overhead

Multiple accounts (GitLab, Jenkins, Kubernetes) per user increase administrative burden.

Ticket communication consumes considerable time.

Inconsistent code standards across many micro‑services complicate maintenance and troubleshooting.

3. RDMS (R&D Management Platform) Emergence

3.1 Concept of the Platform

From toolchain to platform.

The current CI/CD toolchain requires users to log into multiple tools. RDMS aims to integrate these tools into a single system, hide CI/CD technical details, let developers focus on business logic, testers on test tasks, and operations on high‑availability services.

3.2 Business Function Design

Project Management: Create projects with default .NET Core API, Java API, or frontend templates; automatically generate Git repositories, code scaffolding, and HTTP/HTTPS domains.

Build Records: Retrieve GitLab pipelines, display build information for all branches, and provide quick links to repositories.

Deployment Management: Deploy built images to specified environments with real‑time or scheduled deployment options.

Container Management: View container status and live logs.

Config Field Permission Requests: PRE and production config access requires DingTalk approval.

Configuration Management: Add, edit, delete configurations; PRE/production changes need DingTalk approval.

Operation Logs: Record all actions performed on applications.

User Settings: Users must set their GitLab token in RDMS to enable Git‑related operations.

3.3 Technical Architecture

Passport: Single‑sign‑on for all R&D center staff.

GitLab API: RDMS uses GitLab CI for project creation, repository initialization, and pipeline queries.

DingTalk Flow: All PRE/production operations trigger DingTalk approval workflows.

Fulu Open Platform: Provides gateway, menu, and role management for all backend services.

Beehive Scheduler: Supports timed deployments.

Operations Ticket System: CD actions are wrapped in ticket‑based shell scripts for security.

Shell Script Layer: Calls Kubernetes API for deployment, config updates, container restarts, DNS resolution via Alibaba Cloud, and OSS file management.

3.4 Backend Application DevOps Implementation Details

Example walkthrough.

Creating an application from a template generates a repository with a develop branch, a default domain name, and an initial appsettings.Development.json that is written to a Kubernetes ConfigMap on first deployment.

After the build completes, the image is deployed, a pod is created in Kubernetes, and the service becomes accessible via its domain.

3.5 Frontend Site DevOps Implementation Details

Another example walkthrough.

Creating a frontend site generates a repository with a develop branch, a domain name, and configuration files for multiple environments. Deployment uploads the static files to an OSS bucket, which is mounted into the Nginx container in Kubernetes.

4. Outlook

RDMS has been in production for about a month. Future plans include extending the DevOps chain with testing (static code analysis, unit‑test coverage, automated functional and performance testing) and integrating additional tools frequently used by the R&D center.

Enhance the DevOps pipeline by adding test phases.

Integrate more tool platforms into RDMS or develop new features on top of it.