How to make a good Release Plan for a good Release

One of the things I’ve learned over the years is that releases are increasingly an important part of the development process, and in many cases more important than the development itself. (A few lines of code changed, but a release error is a serious accident). The Release of mobile Internet products can also be divided into multiple types: 1. Version Release (AppStore, updates in major application markets), 2. Service release (also called perimeter release, background service upgrade, code refactoring, etc.), 3. This article is mainly about the type 1, and the rest is based on some of my team’s experiences and lessons over the past three years.

When will Release Plan be made?

When do you plan to launch? Usually one or two days before launch. Neither too early nor too late is appropriate, mainly because it’s too far in advance, the project is still in progress, many details can’t be fixed, and plans made at that time are generally unreliable. Second, the lions were too busy working at the time to discuss specifics. Do it on the day of the release, or even worse, on the day of the release, when a bunch of things need to be sorted out, and then start writing. If anything goes wrong along the way, you can imagine the effect.

What does the Release Plan contain?

A release plan can be tailored for each release, so there is no one-size-fits-all template for every release, but it is recommended to include:

1. Participants of this release

2. Scope of release

3. Whether there are dependencies (database schema change, index update, some services need to reloading, blabla..)

4. Timing and order of release

5. Verification scheme after release

6. If an exception cannot be resolved, roll back the solution

For the above points, I would like to make a brief explanation. First, in fact, the most important thing is that every release must be clear to all participants, especially in the pre-release preparation meeting, all relevant students must be present, and everyone should achieve a high degree of cognitive consistency on the whole process. In addition, please note that the roles mentioned here are not only the regular roles of development, testing, operation and peacekeeping, but also the roles of operation, legal affairs and marketing. The acceptance after launch requires the participation of business departments.

Second, needless to say, the scope of the release must be clear, which modules/features need to be live for this release.

Third, the current system architecture includes a large number of middleware. A change in a function, in many cases, not only in the current code changes, database, configuration files, cache updates, etc., will have an impact on the new function. If the code is updated and the table structure is the same as the previous version, then wait for P1 accident.

Fourth, when does the release process start on release day? Start at 9:00 after work? It starts at 7:00 after work, or is it just in time? The order in which each module is released must be clear, because most of the time, there is no downtime.

Fifth, at the moment after the release of the new version, there must be a clear verification scheme, including verifier, TestCase, etc. If it cannot be verified directly, then the corresponding context should be built in advance for the first time confirmation.

Sixth, at any given moment, we should be prepared for the worst, which is to fail and keep the current version.

How to hold a Release Plan meeting

Before implementing the release plan, it is recommended to hold a release meeting for all staff to synchronize and confirm the release plan. The moderator of the release plan meeting is the project leader or project manager. During the meeting, go through each point one by one. After each point, identify the responsible person or interface person. After the meeting, the results of the plan will be released to all participants.

Key points during the Release Plan execution

1. Tracking and Monitor should be done at all times, and check a point for each point; If an exception occurs, Raise a Yellow Flag or even a Red Flag immediately.

2. Deal with abnormal situations. For example, if the IDC room or the third-party cloud host fails, you need to make good calls in advance and find the corresponding interface person, rather than find someone again.

3. Before the release, inform the business side of the release plan in advance to ensure that the release of services will not affect each other.