Here’s a quick overview on CI/CD and the WeChat specificities and how to combine them efficiently.
Run tests (unit, integration, code format, tech debt etc.) on commits
Generate a validated artifact
Push to dev/staging/production environments automatically
Uses its own IDE, requiring multiple validations/security logins via QR code, with tight ACL control in the web admin interface,
Pushing to prod is a manual process, requiring code review by Tencent prior to the release
As we can see, full CI/CD is not achievable by the mere fact that releases need to be audited and require a click in the WeChat Admin Web interface.
But everything prior can be semi-automated, from push/pr/merge, all the way to publishing an experimental build suitable for your stakeholders to review.
How we can achieve CI/CD
Without diving into the specifics of testing (Jest, Coverage etc.) or tooling (Jenkins, Bamboo, Pipelines etc.), let’s shed some light on the glue that allows the (pre)-CD to occur.
The magic comes from our use of the WeChat IDE CLI and the ability to generate a login QR code as an image. This can be pushed through your favorite IM for remote scanning and eventual authentication of the IDE on your builder.
An example flow would be the following:
trigger the execution of the tests automatically
initiate a login on the IDE installed on the CI/CD host (e.g. on a Mac mini where your Jenkins agent is running)
push the generated QR code to a dedicated Slack Channel via a Slackbot
get your release team member to scan and auto-magically push the generated code on WeChat via the IDE CLI
Release team members could be your DevOps team or whoever else fits the role. Preferably someone not actively contributing to the dev-force, but whose contributions would be made as Experimental release user in the WeChat Admin web interface.
This means that their uploads would immediately be pushed as the experimental version of the Mini-Program, available to those with the QR code.