The original address: www.yuque.com/jinxuanzhen…

directory

This sharing is divided into three modules, respectively, why do this thing, the exploration and practice in the solution process, and my personal thoughts on small program development

Why do we do this?


Release phase

Scene description

What happens then? R&d will ask: Did the test pass?” Wait for “5 minutes later, the R&D team will ask:” Is it ready? “” Yes”, but it is very embarrassing that A product B may pop out and say that I have yet to test another function. Since there is product A and product B, there may also be test A and back-end B, which will fall into A small communication cycle






Release time Statistics overview


There was a backlash, and one of the most common phrases I remember hearing was, “Ah, publishing again?” So the overall iteration is not fast,

However, as a startup company, rapid iteration and rapid trial and error is a very important ability, which is obviously not acceptable in this state

Where was the time spent?





Is this a neat process? Ideally, yes, but the reality is often more complicated

So what’s complicated?

The first point is to check the key information before the trial/test, it is necessary to check the key information, why? Because it is to modify the release environment, the changed version information is manually modified, no matter how rigorous people are likely to make mistakes (PS: Actually quite embarrassed, I have done this thing, and twice).

The second thing is the synchronization of information. As you can see from the picture on the left, we have two validation stages, one is testing and one is auditing. What usually happens here?

This can be summarized as “it is difficult for other relevant parties such as product/operation to obtain the release information in the first time, and there is no effective notification means”. In fact, it is the problem of information synchronization

Query scenario

Scene description


However, there are many people who will ask this question. Its upstream docking is customer service, technology, product, bd and other departments

This is multiplied by n times, depending on the nature of the responsibility, and the number of people. Here are the departments, depending on the responsibility, that might ask this question: Product, operations, technology, customer service… It seems to cover most corporate positions

Visibility is a long and repetitive communication behavior

It’s a headache, but it’s really just a missing update log or document

Update log requirements


  • The version number
  • Updated date
  • Demand list

You can see what was released in each iteration and when it was released, so you don’t need to ask again

But what about when we started without this document? You can check the git log with the tag, or you can manually remember such a wiki

There are problems with both approaches:

The first problem is that, except for the current project developers, there is no accurate access to information, such as product/operation/customer service students. Firstly, it is not expected that everyone can use Git. On the other hand, source privacy is also a problem

The problem with the second is that

  • Integrity issues, artificial record more selective record, such as milestone business requirements
  • The question of credibility, when there is a possibility of incompleteness, becomes a reference rather than an answer
  • There are additional human costs involved

(Of course, you can also generate it directly with a Commit Message, but this is against the team’s commit style.)

Unfortunately, no, so, it hurts

conclusion

  • Reduce ineffective communication, avoid repetitive time wasters, and improve team effectiveness — in terms of team effectiveness, we don’t want the “three handshakes” to happen
  • Ensure the ability of information synchronization, ensure the consistency and immediacy of information within the organization — as the main product iteration information of the company must be transparent, so that there will be no deviation between different departments
  • Improve release stability and eliminate potential release risks – more on that in the next article
  • The last one is to meet the need for multiple releases per day – 1-2 releases per day is the limit if we look at current release productivity, not addressing communication costs but reducing efficiency

The solution

General situation of


  • Automated build – mainly responsible for packaging and compiling, with the ability to release experience versions
  • Update log – Provides version recording and snapshot capabilities
  • Communication mechanism – mainly responsible for providing effective means of notification

There is a simple dependency, the update log relies on the build ability to provide raw data sets, and the communication mechanism primarily functions to synchronize messages, but the content depends on the update log

Overall flow chart

Through automatic construction, release the experience version and upload it to Git. Git then calls to our own server through webhook capability, processes log information, uplows version snapshots, stores the processed data to mysql, sends notifications to all directions through mail service, and finally presents it in the view layer

Automated build

What capabilities do build processes require?




What capabilities do build processes require?

  • The ability to package compilations – resolves syntax conversions/conditional compilations/code checks, while defining global constants such as the environment switch encountered earlier
  • The general way to submit the experience version is to click the “upload button” in the upper right corner of the small program development tool. In fact, in addition to this method, wechat provides two other methods of submission, command line and HTTP service. For specific situations, you can refer to the wechat document
  • Version management capabilities – mainly to help us plan relevant version numbers and version descriptions, analogous to NPM’s Version Manager
  • Finally, it is necessary to ensure certain scalability. For example, small programs currently support NPM construction function. If there is no expansion space, it is necessary to modify the source code to add, and this construction process needs to ensure multi-project adaptation to a certain extent






xdk-cli publish

  • Whether to release an official environment
  • Set a version number (there is a growth logic for filling in the version number, the default stage version number + 1)
  • Fill in a version description

In fact, it is a process of switching environment + filling in version information, and then entering the release environment

The specific plan



xdk-cli publish

  • Read the project’s local configuration files, including scaffolding configuration and versioning files,
  • Then pop up the query command, fill in the relevant information to confirm
  • Execute publish hook
  • Upload the experience version and execute the upload command provided by wechat
  • Execute post-publish hooks
  • Upload demo successfully, return a callback

