Applying Continuous Integration to Improve R&D Testing Workflow

Continuous integration (CI) has been around for several years, and as testing practices evolve, teams seek ways to improve test quality and efficiency. This article presents an example of applying CI concepts to enhance the R&D testing workflow, aiming to move beyond theory into practical implementation.

1. Ten Characteristics of Continuous Integration

1) Maintain a single source repository that includes code, test scripts, configuration files, database schemas, installation scripts, and third‑party libraries. 2) Automated build: anyone should be able to check out the source on a clean machine and, with a single command, obtain a runnable system. 3) Let the build run its own tests, incorporating automated test cases to catch bugs early. 4) Each developer should commit to the mainline daily to minimize merge conflicts. 5) Rebuild the mainline on the integration server for every commit to keep it healthy. 6) Keep builds fast (ideally under 10 minutes), possibly by splitting into stages. 7) Test in an environment that mirrors production. 8) Ensure every team member can easily obtain the latest executable. 9) Provide clear visual indicators of build status (e.g., red/green lights). 10) Automate deployment across environments with rollback capability.

2. Background and Existing Problems

The current R&D testing flow includes requirement design, detailed design, developer self‑testing, testing phase, and release. After development, code is merged to the mainline, deployed to a test environment for self‑test, then QA tests it. Upon test completion, code is merged to online and finally deployed to production. This process suffers from several issues:

Development and testing share the same environment, causing interference and fragmented testing cycles.

Code in the trunk during testing may not represent the final release, leading to late‑stage risk discovery.

Manual diff and copy during trunk‑to‑online merges cause errors and duplicate regression work.

Long‑lived branches require extensive regression after merging back to the mainline.

Manual hand‑offs for testing and release reduce efficiency and increase error risk.

3. Improvement Plan

3.1 Development

Problems: Tested code is not always the code that will be released; QA must repeat tests, and developers’ self‑tests cannot guarantee quality.

Improvements: Adopt a trunk‑based development model with feature toggles (boolean configuration flags) so that new features can be turned on/off without affecting the stable behavior. Use branch‑based releases to ensure the code deployed online matches what was tested, and enforce merge policies that require bug fixes to flow through the mainline before reaching branches.

Introduce local builds: before committing to SVN, developers run a local build that executes static analysis and core functional tests. The build server records results in a database and returns a build ID; the commit hook checks this ID and only allows the commit if the build passes.

3.2 Testing

Problems: Lack of isolated environments leads to testing delays; limited automation reduces efficiency.

Improvements: Implement one‑click isolated environment deployment using CI servers (e.g., Jenkins, Docker). The CI server monitors repository changes, pulls code, builds, updates configuration, and deploys to dedicated test machines, optionally providing a personal environment per developer. Automated test execution follows deployment, with results fed back to developers.

Adopt layered automated testing: unit tests during local builds, API tests jointly maintained by developers and QA, and integration/system tests maintained by QA. Test results dictate whether code can progress to the next stage.

3.3 Release

Problems: Manual release processes are error‑prone.

Improvements: Use one‑click code distribution for production, handling full or incremental updates. Platform‑based configuration deployment allows developers to submit configuration changes for QA approval, after which operations push the approved configuration to the production environment, eliminating manual mistakes.

4. Summary

The article presented one example of integrating continuous integration into the development‑test‑release pipeline, highlighting remaining challenges such as automation stability, environment consistency, and monitoring. By reflecting on these issues and applying appropriate tools and processes, teams can achieve higher quality and efficiency.