CN110597535A - Gray scale publishing method and device and storage medium - Google Patents

Gray scale publishing method and device and storage medium Download PDF

Info

Publication number
CN110597535A
CN110597535A CN201910795434.8A CN201910795434A CN110597535A CN 110597535 A CN110597535 A CN 110597535A CN 201910795434 A CN201910795434 A CN 201910795434A CN 110597535 A CN110597535 A CN 110597535A
Authority
CN
China
Prior art keywords
user
gray
version
version information
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN201910795434.8A
Other languages
Chinese (zh)
Inventor
邓园
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beike Technology Co Ltd
Original Assignee
Beike Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beike Technology Co Ltd filed Critical Beike Technology Co Ltd
Priority to CN201910795434.8A priority Critical patent/CN110597535A/en
Publication of CN110597535A publication Critical patent/CN110597535A/en
Pending legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/61Installation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/65Updates
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/70Software maintenance or management
    • G06F8/71Version control; Configuration management

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Transfer Between Computers (AREA)
  • Stored Programmes (AREA)

Abstract

The application discloses a method, a device and a storage medium for gray scale release, which are characterized in that user version information of at least one user is obtained according to gray scale rules configured for a software version to be released, then current version information is matched with the gray scale rules to screen out users meeting personalized gray scale conditions, then prospective users needing to carry out the gray scale release are screened out from the users meeting the personalized gray scale conditions according to historical version information, finally, the software version to be released is pushed to a client of the prospective users, and the gray scale release is stopped when the user version information of the prospective users is not matched with the gray scale rules and the number of the prospective users meets the number of expected upgrading persons. According to the embodiment of the application, the corresponding gray rule is configured for the gray release, the expected user needing to participate in the gray release is accurately selected, and the user experience is improved.

Description

