What Defines an Excellent DevOps? Key Takeaways from the 2019 GOPS Shanghai Conference

Opening

Shi Xuefeng : Another year of GOPS, and the crowd is huge—nearly 1,800 attendees, with experts from major banks and BATJ gathering in Shanghai.

Qi : I agree.

Shi Xuefeng : What’s the plan for the final session?

Dong Yue : Let’s summarize our thoughts on what a good DevOps should look like, its characteristics, and where we should focus our efforts.

Lei Tao : We need to clarify the overall direction and avoid deviating.

From Business Success to DevOps Goals

How to Achieve Business Success

Dong Yue : Elon Musk talks about “first principles”—start from the core problem and solve it step by step. What’s our core problem? Teams work 996; what’s the ultimate goal?

Lei Tao : Are we trying to improve societal efficiency? That’s too big.

Shi Xuefeng : Let’s narrow it—team goals are business success.

Dong Yue : Still a bit broad.

Lei Tao : Let’s start from business success.

Shi Xuefeng : Product development involves two groups: product definition (CEO to product manager) and product implementation (developers, testers, ops). We need to understand the expectations of the definition side on the implementation side.

Lei Tao : Exactly, we need to cooperate to make the business succeed.

Expectations for Business and Product Design

Dong Yue : First, see what the front‑end team is doing. How do we judge they have done their job well?

Lei Tao : They must spot market opportunities and get the strategy right, then cascade it to product design.

Dong Yue : Is there a way to make this easier?

Shi Xuefeng : If you guess wrong, try again—multiple attempts may eventually hit.

Lei Tao : Start‑up companies can’t afford endless trials.

Shi Xuefeng : That’s why MVP (minimum viable product) is popular—build a prototype, test market response, iterate quickly.

Dong Yue : So MVP is about small, fast steps.

Lei Tao : A/B testing is similar—test with a small user group first.

Dong Yue : Gray releases, beta versions are also in the same spirit.

Shi Xuefeng : The core is fast, low‑cost experimentation and validation.

Expectations for Product Implementation and Delivery

Dong Yue : Let’s discuss product implementation now. What should we achieve here?

Lei Tao : We need to ship features quickly. Competitors release 100 features a year; we release 20—that’s a problem.

Shi Xuefeng : That’s throughput—requests processed per unit time.

Lei Tao : Throughput alone isn’t enough; we also need speed.

Dong Yue : If we take three months to release a feature, that’s “slow sprint”.

Lei Tao : An MVP might take three days to develop; if release takes a month, product managers get stressed.

Shi Xuefeng : The goal is high capacity, fast response, appropriate quality, reasonable cost.

DevOps Optimization Methods

Reduce Waiting

Eliminate Release Windows

Lei Tao : The biggest waste is waiting for a release window after everything is ready.

Dong Yue : Why have a release window?

Lei Tao : Some teams need downtime for deployment; they don’t want to do it daily.

Shi Xuefeng : Some software is unavailable at night.

Dong Yue : Let’s not digress.

Lei Tao : Ops don’t want 24/7 anxiety, so they schedule weekly releases.

Feature‑Based Delivery

Lei Tao : Even if an iteration is two weeks with ten unrelated features, a feature finished early still waits for the batch release.

Dong Yue : That’s wasteful.

Shi Xuefeng : If each feature can be tested and released independently, we avoid batch delays.

Lei Tao : Manual regression of thousands of cases makes people want to test once a year.

Shi Xuefeng : Automation can reduce that.

Parallel Processes

Dong Yue : We need to move non‑coding work off the critical path.

Lei Tao : Prepare tests early, write test cases or scripts in parallel with development.

Shi Xuefeng : Code reviews can become bottlenecks; open‑source projects succeed because they don’t wait for reviews.

Dong Yue : In high‑quality, low‑sensitivity domains, it’s acceptable.

Lei Tao : What if we submit to a feature branch before review?

Shi Xuefeng : Others can continue development; if review fails, we still test and deploy.

Automation

Dong Yue : Reducing wait is one class; what other methods exist?

Shi Xuefeng : Automation—code scanning, testing, deployment—makes work faster and independent of human availability.

Lei Tao : Approval processes can be replaced by notifications; only high‑risk actions need manual review.

Shi Xuefeng : That’s moving toward a service‑oriented approach.

