How to Streamline Deployment and Rollback with Containerized and OSS Strategies

Preface

Rollback is a must‑know operation for every developer; it reduces the time users are affected by faulty code. Various rollback methods exist, each with pros and cons—using a Git repository may overwrite other business code, while rolling back built artifacts is the safest and helps resolve online issues quickly.

The "Pain" of Build and Deploy

My work experiences illustrate the evolution of deployment:

In a traditional company with no operations team, we had to log into a jump server and manually copy files to the server, which was extremely cumbersome.

At a startup with minimal infrastructure, the front‑end was tiny; we delivered a zip package to operations, who then deployed it, eventually causing frustration for the ops team.

Later, at a larger company, a mature build‑deploy system allowed us to click a button on a web page to trigger the process.

How is build and deployment actually implemented? Below is an overview of the deployment and rollback mechanisms used at Guming.

Release Analysis

The ultimate goal is to release to production, which means releasing a branch. Typically we create a branch based on a specific requirement and application, develop on it, and then proceed with the release.

Before releasing, we fill in required configuration items and click the release button. Pre‑release checks ensure that only authorized users can release, that there are no code conflicts, that the release occurs within a valid window, and that the application isn’t already being released.

The release platform then instructs Jenkins to fetch repository and branch information, pull the code, and, depending on the application type, compile and package it to generate the appropriate artifact.

1. Containerized Release

Note: The diagram shows Wukong, our self‑developed DevOps platform.

Containerized releases publish Docker images; the image ID links the release to the image. To roll back, we locate the release ID, and the ops script finds the corresponding Docker image and redeploys it, achieving instant rollback. Because the same image is used, the artifact is identical and the deployment is fast.

Before containerization, releases involved finding the corresponding tag, packaging it, and deploying. This ensured only the business code matched, not the environment, dependencies, or build machine, and it was much slower.

2. OSS Release

OSS releases differ from containerized releases by uploading static resources (JS, CSS, etc.) to OSS instead of building an image. The application only needs to remember the version and the corresponding OSS resource path.

In our implementation, after each release we record the manifest address with a hash. When rolling back, we locate the release ID, retrieve the associated artifact, and replace the manifest on OSS with the hashed version, effectively switching the resources while the HTML manifest URL stays unchanged.

3. Mini‑Program Rollback

Rolling back a DingTalk mini‑program is straightforward: after clicking rollback, an internal HTTP call invokes the mini‑program API with the target version, completing the rollback. Alternatively, developers can manually select a previous version in the developer console.

Future Outlook

With a solid deployment and rollback mechanism, our product‑research team enjoys a better delivery experience, spending less time on process overhead and more on business value.

A stable, fast rollback reduces error‑recovery cost, ensuring low trial‑and‑error risk.

For Guming, the relatively small scale allows us to unify tooling across the development workflow, tightly linking each stage and better supporting business growth.

Conclusion

Recommended articles from the Goodme Front‑End Team include deep dives into Git, Webpack history, and intelligent menu solutions for Guming stores.