Gray scale publishing method and device and storage medium
Technical Field
The present application relates to the field of internet technologies, and in particular, to a method, an apparatus, and a storage medium for gray scale publishing.
Background
In order to obtain the opinion feedback of the user as early as possible, improve the product functions and improve the product quality, the user feedback is generally obtained by enhancing the interaction with the user, such as allowing the user to participate in product testing. The software developer can obtain the user opinions in a gray release mode so as to provide relatively complete APP version packages for the market and reduce the user range influenced by product upgrading. The gray release generally refers to gradually expanding the range of trial users when a new version is released, and improving related functions again according to the feedback of the users.
The core of the gray scale distribution is how to control the range of graying the user. At present, generally, by controlling the number of servers for gray scale distribution, a large number of user requests at the same time are distributed to different servers, and if the occupation ratio of the servers for gray scale distribution is higher, the gray scale range of the user is larger. In addition, the number of application stores used for the gradation release is controlled, and if the number of application stores that can release a new version is larger, the gradation range of the user is larger. However, the above methods cannot control the range of users who perform graying, so that the situation that the same batch of users are grayed for many times can occur, and meanwhile, it cannot be determined that some expected users who need graying are grayed specifically, so that the user experience is reduced, and the method is not beneficial to the test of a new version.
Disclosure of Invention
The embodiment of the application provides a gray scale publishing method, which overcomes the defect that a user needing gray scale publishing cannot be accurately defined, and improves user experience.
The method comprises the following steps:
acquiring user version information of at least one user according to a gray rule configured for a software version to be released, wherein the gray rule comprises the number of expected upgrading persons and personalized gray conditions, and the user version information comprises current version information and history version information;
matching the current version information with the gray level rule, and screening out users meeting the personalized gray level condition;
screening out prospective users needing to carry out the gray release of the time from the users meeting the personalized gray conditions according to the historical version information;
pushing the version of the software to be released to the client of the expected user, and stopping the gray scale release when the user version information of the expected user who installs the software to be released is not matched with the gray scale rule and the number of the expected users meets the number of the expected upgrading people.
Optionally, the device number, the item number, the client system version, the current software version, and other user information in the current version information of the at least one user are respectively matched with corresponding information in the gray scale rule, and a user meeting the personalized gray scale condition is screened out.
Optionally, determining a gray black list and a gray white list of the gray release according to the historical version information of the user meeting the personalized gray condition;
matching the user meeting the personalized gray scale condition with the gray scale blacklist, and not pushing the software version to be released to the user matched with the gray scale blacklist in a single phase;
and matching the users which do not match with the gray black list with the gray white list, and determining the users which match with the gray white list as the expected users.
Optionally, when the user not matched with the gray black list is unsuccessfully matched with the gray white list, and when a condition that only the user successfully matched with the gray white list is grayed is set, the user not successfully matched with the gray white list is not pushed the software version to be released;
and when the condition that graying is carried out only on the users successfully matched with the gray white list is not set, determining the users not belonging to the gray white list as the expected users.
Optionally, judging whether the expected user is a user needing forced graying, and matching the current software version of the user needing forced graying with the software version of the user needing forced graying when the user is the user needing forced graying;
pushing the version of the software to be released to the successfully matched user with the forced graying, and forcibly upgrading the version of the software to be released;
pushing the software version to be released when the expected user is not the forced graying user or the current software version of the forced graying user is not matched with the forced graying software version.
Optionally, the user version information of the expected user who finishes installing the software version to be released is obtained;
matching the equipment number, the client system version, the current software version and other user information in the current version information of the expected user who finishes installing the software version to be released with corresponding information in the gray rule, and counting the number of the expected users who finish installing the software version to be released after at least one matching is finished.
Optionally, storing the acquired user version information of the at least one user,
when the user version information is obtained next time, establishing first index information composed of the equipment number and the project number for the latest obtained current version information, and establishing second index information composed of the equipment number, the project number and the intranet gray level version for the historical version information;
searching whether the user version information which is the same as the latest acquired user version corresponding to the first index information and the second index information exists in the stored user version information according to the first index information and the second index information, and storing the latest acquired user version information when the user version information does not exist;
when the stored current version information which is the same as the current version information corresponding to the first index information is searched, comparing historical version information corresponding to the second index information with the stored historical version information corresponding to the current version information, and updating the stored historical version information to be the historical version information acquired this time when the historical version information is different from the stored historical version information.
In another embodiment of the present invention, there is provided an apparatus for gray scale distribution, including:
the system comprises an acquisition module, a storage module and a release module, wherein the acquisition module is used for acquiring user version information of at least one user according to a gray rule configured for a software version to be released, the gray rule comprises the number of people expected to be upgraded and an individualized gray condition, and the user version information comprises current version information and historical version information;
the first screening module is used for matching the current version information with the gray rule to screen out the users meeting the personalized gray condition;
the second screening module is used for screening expected users needing to carry out the gray release of the time from the users meeting the personalized gray condition according to the historical version information;
and the pushing module is used for pushing the software version to be released to the client of the expected user, and stopping the gray scale release when the user version information of the expected user who installs the software to be released is not matched with the gray scale rule and the number of the expected users meets the number of the expected upgrading people.
In another embodiment of the invention, a non-transitory computer readable storage medium is provided, storing instructions that, when executed by a processor, cause the processor to perform the steps of a method of gray scale publishing as described above.
In another embodiment of the present invention, a terminal device is provided, which includes a processor for executing the steps of a method for gray scale distribution as described above.
As can be seen from the above, based on the above embodiment, first, user version information of at least one user is obtained according to a gray scale rule configured for a software version to be released, where the gray scale rule includes an expected number of upgraded users and an individualized gray scale condition, and the user version information includes current version information and historical version information, then, the current version information is matched with the gray scale rule to screen out users meeting the individualized gray scale condition, then, according to the historical version information, an expected user needing to perform gray scale release this time is screened out from the users meeting the individualized gray scale condition, finally, a software version to be released is pushed to a client of the expected user, and when the user version information of the expected user is not matched with the gray scale rule and the number of the expected user meets the number of the expected upgraded users, the gray scale release this time is stopped. According to the embodiment of the application, the corresponding gray scale rule is configured for gray scale release, the personalized gray scale condition and the expected upgrading number are configured in the gray scale rule, and meanwhile, the expected users needing to participate in the gray scale release are accurately selected according to the user version information, so that the user experience is improved.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are required to be used in the embodiments will be briefly described below, it should be understood that the following drawings only illustrate some embodiments of the present application and therefore should not be considered as limiting the scope, and for those skilled in the art, other related drawings can be obtained from the drawings without inventive effort.
Fig. 1 is a schematic flow chart illustrating a method for gray scale distribution provided in embodiment 100 of the present application;
fig. 2 is a schematic diagram illustrating a specific flow of a method for gray scale publishing provided in an embodiment 200 of the present application;
FIG. 3 is a schematic diagram illustrating a registration page of a to-be-released software version provided in an embodiment 300 of the present application;
FIG. 4 is a schematic diagram of a configuration page of gray scale rules shown in embodiment 400 of the present application;
fig. 5 is a schematic diagram illustrating a table structure for storing current version information and historical version information according to embodiment 500 of the present application;
fig. 6 is a schematic diagram illustrating a specific flow of matching gray scale rules in embodiment 600 of the present application;
fig. 7 is a schematic diagram illustrating an apparatus for gray scale distribution according to an embodiment 700 of the present application;
fig. 8 shows a schematic diagram of a terminal device provided in embodiment 800 of the present application.
Detailed Description
The technical solutions in the embodiments of the present application will be described clearly and completely with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
The terms "first," "second," "third," "fourth," and the like in the description and in the claims, as well as in the drawings, if any, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used is interchangeable under appropriate circumstances such that the embodiments of the invention described herein are, for example, capable of operation in sequences other than those illustrated or otherwise described herein. Furthermore, the terms "comprising" and "having," as well as any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements explicitly listed, but may include other steps or elements not explicitly listed or inherent to such process, method, article, or apparatus.
The technical solution of the present invention will be described in detail with specific examples. Several of the following embodiments may be combined with each other, and details of the same or similar concepts or processes may not be repeated in some embodiments.
Based on the problems in the prior art, the embodiment of the application provides a gray scale publishing method, which is mainly applicable to the field of software version publishing. According to the gray scale publishing method, the specific gray scale rule is configured, the user version information of the user is obtained to be matched with the gray scale rule, and whether at least one user is an expected user needing graying or not is judged, so that the user needing graying is accurately selected. Fig. 1 is a schematic flow chart of a gray level publishing method provided in embodiment 100 of the present application. The detailed steps are as follows:
and S11, acquiring user version information of at least one user according to the gray rule configured for the software version to be released.
In this step, the software publisher configures the graying rule according to the user attribute of the expected user who needs graying. Optionally, the software publisher first configures the gray rule for the software version to be published. The gray rule is set according to the attribute of the expected user and the attribute of the software version to be released, which need to be targeted by the software publisher in the current gray release. Specifically, the gray level rule includes the number of persons desiring to be upgraded, a personalized gray level condition, and the like. Further, the expected number of upgrade persons is the number of upgrade persons set by the software publisher for the current gray scale distribution, and the personalized gray scale condition generally refers to a filtering condition that defines an expected user of the current gray scale distribution. By configuring the personalized gray scale conditions in advance, the expected user can participate in the gray scale release.
Further, the personalized graying conditions generally include filtering rules such as a market channel where the intended user is to be upgraded, a city where the intended user is located, a company code, a large district code, a job type, and other extension rules. The software publisher can set the personalized gray scale conditions according to the gray scale publishing requirement. Wherein the personalized gray scale conditions include, but are not limited to, the filtering rules listed above.
Optionally, the user version information of the at least one user includes current version information and historical version information. Specifically, the current version information generally refers to current version information of software used by a user corresponding to the version of the software to be released and other related information. Optionally, the current version information includes information such as a device number of the user, a project number of current software, a client system version, a current software version, a market channel for software upgrade of the user, a city where the user is located, a company code, a large area code, a job type, and a user number. Wherein the current version information includes, but is not limited to, the aforementioned listed information. And the historical version information mainly records the historical version of the software to be released which has been upgraded by the user. In addition, the default historical version is smaller than the version of the software to be released. In addition to recording the above-mentioned historical version, other information types of the historical version information recording are various information of the user under the historical version, together with the current version information.
And S12, matching the current version information with the gray rule, and screening out users meeting the personalized gray condition.
In this step, each type of information in the obtained current version information of a certain user is matched with the gray scale rule configured by the software publisher, mainly matching the personalized gray scale condition in the gray scale rule. Optionally, the specific matching rule is presence, i.e. matching, and one or more rules of the same type as in the personalized gray level condition are present in the current version information and are matched. There is no front and back matching sequence between each rule type in the personalized gray scale condition, and any rule matching fails, namely matching fails. In addition, if any personalized gray scale condition is not configured in the gray scale rule, the personalized gray scale condition is not configured by default, and the personalized gray scale condition is not screened for the user any more.
Further, when the current version information of a certain user completely matches the personalized gray scale conditions in the gray scale rule, the user is screened out and the next matching screening is carried out.
And S13, screening prospective users needing to carry out the gray release of the time from the users meeting the personalized gray conditions according to the historical version information.
In this step, after the user meeting the personalized gray scale condition is screened out, the historical version information of the user is extracted, and whether the user is an expected user needing to perform the gray scale release at this time is judged. Specifically, the gray scale rule further includes configuring a gray scale white list that needs to be grayed out this time, and a gray scale black list that does not need to be grayed out this time, and the configuration of the gray scale white list and the gray scale black list is mainly based on whether the user has been grayed out or has already performed graying out this time. And the historical version information records the version information upgraded by the user. Therefore, according to the historical version information, the gray black list and the gray white list are matched, and prospective users needing to perform the gray release are screened from the users meeting the personalized gray conditions.
And S14, pushing the version of the software to be released to the client of the expected user, and stopping the gray level release when the user version information of the expected user who finishes installing the software to be released is not matched with the gray level rule and the number of the expected users meets the number of expected upgrading persons.
In this step, after the prospective user is screened out, the software version to be released of the current gray scale release is pushed to the client of the prospective user, after the client of the prospective user who installs the software version to be released is cold started, the user version information of the prospective user after the current gray scale release is obtained again, and the user version information obtained again is matched with the gray scale rule again. When the user is upgraded to the software version to be released in advance, the newly acquired user version information cannot be successfully matched with the gray rule. Further, when the number of expected users meeting the requirement that the software version to be released is installed and the user version information obtained again does not match the gray scale rule at the moment meets the expected upgrading number in the pre-configured gray scale rule, stopping the gray scale release.
Based on the embodiment of the application, user version information of at least one user is firstly acquired according to a gray rule configured for a software version to be released, wherein the gray rule comprises the number of expected upgrading persons and an individualized gray condition, the user version information comprises current version information and historical version information, secondly, the current version information is matched with the gray rule to screen out users meeting the individualized gray condition, secondly, prospective users needing to carry out gray release this time are screened out from the users meeting the individualized gray condition according to the historical version information, finally, the software version to be released is pushed to a client of the prospective users, and the gray release this time is stopped when the user version information of the prospective users is not matched with the gray rule and the number of the prospective users meets the number of the expected upgrading persons. According to the embodiment of the application, the corresponding gray rule is configured for at least one gray release, the personalized gray condition and the expected upgrading number are configured in the gray rule, meanwhile, the expected user needing to participate in the gray release is accurately selected according to the user version information, and the user experience is improved.
Fig. 2 is a schematic diagram illustrating a specific flow of a method for gray scale publishing in embodiment 200 of the present application. Wherein, the detailed process of the specific flow is as follows:
s201, registering the version of the software to be released in the background of the gray scale release system.
Here, the gray scale distribution system mainly includes two parts, a front part and a back part. The background of the gray scale release system is mainly responsible for registering the software version to be released and configuring the gray scale rules, and the foreground part is mainly responsible for matching the gray scale rules and acquiring the user version information of at least one user. Fig. 3 is a schematic diagram of a registration page of a to-be-released software version provided in embodiment 300 of the present application. The registration of the version of the software to be released comprises filling in a project name, an internal version number, an external version number, a channel, a download link of an installation package, a client system version and an upgrade document to which the software to be released belongs.
And S202, configuring a gray rule in the background of the gray release system and enabling the gray release system to be online.
Here, the gradation rule is composed of a combination of a plurality of rules including an individualized gradation condition and the number of persons desired to be upgraded. The specific personalized gray scale conditions comprise information such as the equipment number of a user, the project number of current software, the version of a client system, the version of the current software, the market channel for software upgrading of the user, the city where the user is located, company codes, district codes, job types, the user number, the effective time and the like. Fig. 4 is a schematic diagram of a configuration page of the gray rule shown in embodiment 400 of the present application. Optionally, the gray rule mainly includes an individualized gray condition and a number of people desiring to be upgraded, and further includes a software version to be released, a gray rule matching priority, an effective time, a current version interval in which the upgrade can be performed, a gray white list, a gray black list, whether the upgrade is only performed on the gray white list, a client system version interval, and a current software version interval in which the forced upgrade is required. The personalized gray scale conditions are not limited to the cities, channels, companies and positions shown in the embodiment 400, and other filtering conditions may be added by adding an extension rule.
In addition, the configuration page of the gradation rules includes and is not limited to the respective rules listed in embodiment 400.
S203, the client of the user cold starts the request upgrading interface to obtain the user version information of the user.
The client adds an upgrade interface, requests the upgrade interface to acquire user version information of a user during cold start, and sends the current version information of the current user as an interface parameter to a foreground of the gray scale release system.
S204, the foreground of the gray scale issuing system searches whether information consistent with the latest acquired current version information and historical version information of at least one user is stored in the database.
Here, the foreground of the gradation distribution system first searches the database for whether or not information that is identical to the received user version information already exists each time the user version information is received. Optionally, when the foreground of the grayscale issuing system receives the user version information and there is no user version information in the database that is the same as the user version information, the foreground stores the user version information. And respectively storing the current version information and the historical version information which are included by the user version information, and numbering corresponding to the same equipment. As shown in fig. 5, an illustration of a table structure for storing current version information and historical version information is shown for the embodiment 500 of the present application. Wherein, the fields in the table structures of the two types of storage are consistent, but the index information of the two types of storage is different. First index information consisting of a device number (device _ id) and a project number (project _ id) is established for the current version information, and second index information consisting of a device number (device _ id), a project number (project _ id) and an intranet gray version (inner _ version) is established for the past version information. As shown in fig. 5, first index information 501 consisting of project _ id and device _ id is established for the stored current version information, and second index information 502 consisting of project _ id, device _ id, and inner _ version is established for the history version information.
Further, when the latest acquired user version information is received, first index information is also established for the latest acquired current version information, second index information is also established for the historical version information, and searching is carried out in the database through the first index information and the second index information.
And S205, when the information which is consistent with the latest acquired current version information and the latest acquired historical version information of at least one user is not searched, storing the latest acquired current version information and the latest acquired historical version information.
In this step, whether user version information identical to the latest acquired user version corresponding to the first index information and the second index information exists in the stored user version information is searched according to the first index information and the second index information, and the latest acquired user version information is stored when the user version information does not exist. Optionally, after the user version information is obtained, it is first determined whether there is a unique record in the stored two types of data that is the same as the unique record, that is, whether there is a record in which the project _ id and the device _ id are the same in the data in the latest state of a certain user, and whether there is a record in which the project _ id, the device _ id, and the inner _ version are the same in the data in all version change states of a certain user.
S206, when the current version information which is consistent with the current version information which is acquired by the user latest is searched, but the information which is consistent with the history version information which is acquired latest is not searched, the stored history version information is updated to the history version information which is acquired latest.
The current version information of the latest state of a certain user and the historical version information of all version change states are stored through the steps, and data support is provided for configuring the gray rule. Further, the historical version information includes all information that the user has performed the upgrade, so when the historical version information exists, the current version information exists by default.
And S207, the gray level release system foreground matches the acquired user version information with the gray level rule and judges whether the user is an expected user.
In this step, the device number, the item number, the client system version, the current software version and other user information in the current version information of at least one user are respectively matched with corresponding information in the gray level rule, and users meeting the personalized gray level condition are screened out. The types of the other user information may or may not be consistent with the types of the filtering conditions in the personalized gray scale conditions included in the current version information of the user. Further, according to the acquired historical version information, prospective users needing to perform the gray release are screened from the users meeting the personalized gray condition. Optionally, the gray black list and the gray white list of the current gray release are determined according to the history version information. The historical version information records the information of each upgrade of a certain user, and based on the historical version information, the users can be determined to have grayed and the upgrade process of the past time. Through the steps, the expected users are screened out. In addition, the process of matching defaults to either condition not being met, i.e., the matching fails.
And S208, when the client is the expected user, pushing the software version to be released to the client of the expected user.
Here, after the client is successfully installed, the client of the user cold starts to request the upgrade interface again, and obtains the user version information of the expected user who has installed the to-be-released software version. Further, matching the device number, the client system version, the current software version and the user information contained in the personalized gray scale condition in the current version information of the expected user with the corresponding information in the gray scale rule.
And S209, stopping the gray scale distribution when the user is not the expected user.
And S210, judging whether the number of the users who finish installing the software version to be released meets the number of expected upgrading persons.
And counting the number of the expected users who finish installing the software version to be released after each matching is finished, and stopping the gray scale release when the number meets the number of the expected upgrading people. And repeatedly executing the steps S203 to S210 until the expected user who installs the software to be released is not matched with the gray scale rule of the gray scale release at this time and the number of the expected users meets the number of expected upgrade persons.
Based on the above embodiment, the detailed procedure in which the matching of the gray rule in step S207 is as follows. Fig. 6 is a schematic diagram of a specific flow of performing gray rule matching according to embodiment 600 of the present application. Wherein, the detailed process of the specific process is as follows:
s601, matching client system version intervals.
Here, when the client version of the user belongs to the configured client system version interval, the matching is successful. If the configured client system version interval is from 5.1 to 9.0 of Android system (Android), matching is successful when the system version of the client of the user is in the client system version interval. And when the matching is unsuccessful, the gray level issue is not carried out.
And S602, the current software version range of the upgrade can be matched.
Here, when the current software version of the client of the user belongs to the configured current software version interval that can be upgraded, the matching is successful. If the configured current software version interval capable of being upgraded is 1.8.0(3) -Android-shell to 1.9.0(9) -Android-shell, when the current software version of the client of the user is in the interval, the matching is successful. And when the matching is unsuccessful, the gray level issue is not carried out.
And S603, matching the gray blacklists.
Here, the user who satisfies the personalized gray scale condition is matched with the gray scale blacklist, and the user who does not succeed in matching the gray scale blacklist does not perform the gray scale distribution this time.
And S604, matching the gray white list.
Here, the user that does not match the gray black list is matched with the gray white list, and the user that matches the gray white list is determined as the intended user.
And S605, judging whether the user upgrade of the gray white list is set.
In this step, when the user not matched with the gray black list is unsuccessfully matched with the gray white list, and when a condition that graying is performed only on the user successfully matched with the gray white list is set, the version of the software to be released is not pushed to the user unsuccessfully matched with the gray white list, that is, the current gray release is not performed.
Alternatively, when a condition that graying is performed only on a user whose matching of the grayscale white list is successful is not set, a user who does not belong to the grayscale white list is determined as the intended user.
And S606, whether the personalized gray scale conditions are matched or not.
Here, the current version information of the user is matched with the configured market channel for upgrade, the city where the user is expected to be, the company code, the district code, the job type, and other extended rules. And when any one of the personalized gray scale conditions is not matched, the gray scale issuing is not carried out on the user.
And S607, determining the user as the expected user.
And S608, judging whether the user is a forced graying user.
Here, when the current software version of the client of the user belongs to the configured current software version interval of the forced upgrade, the matching is successful. And if the configured current software version interval of the forced upgrade is 1.8.0(3) -Android-shell to 1.8.0(5) -Android-shell, when the current software version of the client of the user is in the interval, the matching is successful. And carrying out common upgrading when the matching is unsuccessful, namely determining whether to participate in the gray release by the user.
And S609, judging whether the software version is a forced graying software version.
And S610, performing forced upgrading on the expected user corresponding to the forced graying software version.
And S611, performing ordinary upgrading.
And S612, ending the graying.
The above steps are not in sequence, when any condition is not matched, the matching is failed, and the gray level issue is not performed.
The embodiment of the application realizes a gray scale publishing method based on the steps. Optionally, an upgrade interface is added at a client of a user, user version information of a current user is used as an interface parameter, a gray level publishing system configured by a server configures a gray level rule through the interface, and obtains current version information of the user, and if the current version information is the same as information of a software version to be published, it can be determined that the user has participated in the gray level publishing. And further, according to the gray rule for judging whether the current version information of the user matches with the configuration, and determining the user as the expected user when the matching is successful. And finally, tracking the version upgrading process of the user through the acquired historical version information of the user. Wherein the configuration gray rule can quantify the details of each gray release, such as when to start and end, which system is applicable, which users can be grayed. And matching can be used for delineating the prospective user according to the filled gray rule. The different users defined by the gray scale rules are different, such as: the users in some application markets can be limited by setting the download channels, the users in some cities can be limited by setting the cities, the repeated gray scales of some users can be avoided by setting the blacklist, and the like, so that the diversity and the expansibility are provided for the user range of the gray scales.
In addition, the server side acquires and stores historical version information of the users and records version change of each user every time, so that the user condition of each gray level can be accurately known, and certain users can be accurately limited not to be gray levels. Specifically, by the method for releasing the gray scale provided in the above embodiment, the user of the gray scale at each time is accurately controlled, and not only can the user be prevented from being continuously grayed, but also the expected user can be accurately grayed. The method can determine the users who have participated in the gray scale release, accurately circle the expected gray scale users, namely, some users can participate in the gray scale release, and simultaneously, track the version upgrading process of the users, so that the users who have participated in the gray scale release at a certain time are not hit in the gray scale release at the time.
Before starting, the version of the software to be released needs to be registered in the background of the gray scale system, and relevant information, such as internal and external version numbers, upgrading popup windows and downloading links, needs to be filled in. Then, the gray rule needs to be configured in the background, such as the current software version that can be upgraded, the number of people desiring to upgrade, and the personalized gray condition, etc. Further, the gray rule is brought online, and gray release is formally started. The client requests to upgrade the interface when in cold start, and transmits the current user version information and some attributes of the login user as interface parameters to the foreground of the system. The system foreground compares the gray level rules configured in the background with the transmission parameters of the current interface one by one, and stores the transmission parameter data of the time into the database. If the match is successful, then the current gray is hit, otherwise it is not hit. If the software version is hit, the interface of the system foreground returns the registered software version to be released, and then the client gives an upgrade popup to click by a user. When the user clicks and installs and restarts the software, the client will request the upgrade interface to report the current user version information, and the system foreground will match the gray rule again and record the transmission parameter data. Since the current greyscale version has been upgraded, the policy match must generally be unsuccessful, i.e. the interface will not register the software version to be released again. Then, when all users do not satisfy the configured gray rule, this time of gray distribution ends.
Furthermore, the gray scale release system realizes the accurate control of the gray scale range mainly by processing the reporting parameters of the upgrade interface and supporting the fine-grained gray scale strategy. Specifically, the reported parameters are user version information of the user, including current version information and historical version information. After the reporting parameters are obtained, it is first determined whether the same unique record exists in the two types of stored data, that is, whether records with the same project _ id and device _ id exist in the data in the latest state of a certain user, and whether records with the same project _ id, device _ id, and inner _ version exist in the data in all version change states of a certain user. Then, different processing is given to different judgment results: if the parameters do not exist, the reported parameters are stored into the two types of data in a newly increased mode; if the data in the latest state exists, comparing the version number (inner _ version), if the version number is the same, not processing, and if the version number is different, updating the recorded data to make the data consistent with the reported parameters; if the data in all the states exist, the data are not processed directly. This stores the data of the latest status and all version change status of a user to provide data support for the configuration of the gray rule.
The fine-grained gray rule mainly sets the specific number of people expected to be upgraded and some specific personalized gray conditions, such as a black-and-white list of upgradable APP versions and user ucid/deviceId. The number of the grey scale people is set by depending on the reporting parameters of the storage upgrading interface, the number of the users using the current grey scale version in the data in the latest state of a certain user needs to be inquired when the strategy is matched every time, the grey scale can be continued if the number of the users not reaching the expected upgrading number, and the grey scale is not stopped if the number of the users reaching the expected upgrading number. And the gray black and white list in a specific rule also needs to rely on the reported parameters of the storage upgrading interface, if a user who hits the gray scale before several times of filtering is needed, the user needs to inquire which users in the data under all version change states of a certain user use the version of the gray scale before, and then the user is set as the gray black list. If the data in the gray black list is too much, some specific rules can be set by analyzing the user data in the gray black list, for example, the former gray users are concentrated in some cities or installation channels, and the cities or installation channels are filtered when new gray rules are set. If only the last user is filtered, the method can also be realized by setting a scalable APP version interval. In summary, the number of gray people can accurately control the amount of users with actual gray, and some specific gray rules, such as personalized gray conditions, can accurately filter those users who do not want to be grayed.
Based on the same inventive concept, the embodiment 700 of the present application further provides an apparatus for gray scale distribution, wherein as shown in fig. 7, the apparatus includes:
the first obtaining module 71 is configured to obtain user version information of at least one user according to a gray rule configured for a to-be-released software version, where the gray rule includes a number of people desiring to upgrade and an individualized gray condition, and the user version information includes current version information and historical version information;
the first screening module 72 is used for matching the current version information with the gray rule to screen out the users meeting the personalized gray condition;
the second screening module 73 is configured to screen, according to the historical version information, an expected user who needs to perform the gray release of this time from users who meet the personalized gray condition;
and the pushing module 74 is configured to push the software version to be released to the client of the expected user, and stop the gray scale release when the user version information of the expected user does not match the gray scale rule and the number of the expected users meets the number of the expected upgrading persons.
In this embodiment, specific functions and interaction manners of the obtaining module 71, the first screening module 72, the second screening module 73, and the pushing module 74 may refer to the description of the embodiment corresponding to fig. 1, and are not described herein again.
Optionally, the first screening module 72 is further configured to:
and respectively matching the equipment number, the project number, the client system version, the current software version and other user information in the current version information of at least one user with corresponding information in the gray scale rule, and screening out the users meeting the personalized gray scale condition.
Optionally, the second screening module 73 comprises:
the first determining subunit is used for determining a gray black list and a gray white list of the gray release according to the historical version information of the user meeting the personalized gray condition;
the matching subunit is used for matching the user meeting the personalized gray scale condition with the gray scale blacklist and not pushing the version of the software to be released to the user matched with the gray scale blacklist;
and the second determining subunit is used for matching the user which does not match the gray black list with the gray white list and determining the user which matches the gray white list as the expected user.
Optionally, the apparatus further comprises:
the first determining module is used for not pushing the version of the software to be released to the user who is unsuccessfully matched with the gray white list when the user which is not matched with the gray black list is unsuccessfully matched with the gray white list and the condition that graying is carried out only on the user who is successfully matched with the gray white list is set;
and the second determining module is used for determining the user which does not belong to the gray white list as the expected user when the condition that only the user successfully matched with the gray white list is grayed is not set.
Optionally, the pushing module 74 comprises:
the judging subunit is used for judging whether the expected user is a user needing forced graying or not, and matching the current software version of the user needing forced graying with the software version of the forced graying when the user is the user needing forced graying;
the first pushing subunit is used for pushing the software version to be released to the forced graying user successfully matched with the software version to be released and forcibly upgrading the software version to be released;
and the second pushing subunit is used for pushing the software version to be released when the expected user is not the forced graying user or the current software version of the forced graying user is not matched with the forced graying software version.
Optionally, the apparatus further comprises:
the second acquisition module is used for acquiring the user version information of the expected user who finishes installing the software version to be released;
and the counting module is used for matching the equipment number, the client system version, the current software version and other user information in the current version information of the expected user who finishes installing the software version to be released with the corresponding information in the gray rule, and counting the number of the expected users who finish installing the software version to be released after each matching is finished.
Optionally, the apparatus further comprises:
a first storage module for storing the acquired user version information of at least one user,
the establishment module is used for establishing first index information consisting of a device number and an item number for the latest acquired current version information and establishing second index information consisting of the device number, the item number and an intranet gray version for historical version information when the user version information is acquired next time;
the second storage module is used for searching whether user version information which is the same as the latest acquired user version corresponding to the first index information and the second index information exists in the stored user version information or not according to the first index information and the second index information, and storing the latest acquired user version information when the user version information does not exist;
and the third storage module is used for comparing the historical version information corresponding to the second index information with the historical version information corresponding to the stored current version information when the stored current version information which is the same as the current version information corresponding to the first index information is searched, and updating the stored historical version information into the historical version information acquired this time when the historical version information is different from the stored historical version information.
As shown in fig. 8, another embodiment 800 of the present application further provides a terminal device, which includes a processor 80, wherein the processor 80 is configured to execute the steps of one of the gray scale publishing methods described above. As can also be seen from fig. 8, the terminal device provided by the above embodiment further includes a non-transitory computer readable storage medium 81, the non-transitory computer readable storage medium 81 stores thereon a computer program, and the computer program is executed by the processor 80 to perform the steps of the above method for gray scale distribution. In practice, the terminal device may be one or more computers, as long as the computer-readable medium and the processor are included.
In addition, the method steps described in the present application may be implemented by hardware, for example, logic gates, switches, Application Specific Integrated Circuits (ASICs), programmable logic controllers, embedded microcontrollers, and the like, in addition to the gray scale publishing program. Such hardware capable of implementing the methods described herein may also constitute the present application.
In particular, the storage medium can be a general-purpose storage medium, such as a removable disk, a hard disk, a FLASH, and the like, and when a computer program on the storage medium is executed, the computer program can execute the steps of the above-mentioned method for gray scale distribution. In practical applications, the computer readable medium may be included in the apparatus/device/system described in the above embodiments, or may exist alone without being assembled into the apparatus/device/system. The computer-readable storage medium carries one or more programs which, when executed, enable execution of the steps of a method of gray scale distribution as described above.
According to embodiments disclosed herein, the computer-readable storage medium may be a non-volatile computer-readable storage medium, which may include, for example and without limitation: a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing, without limiting the scope of the present disclosure. In the embodiments disclosed herein, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
The flowchart and block diagrams in the figures of the present application illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments disclosed herein. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
Those skilled in the art will appreciate that various combinations and/or combinations of features recited in the various embodiments and/or claims of the present disclosure can be made, even if such combinations or combinations are not explicitly recited in the present application. In particular, features described in various embodiments and/or in the claims of the present application may be combined and/or coupled in various ways, all of which fall within the scope of the present disclosure, without departing from the spirit and teachings of the present application.
Finally, it should be noted that: the above-mentioned embodiments are merely specific embodiments of the present application, which are used for illustrating the technical solutions of the present application and not for limiting the same, and the protection scope of the present application is not limited thereto, although the detailed description of the present application is made with reference to the foregoing embodiments, those skilled in the art should understand that: modifications or changes can be easily made to the technical solutions described in the foregoing embodiments by those skilled in the art within the technical scope of the present disclosure, or equivalents of some technical features of the technical solutions can be substituted; such modifications, changes or substitutions do not depart from the spirit and scope of the exemplary embodiments of the present application, and are intended to be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims (10)