Service‑Oriented Automation

Dong Yue : Basic automation is calling ops to run a script; advanced automation lets developers deploy themselves via a UI button.

Lei Tao : Even better, developers configure themselves and click to release.

Shi Xuefeng : That’s service‑orientation, supported by Infrastructure‑as‑Code.

Speed Improvements

Dong Yue : Even with service‑orientation, we still need speed.

Lei Tao : Build time, code scan time, test time—parallelism, incremental builds, caching, reuse help.

Shi Xuefeng : Sometimes commercial tools are bought to cut build time from 10 minutes to 2 minutes.

Process Automation

Dong Yue : Beyond individual tasks, we need pipeline automation—CI/CD.

Lei Tao : Pipelines enforce rules; only code that passes pipeline and review can be merged.

Shi Xuefeng : Tools like GitLab, Gerrit, Sonar provide quality gates.

Dong Yue : Even OA approval workflows are a form of process automation.

Reasonable Technology Choices and Architecture

Shi Xuefeng : Monolithic systems cause large deployments; microservices and containerization (Docker, K8s) help.

Lei Tao : Serverless, function services, language and framework choices also matter.

Early and Frequent Commits and Merges

Shi Xuefeng : CI/CD emphasizes early, frequent commits and merges to keep everyone in sync.

Lei Tao : Does this conflict with feature‑based delivery?

Shi Xuefeng : Feature flags let us merge unfinished features without exposing them.

Dong Yue : Deploy‑release separation is the key.

Lei Tao : Not all teams can adopt strict CI; flexibility is needed.

Early and Frequent Testing

Shi Xuefeng : “Fail fast” – test early, get fast feedback, fix while the context is fresh.

Lei Tao : How early is early? Unit tests, integration tests, automated tests triggered on each commit.

Shi Xuefeng : IDE‑based static analysis, hot‑deployment give near‑real‑time feedback.

Dong Yue : Real‑time is great, but testing still needs deployment.

Shi Xuefeng : TDD writes tests before code.

Testing Pyramid Optimization

Lei Tao : Execute sanity tests (unit, smoke) in 5‑10 minutes after commit; run automated service tests multiple times daily; schedule system, acceptance, manual tests daily; run gray tests weekly.

Test Environment Support

Dong Yue : Test environments must be easy to request and automated.

Lei Tao : Debugging should be convenient, not just log viewing.

Shi Xuefeng : Large systems can’t have a dedicated environment per feature; shared resources are used with virtual isolation.

Testing in Production

Dong Yue : Some tests belong in production—blue‑green, canary, or gray releases.

Shi Xuefeng : Experience versions let more users test early.

Lei Tao : Monitoring is the new testing.

Shi Xuefeng : Full‑chain load testing in production is useful for big sales events.

Other Management Tools

Dong Yue : Version control, artifact management, work‑item tracking, code review, test‑case management—all record and display information.

Shi Xuefeng : Linking code changes to requirements, releases, and test cases is crucial.

Lei Tao : Environment, data‑change, test‑data, and configuration management are challenging; “Continuous Delivery” discusses them in depth.

How to Implement

Dong Yue : Summarized the main ideas—capacity, speed, quality, cost—and now we need a concrete implementation path.

Shi Xuefeng : Should we start with tools or culture?

Dong Yue : Tools are easy and people love them.

Shi Xuefeng : Tools alone won’t make DevOps work; without cultural change they become waterfall.

Lei Tao : Changing culture without altering processes is unrealistic.

Dong Yue : So we need both tools and culture.

Shi Xuefeng : Mechanisms that encourage desired behavior are key—like Toyota’s Andon rope.

Lei Tao : Mechanisms lead to behavior change, which reshapes culture.

Shi Xuefeng : Implementation requires people, processes, and tools—three‑fold.

Dong Yue : First, get executive sponsorship.

Shi Xuefeng : Then pick a pilot team—core business, agile, high demand.

Lei Tao : Form a DevOps transformation group with sponsors, tooling team, and business team.

Dong Yue : Use models and frameworks to benchmark current weaknesses, fix short‑term issues, show quick wins, and expand.

Shi Xuefeng : Avoid being just a commentator; be a practitioner—apply what you hear, adapt, and iterate.

Lei Tao : Bottom line: act first, talk later.

All : Act first, talk later!