Implementing Periodic Releases and Operational Automation for Small Teams

This is a serialized article; the previous part can be found in the linked post about how small teams (under 30 people) gain continuous delivery capability.

After the first stage of preparation, the team is familiar with the entire R&D workflow and infrastructure, and has shifted its mindset toward a "small‑batch production" model.

The next goals are: (1) periodic releases every three weeks (later every two weeks after three months); (2) maintain online quality; (3) adjust the developer‑to‑tester ratio from 2:1 to 3:1.

Periodic Release means delivering completed features to production on a relatively fixed, short time interval. Its characteristics include fixed release intervals, variable feature set size per release, flexible scope within each cycle, and consistent quality standards. Advantages are reduced coordination cost, higher flexibility, and stronger team sense of achievement.

Project‑Based Release defines a fixed scope, pre‑set quality standards, and a release only after all features are completed and meet the standards. Its traits are high individual efficiency, low disturbance, potential fatigue, and higher release risk.

The team decided on a three‑week release cadence, believing it is a significant improvement over the previous three‑month cadence, and communicated this to stakeholders, who welcomed the faster response to demand.

New demand‑management practices were introduced: a wiki‑based demand list for both customer and internal improvement requests, predefined release dates posted on the wiki, and optional weekly demand‑review meetings.

Operations raised two concerns: (1) quality may suffer with shorter testing windows, and (2) the workload could overwhelm the team due to the need to deploy to over 300 machines every two weeks.

To address these, the team increased transparency by involving operations in daily stand‑ups and retrospectives, adjusted system configuration to meet operational needs, and moved toward fully automated deployment.

Identifying Operational Issues revealed manual deployment steps, inconsistent configuration items across modules, hard‑coded ports and paths, repetitive documentation, and divergent procedures across test, staging, and production environments.

Standardization Enables Automation – the team reorganized code into a unified product directory with a Test folder for integration tests, added conf sub‑directories ( default, online, test) for environment‑specific settings, and placed deployment scripts in a script/install hierarchy. This separation of binaries and configurations allows the same binary to be deployed with different config files across environments.

All artifacts are version‑controlled; build IDs identify binary versions, and installation packages now include a revision ID for traceability.

Environment management was optimized to make the software stack on over 300 machines reproducible with a single command, removing the need for expert‑only interventions.

Deployment and monitoring were automated: operations wrote deployment scripts, which were validated in test environments before production use, and monitoring scripts were added to track deployment health.

Testing Strategy Adjustments addressed three issues: test code not co‑located with product code, a single shared development‑test environment, and insufficient automated test coverage. The team moved test code into the same repository as product code, expanded automated testing layers (unit, integration, system, performance), and built dedicated test clusters to enable parallel test execution.

Overall, the team achieved full version control of code, scripts, configurations, and data; standardized one‑click environment cloning; a complete automated deployment pipeline; and a fully integrated RD/QA/Operations workflow.