1. A method of gray scale publishing, comprising:
acquiring user version information of at least one user according to a gray rule configured for a software version to be released, wherein the gray rule comprises the number of persons expected to be upgraded and an individualized gray condition, and the user version information comprises current version information and historical version information;
matching the current version information with the gray level rule, and screening out users meeting the personalized gray level condition;
screening out prospective users needing to carry out the gray release of the time from the users meeting the personalized gray conditions according to the historical version information;
and pushing the version of the software to be released to the client of the expected user, and stopping the gray scale release when the user version information of the expected user who installs the software to be released is not matched with the gray scale rule and the number of the expected users meets the number of the expected upgrading people.
2. The method of claim 1, wherein the step of matching the current version information with the gray rule to screen out users who meet the personalized gray condition comprises:
and respectively matching the equipment number, the project number, the client system version, the current software version and other user information in the current version information of the at least one user with corresponding information in the gray level rule, and screening out the users meeting the personalized gray level condition.
3. The method of claim 1, wherein the step of screening the prospective users who need to perform the gray release comprises:
determining a gray blacklist and a gray white list of the gray release according to the historical version information of the user meeting the personalized gray condition;
matching the user meeting the personalized gray scale condition with the gray scale blacklist, and not pushing the software version to be released to the user matched with the gray scale blacklist;
and matching the users which do not match with the gray black list with the gray white list, and determining the users which match with the gray white list as the expected users.
4. The method of claim 3, wherein between the step of determining the user matching the gray white list as the prospective user and the step of pushing the software version to be released to the client of the prospective user, the method further comprises:
when the user not matched with the gray black list is unsuccessfully matched with the gray white list, and when a condition that graying is carried out only on the user successfully matched with the gray white list is set, the software version to be released is not pushed to the user unsuccessfully matched with the gray white list;
and when the condition that graying is carried out only on the users successfully matched with the gray white list is not set, determining the users not belonging to the gray white list as the expected users.
5. The method according to claim 4, wherein the step of pushing the software version to be released to the client of the prospective user comprises:
judging whether the expected user is a user needing forced graying or not, and matching the current software version of the forced graying user with the forced graying software version when the expected user is the forced graying user;
pushing the version of the software to be released to the successfully matched user with the forced graying, and forcibly upgrading the version of the software to be released;
pushing the software version to be released when the expected user is not the forced graying user or the current software version of the forced graying user is not matched with the forced graying software version.
6. The method according to claim 2, wherein between the step of pushing the software version to be released to the client of the prospective user and the step of stopping the gray-scale release when the user version information of the prospective user does not match the gray-scale rule and the number of the prospective user meets the number of the expected number of upgrades, the method further comprises:
acquiring the user version information of the expected user who finishes installing the software version to be released;
matching the equipment number, the client system version, the current software version and other user information in the current version information of the expected user who finishes installing the software version to be released with corresponding information in the gray rule, and counting the number of the expected users who finish installing the software version to be released after at least one matching is finished.
7. The method of claim 2, wherein between the step of obtaining user version information of at least one user and the step of matching current version information to the gray scale rule, the method further comprises:
storing the acquired user version information of the at least one user,
when the user version information is obtained next time, establishing first index information composed of the equipment number and the project number for the latest obtained current version information, and establishing second index information composed of the equipment number, the project number and the intranet gray level version for the historical version information;
searching whether the user version information which is the same as the latest acquired user version corresponding to the first index information and the second index information exists in the stored user version information according to the first index information and the second index information, and storing the latest acquired user version information when the user version information does not exist;
when the stored current version information which is the same as the current version information corresponding to the first index information is searched, comparing historical version information corresponding to the second index information with the stored historical version information corresponding to the current version information, and updating the stored historical version information to be the historical version information acquired this time when the historical version information is different from the stored historical version information.
8. An apparatus for gray scale distribution, comprising:
the system comprises an acquisition module, a storage module and a release module, wherein the acquisition module is used for acquiring user version information of at least one user according to a gray rule configured for a software version to be released, the gray rule comprises the number of people expected to be upgraded and an individualized gray condition, and the user version information comprises current version information and historical version information;
the first screening module is used for matching the current version information with the gray rule to screen out the users meeting the personalized gray condition;
the second screening module is used for screening prospective users needing to perform the gray release of the time from the users meeting the personalized gray conditions according to the historical version information;
and the pushing module is used for pushing the version of the software to be released to the client of the expected user, and stopping the gray scale release when the user version information of the expected user who installs the software to be released is not matched with the gray scale rule and the number of the expected users meets the number of the expected upgrading people.
9. A non-transitory computer readable storage medium storing instructions that, when executed by a processor, cause the processor to perform the steps of a method of greyscale publication as claimed in any of claims 1 to 7.
10. A terminal device comprising a processor for performing the steps of a method of greyscale distribution according to any of claims 1 to 7.
CN201910795434.8A 2019-08-27 2019-08-27 Gray scale publishing method and device and storage medium Pending CN110597535A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910795434.8A CN110597535A (en) 2019-08-27 2019-08-27 Gray scale publishing method and device and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910795434.8A CN110597535A (en) 2019-08-27 2019-08-27 Gray scale publishing method and device and storage medium

