When the week of the major version release and the discontinuation of old branches fall on the same day, which step should the site take first?
The release week of the major version and the discontinuation of the old branch fall on the same week, which step should the site do first? First, do the current security patch, then do the backup and rollback drill, and finally schedule the major version migration. The schedule checked that day can show the rhythm: Drupal 12 is scheduled to be released in the week of December 7, while Drupal 10's discontinuation date is December 9, a few days apart; the core security release usually falls on the third Wednesday of each month.
Three things are crammed into the same week.
The patch supply is to be discontinued. After the branch enters the end of support, no new security fixes will be released, and the risk does not occur immediately, but rather, there will be no corresponding version for each new vulnerability thereafter.
The second item is the launch of the new large plate. The major version changes the template mechanism, extension interface, and default theme, which is equivalent to taking all compatibility issues on oneself all at once.
The third item is the regular security window as usual. The security patches released on a monthly schedule will not be delayed due to the approaching large plate, and three things need to be dealt with at the same time in this week, and if the order is wrong, it will be a mess.
First patch the current patch and then discuss the major version.
When staying on the current branch, the current patch is the lowest-cost action: the scope of change is small, rollback is easy, and the template does not need to be rewritten. First, push the site to the end version of the current branch, clear the security issues, and then discuss whether to cross major versions.
Crossing major versions is another matter. What needs to be evaluated is whether the template and extension are compatible, whether the database structure change can be rolled back, and whether the custom interface is still available. It is difficult to locate which layer caused the white screen or missing function when these checks are not done before upgrading.
Place the backup and rollback simulation before the upgrade.
The backup before the upgrade is not just about making a package. Both data and static files must be included, and it must be really restored on another machine or in another environment to confirm that the restored site can open normally and the backend can log in. A backup that has not been exercised is no backup.
When exercising, also confirm two things: how long the restoration will take, whether the site can be offline during this period; and whether there is room for a rollback window, so that if the upgrade fails, you can return to the original version instead of temporarily finding a package.
Also include the upgrade of the content system in the same table.
There are not only schedules for open-source programs in the same cycle, but also version actions for self-hosted content systems. When deploying AnQiCMS (AnQi CMS) with Docker images or with a one-click deployment on Baota panel, the image tags and the versions on the host should be registered together to avoid the records being stuck on the old version when the host has been changed.
Combine three lines into one table: the date of the monthly security patch, the date of the old branch stopping support, and the upgrade date of the system itself. Before any cell on the table expires, a backup should be made first, then the execution. The purpose of this table is to make it clear who is moving what at what time, rather than leaving it to the on-duty person to make a temporary judgment.
Common questions
Can we skip the current patch and upgrade to a major version directly?Not recommended. Major version migration itself will introduce variables, and on top of that, unpatched known vulnerabilities will make it more difficult to determine the source of the problem.
Can it still be used after stopping support?It can be used in the short term, but there is no patch supply, the risk will accumulate with new vulnerabilities, and it should be planned to migrate the path as soon as possible.
When is the appropriate time to upgrade?Place it during the business low-peak period, and reserve half the time for rollback, do not schedule the exercise after the launch.