How Frontend Teams Ensure System Stability: Metrics, Standards, and Git Workflows

System stability, development efficiency, and user experience are top concerns for frontend engineers. Building stability requires addressing development, standards, and processes. This article focuses on stability metrics and team norms.

Stability Metrics

System stability is measurable; we first define stability goals and then break them into tasks.

Availability

Discussing stability inevitably brings up Service Level Agreements (SLA), which use annual downtime to express availability, often described as “x nines”. Most services aim for 4‑9 or 5‑9 availability; lower levels are not considered acceptable. Determining availability involves service tiering.

Meituan’s blog once claimed a financial core system achieved 7‑9 availability, which was later revised after criticism.

Failure Levels

Core vs non‑core services reflect service tiering. Different tiers have different stability requirements, influencing incident grading. The diagram below illustrates service tiers and failure levels.

Incident severity also depends on duration, affected users, business loss, and public opinion. Some organizations set KPI such as “no P2 or higher incidents in a quarter”. Stability protection spans pre‑incident, during‑incident, and post‑incident phases; after defining metrics, we turn to team norms.

Team Norms

Team norms guide behavior to prevent accidents. They include code standards, branch management, and release processes.

Code Standards

Consistent code style improves readability and reduces bugs. Frontend teams often adopt guides like Airbnb or Standard. Tools such as ESLint and Sonar in CI/CD enforce these standards.

Branch Management

Branch management addresses Git workflow, branch deployment, and Git rules. Poor practices can cause wrong‑branch deployments, missing features, or lost code.

Git Workflow

Common Git workflows include:

Master‑only: all commits go directly to master.

Feature workflow: parallel feature branches merge into master.

Develop/feature: feature branches merge into develop, then into master.

Gitflow: adds hot‑fix and release branches on top of develop/feature.

Branch Deployment

Front‑end releases may be feature‑driven or scheduled. Environments (dev, test, pre‑prod, prod) correspond to specific branches, aligning with the chosen workflow.

Git Rules

Our team uses a feature workflow, treating feature branches as development branches with additional rules.

At Alibaba, a wrong branch was released, causing missing functionality until the issue was traced back to using the develop branch instead of master.

Code Review

Many teams adopt Google’s Code Review practices.

Release Process

Release can be broken into five steps using a fixed template:

Create a release plan specifying content, timing, order, and rollback.

Notify stakeholders, often via email.

Confirm checklist items and mitigate risks.

Execute the release, synchronizing progress.

Perform online regression; only after passing is the release considered complete.

When releasing a WeChat Mini Program, we once missed adding the domain to the whitelist; we now require this check in the checklist before release.

Conclusion

The article covered stability metrics and how team norms can ensure system stability; future posts will explore additional aspects.