Publications (1)

Publication Number Publication Date
CN110597535A true CN110597535A (en) 2019-12-20

Family

ID=68855769

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910795434.8A Pending CN110597535A (en) 2019-08-27 2019-08-27 Gray scale publishing method and device and storage medium

Country Status (1)

Country Link
CN (1) CN110597535A (en)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111581161A (en) * 2020-04-29 2020-08-25 上海中通吉网络技术有限公司 Mobile terminal application publishing method and system
CN111897571A (en) * 2020-08-04 2020-11-06 上海非码网络科技有限公司 Gray scale publishing method and system based on Spring Cloud
CN112433749A (en) * 2020-11-24 2021-03-02 中国建设银行股份有限公司 Application gray level publishing method and device, server and client
CN112445510A (en) * 2020-11-30 2021-03-05 中国人寿保险股份有限公司 Gray scale publishing method and related equipment for hot update file of client application function
CN112835617A (en) * 2021-03-02 2021-05-25 北京字节跳动网络技术有限公司 Gray scale publishing method, device, server and readable medium
CN112965742A (en) * 2021-02-10 2021-06-15 中国工商银行股份有限公司 Application version release method and system based on user map
CN113918234A (en) * 2021-09-16 2022-01-11 广州心娱网络科技有限公司 Gray strategy implementation method and system
CN116578335A (en) * 2023-07-13 2023-08-11 建信金融科技有限责任公司 Gray release system, method, equipment, medium and product

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018033094A1 (en) * 2016-08-17 2018-02-22 中兴通讯股份有限公司 Rich communication suite release platform, method and system for version update, and mobile terminal
CN108768875A (en) * 2018-05-31 2018-11-06 康键信息技术(深圳)有限公司 Gray scale dissemination method, device and the computer readable storage medium of application
CN109445811A (en) * 2018-09-07 2019-03-08 平安科技(深圳)有限公司 Gray scale dissemination method, device, computer equipment and computer storage medium
CN109471657A (en) * 2018-09-07 2019-03-15 平安科技(深圳)有限公司 Gray scale dissemination method, device, computer equipment and computer storage medium

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018033094A1 (en) * 2016-08-17 2018-02-22 中兴通讯股份有限公司 Rich communication suite release platform, method and system for version update, and mobile terminal
CN108768875A (en) * 2018-05-31 2018-11-06 康键信息技术(深圳)有限公司 Gray scale dissemination method, device and the computer readable storage medium of application
CN109445811A (en) * 2018-09-07 2019-03-08 平安科技(深圳)有限公司 Gray scale dissemination method, device, computer equipment and computer storage medium
CN109471657A (en) * 2018-09-07 2019-03-15 平安科技(深圳)有限公司 Gray scale dissemination method, device, computer equipment and computer storage medium

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111581161A (en) * 2020-04-29 2020-08-25 上海中通吉网络技术有限公司 Mobile terminal application publishing method and system
CN111897571A (en) * 2020-08-04 2020-11-06 上海非码网络科技有限公司 Gray scale publishing method and system based on Spring Cloud
CN112433749A (en) * 2020-11-24 2021-03-02 中国建设银行股份有限公司 Application gray level publishing method and device, server and client
CN112445510A (en) * 2020-11-30 2021-03-05 中国人寿保险股份有限公司 Gray scale publishing method and related equipment for hot update file of client application function
CN112965742A (en) * 2021-02-10 2021-06-15 中国工商银行股份有限公司 Application version release method and system based on user map
CN112835617A (en) * 2021-03-02 2021-05-25 北京字节跳动网络技术有限公司 Gray scale publishing method, device, server and readable medium
CN112835617B (en) * 2021-03-02 2024-04-02 北京字节跳动网络技术有限公司 Gray release method, device, server and readable medium
CN113918234A (en) * 2021-09-16 2022-01-11 广州心娱网络科技有限公司 Gray strategy implementation method and system
CN116578335A (en) * 2023-07-13 2023-08-11 建信金融科技有限责任公司 Gray release system, method, equipment, medium and product
CN116578335B (en) * 2023-07-13 2023-10-03 建信金融科技有限责任公司 Gray release system, method, equipment, medium and product

