CI/CD Best Practices for ToB Scenarios: Frontend and Backend Standards, Testing, and Deployment

The article describes the challenges faced by a team managing over 30 ToB platform systems, including coupled frontend/backend deployment, non-standardized development processes, and lack of quality assurance.

It introduces CI/CD as Continuous Integration/Continuous Deployment, rooted in DevOps culture, aiming to bridge development and operations through automated build, test, and deployment.

Key concepts are defined: DevOps as the combination of Development and Operations; CI as Continuous Integration involving frequent code commits and automated testing; CD as either Continuous Delivery (automated release to a repository) or Continuous Deployment (automatic release to production).

The article outlines basic principles of CI/CD: reliability, fast pipelines, isolated build/run environments, and parity between staging and production.

Process standards are discussed, covering branch development (feature branches, naming with release dates), ensuring untested code does not go to production, regular synchronization checks, and embedding checks in CI.

Branch management standards emphasize using code version branches as the foundation for automated builds, optional feature branches, and date‑based naming for ToB scenarios.

Pipeline standards include compilation using a unified cluster, security scanning (e.g., Whack‑a‑Mole, Owl), static code analysis, and end‑to‑end testing.

Deployment design compares two schemes for placing index.html (BOS vs RD server), recommending scheme 1 for better frontend/backend decoupling and version control via HTML.

Versioning strategies are explained: hash‑based (MD5) for incremental releases and timestamp‑based for full releases; the team chose timestamp versioning.

An example deployment directory tree is shown using a pre block with folders like performance|----202101281200|----css|----js|----index.js, etc.

The importance of unit testing is highlighted, especially for ToB businesses with stable UI, high reliability needs, and longer iteration cycles; benefits include bug reduction, safe refactoring, and design improvement.

Frontend testing layers are described: E2E (black‑box, high cost), integration testing (moderate cost), and unit testing (fast, cheap, pyramid base).

Testing framework selection favors Jest for its performance, zero‑configuration integration (Mock, Test Runner, Matcher, Coverage), and watch mode for developer feedback.

Frontend‑backend contracts are proposed to reduce communication cost: backend splits interfaces by domain, avoids UI‑coupled data, offloads heavy computation to backend, limits network requests, uses BFF or SSR when needed, and follows the minimal principle.

The article presents an engineering capability map that standardizes the full R&D lifecycle and recommends toolchains.

Finally, the YAPI platform (based on Swagger) is shown to provide automatic API documentation, mock data, contract testing, and client/server code generation, improving stability and reducing documentation maintenance overhead.