In order to ensure scalability, the CLI only maintains the functions of upload and version management, and reserved two hook functions, which are respectively executed before and after release. Some project-specific tasks are put in the hook, such as Babel, Lint, sass, NPM function of small programs, and git commit. Git tag submission

Curious about the specific implementation of the CLI, you can scan the following code on wechat, which is an article I wrote about setting up the CLI

Revenue generated

The left picture is the optimized process. It can be seen that through CLI, we combined “modify the release environment + click upload + fill in the version information”, and issued the product directly through interactive commands.

What are our benefits just from a process perspective

  • The release error caused by switching online and offline environment is eliminated
  • Incorrect version numbers are a thing of the past
  • The publishing process is consolidated so that the entire submission process only needs to take place in the editor

Update log

With regard to the update log, as described in the background, our goal is to help non-project developers quickly understand the updates for each iteration **

Three questions

Here are my three core questions to consider before doing this:

  • Which fields need to be included
  • What do you think? Where can I see it?
  • When are log records updated

On the first question, which fields need to be included? The most basic are: version number, version description, release time, requirement list followed by some requirement developers, reviewers, and what are the Pr and Prd associated with this requirement, as well as the status of the current version

What do you think? Where can I see it? We put it on our own internal online management platform, using the form of display

When are log records updated? When version status changes, such as when testing, reviewing, releasing, or rolling back

Demand for output



Data acquisition, data storage, state management, event hooks, view layer

  • Data collection is well understood, collecting some fields
  • Data collection needs to be stored in an online accessible database, which is convenient for our view layer and some subsequent applications
  • Event hooks, when do we get notified that we need to update data, change state
  • The view layer, where the content is hosted

At this time, it is found that local construction is difficult to meet these requirements, and a stable online server is needed to deal with these tasks. Here we use Node to build

The existing process


After receiving the notification, the local code of the server will be updated, and the submission information and version information in the middle will be extracted. The compressed and uploaded OSS is to make a version snapshot. Finally, the prepared data will be inserted into mysql

The view layer can present content based on stored data

The case shows


From left to right: Version number, description, status, release date and two options: modify status, download the code package (which is essentially a snapshot of the process)

The following is the information contained in the project: requirement type, requirement list The individual items in the requirement list include the developer, the reviewer, the audit time, the associated PR, and the associated PRD

You can see the entire version information structure at a glance

The key point






Git Msg, Pr Msg, version information, and OSS storage information

Git Msg and Pr Msg are git related capabilities.


Git Msg depends on tag hook. The definition of tag hook is that a new version is generated, and the relevant version information is mainly extracted from git log. However, the statistical dimension cannot be embodied into PR node to obtain more detailed data, such as PR title and developer, etc

Pr Msg relies on PR hook. Every time PR is submitted, relevant information will be recorded and stored in the database. In fact, two sets of HOOK services are used.

Here, pr_ID is extracted from log information and pushed into the array. The figure on the right can be interpreted as Pr table, which contains detailed information about requirements

Commit MSG Many third party packages on NPM, very convenient

Communication mechanism

As for the last communication module, the purpose of this project is to solve the problem of “it is difficult for other relevant parties, such as product/operation, to obtain the release information in the first time and lack effective notification means”

Extracting key words




Test status, arraignment status, release status, rollback status

The second is content details, which definitely require quality version information. As for version information, the update log mentioned just now is an off-the-shelf service that we use directly as a data source to provide the necessary data

Secondly, there are various notification methods, such as email, Dingding, wechat and so on. Because we use enterprise email and the development cost is relatively low, we directly use Nodemailer third-party library to build an email service

About State Flow

It is divided into two steps, manual change and automatic change

Manual changes


Another way to hack


As you can see from the left picture, when you click submit, the custom event bound by the script will be triggered. This event will directly call the interface of state flow of our service provider to help us modify, without going to the background to make changes

We are looking forward to wechat team opening such a hook capability in the future to help us achieve functional closed-loop without relying on local clients

Current release process

This is the latest set of processes. First, each group tests itself, merges PR, directly uploads the experience version by command, and submits it for review. At the same time, an email is sent to remind that the review has been done

The new process takes about 5 minutes per release, but it is a non-blocking form that can do its own thing during release

  • The only links that developers need to pay attention to are pr consolidation, local execution of a command, and finally the code scanning work of the public platform of wechat during the operation of the review and release
  • For the rest of us, when we get an email, we just do what needs to be done

After the new procedure was implemented, the “three handshakes” scenario in the test group became a thing of the past, from the warmest group to the coldest group

The value of withdrawal


  • By rejecting any form of “three handshakes”, communication costs are reduced, regardless of whether the product/R&D is more focused on the business itself – reducing ineffective communication
  • A stable, reliable and traceable version record ensures consistency of information within the organization
  • The delivery mechanism of mail service no longer requires manpower to deliver relevant information, and its timeliness and integrity are guaranteed
  • The resources saved are enough to support multiple releases a day

It can also help your team members expand their technical boundaries – and get exposed to something different