Similar Documents

Publication Publication Date Title
CN110597535A (en) Gray scale publishing method and device and storage medium
CN103309694A (en) Application program updating method and device
US20090222805A1 (en) Methods and systems for dynamically building a software appliance
KR20100113573A (en) Method and system for deploying non-backward compatible server versions in a client/server computing environment
CN108874426B (en) Application program updating method and device and readable storage medium
CN105955740B (en) software management method and device
CN102999349B (en) A kind of method for upgrading software
US10015279B2 (en) Application assignment reconciliation and license management
CN106550384A (en) base station batch upgrading method and device
CN110162361B (en) Intelligent prompting method and device based on user behavior, terminal and storage medium
CN112650523B (en) Data distribution method, device and equipment for gray level release
US10387135B2 (en) System and method for remotely flashing a wireless device
CN115934130A (en) ECU (electronic control Unit) upgrading method, device, equipment and medium
CN112667631B (en) Automatic editing method, device, equipment and storage medium for business field
CN101086703A (en) System and method for managing default value for computer program
CN109032641A (en) Application version update method and device
CN114356781A (en) Software function testing method and device
CN113641678A (en) Dynamic service configuration method and system based on multi-dimensional form
CN109298831B (en) Information storage method and device
CN110618826A (en) Method and device for updating application program and terminal equipment
CN110995793B (en) Information flow control element updating system, method and device
CN110058855A (en) A kind of interface of software and update method, device and the equipment of workflow
CN111488184B (en) Application program transmission method and device, server and readable storage medium
CN117453479A (en) Method and device for monitoring abnormal upgrading of vehicle
KR20090001720A (en) Apparatus and method for downloading affair files

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
RJ01 Rejection of invention patent application after publication

Application publication date: 20191220

RJ01 Rejection of invention patent application after publication